Yes Vicboy's Apostles =) My game is Heaven Besieged.
Actors are responsible for anything you see or hear. So any model or sound comes to be in the game because of some actor.
Actors handle how those models and sounds behave in the game, so for example a unit actor is reponsible of displaying the model for that unit and is responsible for which animation that model ought to be engaged in at each moment. Many of the animations are handled via the Events for that actor. So for example if that actor receives a signal that its unit has used an ability at some stage it may then play a certain animation.
Short Answer: Animations are something that Actors do. They are part of the actor, not part of the ability.
Long Answer:
Special Animations for abilities are part of the Actor Events for the unit that has that ability. If all you do is just give some random unit the snipe ability or any other ability for that matter you should not ever expect to automatically have the proper animations play for that ability.
Pull up the Actor Events for the Ghost Actor and examine how the actor is set up to play animations in response to snipe being used.
Also I feel compelled to share that I use the duplicate functionality all the time and find it to be a great time saver. It is just a matter of understanding that it doesn't magically do everything you need to do when duplicating and being prepared to clean things up manually. That said it is of course important to learn how to make things from scratch though, or else you will never really have a good understanding of what you are doing in the data editor.
(PS, could you ask your clanmate IHAVENONAME to stop trolling the lobbies for my map?)
@Quirriff: Go
Create units effects now seem to have the field "Effect: Type Fallback Unit". This specifies the unit whose unit type will be the one created, assuming that the "Effect: Spawn Unit" field is set to none.
So I would guess you would want to set 'Type Fallback Unit' to Target, keep 'Spawn Unit' set to None, and set your 'Effect - Spawn' to an effect that applies your hallucinationness behavior.
Yeah, makes sense. You just have to go through the actor events for the duplicated zergling actor and change each place it refers to the original burrowed zergling or the original burrow/unburrow ability and instead have it refer to the new burrowed zergling and the new burrow abilities.
The duplicate functionality of the editor has trouble with getting everything right with the events of duplicated actors.
So what is likely happening is that your new zergling actor is getting created whenever the old zergling unit is created. Since the old zergling unit also has its own actor, you end up with 2 different unit actors for the same unit, which the game is warning you about. If you look closely the unit's model is likely duplicated, ie it looks like there are two zerglings overlapping. This can be subtle error, so Blizz decided to explicitly warn you.
Whenever you duplicate a unit you should go through the events for the actors and manually correct any mistaken references, ie generally when the old ability or unit is referenced instead of the newly duplicated one. So in this case some references to Zergling2 might need to instead point to Zergling22, or maybe vice versa I dunno.
Your issue may be with the Target is Pathable validator in a switch effect for the ability. Looking at how Blizzard set up the ability, it appears that it just doesn't launch the leaping missile if the ling couldn't path to there on its own.
If your map does not rewrite the data fields of the mod then it is fairly easy.
Use XML mode in the editor or save the map and mod as .sc2components files and handle merging the xml files yourself.
And then just copy all the XML lines for each kind of data from the mod to the map.
If your map does overwrite some of the mod data fields, then I would think it might work to just be sure to paste the mod data XML above the map data, but I don't really know.
I don't know what the best way to merge assets would be.
Yes, the load behavior field for the cargo ability let's you specify a behavior you would like to have applied to a unit for as long as it is inside the transport.
Look at the cargo ability and the behavior it applies in my map for an example.
No, you don't need to duplicate anything, and no flags need to be changed. Photoless was mistaken about the need for such.
Just adding a buff which enables the attack ability itself is sufficient to make almost every unit fire out of the transport while moving right out of the box.
Getting the units to fire out the APC while it is moving is easy: just give them a buff which forces attack to be enabled whenever they are loaded(as Photoless discovered).
However this alone will not make for an APC which has polished user controls.
You want it to properly chase units it has been ordered to attack, this includes maintaining the right chase distance.
If it has been ordered to attack a particular unit then you want it to redirect the attack of its cargo units to attack that target every time that target comes in range.
If you order the APC to stop or hold position it should order its cargo to stop.
This sort of stuff is what my example adds to Photoless's solution.
I think my implementation essentially solves the issue, I have no idea what goes into marking a thread as solved.
I do not think the destroy all monsters map solved the attack while moving issue.
Also this seems like a good place to mention again that Photoless deserves the credit for discovering the fundamental idea on how to get units to fire from inside while moving.
I share your preference for data solutions, however I ran into various issues trying to get it to work with data only; maybe you would have more luck. However it works as is, and if performance is your worry the triggers are not odious(even though they may appear to trigger every time a unit is ordered to attack/stop etc. they actually only trigger when an APC is ordered to do these things due to the use of custom attack/stop/etc. abilities). However even this isn't great, and it would be nice if the redirect triggers could be replaced with data.
One issue I seem to recall running into was that when selecting both APCs and regular units, some commands would not always be issued for both even if the APC's redirect type ability had the same Set ID as the regular unit. Anyways after much experimentation I resorted to handling the redirects in triggers.
Also, triggers are the only way that makes sense in order to insure that the APC itself has the right dummy weapon range and thus when chasing closes in to the right distance on its target. I doubt there is an elegant way to set the range to be the smallest range of all units inside using data.
Here is the cleaned up version. APCs should control more or less the same as diamondbacks.
The APC basic attack/move/stop abilities were replaced with custom ones so that the supporting triggers will fire only in response to APC events. This set up should result in minimal trigger lag.
Ok. it took me longer than I thought it would, here is a preliminary, still a bit messy, implementation.
It appears to work with most every unit right out of the box.
In the end I had to use triggers for several things but they shouldn't run often enough to cause any performance issues.
0
@Vicboy: Go
Yes Vicboy's Apostles =) My game is Heaven Besieged.
Actors are responsible for anything you see or hear. So any model or sound comes to be in the game because of some actor. Actors handle how those models and sounds behave in the game, so for example a unit actor is reponsible of displaying the model for that unit and is responsible for which animation that model ought to be engaged in at each moment. Many of the animations are handled via the Events for that actor. So for example if that actor receives a signal that its unit has used an ability at some stage it may then play a certain animation.
0
This has little to do with duplication.
Short Answer: Animations are something that Actors do. They are part of the actor, not part of the ability.
Long Answer: Special Animations for abilities are part of the Actor Events for the unit that has that ability. If all you do is just give some random unit the snipe ability or any other ability for that matter you should not ever expect to automatically have the proper animations play for that ability. Pull up the Actor Events for the Ghost Actor and examine how the actor is set up to play animations in response to snipe being used.
Also I feel compelled to share that I use the duplicate functionality all the time and find it to be a great time saver. It is just a matter of understanding that it doesn't magically do everything you need to do when duplicating and being prepared to clean things up manually. That said it is of course important to learn how to make things from scratch though, or else you will never really have a good understanding of what you are doing in the data editor.
(PS, could you ask your clanmate IHAVENONAME to stop trolling the lobbies for my map?)
0
Is it possible to prevent players who aren't host, (or failing that preventing everyone) from inviting people into a public lobby?
0
@Quirriff: Go Create units effects now seem to have the field "Effect: Type Fallback Unit". This specifies the unit whose unit type will be the one created, assuming that the "Effect: Spawn Unit" field is set to none.
So I would guess you would want to set 'Type Fallback Unit' to Target, keep 'Spawn Unit' set to None, and set your 'Effect - Spawn' to an effect that applies your hallucinationness behavior.
0
@Azizh: Go
Yeah, makes sense. You just have to go through the actor events for the duplicated zergling actor and change each place it refers to the original burrowed zergling or the original burrow/unburrow ability and instead have it refer to the new burrowed zergling and the new burrow abilities.
0
The duplicate functionality of the editor has trouble with getting everything right with the events of duplicated actors.
So what is likely happening is that your new zergling actor is getting created whenever the old zergling unit is created. Since the old zergling unit also has its own actor, you end up with 2 different unit actors for the same unit, which the game is warning you about. If you look closely the unit's model is likely duplicated, ie it looks like there are two zerglings overlapping. This can be subtle error, so Blizz decided to explicitly warn you.
Whenever you duplicate a unit you should go through the events for the actors and manually correct any mistaken references, ie generally when the old ability or unit is referenced instead of the newly duplicated one. So in this case some references to Zergling2 might need to instead point to Zergling22, or maybe vice versa I dunno.
0
Your issue may be with the Target is Pathable validator in a switch effect for the ability. Looking at how Blizzard set up the ability, it appears that it just doesn't launch the leaping missile if the ling couldn't path to there on its own.
0
@njordys: Go
If your map does not rewrite the data fields of the mod then it is fairly easy. Use XML mode in the editor or save the map and mod as .sc2components files and handle merging the xml files yourself. And then just copy all the XML lines for each kind of data from the mod to the map.
If your map does overwrite some of the mod data fields, then I would think it might work to just be sure to paste the mod data XML above the map data, but I don't really know.
I don't know what the best way to merge assets would be.
0
@Terhonator: Go
Yes, the load behavior field for the cargo ability let's you specify a behavior you would like to have applied to a unit for as long as it is inside the transport. Look at the cargo ability and the behavior it applies in my map for an example.
0
@SoulFilcher: Go
No, you don't need to duplicate anything, and no flags need to be changed. Photoless was mistaken about the need for such. Just adding a buff which enables the attack ability itself is sufficient to make almost every unit fire out of the transport while moving right out of the box.
0
@Terhonator: Go
Getting the units to fire out the APC while it is moving is easy: just give them a buff which forces attack to be enabled whenever they are loaded(as Photoless discovered).
However this alone will not make for an APC which has polished user controls.
You want it to properly chase units it has been ordered to attack, this includes maintaining the right chase distance. If it has been ordered to attack a particular unit then you want it to redirect the attack of its cargo units to attack that target every time that target comes in range. If you order the APC to stop or hold position it should order its cargo to stop.
This sort of stuff is what my example adds to Photoless's solution.
0
@Terhonator: Go
I think my implementation essentially solves the issue, I have no idea what goes into marking a thread as solved. I do not think the destroy all monsters map solved the attack while moving issue. Also this seems like a good place to mention again that Photoless deserves the credit for discovering the fundamental idea on how to get units to fire from inside while moving.
I share your preference for data solutions, however I ran into various issues trying to get it to work with data only; maybe you would have more luck. However it works as is, and if performance is your worry the triggers are not odious(even though they may appear to trigger every time a unit is ordered to attack/stop etc. they actually only trigger when an APC is ordered to do these things due to the use of custom attack/stop/etc. abilities). However even this isn't great, and it would be nice if the redirect triggers could be replaced with data.
One issue I seem to recall running into was that when selecting both APCs and regular units, some commands would not always be issued for both even if the APC's redirect type ability had the same Set ID as the regular unit. Anyways after much experimentation I resorted to handling the redirects in triggers.
Also, triggers are the only way that makes sense in order to insure that the APC itself has the right dummy weapon range and thus when chasing closes in to the right distance on its target. I doubt there is an elegant way to set the range to be the smallest range of all units inside using data.
0
I uploaded an example implementation of this for medivacs at the bottom this thread: http://www.sc2mapster.com/forums/development/data/52118-how-to-make-a-unit-with-bunker-moving-shot/
0
Here is the cleaned up version. APCs should control more or less the same as diamondbacks.
The APC basic attack/move/stop abilities were replaced with custom ones so that the supporting triggers will fire only in response to APC events. This set up should result in minimal trigger lag.
0
Ok. it took me longer than I thought it would, here is a preliminary, still a bit messy, implementation.
It appears to work with most every unit right out of the box. In the end I had to use triggers for several things but they shouldn't run often enough to cause any performance issues.
I will post another cleaned up version soon.