However when the actor attaches, if the base unit is moved, it's Selection Circle remains where it WAS. Furthermore, once the Attached actor destroys itself the base unit cannot be selected anymore.
Please see attached 17 second video (bug occurs at 0:11)
Also, check out this awesome spell I made last year, just found the map
I did, same bug using actor event. Also I will need to have extensive control over the Unholy Fire Ability given many situations, the fire "spreads" to nearby units like a disease and can be modified by many variables.
The data editor can ultimately achieve the same thing, but waiting 30 seconds per data entry (fail data editor lag) and just how generally "messy" the data editor is; encourages me to use triggers.
Also, how could I ever make the spell you saw in the second video using the data editor?
I used several triggers in unison sharing global variables to make that spell. The visual part consists of a trigger changing a unit's height and position (unit model changed to fire) over time using trig functions. Here's a sample of the code:
Hm, does the UnholyFireGround actor have a wrong alias? Seems to me the selection circle is attaching itself to the model addition actor and not the unit actor and once the UnholyFireGround actor disappears it bugs out. Make sure UnholyFireGround does not have the _Selectable alias or whatever it is called.
I still think, your actor settings might be the problem. Did you by any chance try to attach a unit actor?
Quote:
Also I will need to have extensive control over the Unholy Fire Ability given many situations, the fire "spreads" to nearby units like a disease and can be modified by many variables.
The data editor can ultimately achieve the same thing, but waiting 30 seconds per data entry (fail data editor lag) and just how generally "messy" the data editor is; encourages me to use triggers.
I wasn't saying you should use data for everything. Just for adding an animation to a behavior, data is usually recommended and most likely even easier. You can still use triggers for every other mechanic of your skill :)
Quote:
Also, how could I ever make the spell you saw in the second video using the data editor?
Doesn't look that hard to do in data. A couple of missile launches, custom movers and search at the missile location and you are set. Maybe you don't have the exact same flight path, but I think, you can get it to look very similar.
Quote:
This is how we used to do it back in the days of Warcraft 3, and to me remains the quickest and most effective way, and the easiest to edit.
Well, I made the same thing in WC3. However, SC2 offers some neat possibilities WC3 didn't, for example the mover system can save you a ton of calculation with very similar results. You don't have THAT much control over the exact flight path with it, but I certainly think, that, once you familiarized yourself with them, movers are quicker and easier to set up than creating such a calculation-heavy trigger every time.
Also, I am pretty sure, they are more efficient, you are calculating tons of stuff, including heavy use of trigonometrics at 16 fps (your 0.01 wait gets changed to the minimum amount of 0.0625). This by itself is not a huge problem, but I am pretty sure, it cannot compete to the very efficient mover system, not even close.
I fixed it by using Attach Model to [Actor: Actor of Triggering Unit]. Apparently attaching an actor is problematic, but attaching the model itself is not. I suppose this is because they are many "strings" attached the the actor, being a more complicated object.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have a trigger that attaches an Actor to a Unit when any unit acquires a behavior. The trigger is presented below:
However when the actor attaches, if the base unit is moved, it's Selection Circle remains where it WAS. Furthermore, once the Attached actor destroys itself the base unit cannot be selected anymore.
Please see attached 17 second video (bug occurs at 0:11)
Also, check out this awesome spell I made last year, just found the map
Interesting. Maybe it is caused by the settings of the attached actor.
Also, any specific reason, why you use triggers? You can easily use actor events to attach the actor, when any unit acquires the behavior.
@Kueken531: Go
I did, same bug using actor event. Also I will need to have extensive control over the Unholy Fire Ability given many situations, the fire "spreads" to nearby units like a disease and can be modified by many variables.
The data editor can ultimately achieve the same thing, but waiting 30 seconds per data entry (fail data editor lag) and just how generally "messy" the data editor is; encourages me to use triggers.
Also, how could I ever make the spell you saw in the second video using the data editor?
I used several triggers in unison sharing global variables to make that spell. The visual part consists of a trigger changing a unit's height and position (unit model changed to fire) over time using trig functions. Here's a sample of the code:
This is how we used to do it back in the days of Warcraft 3, and to me remains the quickest and most effective way, and the easiest to edit.
@EdwardSolomon: Go
Hm, does the UnholyFireGround actor have a wrong alias? Seems to me the selection circle is attaching itself to the model addition actor and not the unit actor and once the UnholyFireGround actor disappears it bugs out. Make sure UnholyFireGround does not have the _Selectable alias or whatever it is called.
I still think, your actor settings might be the problem. Did you by any chance try to attach a unit actor?
I wasn't saying you should use data for everything. Just for adding an animation to a behavior, data is usually recommended and most likely even easier. You can still use triggers for every other mechanic of your skill :)
Doesn't look that hard to do in data. A couple of missile launches, custom movers and search at the missile location and you are set. Maybe you don't have the exact same flight path, but I think, you can get it to look very similar.
Well, I made the same thing in WC3. However, SC2 offers some neat possibilities WC3 didn't, for example the mover system can save you a ton of calculation with very similar results. You don't have THAT much control over the exact flight path with it, but I certainly think, that, once you familiarized yourself with them, movers are quicker and easier to set up than creating such a calculation-heavy trigger every time.
Also, I am pretty sure, they are more efficient, you are calculating tons of stuff, including heavy use of trigonometrics at 16 fps (your 0.01 wait gets changed to the minimum amount of 0.0625). This by itself is not a huge problem, but I am pretty sure, it cannot compete to the very efficient mover system, not even close.
@Kueken531: Go
I fixed it by using Attach Model to [Actor: Actor of Triggering Unit]. Apparently attaching an actor is problematic, but attaching the model itself is not. I suppose this is because they are many "strings" attached the the actor, being a more complicated object.