Units have a queue of orders. Whenever you issue a new order in triggers you decide where in that queue it goes. So if you simply make 5 move orders and tell it to place each (After Existing Orders) then they will be strung together one after the other. Easy as that.
Now if you do this by using the Issue Order to Unit Group action, and select that you want an Order Using Relative Points, and issue a move order then you should get it to order the group to move in formation. Unless I am horribly wrong.
Did you set up the morph to swap the actor?
Morphs are often set up by blizz to swap unit actors in the actor events in response to the morph happening.
You generally have to update these by hand.
Not sure what the planetary fortress actor does that is special tho... perhaps it is just essential that you do AnimGroupApply A.
So when you have a group selected and you order it to move to a place then the units tend to march in a loose formation. I think this is done by just figuring out where each units relative point to the center of the unit group is, and offsetting the target of the command for each unit by this. I would think that you can do this with a trigger just by using the Issue Order To Unit Group command(possibly making use of the relative points option), instead of iterating through Issue Order commands one by one for each unit.
If you do it one at a time there is no way to figure out where each units place is in the formation, since there is no sense of a formation.
It doesn't matter if they spawn one by one, but it does matter if they are ordered one by one.
It will work just like queueing move orders works in game, ie when you hold down shift. You just make one trigger which orders the unit to walk through like 15 or so points in order, just by issuing the 15 move orders with the 'after existing orders' option. There is a maximum number of orders that can be queued(something like 15, I dunno) so if your path is ridiculously twisted you may need to do this in stages.
The simplest way to do it is to just queue up multiple move orders, so the units walk through the center each time there is a corner. No need for regions or active triggers, just a couple of points.
I guess this wouldn't be acceptable if you want to avoid people making mazes which exploit the specific waypoint structure.
Erhm, I guess in this scenario the upgrade would actually be making changes to the ability, and not to the unit or the unit type.
So you would morph into the new unit type but it must still have the same transport ability(to avoid unloading). You can then upgrade the capacity of the transport ability but this will also upgrade the ability of the unit type you morphed from.
So it is all kind of useless if you want to upgrade the capacity of individual bunkers separately.
Presumably the best solution is just to instantly reorder the unloaded units to reload, like you suggested.
I would go out on a limb and guess that morphed cargo carriers will always drop their cargo if the unit they are morphing to does not have the exact same cargo ability. I should stress that this is a guess.
I don't think it is possible to increase capacity via buffs, but it is possible via upgrades. Of course upgrades apply to a unit type and not to an individual unit so that might not be what you are looking for.
A silly hack-around you might try is adding dummy units to the lower tiers of bunker which just take up space, and prevent it from unloading somehow.
You can also snare using 'Movement Speed Maximum' instead of using 'Movement Speed Multiplier'.
I think if you set 'Movement Speed Minimum' and 'Movement Speed Maximum' to something like 0.01 you shouldn't ever have to worry about multiple things stacking and causing immobilization.
Also I am surprised that snaring would cause the units to fail to move out of the way fast enough when being pushed by the superpusher... are you mistakenly using the Acceleration Multiplier instead of the Movement Speed Multiplier?
Back to DrSuperEvil's suggestion: The second unit shouldn't be able to block the superpusher even if the second unit is itself unable to move out of the way. They should just end up overlapping with the superpusher still completely free to move.
Also, If I recall correctly forces can't push immobile units either, so I doubt that they will work... but my memory has proven itself unreliable on many occasions, hehe.
How about just having fungal snare the units 99% instead of suppressing movement? That should be immobile enough without being 'immobile'.
I think you misunderstood the point of my earlier suggestions. I was suggesting ways that a new buff might be able to overwrite the suppress movement flag of the fungal type buff. Anyways, I decided to test it myself and neither of the suggestions I gave worked, so this may just be impossible.
Also, DrSuperEvil's suggestion would work fine. Just take the units you want to be able to push and apply a buff which disables (manually by name) each of the buffs which 'suppress movement'. Of course this would require you to periodically find all units nearby your uberpusher unit and apply the buff to them. So the snare solution might be more elegant.
Have you tried adding a buff with move checked under 'Ability classes enabled', to reenable movement for the duration of your push effect?
I think this might just control whether or not the move command button is grayed out... but its worth trying.
If that doesn't work you might also try the 'Enable move' under Behavior-Modify Flags.
Ok, this is NOT a bug. There is a function hidden away in the API called OrderSetTargetPassenger. This lets you specify the target for an unload order that you first make as an order with no target.
So yeah apparently orders can have targets and they can have targetpassengers.
There is currently no way to unload a specific unit using data or triggers. The order that does so is bugged: it appears to be mistakenly flagged as an order which takes no target, even though it does in fact have a target. So if you attempt to construct an order to unload a specific unit(ie if you use any transport ability's command index 3, labeled as 'Unload Unit') the editor will not allow you to specify a target for the order. Furthermore there appears to be no way to trick the editor into constructing an order which would work.
Confusingly, there is another command, this one having index 2, and being labeled "Unload Target" but this one does not appear to be the one used even though it is flagged as allowing a target. Attempts to get this command to do any thing at all have so far failed and it is a real mystery what it is used for.
We have verified that it is in fact command index 3 that is being used by capturing the order when the user clicks a units icon in the cargo hold to remove it. The command index is then easily queried and found to be 3. Saving such an order order to a variable and issuing it again via triggers reveals that it will only ever unload the exact same unit the player first clicked on to be unloaded, so the order is clearly storing a target; however, when queried about what kind of order it is, this same order shows that it is flagged as an order with no target(order type 0).
This is a very old bug, probably around since release. Here is a related bug report from 3 years ago: http://us.battle.net/sc2/en/forum/topic/540954652 . That bug report suggests that a side effect of this bug is that any kind of Unload Validator which queries something about the target being unloaded (ie does the unit attempting to unload have a certain buff) does not work. Simply because the order (although it has a target) is flagged as not having a target, so the game presumably doesn't bother checking attributes of the target. I have verified that related bug is also still present.
You can emulate this pretty well by clever use of immobilization. Credit for this hack goes to Hero Attack. Give a unit which normally has higher push priority a buff which will periodically immobilize any units around him that you don't want to push. Then he won't be able to push them. Normally this works best if you choose only attacking enemy units since they aren't going to be moving anyway. Whatever buff you apply to a unit to immobilize should remove itself when the unit is not attacking (and of course have a very short duration). Also it may require a trigger to be able to order immobilized units to move properly. Basically the first time you order an immobilized unit to move it will stop attacking and this will remove the immobilization buff, but the unit will forget the order. So you need a trigger to capture move orders given to immobilized units which manually removes the immobilization and possibly reissues the order.
There may also be a more straightforward way to do it via upgrades if you are fine with it only being changeable for an entire unit type at once.
0
@Spellbound7: Go
Ok, I will try to explain it a bit clearer.
Units have a queue of orders. Whenever you issue a new order in triggers you decide where in that queue it goes. So if you simply make 5 move orders and tell it to place each (After Existing Orders) then they will be strung together one after the other. Easy as that.
Now if you do this by using the Issue Order to Unit Group action, and select that you want an Order Using Relative Points, and issue a move order then you should get it to order the group to move in formation. Unless I am horribly wrong.
0
Did you set up the morph to swap the actor? Morphs are often set up by blizz to swap unit actors in the actor events in response to the morph happening. You generally have to update these by hand.
Not sure what the planetary fortress actor does that is special tho... perhaps it is just essential that you do AnimGroupApply A.
Or maybe you did this already...
0
@Spellbound7: Go
Hmmm....
So when you have a group selected and you order it to move to a place then the units tend to march in a loose formation. I think this is done by just figuring out where each units relative point to the center of the unit group is, and offsetting the target of the command for each unit by this. I would think that you can do this with a trigger just by using the Issue Order To Unit Group command(possibly making use of the relative points option), instead of iterating through Issue Order commands one by one for each unit. If you do it one at a time there is no way to figure out where each units place is in the formation, since there is no sense of a formation.
It doesn't matter if they spawn one by one, but it does matter if they are ordered one by one.
0
@Spellbound7: Go
It will work just like queueing move orders works in game, ie when you hold down shift. You just make one trigger which orders the unit to walk through like 15 or so points in order, just by issuing the 15 move orders with the 'after existing orders' option. There is a maximum number of orders that can be queued(something like 15, I dunno) so if your path is ridiculously twisted you may need to do this in stages.
0
The simplest way to do it is to just queue up multiple move orders, so the units walk through the center each time there is a corner. No need for regions or active triggers, just a couple of points.
I guess this wouldn't be acceptable if you want to avoid people making mazes which exploit the specific waypoint structure.
0
@Spellbound7: Go
I believe that inner radius is ignored if it is larger than normal radius.
Basically units seem to use the smaller of inner radius and normal radius to determine their radius for colliding with buildings.
I don't think this walking in the center pathing issue can be solved with data.
0
@DrSuperEvil: Go
Erhm, I guess in this scenario the upgrade would actually be making changes to the ability, and not to the unit or the unit type. So you would morph into the new unit type but it must still have the same transport ability(to avoid unloading). You can then upgrade the capacity of the transport ability but this will also upgrade the ability of the unit type you morphed from.
So it is all kind of useless if you want to upgrade the capacity of individual bunkers separately. Presumably the best solution is just to instantly reorder the unloaded units to reload, like you suggested.
0
I would go out on a limb and guess that morphed cargo carriers will always drop their cargo if the unit they are morphing to does not have the exact same cargo ability. I should stress that this is a guess.
I don't think it is possible to increase capacity via buffs, but it is possible via upgrades. Of course upgrades apply to a unit type and not to an individual unit so that might not be what you are looking for.
A silly hack-around you might try is adding dummy units to the lower tiers of bunker which just take up space, and prevent it from unloading somehow.
0
The command center does this. Lift-off is a morph. Units stay inside if I recall.
0
@Softcloner: Go
You can also snare using 'Movement Speed Maximum' instead of using 'Movement Speed Multiplier'. I think if you set 'Movement Speed Minimum' and 'Movement Speed Maximum' to something like 0.01 you shouldn't ever have to worry about multiple things stacking and causing immobilization. Also I am surprised that snaring would cause the units to fail to move out of the way fast enough when being pushed by the superpusher... are you mistakenly using the Acceleration Multiplier instead of the Movement Speed Multiplier?
Back to DrSuperEvil's suggestion: The second unit shouldn't be able to block the superpusher even if the second unit is itself unable to move out of the way. They should just end up overlapping with the superpusher still completely free to move.
Also, If I recall correctly forces can't push immobile units either, so I doubt that they will work... but my memory has proven itself unreliable on many occasions, hehe.
0
How about just having fungal snare the units 99% instead of suppressing movement? That should be immobile enough without being 'immobile'.
I think you misunderstood the point of my earlier suggestions. I was suggesting ways that a new buff might be able to overwrite the suppress movement flag of the fungal type buff. Anyways, I decided to test it myself and neither of the suggestions I gave worked, so this may just be impossible.
Also, DrSuperEvil's suggestion would work fine. Just take the units you want to be able to push and apply a buff which disables (manually by name) each of the buffs which 'suppress movement'. Of course this would require you to periodically find all units nearby your uberpusher unit and apply the buff to them. So the snare solution might be more elegant.
0
Have you tried adding a buff with move checked under 'Ability classes enabled', to reenable movement for the duration of your push effect? I think this might just control whether or not the move command button is grayed out... but its worth trying.
If that doesn't work you might also try the 'Enable move' under Behavior-Modify Flags.
0
Ok, this is NOT a bug. There is a function hidden away in the API called OrderSetTargetPassenger. This lets you specify the target for an unload order that you first make as an order with no target.
So yeah apparently orders can have targets and they can have targetpassengers.
0
Cut and paste of a bug report I just posted to battle.net: http://us.battle.net/sc2/en/forum/topic/10014151673
There is currently no way to unload a specific unit using data or triggers. The order that does so is bugged: it appears to be mistakenly flagged as an order which takes no target, even though it does in fact have a target. So if you attempt to construct an order to unload a specific unit(ie if you use any transport ability's command index 3, labeled as 'Unload Unit') the editor will not allow you to specify a target for the order. Furthermore there appears to be no way to trick the editor into constructing an order which would work.
Confusingly, there is another command, this one having index 2, and being labeled "Unload Target" but this one does not appear to be the one used even though it is flagged as allowing a target. Attempts to get this command to do any thing at all have so far failed and it is a real mystery what it is used for. We have verified that it is in fact command index 3 that is being used by capturing the order when the user clicks a units icon in the cargo hold to remove it. The command index is then easily queried and found to be 3. Saving such an order order to a variable and issuing it again via triggers reveals that it will only ever unload the exact same unit the player first clicked on to be unloaded, so the order is clearly storing a target; however, when queried about what kind of order it is, this same order shows that it is flagged as an order with no target(order type 0).
This is a very old bug, probably around since release. Here is a related bug report from 3 years ago: http://us.battle.net/sc2/en/forum/topic/540954652 . That bug report suggests that a side effect of this bug is that any kind of Unload Validator which queries something about the target being unloaded (ie does the unit attempting to unload have a certain buff) does not work. Simply because the order (although it has a target) is flagged as not having a target, so the game presumably doesn't bother checking attributes of the target. I have verified that related bug is also still present.
0
You can emulate this pretty well by clever use of immobilization. Credit for this hack goes to Hero Attack. Give a unit which normally has higher push priority a buff which will periodically immobilize any units around him that you don't want to push. Then he won't be able to push them. Normally this works best if you choose only attacking enemy units since they aren't going to be moving anyway. Whatever buff you apply to a unit to immobilize should remove itself when the unit is not attacking (and of course have a very short duration). Also it may require a trigger to be able to order immobilized units to move properly. Basically the first time you order an immobilized unit to move it will stop attacking and this will remove the immobilization buff, but the unit will forget the order. So you need a trigger to capture move orders given to immobilized units which manually removes the immobilization and possibly reissues the order.
There may also be a more straightforward way to do it via upgrades if you are fine with it only being changeable for an entire unit type at once.