SC2Mapster

I realize this is a necro, but just to answer the question incase others had the same...

Hero Attack uses both triggers and data. The tower stays neutral, but applies an effect and behavior. The effect finds the base main unit and then applies a modify unit effect which mimics that team's color (keeping the tower as neutral). Then the effect also applies a behavior which shares the unit's vision with the team. There are more methods to the madness, but that's the gist.

For future reference. anyone curious to know the mechanic in an arcade game would probably be better off posting here and on the forums for that particular arcade game. (Google the mod name to see if it turns up any results)

@Stormahawk: Go Item's dont have hotkeys (unless you're buying it from a shop). You can set the <shortcut val=""/> to a static hotkey for the inventory slot, but thats it. There's very little you can do in the way of customization currently. You can alter the Game UI Settings in the data editor, scroll to hotkey info, and assign one of the empty values to the shortcut. Ex. Shortcut val="@CommandButton00"/>, however this is fickle. The command must be a "target" type command (note: not "self"). Unfortunately there arent any empty target command slots for hotkey customization.

in regards to the "N1", thats a personal game setting. Turn off the command button hotkey helper in your game options. (It also shows the M/A/S/H above the normal command card). If you want it repositioned correctly again above the inventory command card, you'll have to use some UI finess. I'd have to see the current code to know whats going on, but more than likely you repositioned a button or image and not the actual container.

For an image in the inventory container slot: (make sure the ContainerPanel is correct. It varies depending on which "slot" holds your container in the 6 slot normal inventory row. 00 is farthest left, 05 is farthest right.)

<Frame type='CommandButton' name='GameUI/UIContainer/ConsoleUIContainer/InventoryPanel/ContainerPanel01/Slot00' file='GameUI'>
<Frame type="Image">
<Texture val="Path/To/Asset/Image.dds"/>
<Width val="80"/>
<Height val="80"/>
</Frame>
</Frame>

@purakushi: Go Still experimenting, but for now...

Leave pushable off. Set all unit push priority equal. Add a "push" behavior which has a periodic effect that runs every 0.5s -> run persistent that searches 60 times with a duration of 0.01 (not sure if this will cause much lag, but it produces a smooth result. Depends on the number of units in your map I suppose). The search effect searches for player ground units and applies a set effect that applies a "PUSH" behavior and then applies a force effect with mass and amount set to 1. The Push behavior has the "unstoppable" flag checked.

You can have multiple behaviors in this manner that all run the same periodic effect. Ex: Push 10, 20, 30 etc.

Then in the set effect youd simply validate the behaviors to ensure a unit is pushable Ex: Caster Has Push 10 && Target does not have Push 20 && Target does not have push 30.

Or, If you want to use triggers to apply behavior stacks, you can use one validator.

Validator: Unit compare behavior count Behavior: "Push Priority" Compare: Greater than (or equal to) Value: 0 Value: Other Unit+: Target Value: Unit+: Caster

So, In summary

Behavior: Push Behavior - Periodic Search every 0.5s

Effect: Push Persistent - Period Duration: 0.01 - Periods: 60 - Effect: Push Search

Effect: Push Search - Filter: Required: Ground; Excluded: Enemy, Ally, Neutral, etc etc - Radius: 0.1 - Effect: Push Set - Extend & offset by unit radius, center at launch

Effect: Push Set - Apply Push (Behavior) - Apply Push (Force) - Validator: (Put validators for what units can or cannot be pushed here.)

Effect: Apply Push (Behavior) - Apply "Being Pushed"

Behavior: Being Pushed - Flags: Unstoppable

Effect: Apply Push (Force) - Amount: 1 - Mass: 1

Oh, and for same unit types, thats easy. Validator: Unit Type Find: Disabled Other Unit+: Target Unit+: Caster Leave value blank. This will make the unit type validator check if the target unit type is equal to the casters unit type. If not, itll preform the push.

A little more information: Using this method is great for controlling the pushable aspect for team based games. One thing to mention though. Don't forget that by setting the pathing priority to everything equally, you are turning off pushable for EVERYONE. In a standard team game, you'll probably want to do something like

DO NOT set the pushable setting for two enemies

DO set pushable for a player towards himself (Ex: Turn Player 4 pushable On towards Player 4) DO set pushable between allies on a team (Ex. Turn Player Ally6 pushable On towards Player 4 && Turn Player 4 Pushable On towards Ally6)

If using the pick each player in (allies of (player X)) function, don't forget this excludes player X, so youll want to define it outside the loop.

Unfortunately, it appears that you cannot move container positioning as its appears to be hard-coded/locked into place to the top/right of the inventory bar. There are faux methods to achieving what you want, but all solutions so far are less-than-ideal.

The render priority wont help. In your scenario, the inventory buttons are being moved outside of the inventory "panel". There are solutions to this though. 1 is to increase the height of the inventory panel containing the buttons. You might also be able to set the <AcceptsMouse val="true"/> to false for the container, and then applying the same command as true to each individual button.

Quote from bulletbutter: Go

Each unit has an attribute (light, mechanical, biological, massive, etc) that helps dictate how much damage is dealt to it by various weapon types. Is there a way to add custom attribute types? Or at least a clever way to fake it?

It's possible but complicated. Probably the easiest route is to use a buff behavior with a combat damage response of 1 that reduces the damage fraction by X amount and a required effect or excluded effect array set to the possible effects. Of course, this isnt very handy if you have a ton of damage effects, but I guess you'd have to set the "attribute modifier" for the weapon damage anyway, so I guess the work involved is the same.

Ex:
"Super Light Armored Behavior"
Combat Damage Response
- Chance: 1
- Modify Fraction: 1.4
Required Effects: Weapon 1 Damage, Weapon 2 Damage, Weapon 3 Damage, etc etc etc

"Titanium Armor Behavior"
Combat Damage Response
- Chance: 1
- Modify Fraction: 0.3
Required Effects: Weapon 4 Damage, Weapon 5 Damage, Weapon 6 Damage, etc etc etc

@DrSuperEvil: Go

Prevent Kill is pretty self explanitory. It prevents the actor from dying. Normally the death execution will kill the unit and the actor. With that flag checked, the unit will live. Unfortunately, the hitbox (which makes it "clickable") gets disassociated in the process. Hence the reason we destroy the actor at the end of the execution, and tell the primary unit actor to recreate it.

This is for my own referance as well as for the benefit of the community. I'm not sure if these functions are new in 1.5 or if theyre preexisting, but either way, they work. Here's how to

Play an actor's death animation without the unit dying

Typically for feign death type spells, you want to play the actor's death animation. However, normally you cant as its a separate model. We're going to be building some actor events that lets us play the animation. I'm going to assume you know the basics of creating a spell. Lets get started with the actors.

Create a new actor event: type: Macro

Name it something like "Feign Death"

Under actor events, add a new event

Effect.YourEffectName.Start - PrepareDeathSequence (Note: In this dropdown list, this is named "Prepare").

This sets up our death animation. Select the death type you want, and select "NoKill". This keeps our actor from dying. We'll want to control this manually.

Add a new event

"Prepare"DeathSequence - "Execute"DeathSequence (This forces the model to switch, and the death animation to play as listed in the unit actor's death events.)

"Execute"DeathSequence Destroy

Thats it for the macro. Now go to your unit.

Find your unit actor. Add a new event

"Execute"DeathSequence Create YourUnit'sActorHere

Note, youll have to switch the list from "custom" to "actor" here and specifically define which actor you want to create This is because we destroy our actor in the death event macro. We destroy the actor because otherwise the hitbox will disappear and you'll be unable to click your unit afterward.

Find "Event Macros" in the unit's list, and add your feign death macro and your done. Now whenever your unit executes the effect, it'll play its death animation then switch back when done.

I know this is a bit dated, but here's some more information on dialog actors & unit models:

- dialog unit models use the "set dialog unit link" action.
- A portrait is stationary, which a unit model link will spin.
- "Set Dialog Camera" works for models or portraits.

You have a variety of options for the camera. All cameras appear to be internal (ie cant be found/modified?)

• Camera Options:*
  
  • Star2Camera[x][y], where x = Lower, Higher, or Mid and y = the zoom out level.
    Example: Star2CameraMid01 zooms the camera very close to the model, based on the unit's center.
    Star2CameraHigher08 zooms the camera far away from the model, and moves the camera up by approximately unit height x2 (making the unit appear lower)
    Star2CameraLower03 zooms the camera out a little, and moves the camera down, making the model appear higher. Again, based on the unit's height.

Tested and confirmed y values are 01-10

Setting a camera works instantly. If you use an actor messge to swap a model/actor of a unit model or portrait dialog, you must wait 2seconds before you can send another actor event. (sending actor events to dialogs is VERY slow, so its best to set as much as you can in data or cameras)

I know this thread is getting a bit dated, but I just wanted to clarify on the "issue".

Whenever a unit is trained via the trained ability, it is ALWAYS placed on the ground outside the shop before the game internally moves it into the casters inventory. The reason a "structure" would need a movement speed would be so it could nudge close enough to "grab" the item.

Purchasing an item via the train ability is the same thing as creating a unit at a shop, moving it instantly to the feet of the caster, then ordering the caster unit to pick up the item. The only difference internally is the game registers the normal train ability as a "Any unit -buys- any item" event.

@Morato7: Go

Does your burrowed roach have a weapon?

@Rice87: Go This wouldnt be possible via data only (There is no data command to "follow mouse" as far as Im aware).

For a top-down type game, youd probably have to use a trigger timer and a "cursor" unit. Every X seconds, check the position of player's mouse and move cursor unit to position of mouse. Then if mouse-left-click, order "actual unit" to fire at "cursor unit". Your weapon should only be able to target the cursor unit, and you would probably need a projectile weapon with a periodic persistent search (i.e. every 0.1s check in a radius of 0.01 for enemies any apply X damage (dont forget to use a marker so damage isnt repeatedly applied).

@tyfenn: Go You'll need to make sure the first set effect has a unit type validator that checks the unit type of the target, not the caster.

Sets effects are very basic. They simply allow you to group several effects together, and in the set you can run validators on the entire group of effects to determine whether they are run or not.

Actually, this is rather easy.
Add the roach weapon to the burrowed version

Create two new issue order effects
"Order Unburrow"
Ability Command: Unburrow
- Check Preempt

"Order Burrow"
Ability Command: Burrow
- Check preempt

Add a few validators
"Is Burrowed" (Unit Type check)
- Caster
- Flag: Buried Required

"Not Burrowed" (Unit type check)
- Caster
- Flag: Buried Excluded

"Not Attacking and not Burrowed" (Combine)
- Caster Not Attacking
- Not Burrowed
- type: AND

"Attacking and Burrowed"
- Caster Is Attacking
- Is Burrowed
- type: AND

Create a new switch effect:
"Roach Switch"
Case 0 - Order Unburrow Validator: Attacking and Burrowed
Default - Order Burrow: Not Attacking and Not Burrowed

Create a new behavior - "Roach Autoburrow"
Set the Periodic effect to "Roach Switch"
Set the period durations to something low like 0.1

Add the behavior to the roach.
done.

This might need a little tweaking, but these are the basic steps. I use the same thing in a reworked version of spidermines (Although mine are based on Has Orders, to include move commands).

Note: I've tried all the combinations for auto-burrow (i.e. automatic flag, autocast, etc etc. None of it gives the desired result of Unburrow when attacking)

If you want it to unburrow when moving, the burrowed version MUST have a move speed, even if it is something like 0.117

If you just want it to unburrow when attacking (and not reburrow when done), you can skip a few steps.

I know the "Hard LImit" was 255 and that some upgrades dont seem to apply after 125, but I didnt know how globally it applied.

@Kueken531: GoDon't forget, theres a new option to "Set Catalog Field as Integer" or something of the sorts. That threw me off for weeks.

@Yaksmanofage: GoYour call. Upgrades, however, have a soft (125ish) and hard (255) cap. The only way to change that is a reset trigger.