SC2Mapster

Thank you for responding - is there any chance I might trouble you for a more detailed example?

Let's say I have UnitChassis for the main unit actor, UnitTurret for a turret on it, and UnitTurretModel for the turret's actor, which needs to be playing its move animation. What would I need to do to get this to work properly?

EDIT: Nevermind, thank you Kueken, I've figured it out.

For anyone who follows:

Set an AnimPlay message to trigger on the UnitChassis (UnitMovementWalk [Walk]) when it starts its walk cycle. Set the target field to UnitTurretModel.

So, I searched several, several times hoping to find the answer to this, but I seem to be at a loss.

I have an actor attached to another actor via the data editor for use as a turret. I've managed to get it to work just fine for targeting other things with its turret and animating on attack thanks to a couple tutorials on here, but somehow I can't seem to figure out how to tell it to play its move animation when the parent actor is moving.

Can someone help me with this? I tried the Move event in Events+ but it doesn't seem to trigger when moving as the Attack, also tried UnitMovementUpdate with a variety of sub field options. I'm still very new to the Data Editor, so it's quite possible I've missed something obvious. I greatly appreciate any assistance offered.

Okay, seriously guys? We get a "YAY NEW MODELS THREAD" and half of you are whining that you've been given new toys but they don't match the color of your old toys.

Reskin the bloody things or something, don't complain because you've been given new assets to work with.

Also: YAY NEW MODELS!

@vadremix: Go

Another really good reason to use local variables is to keep yourself sane when doing complex trigger work w/ math functions so you can reference a derived value multiple times rather than re-calculating it every time you have an action that requires the same derived value. Dynamic/scalable UI creation is a good example of this, since you will often reference the same offset or value multiple times.

Also, if creating reusable frameworks, or systems, they allow you to leave pre-defined values easily changed at the top and reference throughout the trigger without making you or whoever else uses your system go through action-by-action and redefine the same value over and over.

Are you only trying to change the team color of the unit, or do they actually need to go to the players designated in the trigger? Either way, try using "Set Unit Color"

Defensive and Passive are pretty self-explanatory - Defensive will only attack if being attacked, Passive will run away when attacked. None, though I haven't tested it, I would imagine will not only not attack but will likely sit there and take it, too. Why not simply test it?

Very nice. I think your best bet for rotation is unfortunately going to be actual pre-animation of the model, but best of luck finding another solution!

I think it would be a much better idea to build a secondary trigger that checks for the unit order events you're looking for and flags the unit by either saving to a table or assigning the equivalent of a custom value from WC3 to the unit that the main trigger can check for on its periodic event.

Do you really need to check for movement if the unit is performing a command you know will move it? If so the other thing you could do is add in a secondary function on your trigger that memorizes the X, Y position of the unit being evaluated and then compares it after a non-game halting wait to the new position of the unit.

I haven't actually tried this, but here's a thought:

Comparison
    Value 1: Unit Order
        Unit: Triggering Unit
        Index: 0
    Operator: ==
    Value 2: Order Targeting Point
        Ability Command:  Move
        Target Point: Target Point For Order
            Order: Unit Order
                Unit: Triggering Unit
                Index: 0

Build an "Or" list for all orders you want to filter for.

Two things are at work here for your first question

First off, the "special texture" you're seeing on the border, is actually the "Decal" doodad, variation 4. You could achieve a similar effect if you wanted a physical border with variation 1 of the "Ground Props" doodad. It's fantastic for things like curbs.

The other "special texture" is variation 22 of the "Decal" doodad again. Other variations include different line types, warning labels, arrows, etc. It's obviously good for building roads (something I'm working with quite a bit, heh) and other such th ings. The yellow version is just a recolored version. You may also want to try messing with the HDR multiplier to darken it slightly.

Secondly, I've not figured out a good way to rotate or offset textures for terrain, but a great alternative solution for your ramp problem would be to use the "Terran Tarmac" doodad, which acts a lot like a splat from WC3. It applies itself to the ground, in other words. Try playing with that and you'll see what I mean. Independent scaling of x and y will make it a breeze to ensure it fits your ramp properly, too.

It's much easier than you think - under the Unit properties for the unit, find "(None) Default Acquire Level". You want to set this to Passive or Defensive, depending on whether or not you'd like the unit to defend itself under fire. Most units are, understandably, set to Offensive by default.