1) Try the flags "Allow passenger smart command" and "Allow smart command".
2) Open the Commands for the ability. Set up and use the "Unload Target" command, not the "Unload All" command.
4) Ouch, that's a tricky one. If only there were a "Unload Effect" to instantly teleport the unit at the back of the transport... I'll post later if I can think of a good solution.
5) The medivac transport ability is by default linked to some actors that trigger specific animations (falling from a height) for units. Just use your own new ability.
A Create Persistent runs its initial delay, the specified count of periods, the expire delay then it DOES destroy itself naturally without the need to do anything else on your part.
If you use the "Persist until destroyed" flag, then it will keep running periods forever, ignoring the specified count of periods. In that case, you need to set some kind of periodic validator that will eventually return false so the effect goes out of the loop and destroys itself.
In the vast majority of cases, you do NOT need a "Destroy Persistent" effect, you just let the "Create persistent" effect destroy itself naturally (either through count of periods, or periodic validator returning false).
Yes well, it's difficult to say without seeing your data.
So I'll take a wild guess. You modified the existing ability not to cost any energy, and it casts, yet it's immediately canceled by the Create Persistent validators because the caster has less than 5 energy? It can be many things...
Yes, I and others have all used these models abundantely. There are minor drawbacks, for example the HurricaneBattlecruiser.m3 model doesn't have a death animation (try a large generic explosion instead).
If Galaxy were compiled to real executable code processed directly by the processor, then you could mess around the memory space of the process and other nasty things (modify file system, install viruses, whatever).
But Galaxy is all executed within a VM (Virtual Machine), which interprets the instructions and ensures all memory accesses stay inside the interpreted code's memory space. It may be 100 times slower but is quite safe (when properly written anyway).
You have to create a distinct set of Shield actors (ShieldImpact, ProtossShieldFacer, etc. ).
Modify the existing ShieldImpact actor so it does NOT get created for your units. Then have your own brand new ShieldImpact-like actor be created for only your units (through validators). You can then SetTint (on ActorCreation) for all your new shield actors, which will only exist for the validated units.
Instead of Destroy Persistent, can't you just use validators so that the existing Create Persistent terminate itself whenever the periodic validator indicates it to do so?
0
1) Try the flags "Allow passenger smart command" and "Allow smart command".
2) Open the Commands for the ability. Set up and use the "Unload Target" command, not the "Unload All" command.
4) Ouch, that's a tricky one. If only there were a "Unload Effect" to instantly teleport the unit at the back of the transport... I'll post later if I can think of a good solution.
5) The medivac transport ability is by default linked to some actors that trigger specific animations (falling from a height) for units. Just use your own new ability.
0
A Create Persistent runs its initial delay, the specified count of periods, the expire delay then it DOES destroy itself naturally without the need to do anything else on your part.
If you use the "Persist until destroyed" flag, then it will keep running periods forever, ignoring the specified count of periods. In that case, you need to set some kind of periodic validator that will eventually return false so the effect goes out of the loop and destroys itself.
In the vast majority of cases, you do NOT need a "Destroy Persistent" effect, you just let the "Create persistent" effect destroy itself naturally (either through count of periods, or periodic validator returning false).
0
Yes well, it's difficult to say without seeing your data.
So I'll take a wild guess. You modified the existing ability not to cost any energy, and it casts, yet it's immediately canceled by the Create Persistent validators because the caster has less than 5 energy? It can be many things...
0
Yes, I and others have all used these models abundantely. There are minor drawbacks, for example the HurricaneBattlecruiser.m3 model doesn't have a death animation (try a large generic explosion instead).
0
If Galaxy were compiled to real executable code processed directly by the processor, then you could mess around the memory space of the process and other nasty things (modify file system, install viruses, whatever).
But Galaxy is all executed within a VM (Virtual Machine), which interprets the instructions and ensures all memory accesses stay inside the interpreted code's memory space. It may be 100 times slower but is quite safe (when properly written anyway).
0
Eheh nice, bubble sort.
I find it very awkward writing code in a language without pointers (and structs), the "good" sorting algorithms aren't even possible to write.
0
Make sure your missile mover has "Ignore terrain" enabled for all phases.
0
You have to create a distinct set of Shield actors (ShieldImpact, ProtossShieldFacer, etc. ).
Modify the existing ShieldImpact actor so it does NOT get created for your units. Then have your own brand new ShieldImpact-like actor be created for only your units (through validators). You can then SetTint (on ActorCreation) for all your new shield actors, which will only exist for the validated units.
0
Instead of Destroy Persistent, can't you just use validators so that the existing Create Persistent terminate itself whenever the periodic validator indicates it to do so?
0
Yes, and you can modify an ability's cooldown with a Modify Unit effect, to see the cooldown on the ability and so on.
0
Then I wouldn't use an ability for that, I would use a behavior with a damage response.
You can simulate cooldown and everything by validating against the presence of a second behavior (short duration) applied with the damage response.
0
What do you mean "before he takes damage"? If the unit is attacked, it's too late to order it to do anything before it takes damage.
Do you want to auto-cast this whenever in the proximity of enemies? Any visible enemy within a range of X?
0
Change the Create Healer effect, set Shield instead of Life. You may want to modify the ability's target filters too.
0
Ah yes, I see. Interesting use of Unknown and fallback :).
Icesmaster, there are several ways to implement this, pick whichever you want.
0
Interesting, I just never did colliding projectiles that way. How would you then define a maximum range, without a timeout or a range validator?