Follow orders - please follow **** orders

[Sam L.R. Griffiths]

I want the ability to issue and order and have it acted on immediately.

I want some means of issuing an order that overrides all preceding orders and is left as the only order in the queue.

Trying to control 50-60 ships in 4 different fleets by having to edit each ships order queue in the middle of a battle does not work well.

You have that means now, it requires an additional step but it is there: select one or more entities, right-click and select "clear all orders and wait", then issue the desired order. Providing no "critical" condition orders are under way they should be executed immediately.

The only alternative to this I would personally deem acceptable (without adversely affecting my gameplay) is a right-click option of "execute now" (or similar) which would work in a similar way to the approach above except there would not be a notional period of idling between the clear order and execution of the requested order. The steps in this case would be: select one or more entities, issue the desired order, right-click and select "execute now". End effect should be near enough identical in actual practice but it might address concerns about any period of idling.

Ultimately, there are UI issues in V2.0 as well as individual order following issues that seem to be messing things up. The order queuing aspect is the only part of the system that seems to be working better in 2.0 than it did in 1.6, I get less hangs and rendering issues with long order queues in V2.0 versus V1.60.

I have a station with 500+ defence drones and for some reason at one point a large number of them (283 of them) launched to deal with various threats (either in one event or several - not sure) but they seem to refuse to RTB to drone storage. This problem seems to have been made worse in V2.0 (in 1.60 I had noted something similar with the drones on my Carriers and Destroyers) and gives even more weight to individual entity AI behaviours being at fault. I eventually got them to go to internal ship storage but that is less than ideal. I realise drone behaviours are likely to be a separate logic path to NPC piloted ships but the root cause could be the same - individual order execution bugs.

[radcapricorn]

Right... back to the ignore list then.

[Archaeosis]

It's pretty obvious that giving an order should automatically clear all others, but holding shift and giving an order should queue it.

Just like every other game that's ever been made.

Having to manually clear the order queue every time is completely unworkable in urgent situations, and AI choosing to override your orders and die in the process is terribly broken.

Once both are fixed things should be much more manageable, hopefully by 2.5.

Hope this doesn't attract another 6 page essay by Rog explaining how terribly and objectively wrong I am.

[pref]

Direct orders should NEVER automatically and universally take precedent over completing ANY queued order chain (regardless of origin) since there could be consequences in other areas - especially when talking about station subordinates, but can apply in other cases too.

As highlighted already, there is the option to cancel any and all existing queued orders for the case where you need/expect an order to be executed as a matter of priority.

Yes, manual orders should take prio over behaviour ones - simply as this scenario will need less manual adjustments. Either way you have to adjust sometimes, but most of the time any order you give manually you expect to get executed when you issue it.
In the rest few cases you can still adjust priority in the queue, but at least you don't have to do it most of the time. With a modifier key this would work much more fluently ofc.
Even more so since if one or more behaviour order is executed before yours, your order might not even make sense any more as the context is gone in which you issued it due to changed positions, object existence or whatever else.
Also during execution of a behaviour originated order another could be added automatically which can delay execution of your order much further. And adding it below yours will make absolutely no sense in most cases.
The queue should treat behaviour orders with lower priority by default as long as player doesn't change any priorities manually.

The only consequence to this would be that your assets would feel like they are doing what they should.

[Sam L.R. Griffiths]

Direct orders should NEVER automatically and universally take precedent over completing ANY queued order chain (regardless of origin) since there could be consequences in other areas - especially when talking about station subordinates, but can apply in other cases too.

As highlighted already, there is the option to cancel any and all existing queued orders for the case where you need/expect an order to be executed as a matter of priority.

Yes, manual orders should take prio over behaviour ones - simply as this scenario will need less manual adjustments. Either way you have to adjust sometimes, but most of the time any order you give manually you expect to get executed when you issue it.
In the rest few cases you can still adjust priority in the queue, but at least you don't have to do it most of the time. With a modifier key this would work much more fluently ofc.

Nope - what you are talking about would introduce more faff and screwing around and would NOT result in logical nor sensible processing of orders.

The current approach is both logical and sensible, even if what you are asking for were limited to combat orders it would create issues for some like myself.

As it stands, ALL automated behaviour orders are generated as short order sets - c/f buying/selling wares for a station generates a buy order and a sell order as the primary operations - such order sets/sequences should not be interrupted mid flow by default as some are proposing.

If particular individuals are having issues with default order behaviours then it is the default order behaviours that need to be addressed - the queuing system should not be modified as some are pushing it to be. The alternative approach to order issuing that some are arguing for is anything but logical nor sensible.

[pref]

The alternative approach to order issuing that some are arguing for is anything but logical nor sensible.

So far your sole example against this was the only real nonsense in this discussion.

[waynetarlton]

Not sure why they re-invented the wheel in X4 with so much. Doesn't make sense it's kind of like it's all back to the first ever X game. Pity.

[pref]

Not sure why they re-invented the wheel in X4 with so much. Doesn't make sense it's kind of like it's all back to the first ever X game. Pity.

They haven't.
All games were this limited in commands, and for X3 mods provided essential functionalities to manage trade/combat fleets. They just became part of vanilla at some point.

There are some good additions with X4 like the command queue, or placing/modifying orders on the map. These are a nice step forward but they need some further polish.

[radcapricorn]

There are some good additions with X4 like the command queue, or placing/modifying orders on the map. These are a nice step forward but they need some further polish.

Yip. "Default behavior" should be just that: behavior when not under any specific orders. Once an order is given, it should be executed. Queuing should either be context-sensitive or done via modifiers. If you order a ship currently in combat to "fly to..." it should bloody well "fly to", not "I will fly there after I'm dead".

[Sam L.R. Griffiths]

The alternative approach to order issuing that some are arguing for is anything but logical nor sensible.

So far your sole example against this was the only real nonsense in this discussion.

Hardly, the dock at command is the only one of the current three options that reliably and accurately moves to a particular point in space (e.g. the landing docks on the carrier/station/destroyer in question) - the move to position does not allow accurate enough positioning of the target location in 3D space (it is ok for elliptic plane navigation but not for positioning in combat or other circumstances), and the follow order typically ends up with the ship being positioned at an arbitrary location relative to the targeted ship - neither is good enough for tactical usage like outlined in my example.

The current approach is workable for a wide variety of tactical options - your proposed alternative is a recipe for disaster by comparison.

The approach adopted by Egosoft for order queuing and entity heirarchy has strong similarities to the C&C methodologies behind simulations for real world C&C systems. The approach they have taken for immediate execution order support is not ideal perhaps but the bigger problem is how the orders currently cascade to subordinates for at least some orders. When a squad/fleet/wing leader is told to RTB (for example) their subordinates should be following them in formation and try to dock with the target station/ship at the same time unless there is a good reason for them not to (e.g. they have direct orders of their own that supersede the parent wing orders), as it stands (in at least some cases when ordered as a wing) they tend to lag behind the leader rather than execute the same order at the same time. This is more to do with the actual AI behaviours themselves than the order queuing system - the cascade of the order should probably always happen at the start rather than the end. The work around for the cascade issue is to independently order each ship but that kind of defeats the object of having them organised as a hierarchy in the first place.

As I highlighted before, the only compromise solution I would find acceptable and non-disruptive for me would be the addition of an "Execute Now" or "Jump to last order in queue" right-click menu option that sits alongside the "clear all orders" and "clear all orders and wait" menu options. Such a menu option would cancel all orders except the last one. You could add a "move last order to top" menu option as well but it is not as logical nor intuitive.

The execute now option would allow for the queuing of a retreat/egress order at the start of an engagement and allow for the engagement to be terminated early at a moments notice. The queueing system kind of already allows for this through setting default behaviour and using clear all orders.

Personally, I have NEVER had any trouble with understanding the order queuing approach adopted by Egosoft and IMO it is the way it should have always been implemented since day one of the X-series. The same goes for the fleet/wing hierarchy structure.

[Sam L.R. Griffiths]

There are some good additions with X4 like the command queue, or placing/modifying orders on the map. These are a nice step forward but they need some further polish.

Yip. "Default behavior" should be just that: behavior when not under any specific orders. Once an order is given, it should be executed. Queuing should either be context-sensitive or done via modifiers. If you order a ship currently in combat to "fly to..." it should bloody well "fly to", not "I will fly there after I'm dead".

That is where the clear all orders comes into play - this I have already outlined already.

The problem we have in V2.0 is less with the order queuing system and more with the orders themselves. If the default Escape behaviour worked in 2.0 as it did in 1.60 and prior there would probably be less complaining about it.

I disagree with the principle of Egosoft defining when new orders take precedent over existing orders on a unilateral basis - it should be left to the player to decide when an order should take precedent or not and that is currently catered for with the two Clear All Orders options but another menu option for execute now would not go amiss.

Given various issues with the current UI, adding too many menu options such as immediate equivalents of the currently queued options is likely to create more problems where the UI is concerned - Currently, the more UI elements that are rendered the less reliable the UI is, This seems to get worse as the number of ships and stations owned by the player increases.

[EDIT]See this article on Wikipedia for a publicly available explanation of what I am getting at.

Essentially, current default order behaviour is inline with the principles of WARNO/WARNORD, the FRAGO/FRAGORD principles are also currently supported courtesy of the clear current orders menu options. It is not ideal but direct orders should not take precedent without the player making the explicit decision to that effect. The nature of the order is not a clear indicator in itself of whether it should be a WARNO or FRAGO.[/EDIT]

[pref]

The alternative approach to order issuing that some are arguing for is anything but logical nor sensible.

So far your sole example against this was the only real nonsense in this discussion.

Hardly, the dock at command is the only one of the current three options that reliably and accurately moves to a particular point in space

The current approach is workable for a wide variety of tactical options - your proposed alternative is a recipe for disaster by comparison.

So this:

there are times you want a direct order to override, and times you don't. The situation is anything but cut and dry but the current approach is a better option than having direct commands ALWAYS overriding.

So can you say an example when instead of executing your order immediately, you want the ship to go dock and instantly undock and execute your order?

tagging a target, luring it back to the carrier/fleet/station via the dock command (follow and fly to position/object do not work well enough as alternatives), then engaging the target again when the lured target is in the desired kill zone.

is your sensible example why it would make sense generally to queue any and all direct orders after the dock command resulting from the "dock at" default behaviour? Is this a typical example in your mind and not a real rare exception?
And why would you issue any other command in this case anyway if you want to lure a ship to the carrier? How does this make any sense?
And it is by the way just a workaround for the issues with fly to and follow command even according to your interpretation so it has zero relevance to the topic at hand.

Well, lol.

[Sam L.R. Griffiths]

...

Cut the personal attack agenda - I have clearly explained a very specific example of where order queuing is appropriate in a combat setting but it is not the only possible example - it is just a very visual one.

[pref]

...

Cut the personal attack agenda - I have clearly explained a very specific example of where order queuing is appropriate in a combat setting but it is not the only possible example - it is just a very visual one.

Where am i being personal?
I'm just saying your reason is invalid, that's all.

[Sam L.R. Griffiths]

...

Cut the personal attack agenda - I have clearly explained a very specific example of where order queuing is appropriate in a combat setting but it is not the only possible example - it is just a very visual one.

Where am i being personal?
I'm just saying your reason is invalid, that's all.

Your general attitude has been highly ignorant and confrontational - you have singled out an example meant purely as an illustrative case and used it to try to discredit the points I have been making overall.

As for the dock at default behaviour, and queing orders after it - there are other cases where this might make sense but there is always the option to clear current orders before issuing the new order(s).

I suggest you review the Wikipedia article I linked to in an edit of my earlier post to understand the point myself and others have being making - it is all to do with the player being the person that should determine whether an order should be queued or executed immediately. Currently, that is supported through the "clear all orders and wait" menu option which even blocks default behaviour from adding new orders. If any orders were automatically issued as immediate that decision would have been taken out of the player's hands - something I strongly feel should not be done.

However, for now if people really are having issues with the default orders in a combat centric context perhaps they should just use the Hold Position (or defend position) default behaviour for such vessels for now. At least that way they should know EXACTLY what orders are being issued and why.

[Hornet108]

...anyway, I reckon some hotkeys to have your wingmen return to you and attack your target would be nice, no?

[ZaphodBeeblebrox]

I am just going to keep banging this drum until somebody takes notice.

1) Allow the player to decide the importance of an order and its priority.
2) Allow the player greater control of the order queue.
3) Egosoft explain the orders that are available and what they actually do.

I don't care about anybodies opinion on the queue, or each of the commands. Give more control to the player. Explicity define for all of us what a particular order does.

[radcapricorn]

...and how to give it. For example, the default behavior after assigning a ship to a wing is "Escort Ship". Unless I'm blind, once you switch it to a different behavior, you can't put it back to "Escort Ship".

[Sam L.R. Griffiths]

...anyway, I reckon some hotkeys to have your wingmen return to you and attack your target would be nice, no?

This does make more sense than what some have been asking for but I think it needs to be doable from the HUD or the enter menu either in addition to or instead of the hotkeys.

[Sam L.R. Griffiths]

I am just going to keep banging this drum until somebody takes notice.

Notice was taken the first time you posted something similar.

1) Allow the player to decide the importance of an order and its priority.

How do you propose this is improved? Currently, high priority orders are a two stage process - clear existing orders, issue the replacement order. Alternatively, you can edit the queues directly after issuing the order. However it is done, it will still inherently need to be a two stage process. My earlier suggestion of a "jump to last order, and clear the rest" or "bring last order to top, and defer the rest till afterwards" is probably the only viable way to address what you are asking for without messing things up for everyone. It would still be a two stage process though which is unavoidable without cluttering up the interface.

2) Allow the player greater control of the order queue.

You can't get much greater control of the order queue than we currently have, the only thing that could really be added is support for drag and drop of orders in the queue.

3) Egosoft explain the orders that are available and what they actually do.

The orders on the most part should be self-explanatory to anyone that has played at least X4. However, there is this page of the X4 Manual that seems to at least attempt to address this point.