Skip to content
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

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

Banestorm
Copy link

...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:

  • 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.

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.
@Banestorm Banestorm changed the title Make unit queuing behave more like other RTS games Make command queuing behave more like other RTS games Jul 17, 2022
@Jammyjamjamman Jammyjamjamman self-requested a review July 19, 2022 21:55
@Rampoina
Copy link
Contributor

Maybe it would be nice to keep this under a configuration option?

@Banestorm
Copy link
Author

Banestorm commented Jul 28, 2022

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.

@Rampoina
Copy link
Contributor

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.

Copy link
Contributor

@Jammyjamjamman Jammyjamjamman left a 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.

@Rampoina
Copy link
Contributor

Rampoina commented Aug 7, 2022

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

@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.

Copy link
Contributor

@Rampoina Rampoina left a 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

@Rampoina
Copy link
Contributor

Rampoina commented Aug 7, 2022

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

@titiger
Copy link
Member

titiger commented Aug 24, 2022

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 serious opinion: don't queue anything after morph commands.
For queuing attack commands to ground ... Those willl never end if there are any units in range. So queuing anything after this will quite likely not have the wanted/expected result in many cases.

@Banestorm
Copy link
Author

For queuing attack commands to ground ... Those willl never end if there are any units in range. So queuing anything after this will quite likely not have the wanted/expected result in many cases.

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.

@pavanvo
Copy link

pavanvo commented Aug 24, 2022

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.

@titiger, @Banestorm I send new PR #257 based on this, which allowing to queue command after morphs

@Rampoina
Copy link
Contributor

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.

I already saw it's not as simple as I thought, this can be left to another PR/issue.

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

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)

@andy5995
Copy link
Contributor

Another thing this allows is a poor man's patrol (which MG lacks)

@titiger Forum post related to patrolling

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants