Consider making the leader have a hangar ability and the followers hangar units, similar to a carrier's interceptors. It should be possible to make it so any damage done to the leader unit is redirected to one of the followers, and the followers will automatically follow the leader and attack his target. You can choose whether or not you want the followers to be selectable and commandable as individuals, as well.
A stack overflow almost always indicates infinite recursion. Like s3rius said the code you posted is unreadable and I'm not going to bother deciphering it but at some point in there you have an infinite loop where two functions are calling each other.
Yeah it's a quirk of hangar units, they ignore their own height settings and use whatever the host's height is.
There's an easy fix though, in the interceptor's actor under host site ops add "SOpHigherBy5" to the operations field. That'll make them REALLY high so you probably want to dupe the SOpHigherBy5 actor and change the offset to +3.75 which is the standard height for air units.
I'd say it's a bug since the same fields can be modified for an Effect-type ability - such as cooldown.
Another bug: Augment-type abilities don't trigger "Unit Uses Ability" events when they are autocast. They DO trigger them when manually cast.
It seems augments are only implemented to the extent needed for the Zealot's Charge ability and severely limited beyond that.
edit: I just found a really neat workaround though. If you ever want to trigger an event, but no trigger is appropriate, you can create a dummy effect that does 0 damage to whatever unit you want to trigger for the event for, then create a "Unit Is Damaged" event and set the Effect parameter to your dummy event. With this technique you can create trigger hooks for ANYTHING.
This appears to be a bug in the game engine. Values for Augment-type abilities can't be modified via upgrades or triggers. At first I thought it was just a limitation of the data editor but even when hand-writing the XML it isn't possible to change them. (I verified I was using the right path by putting it in a tooltip, which reads the correct value, but the upgrade will not write a value. I did the same test with triggers, reading the value from the catalog and printing it, writing a new value to the same path, and reading and printing it again; this just causes a trigger error on the write line.)
Anyway, just a heads up in case you were planning on making an augment ability.
It's in alpha but it's pretty complex so you can see some of the things I did to try and keep it organized, particularly judicious use of the (Editor Prefix) field, and organizing triggers into folders/splitting them into actions and functions for reusability and to prevent any one trigger from being too large. Basic programming stuff. Anyway, I am not going to hold it up as a GREAT EXAMPLE OF WHAT TO DO, you can judge for yourself, but it's not locked for editing so feel free to open it up.
Make a behavior, in the Damage Response field set "Chance" to 1 (or whatever % chance you want the ability to trigger on attack), set Location to Attacker, and then under "Handled" you can trigger any effect you want. If you just want a damage bonus and mana drain then you can add the damage bonus directly to the Damage Response area, and have it trigger a Modify Unit effect that lowers the caster's mana. You'll also want to add a validator to the behavior that disables it when the unit is out of mana.
@RileyStarcraft: Go: in the Launch Site Ops section of Actor \ Target that you were talking about, there's only a line titled "Operations" with "SOpAttachHarness" written in it. The other two parameters are Hold Position and Hold Rotation, which don't seem like they would affect it. What exactly would I put in "Operations" to change the z offset?
There's a built-in actor called "SOpHigherBy5" that will raise the height by 5 units. That's REALLY high though so you might want to duplicate that actor, call it SOpHigherBy2, and change the Z value in the Offset field to 2.0.
Then in your Launch Site Ops field, in the Operations line after "SOpAttachHarnass" add "SOpHigherBy2". That will raise the height by 2 units. You can experiment to find out the exact height you need.
I tried what you said to make the entire tower's model turn. As far as I can see, it doesn't work. Am I missing something?
What model are you trying to use? I should have specified this will only work if you're using a model that can rotate. For example making a "Hydra Tower".
If you're trying to have a building rotate then sorry I haven't been able to find out how to do that. But it would look goofy as hell anyways.
0
Hi everyone. Here's a quick tutorial on a technique for creating custom trigger hooks in your data editor objects.
http://rileystarcraft.blogspot.com/2010/06/tutorial-create-custom-trigger-hooks.html
This allows you to create triggers that respond to things like behaviors being turned on/off/refreshed or arbitrary effects occuring. Enjoy!
0
If you're okay with using placeholders for the time being it's basically a sure thing that the release version of the game will have door units.
0
Consider making the leader have a hangar ability and the followers hangar units, similar to a carrier's interceptors. It should be possible to make it so any damage done to the leader unit is redirected to one of the followers, and the followers will automatically follow the leader and attack his target. You can choose whether or not you want the followers to be selectable and commandable as individuals, as well.
0
A stack overflow almost always indicates infinite recursion. Like s3rius said the code you posted is unreadable and I'm not going to bother deciphering it but at some point in there you have an infinite loop where two functions are calling each other.
0
Search for "Carry" in the models list. Those are pretty handy especially since you can use tinting to recolor them.
0
@thunderclaw83: Go
http://rileystarcraft.blogspot.com/2010/05/tutorial-how-to-duplicate-unit-in-data.html
0
Yeah it's a quirk of hangar units, they ignore their own height settings and use whatever the host's height is.
There's an easy fix though, in the interceptor's actor under host site ops add "SOpHigherBy5" to the operations field. That'll make them REALLY high so you probably want to dupe the SOpHigherBy5 actor and change the offset to +3.75 which is the standard height for air units.
0
@Xatham: Go
Why don't you just use Owner of Unit to get the player who controls a hero?
0
@s3rius: Go
I'd say it's a bug since the same fields can be modified for an Effect-type ability - such as cooldown.
Another bug: Augment-type abilities don't trigger "Unit Uses Ability" events when they are autocast. They DO trigger them when manually cast.
It seems augments are only implemented to the extent needed for the Zealot's Charge ability and severely limited beyond that.
edit: I just found a really neat workaround though. If you ever want to trigger an event, but no trigger is appropriate, you can create a dummy effect that does 0 damage to whatever unit you want to trigger for the event for, then create a "Unit Is Damaged" event and set the Effect parameter to your dummy event. With this technique you can create trigger hooks for ANYTHING.
0
This appears to be a bug in the game engine. Values for Augment-type abilities can't be modified via upgrades or triggers. At first I thought it was just a limitation of the data editor but even when hand-writing the XML it isn't possible to change them. (I verified I was using the right path by putting it in a tooltip, which reads the correct value, but the upgrade will not write a value. I did the same test with triggers, reading the value from the catalog and printing it, writing a new value to the same path, and reading and printing it again; this just causes a trigger error on the write line.)
Anyway, just a heads up in case you were planning on making an augment ability.
0
Feel free to open up and tinker around with my TD map:
http://www.sc2mapster.com/maps/rileys-tower-defense/
It's in alpha but it's pretty complex so you can see some of the things I did to try and keep it organized, particularly judicious use of the (Editor Prefix) field, and organizing triggers into folders/splitting them into actions and functions for reusability and to prevent any one trigger from being too large. Basic programming stuff. Anyway, I am not going to hold it up as a GREAT EXAMPLE OF WHAT TO DO, you can judge for yourself, but it's not locked for editing so feel free to open it up.
0
@OneTwoSC: Go
Make a behavior, in the Damage Response field set "Chance" to 1 (or whatever % chance you want the ability to trigger on attack), set Location to Attacker, and then under "Handled" you can trigger any effect you want. If you just want a damage bonus and mana drain then you can add the damage bonus directly to the Damage Response area, and have it trigger a Modify Unit effect that lowers the caster's mana. You'll also want to add a validator to the behavior that disables it when the unit is out of mana.
Good luck.
0
There's a built-in actor called "SOpHigherBy5" that will raise the height by 5 units. That's REALLY high though so you might want to duplicate that actor, call it SOpHigherBy2, and change the Z value in the Offset field to 2.0.
Then in your Launch Site Ops field, in the Operations line after "SOpAttachHarnass" add "SOpHigherBy2". That will raise the height by 2 units. You can experiment to find out the exact height you need.
0
@Vexal: Go
Ah, if you're using a unit's model, it's flagged as turnable and it's still not turning....
Is the weapon arc set to 0? If the weapon arc is 360 then it doesn't need to turn to fire.
0
What model are you trying to use? I should have specified this will only work if you're using a model that can rotate. For example making a "Hydra Tower".
If you're trying to have a building rotate then sorry I haven't been able to find out how to do that. But it would look goofy as hell anyways.