-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make command queuing behave more like other RTS games #215
base: develop
Are you sure you want to change the base?
Conversation
This was resulting in non-intuitive and surprising behaviour when queuing commands. Removing this system results in Megaglest behaving more like other RTS games. For instance, the following are now possible and weren't previously: - Queuing multiple attack ground commands to move along a specific path attacking all enemies on the way. - Queuing attack ground followed by hold position, which is a sensible thing to do if you want a unit to guard a specific area. - Queuing a move command followed by a produce command, if you want to have your summoner summon a daemon at a specific location. The behaviour of queuing the stop command is unchanged, and commands that must be the last in the queue, such as morphing, are still properly replaced when something else is queued.
Maybe it would be nice to keep this under a configuration option? |
I don't see the point of using a configuration option for this. Most users are unlikely to notice that anything has changed, unless users were for some reason depending on the behavior of shift-queuing some commands cancelling other commands in queue. I'd expect that most users wanting to cancel commands however, wouldn't do shift-queuing to do so, but just issue an order without shift to remove the entire queue at once, or that they would use the stop command. |
I definitely don't care for the old behavior but maybe somebody expects/wants it. You're probably right but I'll let somebody else chime in if they care. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me overall. I'd be ok with this not a setting change, but will need the project owners to agree.
@Banestorm why should morphing be last? I think that you should be able to queue commands after morphing, such as commanding your battlemages to attack-move after morphing, etc I'd rather fix #236 here, since it's an easy fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just removing this to fix #236
Queueability isQueuable() const {return qOnlyLast;} //After morph anything can happen |
actually, no, with this the unit doesn't get replaced with the morphed unit until it stops |
Queuing anything after morph is not an easy task because you have to know which unit type will be the morph result and only allow commands of the new unit type. And I don't think this is possible with the current GUI where you only see the commands/skills, not the ones of the future unit type. |
My understanding is that this is how other major RTS games work as well. Sometimes the use case is to do multiple queued attack to grounds, to say, clear out a full enemy base. |
@titiger, @Banestorm I send new PR #257 based on this, which allowing to queue command after morphs |
I already saw it's not as simple as I thought, this can be left to another PR/issue.
Yes, this is how it works in most other RTS games I know. Another thing this allows is a poor man's patrol (which MG lacks) |
|
...by removing the command priority system
The command priority system was resulting in non-intuitive and surprising behaviour when queuing
commands. Removing this system results in Megaglest behaving more like
other RTS games.
For instance, the following are now possible and weren't previously:
attacking all enemies on the way.
thing to do if you want a unit to guard a specific area.
have your summoner summon a daemon at a specific location.
The behaviour of queuing the stop command is unchanged, and commands that
must be the last in the queue, such as morphing, are still properly replaced when something
else is queued.