HomeWildfire Games

Enable production entities to autoqueue.
AuditedrP25381

Description

Enable production entities to autoqueue.

This adds a new command button that enables training of units automatically.
Use:

  • Enable auto-queue.
  • Train an entity.

This adds a new item to the queue whenever the previous item starts, such that good micro is more resource-efficient.

Patch by: @azayrahmad
Differential revision: https://code.wildfiregames.com/D3865
Comments by: @Langbart, @nani, @Stan, @wraitii

Details

Auditors
nani
Committed
FreagarachMay 5 2021, 8:12 AM
Differential Revision
D3865: Auto-Queue feature
Parents
rP25380: [Windows] Automated build.
Branches
Unknown
Tags
Unknown
Build Status
Buildable 17070
Build 39190: Post-Commit BuildJenkins
Build 39189: Post-Commit Build (macOS)Jenkins

Event Timeline

nani raised a concern with this commit.Jun 8 2021, 6:14 PM

Although the auto-queue works it has some pretty apparent broken functionality:

  • The automatic adding to the queue happens always when the first one starts training the unit not after trained (or completed)
  • The previous problem makes it worse when you want to delete the unit that is in training (or all the units in the queue) and the auto queue starts to add more units to queue before you can delete them.

You can see the problems if you try to play a game with it enabled.

This commit now has outstanding concerns.Jun 8 2021, 6:14 PM
Stan added a comment.Jun 8 2021, 6:16 PM

@nani Apparently it's intended so it's no OP.

nani added a comment.Jun 8 2021, 6:17 PM
In rP25381#52928, @Stan wrote:

@nani Apparently it's intended so it's no OP.

Well, that makes no sense

Stan added inline comments.Jun 8 2021, 6:27 PM
/ps/trunk/binaries/data/mods/public/simulation/components/ProductionQueue.js
812

@nani Maybe this make a bit more sense ? ^

Another concern by @PlayerOf0AD this should check for entity limits.

In rP25381#52929, @nani wrote:

Well, that makes no sense

As written, it does, it makes auto queue slightly worse than manual queueing.

The previous problem makes it worse when you want to delete the unit that is in training (or all the units in the queue) and the auto queue starts to add more units to queue before you can delete them.

That is more problematic, we probably de-activate the auto queue if the production queue is manually changed.

Creating ticket.

nani added a comment.Jun 8 2021, 6:51 PM
In rP25381#52929, @nani wrote:

Well, that makes no sense

As written, it does, it makes auto queue slightly worse than manual queueing.

The previous problem makes it worse when you want to delete the unit that is in training (or all the units in the queue) and the auto queue starts to add more units to queue before you can delete them.

That is more problematic, we probably de-activate the auto queue if the production queue is manually changed.

Creating ticket.

That would remove any benefit or reason to exist for an auto queue functionality, the original idea of an auto queue is to let the player to more interesting things than just clicking to make more units. If we, for example, do this you proposed, then what's the point of having something called auto(matic) if you need to manually change it back it every time you do anything.

As for:

As written, it does, it makes auto queue slightly worse than manual queueing.

Again, that makes no sense. The tool, that is the auto queue does one thing any only one and if t is broken then is the same as saying is not worth the hassle to use it because the idea of automatic the action is not met.

If you want to make the auto queue less appealing to use don't cripple the tool but instead make it have negative consequences, like 5% longer production time or the unit being slightly more costly or having to make research a tech before being able to use it.

(sorry for rant but when I played the game svn I was spending inordinate amounts of time managing the auto quene manually which was very annoying)

In rP25381#52938, @nani wrote:

That would remove any benefit or reason to exist for an auto queue functionality, the original idea of an auto queue is to let the player to more interesting things than just clicking to make more units.

Mh, I see your point. I definitely didn't consider that, and it does make it less useful than it could be.

Again, that makes no sense. The tool, that is the auto queue does one thing any only one and if t is broken then is the same as saying is not worth the hassle to use it because the idea of automatic the action is not met.
If you want to make the auto queue less appealing to use don't cripple the tool but instead make it have negative consequences, like 5% longer production time or the unit being slightly more costly or having to make research a tech before being able to use it.

I'm not seeing much of a difference in practice. Except for the above issue, the autoqueue is 'pessimised' by holding some more resources 'hostage'. This is a debuff that feels equivalent to costlier units or longer production time.

@nani has the autoqueue been adapted enough to your liking?

Silier added a subscriber: Silier.Jun 20 2021, 8:23 PM

@nani has the autoqueue been adapted enough to your liking?

Sorry but thats wrong question.
Feature should not be changed just to please someones liking but to adress flaws it has. In case it does not have them, it should not be changed.

nani added a comment.Jun 20 2021, 10:29 PM

@nani has the autoqueue been adapted enough to your liking?

Tried it, I think it behaves as it should now. As I said before, we could add some negative characteristics like a % extra time to train an unit or something similar but that can be added with ease in the next alpha if in this one we detect the function is too overpowered (personally I think is not, but I like it because I have to click less and thus don't get my wrist all work up, see https://en.wikipedia.org/wiki/Carpal_tunnel_syndrome )

In rP25381#53209, @Angen wrote:

@nani has the autoqueue been adapted enough to your liking?

Sorry but thats wrong question.
Feature should not be changed just to please someones liking but to adress flaws it has. In case it does not have them, it should not be changed.

Well, no comment on this, just want a better 0ad experience.

In rP25381#53209, @Angen wrote:

Feature should not be changed just to please someones liking but to adress flaws it has. In case it does not have them, it should not be changed.

I agree, but the concern seemed to be a matter of preference, so hence the way I asked the question. But I guess it is not enough, since @nani did not resign from this commit yet.

nani accepted this commit.Jun 21 2021, 1:57 PM

But I guess it is not enough, since @nani did not resign from this commit yet.

No, the issues I mentioned before are now fixed (D4144), I just forgot to set as resolved.

All concerns with this commit have now been addressed.Jun 21 2021, 1:57 PM