SC2Mapster

Hello,

I've come across a problem on my map and a quick google search is telling me something I don't want to hear - I would like to confirm that there is no way to get around this problem:

Does Starcraft 2 support ANY amount of N-Key Rollover with keyboard inputs, outside of the generic alt/shift/ctrl keys?

I am currently trying to make a 10-dimensional WASD movement system, which means that at least a few keys will be pressed (and their input should be detected) simultaneously for fluid movement. Currently, if I hold down one key and try to press another, the other key will override the first key I was holding down, which is NOT GOOD for a WASD style movement system.

How did other WASD systems overcome this problem? Did they just accept it and give up? I can't imagine a good WASD movement system without proper N-Key Rollover support...it would feel way too choppy.

The only pseudo-solution I've come up with so far is to enable the "continuous" flag under the command for each ability, but this is still no where near perfect as keys with cooldowns will not register multiple times if another key is being held down simultaneously, and the most recent key pressed will always have a greater influence than the previous keys being held down...

I would like proper N-Key Rollover support. Is this possible?

Alright so I figured out a way to do this without way-too-complicated maths and triggers (with a few hiccups I'll probably fix in the next few days):

1. I simply took a doodad that dynamically changes heights of units (in my case, I took the "Space Elevator Ramp" doodad model);

2. I attached it with an offset directly below my ship;

3. Increased the x/y scale of the model so that it extends across the entire map plane;

4. Set the opacity to 0 for the actor or model (I set it through actor messages)

I have some funny glitches happening right now...but I'm sure with a few SOps and a few tweaks to data and i'll be fine...

Lol.

Untitled Trigger 001
    Events
        Unit - Any Unit Height changes
    Local Variables
    Conditions
        (Triggering unit property change) > 0.025
    Actions
        Actor - Create a SOp Tilter Yoink actor in the scope (Actor scope for (Triggering unit)) with content parameters "HostSiteOperations", "Operations", null

Why does this not work?

I get the following error when this trigger is run:

USER: CActorSiteOpTilter[SOpTilterYoink] Cannot directly create a siteOp with the actor Create message, since a siteOp must exist within the context of a siteOp chain.  Culprit: SOpTilterYoink.

I'm assuming I'm just not using the action definition correctly, since the SOp itself works fine if I apply it via the data module. Could someone explain to me how "Create Actor" content parameters should be used?

Or if a SOp truly can't be applied via the "Create Actor" message like the error message implies, then how would I go about adding a SOp via triggers?

That sounds like an interesting idea. I haven't really dabbled much with the UI portion of the editor yet though, so I'm not really sure where to get these UI's as models so I can attach them (using triggers presumably). I can't really find much in Data that pertains to the UI we see on the screen, and the UI Editor doesn't seem to do anything interesting with them (other than show what they look like...).

Hello,

I would like to know if this is possible - I have a map where each player controls a given ship. When issuing orders to move to this ship (or any order for that matter), I want the graphic waypoint line (and pointer) to always be on the same plane, or height, of the issuing unit. Is it possible to adjust the terrain dynamically (so that it always matches this unit's height) so that this is always the case?

As you can see from the example above, whenever orders are issued for the unit, it takes the point where you clicked relative to the base of the map, not the height of the unit being issued. This leads to wonky unit orders when rotating the camera around, since where you click might not be where you actually move (relative to your height).

I'd just like to update that I've found the cause of this issue. I was not looking in the right place. Thanks to this Thread I was able to figure out that the camera, when set to "Mouse Rotation" via triggers, actually interacts with the UI of all things! This causes you to get these weird clipping issues at particular angles relative to your screen (I thought it was relative to each model).

Now, the only problem I have is that I want to retain my UI while not having this issue. Any ideas?

This works when you're set to follow a unit. I had been trying to find a fix for this weird camera behavior and this is a solution. That being said, I wish I could keep my UI and not have this problem...

Also "Game UI Data -> Default SC2 UI Settings -> Field: UI - World Console Bottom" no longer exists in the Game UI Data catalog. Don't know if it was removed over the past 4 years...

Quote from DrSuperEvil: Go

Also the validator you are using does not take into account modifications to height values. It only compares base field values.

Aww crap, I guess that explains it...my fighters are dynamically changing their height every time they engage a target, so clearly validating their base value won't work...*sigh*

I suppose I'll have to go about it the very very long way and have behaviour stacks added each time a unit goes up or down 1 height and work my way from there with behaviour validators...

I don't suppose there's a validator that DOESN'T involve adding a crap ton of behaviours that would fit the bill nicely here?

Quote from DrSuperEvil: Go

Is the combine OR or AND logic? Also what do you want to achieve with a validator like this? Have you checked you are setting the Other Unit field correctly?

It was "And". The intention initially was just to test if I could have my Battlecruiser shoot at targets with its weapon at all targets 1 height above, same height and 1 height below the Battlecruiser, and ignoring any targets that are 2+ height difference or more away relative to the Battlecruiser.

If that HAD worked, I would'v made a bunch of combine validators to check the same things for greater heights (ex. 2-4 range above and below the BC, 4-6 range, etc), but with additional "Location Range" validators to tell the weapon to shoot them at lower ranges only to compensate for the height difference (since range + height = hypotenuse, and the hypotenuse is always longer than its two adjacent sides).

And lastly, I'm not quite sure what the "Other Unit" field does, I was under the impression that it simply told the validator to compare the "Unit" field to itself.

Alright so I fixed the first issue without too much trouble; all I did was increase the base height of every unit in my game by several units. This prevents the camera from clipping to the floor of the map when rotating above/below the target.

The only issue I have now (and it's not really half as bad, but still a minor annoyance) is the clipping with the Battlecruiser itself. If I rotate it and look around it's wings, it seems to clip in/out a little bit to adjust with the model itself. I don't see anything in Camera data that could fix this, and nothing in the Model data's fields seems to indicate an interaction with the camera itself.

As for triggers, my camera couldn't be simpler. It's just "Camera - Turn camera mouse rotation on for player _". That's it. The only other thing set up for my camera is which camera in data is the default camera (of which none fix this issue anyway).

Figured out the answer to this question. It seems like nobody's ever stated that there is a field found within the "Cameras" tab in the Data editor called "Zoom Levels +". From there, open it up and find "Height Offset". Adjust the value per zoom levels as required. Make sure to have Height Displacement turned off (via triggers) and height smoothing as required. This will make your camera have a static height (NOT DISTANCE, ffs) relative to the ground it's on. If you only want one height for the player to see from, just make one zoom level (or make many, with the same "Height Offset").

Cheers (5 years later),

Hello again,

I'm currently trying to make a "pseudo" 3D weapon distance acquisition array using validators.

I am using the "Unit Compare Field" as a means to evaluate whether a target is too high or too low from the casting unit for a weapon to fire at a given range.

However, the validator is not behaving as expected. I have a Combine Validator that tells the weapon effect that a target should (via Unit Compare Field):

A-have a height less than or equal to 1 relative to the caster unit

B-have a height greater than or equal to -1 relative to the caster unit

The only targets that are acquirable through this means are targets at exactly the same height as the caster unit (so in this case other Battlecruisers). It doesn't matter if I change the numbers to 3 or 10, the weapons will only target other targets on the exact same plane.

Why does this not work?

I don't know the answer to the first question, as I'm wondering the same thing.

But for your second question - the easiest solution is to modify the "Lateral Acceleration" field in Units. If you want it to turn on a (very large) dime give it a number very close to 0, if you want it to turn in smaller circles, increase the lateral acceleration further.

EDIT - After toying around, I was able to do this fairly reliably by creating a dummy weapon (strafe) which will make your unit behave the way you want it to, while adding a second weapon (legacy) to your unit with an arc of 0 (or whatever you want it to be) with your actual weapon effect and stats. Play around with Options+ and Legacy Options+ for things to work out the way you want them to.

See the video below for a brief synopsis of the problem:

I'm trying to create a SC2 themed TPS space combat simulator and am in the early phases of doing so. I've hit a roadblock early though, as I can't even seem to get my camera to act properly. As you can see in the video above, the camera rotates fine around the target, except at very specific angles when setting the camera near the horizon (180 degrees and 000 degrees). The camera also seems to have a tendency to "clip" to the Battlecruiser if there's a wing or flap in the way, although it's minor.

I get the impression that the camera is subject to some sort of clipping with respect to both the unit it follows as well as the terrain "base" itself. I'm wondering how I can go about fixing this. I've seen other TPS not have this issue so clearly I'm doing something wrong. The few maps that I've been able to analyze that have the mechanics I'm looking for haven't really given me a clue as to where I should be looking.

I have already trying to modify essentially every parameter under "Cameras" in data (I created a custom camera and applied it via the "Set Camera Data" trigger but none of the parameters seem to fix this particular issue. Any ideas?

As a side question - does anyone know the simplest way to implement a 3D weapons system into the game (preferably through data, although I'm going to assume it's going to involve complex arrays and a lot of variables in triggers...). AKA weapons that track the range of a target not only in the x, y coordinate system but also take into account the relative height of the target to you? (imagine a range SPHERE instead of a circle)

This project is so much better than what I've been working on. I do hope you eventually get to finish this map; it reminds me a lot of dreadnought/fractured space but with a sc2 feel and without the p2w aspect.

I do have two questions, though:

1. You say your turrets track target with pitch. Was this done through complex use of editor, or did you use Star Tools "Turret Behaviour" feature on your custom models to make them track targets in 3 dimensions?

2. You say weapons fire in 3 dimensions. One issue I've been having with my map is that range is 2D (x, y coordinate system). There's no way to make a "spherical" zone of influence for weapons or abilities via the editor as far as I'm concerned (or take into account z axis when calculating distance from target). How did you go about circumventing this?

Sorry for the necro, but seeing as not a single one of the threads mentioning this problem have any solution, here's the best I could find:

Through Triggers: -In Actions - Show/Hide Environment: choose "hide", and select "terrain"

Through Data: -Go to Terrain Type in Data: find your terrain, scroll down to "Fog of War Plane", choose "disabled"

Downside with both of these methods is that you won't have a fog of war anymore. Visibility is still restricted by your sight radius and whatnot, you just won't have a visual indicator to tell you what that radius is. Units will just suddenly appear in front of you...