Problem with that is I want to attack it, not just move the position - my previous example of 'move' was just for testing and I left it. Moving to the position of a unit (not to the unit itself) does work though.
The attack 'ends' if my target that I've queued up is no longer in vision, that would explain why it worked when I targeted one of my own units.
This is a problem though, because the mechanic I'm working on is going to end up as a 'tracking' mechanic. If you queue up an attack on a unit that no longer has vision, it will make a best attempt to find that unit based on when the target unit was last visible (aka chase the unit into fog for X number of seconds).
It works when I retain vision, but when I replaced the order with a manually set order like you suggested, it still doesn't work.
I'm not sure if it has something to do with the position of the order where it doesn't want to take it, or what? I will try having the unit move back and forth to see if that works.
With this suggestion, I thought about it a little, and instead of having the current queued order replace and have the rest of the orders before that get placed before the existing queue, I would just save the order for later (after rebuilding the queue) and place the recent order to the end. I get much better results with the queuing.. but I'm still having an issue with getting the attack order to stick on that unit. Videos to follow.
OrderQueueManipulation-UnitEventsUnit-Ghost[4.06,60.00] is issued an order to Attack
Local Variables
order = (Triggering order) <Order>
unit = (Triggering unit) <Unit>
end = 0 <Integer>
i = 0 <Integer>
unit orders = (Triggering order) <Order[64]>
Conditions
(Target type for order) == Unit
Actions
------- The trigger must be turned off to stop it self-firing.
Trigger - Turn Order Queue Manipulation - Unit Off
------- First get all unit orders.
------- Skip last order as that is the triggering order.
Variable - Set end = ((Count of orders on unit) - 2)
General - For each integer i from 0 to end with increment 1, do (Actions)
Actions
Variable - Set unit orders[i] = (unit order at index i)
------- Clear all unit orders with the corrected order.
Variable - Set order = ((Ability command for order) targeting Ghost [19.94,59.93])
Unit - Order unit to ( Stop) (Replace Existing Orders)
------- Now refill the orders from top to bottom.
General - For each integer i from 0 to end with increment 1, do (Actions)
Actions
Unit - Order unit to unit orders[i] (After Existing Orders)
Unit - Order unit to order (After Existing Orders)
------- The trigger must be turned on again to pickup new orders.
Trigger - Turn Order Queue Manipulation - Unit On
Move to position of unit does work, but the purpose is to be able to target the unit directly. It is only set to move as a test, my ultimate goal is to have it issue the attack order instead.. and the path isn't completely blocked.
I'll post some videos in a little bit showing what it does.
The reason why it goes 'before existing orders' is because it is a queued action.
Let say this is your order queue:
0 - Move to point
1 - Move to point
2 - Attack to point
3 - Move to point
Then, with my current script - it takes an attack on a unit, and changes it to move to unit, it would do this:
0 - Attack to unit -> 0 - Move to unit
THEN
0 - Move to point
1 - Move to point
2 - Attack to point
3 - Move to point
4 - Move to unit
This would keep the current queue intact, and modify the most recent queued up command and have it stay at the end. When I initially target the unit I really want to move to, it doesn't actually move to it (this is a queued order, which after the order at position 3 is executed, the unit is no longer in range or in vision for order 4, and the unit stops). If I target a different unit, it redirects it to the target and ends up moving to the unit just fine, out of range and out of vision as well.
Not sure if I'm explaining the issue well at all.. I could try to get a video of it for an example if that would help.
Sorry I know this thread is a little old, but I'm working on queue manipulation myself and noticed this..
So I've modified this example so that it watches for an attack on a unit (focused on one unit for control) and moved the variables to be global instead of local.
The problem I am running into here is when I actually target the Ghost (this ghost - Ghost [19.94, 59.93]) - it doesn't really 'replace' the order. When I target other units, it issues the move order to the correct unit just fine.. only when I target the unit I actually want to move to, then it has a problem. Any ideas?
OrderQueueManipulationEventsUnit-Ghost[4.06,60.00]isissuedanordertoAttackLocalVariablesConditions(Targettypefor(Triggeringorder))==UnitActions------- The trigger must be turned off to stop it self-firing.Trigger-Turn(Currenttrigger)Off------- First get all unit orders.------- Skip last order as that is the triggering order.Variable-Setend=((CountofordersonGhost[4.06,60.00])-2)General-Foreachintegerifrom0toendwithincrement1,do(Actions)ActionsVariable-Setunitorders[0]=(Ghost[4.06,60.00]orderatindexi)------- Clear all unit orders with the corrected order.------- In this case I offest the order by 2,2 just for demonstration purposes.Variable-Setorder=(MovetargetingGhost[19.94,59.93])Unit-OrderGhost[4.06,60.00]toorder(ReplaceExistingOrders)------- Now refill the orders from top to bottom.General-Foreachintegerifromendto0withincrement-1,do(Actions)ActionsUnit-OrderGhost[4.06,60.00]tounitorders[0](BeforeExistingOrders)------- The trigger must be turned on again to pickup new orders.Trigger-TurnMoveQueueOn
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
@willuwontu: Go
Problem with that is I want to attack it, not just move the position - my previous example of 'move' was just for testing and I left it. Moving to the position of a unit (not to the unit itself) does work though.
So I tested it a little bit more.
The attack 'ends' if my target that I've queued up is no longer in vision, that would explain why it worked when I targeted one of my own units.
This is a problem though, because the mechanic I'm working on is going to end up as a 'tracking' mechanic. If you queue up an attack on a unit that no longer has vision, it will make a best attempt to find that unit based on when the target unit was last visible (aka chase the unit into fog for X number of seconds).
@SomeoneTookMyNameTT: Go
It works when I retain vision, but when I replaced the order with a manually set order like you suggested, it still doesn't work.
I'm not sure if it has something to do with the position of the order where it doesn't want to take it, or what? I will try having the unit move back and forth to see if that works.
Works on different unit
Does not work on intended unit
@willuwontu:
With this suggestion, I thought about it a little, and instead of having the current queued order replace and have the rest of the orders before that get placed before the existing queue, I would just save the order for later (after rebuilding the queue) and place the recent order to the end. I get much better results with the queuing.. but I'm still having an issue with getting the attack order to stick on that unit. Videos to follow.
Move to position of unit does work, but the purpose is to be able to target the unit directly. It is only set to move as a test, my ultimate goal is to have it issue the attack order instead.. and the path isn't completely blocked.
I'll post some videos in a little bit showing what it does.
Thanks for your response on this.
The reason why it goes 'before existing orders' is because it is a queued action.
Let say this is your order queue:
0 - Move to point
1 - Move to point
2 - Attack to point
3 - Move to point
Then, with my current script - it takes an attack on a unit, and changes it to move to unit, it would do this:
0 - Attack to unit -> 0 - Move to unit
THEN
0 - Move to point
1 - Move to point
2 - Attack to point
3 - Move to point
4 - Move to unit
This would keep the current queue intact, and modify the most recent queued up command and have it stay at the end. When I initially target the unit I really want to move to, it doesn't actually move to it (this is a queued order, which after the order at position 3 is executed, the unit is no longer in range or in vision for order 4, and the unit stops). If I target a different unit, it redirects it to the target and ends up moving to the unit just fine, out of range and out of vision as well.
Not sure if I'm explaining the issue well at all.. I could try to get a video of it for an example if that would help.
Sorry I know this thread is a little old, but I'm working on queue manipulation myself and noticed this..
So I've modified this example so that it watches for an attack on a unit (focused on one unit for control) and moved the variables to be global instead of local.
The problem I am running into here is when I actually target the Ghost (this ghost - Ghost [19.94, 59.93]) - it doesn't really 'replace' the order. When I target other units, it issues the move order to the correct unit just fine.. only when I target the unit I actually want to move to, then it has a problem. Any ideas?