Power queue patch

[wzdev-ci]

keyword_power resolution_fixed type_to-do (no feature requests!) | by Zarel

---

What it does

Overhauls trunk power code. Replaces the current "power flow" system in trunk with a "direct debit" system, and adds a queue system for handling power.

Why it does it do it

When gerard_ quietly committed his overhaul to the power system, I saw several flaws with it. At the time, though, I was busy with other work, so I just mentioned I disagreed with the system and that I would work on a replacement proposal.

Around half a year later, gerard_ logged into IRC, and I remembered I was supposed to work on a replacement proposal. I brought it up, and he agreed that his power flow system had a few flaws, and liked my proposal better. Several other users (I don't remember who, but I think Daltx, EvilGuru, Kreuvf, and Safety0ff were among them) did as well.

So the proposal is this: Direct debit plus power queue.

Direct debit is the system used in Supreme Commander 2, as well as all the C&C games (I think) and all the StarCraft games. They use it because it's the best. When you want to make something that costs, say, 50 power, your power goes down by 50 and you stop making it.

Anyway, basically, the biggest problem with the power flow system: You never know how much power you have. Say you want to build something that costs 50 power. You have 60 power left. Do you have enough power to pay for it? Answer: It depends on how many other things you're currently spending power on. This means that: You have to keep track of what's sucking power, and you also have to do a bunch of complicated math to figure out if you have enough power left to do anything.

That's the advantage of direct debit. You instantly know. Is 50 less than 60? If so, you have enough power. If not, you don't.

The second disadvantage of power flow is that, since there are sources of power decrease as well as power increase, you need a complex interface to keep track of it all and visualize it. With direct debit, all power deductions come instantly, so no complex interfaces are necessary, besides maybe queue jumping, which can be as simple as double-clicking.

The third disadvantage of power flow happens when you're at zero power. Say it takes 1 minute to accumulate enough power for a tank. If you just naively click on a tank in the two factories, you won't have either tank until 2 minutes have passed. But if you make one tank, and then start the second one right when the first finishes, you'll have one tank after 1 minute, and you'll still have both at the 2 minute mark. That means the power flow system encourages micromanagement.

My direct debit system automates that process - if you're low on power, it automatically puts all your power into the first thing in your power list, instead of spreading it around. That way, the last thing takes just as long, but you get everything else much faster, and this all happens automatically, instead of you having to micromanage it when you, as an RTS gamer, have better things to do, like micromanaging an attack, or building up your base.

gerard said that the only reason he implemented a power flow system instead of a direct debit system is because direct debit systems traditionally disallow you from building things once you're out of money. My patch solves this with a power queue - instead of disallowing the build, it puts it on a queue instead, and thus my patch is superior in every way to the current system, and gerard endorses it.

Per had some reservations about it, which is why I'm posting this lengthy justification of my patch. I hope this explanation (and the support of the majority of users and devs, including the guy who wrote the old system) is enough.

---

Issue migrated from trac:1970 at 2022-04-15 22:05:27 -0700

[wzdev-ci]

Zarel uploaded file powerqueue8.patch (67.5 KiB)

most of the bugs have been worked out

[wzdev-ci]

duckblaster commented

---

i think it is a good idea, very useful although it could be a bit better with some sort of priority system so if you have low power and try to build a power generator it get power first no matter what

[wzdev-ci]

Zarel commented

---

That's what I was talking about in reference to queue jumping: If you double-click on something, it will go to the front of the queue (and get power first).

[wzdev-ci]

Per commented

---

droid.c: In function ‘droidUpdateBuild’: droid.c:1110: error: ‘pointsToAdd’ may be used uninitialized in this function

hci.c: In function ‘intStatsRMBPressed’: hci.c:6515: error: passing argument 1 of ‘powerQueueCancelWorker’ from incompatible pointer type power.h:144: note: expected ‘struct BASE_OBJECT ’ but argument is of type ‘struct FACTORY ’

research.c: In function ‘researchResult’: research.c:1747: error: implicit declaration of function ‘StructureGetResearch’ research.c:1747: error: invalid type argument of ‘->’ (have ‘int’) research.c:1748: error: passing argument 1 of ‘powerQueueCancelWorker’ from incompatible pointer type power.h:144: note: expected ‘struct BASE_OBJECT ’ but argument is of type ‘struct STRUCTURE ’ research.c: In function ‘cancelResearch’: research.c:1981: error: ‘psResearchFacility’ undeclared (first use in this function) research.c:1981: error: (Each undeclared identifier is reported only once research.c:1981: error: for each function it appears in.)

structure.c: In function ‘cancelProduction’: structure.c:6849: error: passing argument 1 of ‘powerQueueCancelWorker’ from incompatible pointer type power.h:144: note: expected ‘struct BASE_OBJECT ’ but argument is of type ‘struct STRUCTURE ’

A little hard to test when it does not even compile correctly...

[wzdev-ci]

Per commented

---

Add reference to original power flow patch in #386 for those who are interested.

[wzdev-ci]

Zarel changed status from new to accepted

[wzdev-ci]

Zarel changed owner from ` toZarel`

[wzdev-ci]

Zarel commented

---

Replying to Warzone2100/old-trac-import#1970 (comment:3):

A little hard to test when it does not even compile correctly... It compiles correctly in Mac OS X. No warnings, either.

Can you come on IRC?

[wzdev-ci]

Zarel uploaded file powerqueue10.patch (71.7 KiB)

New version

[wzdev-ci]

Zarel commented

---

Okay, so basically, remember how Per mentioned that you didn't get power back when you undid manufacturing? I thought that was weird, since I replaced all the old power code with my new stuff. So I searched through the code, and found:

// FIXME: give power back 

where the "give back power" code should be. Apparently gerard_ never got around to implementing giving back power since he replaced the old code in [7097]. Another advantage of my new power code: It's a lot simpler to calculate how much power needs to be given back!

Anyway, powerqueue10.patch fixes this, so we have no problem now.

powerqueue10 also improves progress bar visualization, and might fix compilation on Linux - please tell if it doesn't.

[wzdev-ci]

Per commented

---

You missed one of the issues I told you about last time:

droid.c:1110: error: ‘pointsToAdd’ may be used uninitialized in this function

I still do not understand how it is supposed to work with regards to build queues. Are they supposed to be deducted immediately, or when the item arrives at the front of the queue?

The power calculation seems wrong for droids. I turn off all power income, then look on the power meter at the bottom of the screen how much power something would cost me. Then I click on that item, and I end up with far less power left than the power meter said I would have. (This seems to work for construction and research, though.)

The debit is instant. Instant changes are bad. All changes of this kind should be animated, even if this is merely an illusion.

I ended up with negative amounts of power. Lots of it. Surely this is not intended?

Power queue priority change by clicking on 'on hold' items did not seem to work.

With all of these issues, you can imagine that I am still a bit less than enthusiastic.

[wzdev-ci]

Buginator commented

---

I don't really see what the major advantages are to your system, compared to the system we have now. It is just another way to handle power, with no real major advantage that I can find, unless you are trying to clone another game's way they handle power ?

Besides what Per said, I am also wondering what changes will be needed for the AI to notice the differences, and how will this play out with the whole campaign game ?

[wzdev-ci]

Zarel commented

---

Replying to Warzone2100/old-trac-import#1970 (comment:7):

You missed one of the issues I told you about last time:

droid.c:1110: error: ‘pointsToAdd’ may be used uninitialized in this function

Okay, I've fixed that in the next patch. For now, just initialize pointsToAdd to 0 a few lines above.

I still do not understand how it is supposed to work with regards to build queues. Are they supposed to be deducted immediately, or when the item arrives at the front of the queue?

In terms of code (and the power bar size), it's deducted from the player's currentPower value when the power is allocated (i.e. right when the yellow progress bar starts to move).

In terms of the number displayed to the left of the power bar, the number represents the amount of power you'd have after everything in the queue is deducted. It also represents the amount of power you'd have after whatever your mouse is currently hovering over is deducted (default 1.00 behavior), so it's kind of annoying to get the actual value. I'll probably fix it to be easier to interpret at some point.

Of note: There's an assert if you partially demolish a power generator, then build it up again. The assert is "safe" in that you can continue over it without corrupting anything, but it does mark a bug (in trunk, not in my patch), so I don't want to remove it.

The power calculation seems wrong for droids. I turn off all power income, then look on the power meter at the bottom of the screen how much power something would cost me. Then I click on that item, and I end up with far less power left than the power meter said I would have. (This seems to work for construction and research, though.)

Keep note the above: The power displayed is how much power you have after deducting what you're hoving your mouse over. That said, I'll test for this bug in a bit.

The debit is instant. Instant changes are bad. All changes of this kind should be animated, even if this is merely an illusion.

StarCraft 2 uses instant changes, and iirc so does C&C 3, Red Alert 3, SupCom 2, StarCraft 1. I can think of a few that animate down (AoE 2?), but from what I know it's not common. Animation can be frustrating for people with fast reaction times, which is why I think so many games don't do it.

That said, sure, I can implement that at some point, but let's not have that be a blocker for this patch, k? Preferably, we'd open another ticket for it after this one was committed, where we can discuss the pros/cons there.

I ended up with negative amounts of power. Lots of it. Surely this is not intended?

The power level indicator is after queued power. I mean, it's more informative to see "-100" which means "all my queue will have been processed after I earn 100 power" than "0" in the old system which means "we're out of power, and we have no idea when we'll have more of it."

Maybe I could show it with two values, like "0 (-100)"

Power queue priority change by clicking on 'on hold' items did not seem to work.

I haven't implemented it yet. I don't think it should block the patch, either, since "order of original selection" is still better than the old system, which was the equivalent of "everything last".

With all of these issues, you can imagine that I am still a bit less than enthusiastic.

Other than a possible bug in the way manufacture cost is calculated (which I will fix before committing), I don't think any of the other problems you report should be blockers, since they are things that are worse in current trunk. I can fix those at some point, but I shouldn't have to fix every trunk bug before I commit my patch.

[wzdev-ci]

Zarel commented

---

Replying to Warzone2100/old-trac-import#1970 (comment:8):

I don't really see what the major advantages are to your system, compared to the system we have now. It is just another way to handle power, with no real major advantage that I can find, unless you are trying to clone another game's way they handle power ?

You know, I spent like eleven paragraphs explaining the advantages to my system in the ticket summary, and I just mentioned two more advantages in my two previous comments. You could at least acknowledge that I've tried, and say something like "I don't consider anything you've said so far to be a major advantage." :(

Anyway, here's the pro/con you asked for on IRC:

Pro: You know at all times exactly how much money you have to spend.

Pro: The system is more similar to 2.3 than gerard/trunk is (functionality-wise), so users will have an easier time adjusting.

Pro: The system is more similar to 2.3 than gerard/trunk is (balance-wise), so users and AIs will have an easier time adjusting.

Pro: The system queues power allocation instead of spreading out power allocation, which means that, at low power, building, say, 5 1-minute tanks on 5 factories will produce 1 tank a minute, instead of waiting 5 minutes before they get produced.

Pro: The system requires less micromanagement. Producing 1 tank a minute in gerard/trunk (or 2.3, for that matter) required a ton of micromanagement that should be spent directing tanks or deciding what to research/manufacture. The power queue automates the process so the time can actually be spent doing the latter.

Pro: The system makes many different power calculations in the code far easier. For instance, the thing that was so hard for gerard_ he never got around to fixing it was a one-liner in my code.

Pro: Since power deductions occur instantly, there's no need for complex interfaces visualizing what's sapping your power. (Witness SupCom1 and all the "-x" "+x" numbers on all the structures, and the interfaces for turning structures on/off - that's too much micromanagement that detracts from actually playing the game.)

Pro: Since power deductions occur instantly, your power always rises at a constant rate, so there's no need to go around hunting for possible drains on your power if you need to divert all your available power towards one important thing.

Pro: Since power deductions occur instantly, all you have to do to see if you have enough power to do something is to compare your current power with the price. If the price is higher, you don't. Otherwise, you do. With gerard/trunk, the calculations require some fairly complex calculations to handle the changing power flows.

Con: You won't be able to play the "keep your power flow above 0" minigame. This is the only advantage of gerard/trunk I've heard from Per, and it's rather questionable - personally, I'd rather play the game than micromanage that.

These are all the cons, but I think I missed a lot of pros.

Besides what Per said, I am also wondering what changes will be needed for the AI to notice the differences, and how will this play out with the whole campaign game ?

None at all. See our IRC conversation and above.

[wzdev-ci]

Per commented

---

First and mostly unrelated, I am really tired of half-finished, half-broken patches going into trunk, which is why I have started doing future movement work in a branch.

Second, the fact that you see a thousand pro and only one "questionable" con for this patch is in itself a warning flag for me. It means you are not thinking this through carefully enough.

I have read all your arguments, took time to think about it, and tested your patches, and I remain unconvinced. I disagree that this system is closer to 2.3 than trunk. 2.3 has a two phase power flow, not any kind of direct debit. I disagree on all points that depend on the assumption that a user's power flow will always be negative and storage currently at zero. Power management is not that hard. Even the AI can do it, and it is one of the things it was actually quite fun to teach semperfi (a digression, not an argument). In fact, if you play frugally with your power, which is always a good idea, good power management comes naturally.

I disagree on less micromanagement and simpler interface - in fact, I think that once (if) you move closer to the finish line with your patch, you will be forced to make things rather more complicated than the extremely simpler interface we have now (which is 2.3 just made simpler by removing one accrue phase). Turning on/off power drains is currently simple, the only thing that is hard is understanding their relative priority, but I do not see that as a big issue since you do not have to worry about it at all as long as you are frugal with your power. On the other hand, I have yet to see how simple managing the power queue will be.

Lastly, showing a negative amount of power is completely broken, as far as communicating anything to the user goes. Showing two numbers is confusing (and twice as complex as 2.3/trunk interface-wise).

I am pretty sure that this discussion does not belong in a ticket, though. We should take this to the mailing list or the forum.

[wzdev-ci]

Zarel commented

---

Replying to Warzone2100/old-trac-import#1970 (comment:11):

First and mostly unrelated, I am really tired of half-finished, half-broken patches going into trunk, which is why I have started doing future movement work in a branch.

I said I'd fix all the regressions before committing. Again, I do not think I should have to fix every trunk bug and flaw before committing this.

Second, the fact that you see a thousand pro and only one "questionable" con for this patch is in itself a warning flag for me. It means you are not thinking this through carefully enough.

It means I understand well the reasons why nearly every RTS uses my system, and only one that I know of (SupCom) uses power flow, and that one has ridiculously complex power management.

I have thought about this for ages, and you are really the only one with any disagreement, and as far as I know you haven't even given any valid reasons against the patch (that don't have to do with the implementation, which can be fixed) besides the one I mentioned.

I have read all your arguments, took time to think about it, and tested your patches, and I remain unconvinced. I disagree that this system is closer to 2.3 than trunk. 2.3 has a two phase power flow, not any kind of direct debit.

The first phase is pretty much direct debit, except less efficient.

I disagree on all points that depend on the assumption that a user's power flow will always be negative and storage currently at zero.

Power systems have practically no difference when storage is significantly higher than zero, or power flow is positive. There's one exception: it's far easier to tell whether or not your storage will fall below zero in a direct debit system.

Power management is not that hard. Even the AI can do it, and it is one of the things it was actually quite fun to teach semperfi (a digression, not an argument). In fact, if you play frugally with your power, which is always a good idea, good power management comes naturally.

I disagree on less micromanagement and simpler interface - in fact, I think that once (if) you move closer to the finish line with your patch, you will be forced to make things rather more complicated than the extremely simpler interface we have now (which is 2.3 just made simpler by removing one accrue phase). Turning on/off power drains is currently simple, the only thing that is hard is understanding their relative priority, but I do not see that as a big issue since you do not have to worry about it at all as long as you are frugal with your power. On the other hand, I have yet to see how simple managing the power queue will be.

No, power flow is not 2.3 made simpler by removing one accrue phase, it's 2.3 made simpler by merging the two phases, so that power accruing happens slowly, which I believe is undesirable.

You keep using that term "as long as you are frugal with your power". No power system has any flaws as long as you're frugal with your power. I've repeated that many times - what is unclear or incorrect about that statement?

And, again, it's far easier to be frugal with your power in a power queue system, since you can see exactly how much power you have left, and exactly how much power you'll have left after you do something that uses power.

Heck, I think the accrue phase was Pumpkin's way of animating the power drain (like you were talking about) of a direct debit system. If you really hate mine, let's talk about reverting power flow as well, as it has lost the support of pretty much everyone, including its original author.

Lastly, showing a negative amount of power is completely broken, as far as communicating anything to the user goes. Showing two numbers is confusing (and twice as complex as 2.3/trunk interface-wise).

You are not proposing keeping trunk the way it is? Trunk, if it were to be kept, would need at least three numbers: Current power, positive flow, negative flow. You know, the way SupCom does it. Also of note: Supreme Commander shows a grand total of 5 numbers per resource - far more complex than the two I'm proposing. Or are you seriously suggesting giving no hint whatsoever about the direction of power flow? Gerard was planning on adding those visualizations, you know.

You accuse me of ignoring the flaws of my own system, and yet you champion an incomplete patch that you don't even wish to be completed?

[wzdev-ci]

Per commented

---

Please stop extrapolating and exaggerating to try to make your case, it does not help. Yes, I propose keeping trunk the way it is. Gerard was indeed planning to add visualizations, and I talked him out of it. I do not think it is necessary, as you can see what is going on by looking at changes to the power meter (except, again, when it has hit rock bottom).

Now let's move this discussion to the forums.

[wzdev-ci]

Per commented

---

I made a forum post http://forums.wz2100.net/viewtopic.php?f=6&t=5887 to kick off the debate.

[wzdev-ci]

Zarel uploaded file powerqueue-pre11.patch (78.0 KiB)

Preliminary next version

[wzdev-ci]

Zarel commented

---

powerqueue-pre11.patch contains a few unrelated patches that I haven't had time to separate out. But I wanted to push it out ASAP because it also contains support for double-click-to-move-to-front-of-queue.

I also tested manufacturing units. It bills accurately, and I've created patch #1992 (which is one of the patches that haven't been separated out of this one) to easily visualize that.

[wzdev-ci]

Zarel uploaded file powerqueue11.patch (76.2 KiB)

Split the patches out - rebased in current trunk

[wzdev-ci]

Safety0ff commented

---

I tried playing the latest patch on NTW2 ( I only used 4 generators.) And the following happened (see screenshots.)

I noticed I was getting low on power ( -14k) so I cancelled everything except funded research and my power was still in the negative.

So I tried using power and things were funded as it I had sufficient power (except for the power module, which stayed at full green bar.)

Screenshots are in the archive I'm about to upload.

[wzdev-ci]

Safety0ff uploaded file bug.tar.gz (1398.5 KiB)

[wzdev-ci]

Zarel commented

---

Replying to Warzone2100/old-trac-import#1970 (comment:16):

I noticed I was getting low on power ( -14k) so I cancelled everything except funded research and my power was still in the negative.

Yeah, that's one of the problems with building. You have to demolish the structure to cancel the build. :/ I'll look into auto-deallocating it like in 2.3.

Alternatively, this might be a different, unrelated bug.

[wzdev-ci]

Safety0ff commented

---

Replying to Warzone2100/old-trac-import#1970 (comment:17):

Yeah, that's one of the problems with building. You have to demolish the structure to cancel the build. :/ I'll look into auto-deallocating it like in 2.3.

Alternatively, this might be a different, unrelated bug. Just fyi I had finished building everything.

[wzdev-ci]

Buginator changed milestone from 3.0 to unspecified

[wzdev-ci]

Buginator commented

---

This will not be in 3.0, setting to unspecified.

[wzdev-ci]

Per changed status from accepted to closed

[wzdev-ci]

Per changed resolution from ` tolater`

[wzdev-ci]

Dylan Hsu endlessnumber@... commented

---

You may dislike my past actions but it is imperative that I state my case here.

It is imperative that either 2.3's power system or a direct debit system is implemented for 3.0. If you disagree, be VERY sure that you have some competitive multiplayer experience on which to base your argument. Empirically, in the RTS world direct debit reigns supreme. As one of the strongest players of this game (if not the strongest player), I feel I have a good perspective on this issue. If you would like some perspective, I am still roaming IRC, but I have been less active lately. My skills are intact. I have videos of my competitive 1v1 wins which you can watch should you wish to gain some perspective. But I digress.

The lowest-manpower solution is keeping the current state of power flow. The highest-manpower solution is switching to a direct debit system with a queue. Reverting to 2.3 power system is a modest expenditure of manpower and employs a tried-and-true system once more. Power flow is unplayable in a competitive setting. Direct debit can become intensive in micromanagement. 2.3 power system has worked and will perform equal to or better than a prospective direct debit situation in the future.

Releasing 3.0 with power flow would equate to shooting your racehorse in the leg before the gates open. Be very careful, gentlemen, for the sake of this project. I offer you my competitive perspective if wanted, and if unwanted, so be it. You can kill your 3.0 release if you really want to. I am powerless to stop you.

I suggest reopening this ticket and beginning discussion anew.

Yours, D

[wzdev-ci]

Dylan Hsu endlessnumber@... changed status from closed to reopened

[wzdev-ci]

Dylan Hsu endlessnumber@... changed resolution from later to ``

[wzdev-ci]

Zarel changed status from reopened to assigned

[wzdev-ci]

Zarel changed type from patch (an actual patch, not a request for one) to to-do (no feature requests!)

[wzdev-ci]

Zarel changed milestone from unspecified to 3.0

[wzdev-ci]

Zarel commented

---

This patch is incompatible with the current master, and at this point will be fairly difficult to port. I'm going to rewrite this when I have time, but I can't guarantee when that will be.

[wzdev-ci]

Cyp changed status from assigned to closed

[wzdev-ci]

Cyp changed resolution from ` tofixed`

[wzdev-ci]

Cyp commented

---

Master now has a power queue. Thanks for reporting, and please reopen if the problem still exists.

[wzdev-ci]

cybersphinx changed milestone from 3.0 to unspecified

[wzdev-ci]

cybersphinx commented

---

Milestone 3.0 deleted