The problem would be, that footprints do not support these collision flags, only units do. Since doodads only have collision, if they have a footprint, you would need to handle everything with units instead, probably spamming the map with invisible blocker units. If this can be applied for your map, it should not be problematic, the collision flags work nicely in this case.
Strange. I tried it out, got a problem with the removal of the behavior (it is applied for every shot but the damage response triggers only on death), so I added an additional behavior handling the removal.
Now, if I uncheck the fatal flag for all behaviors, it works fine, regenerating energy on every shot, even the killshot. But as soon as I check fatal on the defender it doesn't work, no energy regenerated ever.
However if I leave out the removal behavior so the defender behavior stays indefinitely, it works again...
Well, for your specific application I guess a small duration on the behavior wouldn't hurt. I would avoid that for generic damage responses, because that would probably make them trigger multiple times unintentionally, but since we are talking about only fatal damage responses, thats no big deal I guess. You might get energy for units killed in a 0.0625 time interval after you last damaged them.
I might need to add, that this is easily doable in triggers, which doesn't include this hack-ish way of using damage responses. Keep in mind, that this might be unintentional behavior, which could be fixed in a future patch (...which would hopefully also fix the attacker damage responses to provide a replacement :) ).
Believe what DrSuperEvil is suggesting is in place of just a 'damage' effect on your weapon, use a set effect that applies a behavior with a damage response with a handled effect of modify unit + energy and then of course your damage effect. To ensure this only happens when said ability is active, I would have a validator requiring Energy Steal or whatever buff count > 0. I would also probably only have the applied behavior last for about 5-10 seconds, so you can't just hit 10 units and come eat energy from them later.
I don't think so. He is probably referring to an 'attacker' damage response being able to apply a secondary behavior to the target unit (using the Handled effect field with an Apply Behavior effect), which in turn uses a 'defender' damage response that even triggers for the damage instance, which applied the behavior in the first place. You would instantly remove the behavior after the defender response triggered, so it is guaranteed it will only trigger for that one damage instance.
This might still sound confusing, so another clarification:
Unit has a behavior with a damage response set to 'attacker'
Unit causes one instance of damage to the target
Damage response triggers, executing the Handled effect
Effect applies a 2nd behavior, this time to the target
Damage response for the 2nd behavior triggers for the same instance of damage!
Handled effect removes the 2nd behavior and adds energy to the attacker.
Data is not really flexible regarding dynamic damage amounts. You can do damage based on the current vitals of the target, but you cannot do damage based on missing vitals or vitals of the caster (besides crazy workarounds like defining fixed intervals and checking with huge amounts of validators or looping 1 damage + 1 vital drain effects or something). So I would suggest to use triggers instead.
Unfortunately there is no way I know of to attach a model to the cursor of a player, outside of ability targeting mode. So you would need to either use the ability targeting mode somehow (hard to do, because you cannot even enter it via trigger or something) or use triggers to track mouse position and move the model manually.
They probably share the same Text Key for the name, with different editor suffixes. Check the Unit: Name field and change the Text Key to something different for all your walls.
Your questions are very generic, and I would have to say: Yes, there is a way to make the map work the way you want it. Until we know the specific triggers of your map however, it will be hard to find out, whats wrong with your triggers, and we can just guess
I have no idea, how your triggers would be set up to unintentionally spawn another wave of bosses. You did set them up, either you spawn them once and don't get that issue, or you spawn periodically somehow, in which case you want some check before spawning. And for the victory thing, there are various possibilities. You could count the dying bosses in a variable and end the game if the count is high enough. You could check, if the number of living bosses on the map is > 0. You could flag the players as victorious using a boolean and check those after each boss kill. Whatever you like.
All an ability needs to be able to autocast is the Autocast flag and either an Autocast Range > 0 or an Autocast Validator != none. Depending on the kind of ability, you might need further adjustments to make it autocast in the appropriate situations.
Also make sure you can manually cast it. I had this situation a couple of times where I was like "Why doesn't he cast it?" and then found out the ability wasn't even castable manually and the autocast part worked just fine :D
You can try to just set the location of the cooldown to Player, which should sync the same cooldown for all units of the player using it, if applicable for your map.
If that doesn't work for your map, you can get the Triggering Inventory Item, which is a unit. You can use catalogs from here to read out the item of the unit and the cost of this item, like this:
There is no native way to do it. Mille's workaround is the way to go. You can actually do it in data, but it would require 1 event per frame, so it is not really practical; I would use triggers the way he describes.
Zelda, I was totally unaware that Blizzard allowed you to publish maps with a white-list. Absolutely wonderful if you can.
I recall some sentence in their ToS for the editor, that it is not allowed to restrict access to the map and have users pay for full access or something, so a white-list for testing might be somewhat of a grey area.
0
The problem would be, that footprints do not support these collision flags, only units do. Since doodads only have collision, if they have a footprint, you would need to handle everything with units instead, probably spamming the map with invisible blocker units. If this can be applied for your map, it should not be problematic, the collision flags work nicely in this case.
0
Strange. I tried it out, got a problem with the removal of the behavior (it is applied for every shot but the damage response triggers only on death), so I added an additional behavior handling the removal.
Now, if I uncheck the fatal flag for all behaviors, it works fine, regenerating energy on every shot, even the killshot. But as soon as I check fatal on the defender it doesn't work, no energy regenerated ever.
However if I leave out the removal behavior so the defender behavior stays indefinitely, it works again...
Well, for your specific application I guess a small duration on the behavior wouldn't hurt. I would avoid that for generic damage responses, because that would probably make them trigger multiple times unintentionally, but since we are talking about only fatal damage responses, thats no big deal I guess. You might get energy for units killed in a 0.0625 time interval after you last damaged them.
I might need to add, that this is easily doable in triggers, which doesn't include this hack-ish way of using damage responses. Keep in mind, that this might be unintentional behavior, which could be fixed in a future patch (...which would hopefully also fix the attacker damage responses to provide a replacement :) ).
0
I don't think so. He is probably referring to an 'attacker' damage response being able to apply a secondary behavior to the target unit (using the Handled effect field with an Apply Behavior effect), which in turn uses a 'defender' damage response that even triggers for the damage instance, which applied the behavior in the first place. You would instantly remove the behavior after the defender response triggered, so it is guaranteed it will only trigger for that one damage instance.
This might still sound confusing, so another clarification:
0
Could you elaborate, which actor exactly causes the problem and what indicates it?
0
Data is not really flexible regarding dynamic damage amounts. You can do damage based on the current vitals of the target, but you cannot do damage based on missing vitals or vitals of the caster (besides crazy workarounds like defining fixed intervals and checking with huge amounts of validators or looping 1 damage + 1 vital drain effects or something). So I would suggest to use triggers instead.
0
Unfortunately there is no way I know of to attach a model to the cursor of a player, outside of ability targeting mode. So you would need to either use the ability targeting mode somehow (hard to do, because you cannot even enter it via trigger or something) or use triggers to track mouse position and move the model manually.
0
If in doubt, add an ActorOrphan -> Destroy event, that should destroy the actor in any case, as soon as the associated objects are removed.
0
They probably share the same Text Key for the name, with different editor suffixes. Check the Unit: Name field and change the Text Key to something different for all your walls.
0
Either add a separate event for each specific unit, or use any unit and use the Conditions to filter the correct ones.
0
Have a look at this post. Note, that it is from 2010, so I am not sure, if everything still works 100%.
0
Your questions are very generic, and I would have to say: Yes, there is a way to make the map work the way you want it. Until we know the specific triggers of your map however, it will be hard to find out, whats wrong with your triggers, and we can just guess
I have no idea, how your triggers would be set up to unintentionally spawn another wave of bosses. You did set them up, either you spawn them once and don't get that issue, or you spawn periodically somehow, in which case you want some check before spawning. And for the victory thing, there are various possibilities. You could count the dying bosses in a variable and end the game if the count is high enough. You could check, if the number of living bosses on the map is > 0. You could flag the players as victorious using a boolean and check those after each boss kill. Whatever you like.
0
All an ability needs to be able to autocast is the Autocast flag and either an Autocast Range > 0 or an Autocast Validator != none. Depending on the kind of ability, you might need further adjustments to make it autocast in the appropriate situations.
Also make sure you can manually cast it. I had this situation a couple of times where I was like "Why doesn't he cast it?" and then found out the ability wasn't even castable manually and the autocast part worked just fine :D
0
You can try to just set the location of the cooldown to Player, which should sync the same cooldown for all units of the player using it, if applicable for your map.
If that doesn't work for your map, you can get the Triggering Inventory Item, which is a unit. You can use catalogs from here to read out the item of the unit and the cost of this item, like this:
This would be for a cooldown located at the unit, which most standard items use.
0
There is no native way to do it. Mille's workaround is the way to go. You can actually do it in data, but it would require 1 event per frame, so it is not really practical; I would use triggers the way he describes.
0
I recall some sentence in their ToS for the editor, that it is not allowed to restrict access to the map and have users pay for full access or something, so a white-list for testing might be somewhat of a grey area.