Shift-queueing not possible for future states

This has been reported for monks: You cannot shift-queue delivery of a relic because the monk doesn’t have the relic in his hands. This is a requirement for shift-queueing the delivery of the relic. No relic, no depositing of the relic.

But this happens with other things, so devs, please have this in mind when designing a fix for it. Another example: You cannot shift-queue the delivery of sheep in the TC using a scout that does not yet have sheep following him. If you do, you’ll garrison the scout in the TC instead, because that’s what dictated by the current state of the scout.

Following scout examples, you cannot shift-click the delivery of a deer carcass because the current state of the scout does not know that, by the time it gets back to the TC, it will have a deer carcass.


If I’m understanding correctly @webJose , you would prefer the unit to act based on current state (from the unit’s POV) as they approach an action.

So if, for example, you were to shift-queue a Scout to the TC in anticipation of him finding Sheep, but maybe he doesn’t find any, he would then garrison. But if he approached with Sheep, they would be delivered. If he were to have additional commands beyond interacting with the TC, he would, to follow the example, ungarrison and continue forth if he didn’t have Sheep.

Does that sound like the behavior you hope to see?


I think you’re close, but there is no reason the unit should garrison at all.

Herd Sheep should just simply not disable, ever. If there are no sheep, then there are no sheep to herd back, simple as that. The scout would still behave as if it were had herded sheep.

For the monks maybe a different button is needed for drop relic? Then the drop relic button is never disabled, and if a monk doesn’t have a relic, it itself still behaves as if it is dropping one off. So you can shift queue to pick one up, and return it, without any buggy behavior.

I think the code is trying to limit commands far too much and it’s creating behavior “states” where it really doesn’t need to be doing so. Sometimes being “smart” gets in the way of actually just being simple and actually smart.


Hi. I ddi not think that much through, but sounds very nice.

In programming terms, how about making the queue a queue of “raw actions”.

Scout queue:

  1. Go to this location.
  2. Perform default right-click action on TC (which will force the scout to first travel towards the TC).
  3. By the time it reaches the TC:
    A. Deliver ship, or carcass if present.
    B. Garrison in TC if this is the last entry in the queue, or continue with next action in queue.

I think that would be ideal. Every time a unit reaches the destination for an action, resolve that action at that time according to the unit’s current state.

NOTE: Special care for military units. Thinking about attack-move. Dunno how it is programmed, but the above logic might break this.

1 Like

I hate to make parallels to age II, but for this one I think that age II DE has it good.

Make an option to only garrison with the f bind (or alt + click, as in DE now).

That way it could make shift click focus on the perks of differents units (herds and carcass drop off for scouts, relics for monks and tax for imperial officers)

This would really help (especially less micro-friendly players) to use professionnal scout, queue relics and actively use and micro imperial officers.

1 Like

Thank you, all! A lot to think about here. I appreciate the dialog. I’ll make sure the team sees this convo.


Thank you very much for following through. This is an important part of the gameplay. I hope I could make myself clear about what “raw action” is and how and when to resolve it to a “final action”. You guys probably already have better names for these, hehe. Cheers!

1 Like

I think the unit shouldn’t resolve the command until it gets to the destination. At the moment it will resolve the command immediately when you issue it. If I click on a relic and then the monastery it shouldn’t convert my click on the monastery to a move command until the monk gets there. Once he gets there it should check to see if he is holding a relic or not and then perform the appropriate action.

There is some weird behaviour with the way it currently works. For example, you can actually shift queue a relic drop off but only if you already have at least 1 relic inside the monastery. If the monastery is empty then the monk will just move there but if it has one relic then you can queue up the command to remove it, that then gets changed to depositing the new one once the monk reaches it.

Also, if you have a few units grouped up there can be some strange behaviour. For example, if you are using professional scouts and you queue up 2 of them to pick up deer and then drop them off. You can only issue the drop off command when at least 1 scout has a deer picked up. If one of the scouts hasn’t picked up a deer at the time you issue the drop off command then he won’t drop it and instead just move to that location.

There might be other solutions to this problem as well. It might be worth checking out other games like AOE2 and StarCraft 2 to see how they do it.

1 Like

I don’t think it should consider something like gathering sheep at all, as thats not an explicit action. It should immediately treat the next action as if the previous action had been completed, and if at any point an action can’t be completed as commanded, the chain breaks and no further actions are carried out.

So right click a relic with a monk → shift right click a monastery. It should treat that second action as a relic dropoff action, because the first action is to grab the relic. But if the relic can’t be picked up, then the monk never travels to the monastery, he stops either where he is, or at the location the relic would have been at (preferred).

Scout right click waypoint → shift + right click deer carcass → shift right click town center. Scout will move to waypoint as normal, then he’ll attempt to move to and pick up the carcass. If he picks it up, he continues to the town center for dropoff. If he can’t pick up the deer carcass, he stops.

Then you have a lot of flexibility with commands, but you don’t have weird situations where if a command doesn’t complete, then suddenly they’re doing a completely different action (such as 1-click garrison)

1 Like