New Top Bar. It now shows the correct resource pull and can show a Build Power Bar

[warped glade]

I will have a look at it, but I can't promise anything, since I am very new to all this programming stuff.

[knotty escarp]

fair points - i'm unsure about this approach tbh - the simple bar mechanic seems the easiest to understand (still even need a tooltip for new players)

Sure! lets get it in there (as a setting) and gather more feedback.
We still have the entire rest of the UI to look at/design/refine 😄

[warped glade]

We just need to decide what version we want to go live with.

My suggestion would be something like this:

Combined with the improved indicators
#1167027291440812063 message

And the flags that are under the top bar.
I think it is better to have them below the bar. That makes it easier to see without any flashing or intense colors.
#1167027291440812063 message

[knotty escarp]

how about this one?

[warped glade]

In my mind there are a few things that need to be done to finally implement it into the main game (list will grow but the target is set and achievable) 🎉

1. Get stuff working with Beherith's lua
2. implement the final graphics we decided to go with.
   a) designers design
   b) we implement it
3. get the switches working that @signal forum started in this PR
4. get the Tooltip right (they are in a separate file)
5. get an explanation of this new top bar on the website
   #1167027291440812063 message

[warped glade]

With "reserved BP" ?
In my opinion it would be a gain.

Ok so to summarize:
A short bar in the middle, with a small build icon on the top left. The window has round edges on the bottom. It is a bit higher than the other two windows. The bar is on the same height and has the same height as the other bars.
BP bar with used, reserved, total BP.
Without total numbers, just the %.
Flags will appear under the BP. The flags should say:
Energy
Metal
Idle BP
Anything else? Reclaim BP? Build BP?

Some more details: should the window overlap like we see here?
Should the color of the % get red if things go wrong?
Have I forgotten anything?
How much shorter is the BP window opposed to the other two?

[steel hemlock]

seems like this has come along nicely can't wait to try the new version robert

[warped glade]

@knotty escarp
Regarding point 5) of the growing list:
How do we start here? My repository and this threat have some explanations. Are they good enough? Should we reach out to a streamer to make a tutorial? That might help...

[inland haven]

Why would the BP bar -not- be drawn if someone has chosen to use this widget? Is that for if this gets merged to the base game and someone wants to hide the BP portion?

[knotty escarp]

Yes this certainly can help.

You may also write down the simplest form of explain this with screenshots.
This should probably go into the "widgets" forum - though we could also add this to the 'guides' section on the website (though I think it's better to do that once it fully developed/ready)

a video might be the best way indeed

[warped glade]

exactly that
AND to see the actual resource request

[inland haven]

What do you mean, to see the actual resource request?

[steel hemlock]

@warped glade if you need help writing explanation and getting the screenshots I can help also sorry I kind of left with out saying anything I got bogged down with a lot of school stuff

[warped glade]

There are issues with the calculations with low priority cons. They get ignored as soon as you stall their resource needs will be ignored totally.

But this widget gets those calculations right.

[inland haven]

What needs to happen for this PR, @signal forum @warped glade ? https://github.com/roberthartmann/widgets_for_BAR/pull/1

[warped glade]

The switches seem to crash the widget somehow. It is not necessarily the "fault" of the switch functions, thought.
I made some notes to where I thought the different parts of the widget pull their info from and made some

if xxx == true then

end

Parts but I never tested it fully if all combinations worked properly.

[inland haven]

And @knotty escarp @warped glade @mild python : what's the benefit of showing a percentage-used number? The bar already indicates used/reserved proportions, in a more visual form.

[warped glade]

The % gives you a better feeling I guess. It isn't necessarily the number that is necessary, just the feeling. And if there is a number you can color it. e.g. 20% bad... So it's red.

[inland haven]

I found this a little confusing but I assume you mean "making sure that used/reserved BP isn't below 50%" as well as "if eco-supported BP is 90%+ it's time to build more BP".

[subtle plaza]

I was referring to this version. While using this, the bar was nice, but my eye keyed in on the % number first.

[inland haven]

I still feel like the single most important number to show is how much extra BP you need, if any, to keep up with income. This number would disappear when you're no longer BP-constrained. If the number is bouncy we can smooth it out. This could be colored based on the ratio between it and total BP. Maybe 101-120% is yellow and 120%+ is red. E.g. total BP is 500, eco-supported (min of metal-supported and energy-supported) is 580, you'd see a "-80" in yellow, as 580/500 = 116%. This would be accompanied by a "need more buildpower" tooltip.

If the goal is for the UI to be simple and also tell users what to do, showing the BP deficiency as a number is useful because it tells a power-user how many cons they should queue up.

[warped glade]

If you manage to do that I am on fire!
I just don't see how to achieve it with such a difference in M/BP and E/BP.
But I am more than happy to be proven wrong.

In my head it's like
I have 10 metal. I need 100 BP to spend it when I build a factory.
Now I want to build wind. That will take about 500BP to do it.
But do I really need 400 BP now? Does that make any sense? Only if I want to go 100% for now. As soon as I start a Thud the total need of BP will drop to 200. That will be very confusing. But as I said I am happy to learn.

[warped glade]

we could simplify it by just taking the average metal income and show the user how much BP he has relative to that.

[mild python]

I think it presents the key information in a more succinct way. It's important to have pretty precise values for metal and energy for a variety of reasons, but for BP the goal of this new bar is really just to give users a sense for how they are utilizing their BP. Having a full-size bar with tons of specific numbers is not necessary given the information it's trying to convey, and can lead to information overload and lots of visual noise.

To be clear this is my own opinion, if you like all that extra information portrayed, more power to you. But I would personally not use this widget in its current state, not at all to discount the amazing work that Robert has done, but it simply too large and too detailed for what I would want to get out of it, which is "how well am I balancing BP with m/e". Granted this opinion comes from someone who has been playing this game over a decade, so I have a strong intuition about that that newer players won't have yet.

I think a simplified version that takes up less space and displays fewer precise numbers will be more helpful and easily digestable particularly by newer players who don't really understand BP and need some extra guidance, and for those who want precise numbers, a lot could be displayed in tooltips (or, depending on how much option support robert wants to put in, a more detailed display could be optional)

[inland haven]

Here's what I have now, including the debug tooltip showing my math. This was a contrived example where I had a bunch of income but only 480 BP. This economy would have supported 274 additional BP (limited by E), rounded down to the nearest 10 for display purposes (and because AFAIK all buildpowers in the game are multiples of 10). As I keep my eco constant but build more BP, this 270 will drop and eventually disappear. I am considering showing a BP surplus in those cases, so there's not just an empty spot, but to show it in grey (perhaps a smaller font too) so it doesn't draw too much attention. If I do this, the deficit would be prefaced with a "-".

This could be improved by making the icon smaller so it can be next to the BP surplus/deficit number.

If you really need to know how much active/reserved/total BP you have, I think the tooltip is the best place.

Notice I also removed BP.png in favor of stock construction stripes for consistency with the base game and to make widget install easier (no more images!).

+552 E income, minus the -42 spent by non-builders, is 510 E available for builders. Current builders are spending 0.676 E per BP, so we could support 510 / 0.676 = 754 BP on this E income. Doing the same math for metal says you could support 801 BP. The lower of those two is 754, and I have 480 already, so I need to build 274 more (rounded down to 270) to keep up with my income, assuming idle builders and new builders spend metal/energy at the same rates as current builders.

[inland haven]

Really good feedback. I've played this game for decades and never needed to know the numeric value of my buildpower. I just need to know:

• "do I need more builders?" (see deficit number in screenshot above),
• "do I have idle builders?" (see red portion of BP bar), and
• "do I have enough E income for my M income?" (see yellow/grey indicators on BP bar).

I could see pros, which I am not, also wanting to know "do I need to reclaim any builders?". That could be handled simply by showing BP surplus in place of the deficit number as mentioned above.

[subtle plaza]

I’d like to play with the new version you just posted, but I’ll say what I liked about the variant I was using: the idle BP wasn’t factored in. It was just telling me if my current constructions were stalling or not. Example being, I just stopped building afus. I’m now trying to pump out units. I have a bunch of idle con turrets in my afus area. I know that, and it’s fine. What I really need to know is if I’m applying enough BP to my gantry and front-line builders who are working on porc. The “idle builders” number is irrelevant, and I don’t love that it takes up space in the bar. IMO the only question is “am I using the full power of what im trying to use?”

I know that’s more simplistic though, and doesn’t consider metal potential of reclaim

I’ve played the game for like 6mo. So I got nothin on you folks with a decade under your belt 🙂

And im like OS21, so not an expert.

[warped glade]

I am 100% with you.
The amount of info that is really needed is relatively small for BP. I think it was somehow necessary to see all these various numbers to get a feeling of what you actually do with it.
Right now I find myself barely looking at anything else than the sliders and the other widget that shows idle builders. Because If sliders are too far left, you need more eco. And if I have no idle builders the reserved BP is good enough.

It took the usual way:
It started simple
Then you get overexcited and do everything and anything you can imagine
And at the end you can boil it down to the stuff that really matters, because now you know 😎

I think I will go with a "no BP" mode a "simple" mode and a "pro" mode. What I want to include in any case is the right amount of pulled resources. I simply think this is an ancient bug. (Btw. this could become the ONE thing that Zero K could copy from BAR 😉)

@inland haven 👍👍👍👍👍👍👍👍👍👍👍👍

[olive musk]

I agree, idle builders could be a separate thing (it kinda is with idle cons widget - it could get buffed to show count of idle con turrets)

[inland haven]

If you want more numbers, you can still get that by setting proMode=true:

But here's the default version:

I'm getting ready to commit this and make a pull request.

[subtle plaza]

Is there a second green bar in there too? Or is it only light green filling a red bar? In this mock-up, I was thinking it would make sense to align the color of the numbers with their fill bar.

Is the bar red in your screenshot because you’re trying to build more and you can’t or is that “idle”?

[inland haven]

There would be a dark-green bar if I had some reserved BP that wasn't used. It just so happens that wasn't the case so the light green and dark green bars (and numbers) are identical.

Aligning the numbers with their positions gets tricky if the bars shift.

And the rest of the bar is red because that represents idle BP.

[subtle plaza]

No no, just the colors

[subtle plaza]

I’ll remain open minded, but my first reaction is that idle BP should be a neutral stat vs “negative” with the red

Not using your BP could be a player choice that we don’t need to yell at them about

[inland haven]

@warped glade, PR ready for review: https://github.com/roberthartmann/widgets_for_BAR/pull/2

[inland haven]

Give it some reclaim orders, or move it somewhere where it can start doing some useful work, or set it to guard something -- any of those will cause its state to change from idle to reserved. (If none of those sound good, you can reclaim the unit for some bonus resources.)

[subtle plaza]

What about the static afus farms with 32+idle con turrets? Do we want that player to have a red bar because we think they should reclaim those cons or build more afus?

[inland haven]

You can use a transport to move the turrets elsewhere.

The player is always allowed to look at the UI and say "yeah but I know better", but I would expect that in 95%+ of cases idle BP is unintended and you'd be better off telling the unit to do something.

[subtle plaza]

🤔 don’t think I’ve ever seen that except for some early builds where a pro player moves one or two turrets around. My reaction is purely to the red. But excited to give it a go and see how it feels in action

[inland haven]

It's pushed, go for it! https://github.com/gmcnew/widgets_for_BAR/blob/main/gui_top_bar_alpha.lua

[warped glade]

That example is worth a fusion, a moho mm, a T1 botlab and few con turrets and a constant stream of Ticks.
I know what is more valuable 99% of the time.

Plus a lot of build space plus it is more resilient against all kinds of damage.

[knotty escarp]

(im speccing btw)

also this topbar does not yet scale with UI scale settings, is that correct?

[inland haven]

Looks like the alert indicators may still need some tuning. 🙂 And yeah, I noticed it doesn't scale well with the UI scale setting -- I think that predates my changes but should be looked at.

[inland haven]

I suspect the "too much buildpower" warning is too opinionated and needs to be removed. I'm concerned that there may be situations where you have tons of BP that you're putting to non-building use (guard/repair/reclaim) where you'll see this warning.

• If the extra BP is idle, that's already handled by the red portion of the bar.
• If the extra BP is on guard/repair/reclaim duty, there's no problem.
• If the extra BP is trying to build but is stalled, well, you already have the metal and energy bars to tell you that you need more resources.

[inland haven]

This just needs testing and then probably some more fine-grained determination of what non-idle BP is truly surplus.

[olive musk]

which version is that? I want to use this small bar now 😄

[inland haven]

#1167027291440812063 message

[warped glade]

I added a description for the versions in the repo, now. And I added a short introduction for the sliders.

I am looking at the PR right now.
And I see some lines that could be improved. Some/most of which are mine 😂.
I am in the process of commenting on them.

[warped glade]

Why did you re-establish the metalExpense? Did it get fixed?
I don't fully understand all the changes of the different calculations, yet tbh.

And some things seem very strange... Why is BP[8] switched from usefulBPfactorM to indicatorPos. In addition this number is also stored in BP[10]?
Now it is BP[8]=BP[10]=indicatorPosM
Same applies for 9/11 and energy.

I can't remember doing this myself...

[inland haven]

BP 8/9 and 10/11 are now redundant and can be cleaned up.

Using metalExpense instead of metalPull made the predicted eco calculations work. I didn't need the pull numbers anymore. To test this you can build a lvl1 lab, pump out any non-con unit, and then have your commander assist, stop assisting, etc. -- the M/E indicators shouldn't move because the prediction should have been that any unused BP (your commander) is spent in the same proportions as currently used BP (just the lab).

Some of the boolean logic is cleaned up, if proMode == true is identical to if proMode,

[warped glade]

Ok, I will test it.

Perhaps I have a knot in my head.

Can you please look at the comments in the PR? That would help me.

[warped glade]

Why a non-con unit? My totalAvailableBP is only taking finished units into account?

Oh... Because it was deleted... Well it should stay in there...

[inland haven]

Just because building a con will change your total BP (and E production!) and make the graph shift. So when I'm trying to keep BP constant and test M/E indicators responding to build orders, I build non-cons.

[warped glade]

But it is great that you deleted it.
Now I see where the time lag between the sliders and some numbers came from.

The sliders use the avgUsedBP and the add stalling is using the totalStallingE. That isn't an average.

[warped glade]

Kk

[warped glade]

@inland haven
I still don't get it...
Let's say you can support 50% of your BP with Metal. You are only using 30% of your BP.

usefulBPFactorM = math.min(1, metalIncome / BP['metalExpenseIfAllBPUsed'])

Is now able to tell me where the sliders belong and that I am using less BP than I can support?

For me these are different things.

I am only using 30% of my BP and 60% of the metal I get, so the widget should yell at me: use your BP.
At the same time it should not tell me that I am stalling.

[warped glade]

A whole different thing is now raising in my head.
Should we tell the player what to do instead of just yelling at him the obvious while stalling? Need E/Need M was my first attempt to do that. But perhaps we should even tell him "prioritize or reclaim your BP" nothing worse than having a AFUS at 90% with many con towers (with low prio) while a bunch of cons sucks all your metal while building, let's say a Mammoth at 10%.

We could consider a tutorial mode for the new UI... We have all the data anyway. And we have a nice lady with a beautiful voice.

[inland haven]

I don't like the "need M/E" alerts, that's what the metal and energy bars are for. In general I think we should err on the side of fewer player directions until this gets some more playtesting and/or we're confident we can give directions that are going to be correct almost all the time.

[inland haven]

That's right, it shouldn't tell you that you're stalling on M. Care to share a screenshot with the debug tooltip visible?

[warped glade]

I am away for tonight. Tomorrow I will test all this.

But perhaps you can explain to me what your thoughts were. And how the logic behind this works.

[inland haven]

There's still a good amount of bounciness in the numbers due to ramp time if you're spamming cheap units. I have an idea on how to fix it, in the meantime consider any annoyance to be a penalty for tick spamming. 🙂

[warped glade]

a very easy example:
I am stalling on energy here. --There is no marker.
I am not using all my BP. --it tells me I have not enough BP

here I am even reserving 100% of my BP on high prio. No stalling indicator

the numbers seem to scale in an odd way

the build bar needs to be full here

looks like unfinished buildings/cons were taken into account

please get me right, I think you have done quite some work. But the calculations are quite complex and grew for month.
Surely there are some parts that can be optimized, but making values obsolete and redoing big parts of the calculations will likely lead to the same issues I ran into.

[inland haven]

(1) I made the "need energy" alert only occur in pro mode, partially due to screen real estate and partially because I wasn't convinced it was useful when you have the energy bar right there. IMO if you're E-stalled the existing UI already shows you that in the form of an empty energy bar.
(2) The "need buildpower" alert is bugged, it treats a surplus as a deficit, I've fixed that locally.

[inland haven]

Did you give it a couple seconds to settle out? If so, I think you may be seeing the same bug I noticed once where it was reporting BP that I didn't actually have -- probably something to do with trackedUnits getting out-of-sync with reality.

[warped glade]

sure

[inland haven]

Not sure what you mean here, can you explain? Looks like all your BP (just your commander and lab?) is being used and indicated as such.

[warped glade]

pro mode enabled

i don't see a difference

[warped glade]

the fab and the con isn't finished
but they are taken into account

that is not how it should work
I made a list for that.
totalAvailableBP

[inland haven]

Hmm... I've never noticed that and I don't believe I changed that logic.

proMode also shows the larger BP bar with extra numbers, looks to me like proMode is still off in those screenshots.

To fix "need more BP" showing up erroneously, you can change
if BP['buildpowerSurplus'] ~= nil then
to
if BP['buildpowerSurplus'] ~= nil and BP['buildpowerSurplus'] <= -10 then

[warped glade]

ok

classic...
i edited it in my download folder...

i still am stalling... no flag

the metal request is false when I set the tower on low prio...

it should say 14 and only says 7...
that was important part of the new top bar

g2g sorry, will be back on a pc with bar tomorrow

[inland haven]

Thanks, I'll look at that.

[warped glade]

the flags appeared after a while (with low prio BP)
but the metal request is still wrong

[inland haven]

What do you mean by metal request and how can you tell it's wrong?

By that you mean the pull, correct? The leftmost "-7" in the metal bar (should be -14)?

[warped glade]

the two red numbers are identical... that is not right

low prio BP still wants to suck metal in the real world. but the metal request does not take it into account.

look at the comments in the pull request

[inland haven]

Some of the code was unnecessary or confusing (e.g. initData and BP just being two references to the exact same table), I tried to do some cleanup as I went but may have clobbered some good stuff in the process. 🙂 I'll push my latest changes, do some more testing, and check the PR.

[warped glade]

Some of the code sure was non optimal. It worked, I tried to improve it but I became blind for the imperfections.
I guess there are reasons for the 4 eye principle after all.
I'd even go so far and say it needs a new pair of eyes and hands to make further improvements after a while.
That's why I am so happy that you are working/ messing around / questioning/ improving / worsening my code. It enables the code to get better, more resilient and optimized.

[subtle plaza]

(math is scary and I don't want to get involved.... but I had bar crash on me twice since installing this widget. Coincidence? Is it possible for a widget to crash the game?)

[mild python]

possible but unlikely. Share the logs from your crash and perhaps the real culprit can be found

[inland haven]

@subtle plaza , in my experience if the widget crashes, the game just reverts to a different (fairly unattractive) top bar, but the whole game hasn't crashed for me.

[inland haven]

@warped glade, I pushed several changes, I think this handles some of your comments on the PR. https://raw.githubusercontent.com/gmcnew/widgets_for_BAR/main/gui_top_bar_alpha.lua

[subtle plaza]

I pushed the upload log button. Not sure where that goes, but hopefully it’s helpful.

[mild python]

-uplog

[cinder iris]

https://cdn.discordapp.com/attachments/773285618826346546/826433908736000000/BAR_uplog_anim2.gif

[warped glade]

we are inconsistent with our flags.
"need Energy" with an E
"Too much buildpower with a "T", a "b" and without a " " I am German after all so for me this looks OK 😛

[warped glade]

there are cons moving around and the con turret has a guard command on a con out of range (that's something for another widget)
the thing is: there are no flags in this condition. (I can support slightly more than 40% of my BP)
no: use your BP
no: too much BP

I'd still think there are ways to improve the guiding for new players.
in this case something like use your BP would be a good idea, since the storages are full

  if res == 'BP' and drawBPBar == true then
      local _, _, _, incomeMetal, _ = spGetTeamResources(myTeamID, 'metal')
      if incomeMetal and incomeMetal ~= 0 then
          currentResValue[res] = math_floor((r[res][2] - r[res][1]) / incomeMetal) --time you are behind
      else
          currentResValue[res] = 0
      end
  end


if playerIdlingBP == 1 and playerStallingMetal = 1 and currentResValue[res] > 20 then
  reclaim = 1
end 

local bpReclaimText ='   reclaim BP or use BP on more eco   '

the sliders behave strange...
they go up and down too much

the resource request raises when you are stalling

very different numbers are shown when stalling with and without low prio cons

[silver pendant]

I still very highly recommend that you read the build prio widget, and try to hook into that. Even better if you base your work off my PR.

[warped glade]

Somehow this got totally forgotten because of all this new math in my widget... It was never planned...
Let's see first what your gadget does!
And then come back to the release plan and not get carried away, again.

If my plan sucks, tell me. We can adopt it.
#1167027291440812063 message

@inland haven
Here is the link.
#1167027291440812063 message

[silver pendant]

Updated my gadget

[silver pendant]

Some notes on numbers that I can easily calculate from the Builder Priority Gadget

1. Total amount of buildpower
2. Total amount of high-prio buildpower
3. Total amount of low-prio buildpower
4. fraction of resources used by high-prio builders
5. Fraction of resourses used by low-prio builders

Where I think things get tricky, is if a builder is not using its buildpower because it is not building anything.

[warped glade]

You are guessing that right.
I managed to get them by tricking around quite a bit, but it took time.
But the journey doesn't end there.
As far as I understand the first few lines of your gadget you are looking at every con and the project it wants to build. You are deeper into your calcs. Could you imagine to "just" add up the "ignored" request of the low prio cons? What I mean with that: if you put your low prio cons to BP 1 or 0.001 the calculations of the request will ignore the low prio BP that can't get supported. And this is why the request is lower than I would expect as soon as I stall.

[silver pendant]

ignore the 0.001's

[warped glade]

@silver pendant
Hmmm I try to explain it another way:
There are 3 scenarios:

1. you have recourses in stock and have a higher request than production
2. you are stalling on one resource and only have high prio cons
3. you are stalling on one resource and you have cons with low prio, too.

With the current in game top bar scenarios 1 and 2 show the same recourse request and the third scenario shows you a lower one.
In this version of the top bar scenarios 1, 2 and 3 show the same request (as I think it is supposed to be)
#1167027291440812063 message
As far as I understand the new version is how it is supposed to work.
That means we have to calculate the "missing" request somewhere. Can that be done in your gadget? It feels like it, since it is disturbing m/e and BP. We would just need to add all the rest up and send it somewhere, right?

[silver pendant]

Yes, please provide a detailed description of what exact numbers you desire

[inland haven]

This is my first time seeing that the metal pull tooltip has this disclaimer:

Builders on low-priority will only use leftover resources and thus their demand isn't counted here.
So we should also provide updated versions of the tooltips for French and English (the only two languages which appear to include this sentence about low-prio builders).

[inland haven]

Prior to my changes the M/E indicators were incorrectly assuming that all M/E spent was for building purposes (ignoring metal extractors, for instance). That's fixed now, but the determination of how much M/E is spent by non-builders is still a little buggy. In your next video, if you hover over the BP bar the debug tooltip will show some of this math.

[inland haven]

I'm okay with an "Idle buildpower" alert if we can get it tuned right. I don't want to be alerted just because my commander is reclaiming/repairing or trying to run for his life.

[warped glade]

well reclaiming and repairing are setting units to a reserved state (even queued) so it will never appear. For the com we can add all actions, like moving and so on. we can check if it is cloaked, too.

[warped glade]

is that so? I thought I took the pull, substracted the wrong numbers of the builders and added the right ones

[inland haven]

I think you got current pull right, but projected max pull (if all BP is used) was the problem. The "how much BP can we support?" calculation was I believe assuming all expenses were build expenses.

[warped glade]

basically the sums of all builders

totalMetalRequestOfAllLowPrioBuildersThatAreSetToBP0.001 = 0
for lowPriobuilders
  if setTo0.001 then
    totalMetalRequestOfAllLowPrioBuildersThatAreSetToBP0.001 = totalMetalRequestOfAllLowPrioBuildersThatAreSetToBP0.001 + M/BP*BP
  end
end

the same for energy.
so we can change this tooltip to "Builders on low-priority will only use leftover resources and BUT their demand is STILL counted here."

[warped glade]

true.
It was a good thing for energy converters and shooting. (since it is temporarily)
But for things like radar and mexes this is bad. Because you need them to run all the time.
Good thing you noticed this. Together we get everything right.

But we should still put a bit more thought into it. What do we want to support with the highest prio, or how is the engine handling it? This is what the Bar should really show us.

[warped glade]

@inland haven
so let's try to get this number and all the numbers he supposed out of Beherith's gadget, first.
That will help us along the way.
With these numbers everything else will be clearer and easier to handle.

[inland haven]

That's a good idea, do you want to do it? Once the changes are in your gui_top_bar_alpha.lua (along with your alpha 1 changes, see my first commit) I can merge to my branch and test.

[warped glade]

I would do it if I could do it. I have looked and searched for a possibility to get values from one lua to another, but have failed.
What do I need to do?

The calculations should be the easy part as far as I see it.

[inland haven]

It looks like @silver pendant's code actually changes the way high- and low-priority work. But I'm not sure how this top bar needs that.

I did find a bug with priority and reported stall, as shown in one of your videos -- that will be fixed shortly.

I also made the M/E indicators much smoother. The problem is that fetching metal income/expense was somehow out-of-sync with fetching unit resources consumed, so there would be brief windows of time where builders were consuming more E than we were actually spending, causing the code to think that non-builders were responsible for negative E spending and making a mess of the projections. I fixed this by smoothing the non-builder M/E expense over time so that any blips are drowned out by the majority of datapoints being reasonable.

[inland haven]

@warped glade, I pushed my changes:

• fixed (?) the low-vs-high-priority pull rates
• made the M/E-supported indicators smoother
• tweaked notifications so in non-pro mode the user will only see the single most important notification

[warped glade]

Thx. Will have a look at it soonish. Probably on Sunday.

[inland haven]

In one of your comments you said in-progress cons were counting against you. I wasn't able to reproduce that, but I'm wondering if it'd be useful to include them intentionally. That way if I start building a con turret before my eco supports it I could get the "too much buildpower" alert immediately. Conversely, if I have a BP deficit, I can see if starting a con fixes the problem or not. I would probably count cons being built as Reserved so they aren't flagged as idle.

[warped glade]

That could be a thing...
I am using
widget: unit finished
We could use
Widget: unit created
(Again)

[inland haven]

Todo items of the top of my head:

• improve spectator mode, right now if the game is paused and you switch between players the bar doesn't update properly
• ✅ merge in the last few months of gui_top_bar.lua changes from the base game (starting with https://github.com/beyond-all-reason/Beyond-All-Reason/commit/efa2a47f89cb6a75d4fac526501617e46c355e6f)
• ✅ fix the top bar not scaling properly in response to the UI scale setting
• ✅ add widget options for drawBPBar, proMode, drawBPIndicators, and DebugMode
• ✅ use DebugMode instead of proMode to decide whether we should show the debug math in the tooltip
• localize tooltips
• Only treat commanders and commando BP as idle if the unit is completely idle (sitting still, no orders). Any other action that isn't building should count as Reserved, since these units can be used in combat roles.

[warped glade]

Now that we have reserved BP that understands any kind of BP usage in a queue it might even be the better way to handle it.

[warped glade]

Todo items of the top of my head:

• improve spectator mode, right now if the game is paused and you switch between players the bar doesn't update properly

• I am using game frames to update.
  We could switch to game time or something that keeps running while the game is paused.

• merge in the last few months of gui_top_bar.lua changes from the base game (starting with https://github.com/beyond-all-reason/Beyond-All-Reason/commit/efa2a47f89cb6a75d4fac526501617e46c355e6f)

Jap. Good idea.

• fix the top bar not scaling properly in response to the UI scale setting

I thought I used the multiplyer everywhere. But it seems as if I did not...

• add widget options for drawBPBar, proMode, drawBPIndicators, and DebugMode
  Perhaps the second pull request can help there

• use DebugMode instead of proMode to decide whether we should show the debug math in the tooltip

• localize tooltips

• Only treat commanders and commando BP as idle if the unit is completely idle (sitting still, no orders). Any other action that isn't building should count as Reserved, since these units can be used in combat roles.
  Good idea. I figure you are smart enough to do it but if you don't want to spend your time on thinking: just take these two guys and make something like

If #commandos>0 then
Com not idle

@subtle plaza look at the end of the video. This is why I think the min wind indicator is so important
https://www.youtube.com/watch?v=WYlAvj44mWk

[inland haven]

There's a chance that the following is an overcomplication, but hear me out:

The surplus BP that we show users in absolute numeric form, and that can cause an alert, is currently calculated as "total BP - eco-supported BP". Maybe "surplus" should instead be the same as "idle", with stalled BP counting as idle. If you have more builders than your eco would support, that's not necessarily a problem if some of them are Reserved due to guard/repair/reclaim duty or simply due to driving to their next order. (Counterargument: why are you using cons to guard/repair/reclaim when rez bots provide more BP per metal for these purposes?) Only if you have BP that's stalled should you consider repurposing or reclaiming them.

In other words, the 3 buckets would be:

1. used (actively building)
2. reserved (being built, or has a build/guard/repair command enqueued -- for commander/commando, being cloaked or moving counts as being reserved, too)
3. idle or stalled

Only this third category -- idle or stalled -- would be shown as a surplus, and then only in percentage form. If this percentage climbs above a certain threshold and your absolute number of idle(/stalled) BP climbs above a fixed value, you'll get an "Idle buildpower" alert.

[subtle plaza]

Ouch! Bad timing. I suppose my only comment is, “would Blodir have made a different strategic decision if he had an indicator on his HUD saying he was highly leveraged on wind and would be screwed if it dropped?” My gut is that he would have accepted the risk and made the same play. So while an indicator in the hud would be INTERESTING, I’m not sure if it would change the way folks play. 🤔

Can we ask him? 🙂

[inland haven]

What's a good way to indicate this on the BP bar (paging @knotty escarp)?

1. Add a thin vertical line (orange?) representing the amount of BP your E could support at min-wind
2. Split the indicator into two triangles, perhaps with a thin yellow line connecting them as in <#1167027291440812063 message>
3. Just make the E indicator wider to cover the entire possible range of E-supported BP (this may be too visually heavy)

[inland haven]

4. A thin horizontal yellow line behind the E indicator. As the wind changes, the E indicator will slide along this yellow line.

[warped glade]

I don't know if he would have changed his decision in this precise situation, but there are less desperate times. And let's say you only avoid 5% of stalling on e during a self chosen attack with the com because of such an indicator. That would be freaking amazing.

[warped glade]

For what it's worth I'd go with 1 or 4.

[warped glade]

Hey @sudden laurel ,
we have watched your game against rANDY. What a fight!
The end of one game caught our attention, since we are working on a new UI with a bit more information.
In short we want to give the user the possibility to see how much of his build power (BP) he is using and how much of the BP he can supply with his current metal and energy income.
So we saw you stalling on E while you could have D-guned the LLT. And boy oh boy do I hate wind sometimes! We were wondering if you think there is any value in showing you how small e income you have if the wind is at its minimum. (Even if it isn't).
There are descriptions of what exactly the new top bar is currently able to show when you look at the pinned messages.
It would be great to know the thoughts of a pro gamer about that.

[sudden laurel]

i'm not sure about the buildpower stuff. In supcom I have a mod that alters the values a bit so they properly show the absolute amount of mass/e draw and income (importantly without counting reclaim) which makes it pretty easy to balance buildpower. But in this game the situation is a bit more complicated with the priority system? I don't really even properly know how the priorities work tbh, but anyway my personal preference would be to get closer to what my experience in supcom is. Also btw, I think showing the differential is pretty useful which is the most visible value displayed in supcom.

The wind risk stuff could be useful for sure, as long as the UI isn't too cluttered. Ngl I find it a bit hard to understand the pic. Ideally you'd display the wind risk info (base income, potential income, current income) but in a subtle way without cluttering the UI too much. Especially for new players (I'm a new player) the info overload can be kind of a lot.

Also, I think I tried an earlier version of this mod when I started, but I felt like the bars were too narrow and in general the UI scale was too small for me. I think making the UI scalable is pretty important.

[sudden laurel]

yea i mean i just ran at his com because game was over anyways, that's why i tried to snipe him

[inland haven]

Hmm... kinda ugly IMO, but the tiny yellow bar shows the range of E-supported BP. Need to consider doing something similar for metalmakers or just remove the tiny bar and say "you knew this was non-guaranteed income when you decided to build all those winds and metalmakers, deal with it".

[inland haven]

I think I'm going to commit this behind a disabled flag and then work on porting the recent topbar changes from the base game and fixing UI scale, this is definitely a bit small as @sudden laurel said.

[inland haven]

Done:

• merge in the last few months of gui_top_bar.lua changes from the base game
• fix the top bar not scaling properly in response to the UI scale setting

[inland haven]

This is implemented, see the includeConsBeingBuilt flag (enabled by default).

I also added a countStalledAsIdle flag (disabled by default). It's not ready for prime time yet: I think idle BP needs to be something the user can address quickly and easily (Ctrl-B), but finding stalled builders that should actually be doing something else is a little trickier. Also, if your income is variable due to wind, metalmakers, or reclaim,stalled BP could be un-stalled in the next few seconds, in which case repurposing those cons isn't necessarily the right move.

[warped glade]

It might be improbable look wise, but it shows one thing: don't let your min E income be so low that it is further left than your M income. Or get E storages.

And WOW does this thing show you: wind is too important for your eco right now! You are playing with fire!

Could a triangle be a thing? Low on the low wind side and high on the max wind side?

[subtle plaza]

Is the new version installable now?

[warped glade]

interesting... a mod that shows more important numbers.
How is it called? I'd love to learn from that.

The priority system is built to help the players.
In short:
there are cons that have high prio. They will get the resources first.
there are cons with low prio. They will get the left overs. The left overs are not spread equally. Random builders will get 100% of their BP suppied. As soon as the resources are exploited the rest of the low prio cons will just make sure the blueprints will not decay.
An lesser kown fact: you can set all cons to high prio in the advanced settings.
I am considering making a widget that let's to klick at a blueprint/factory and set all cons helping this on high prio and the rest on low prio. After the project is finished all cons should return to their former state.

This pic is not for the UI. It is for communicating the problem with wind speeds and unknown, important values. This is why I'd like to learn from the sup com mod.

So you would prefere higher bars? The UI scale is an issue we are working on. That is why we are making the BP bar smaller/round.

[sudden laurel]

i guess u could still show absolute requested mass/e drain instead of actual mass/e drain after priorities then

would be more useful number to look at imo

[warped glade]

this is what my top bar already does

I even changed the headline 🙂

[sudden laurel]

the supcom mod was made by eternal- i think but he has probably namechanged xd i don't have the latest version of faf installed atm

it just changes the numbers such that they don't take reclaim into account iirc

[sudden laurel]

oh nice

might have to give it another shot

if it's bigger now

the eco panel is like the most important part of the ui

yet it's the smallest

tbh i would like a mod to also reduce the size of building panel etc

that ui is too large xd

so scaling with just one ui scaling slider is not enough, unless there's sane defaults

[warped glade]

here is a link to a google slide

you can add a slide and just play around and tell us what you would put where 🙂

https://docs.google.com/presentation/d/139HtRYHzvnh_isKjgk1SrQrOY61Uuqa0YN1tiaFdB-g/edit?usp=sharing

[warped glade]

I am with you here.

@subtle plaza @inland haven
can/should we implement a possibility to change the scale of the top bar unconnected to the rest of the UI?
feels like it would make sense

I like the way you think, Blodir!

[sudden laurel]

btw, kind of a weird place to ask, but i heard that someone was working on soft cancel (i.e. press g and it cancels all production except currently producing unit) do u know if we're getting that soon?

that's the single most frustrating ui thing in bar for me

lack of it that is

[warped glade]

haven't heared of this, but it should not be too much of a problem.

if buildorders > 1 then
cancel all but 1
elseif 
cancel all build order
end

tell me who is working on it and I shall complete it 🙂

[sudden laurel]

basically i would like if pressing g would cancel all but the currently producing unit, and ctrl+g (or double tap is fine too) would force cancel all

so u don't waste any factory time / energy

even if u get the mass back

yeah not sure who was working on it

let me try to search

https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2194

[warped glade]

makes sense.
thx.
this is a gadget? Well that complicates things...

perhaps I can bypass it by making it a widget that reacts on another key, like "h" or something

[sudden laurel]

i don't know what that means, but i suppose ideally you'd just have a new command that you can keybind in the config file?

also it kinda needs to be integrated into base game since widgets are not allowed in tournaments

[hybrid mulch]

Someone will need to write a widget which the key bind can trigger

if that makes sense, but once it exists that could be added to the base-game widgets easily enough

like how the build-grid got added

[warped glade]

well since they are working on something like this on a gadget base (basicalliy an internal mod). The likelyhood of integrating the widget (an external mod) into tournaments is a bit lower.
I think it would be a more solid solution to help this the gadegt (internal mod)

[warped glade]

I asked in the dev-chat what needs to be done.

[inland haven]

https://raw.githubusercontent.com/gmcnew/widgets_for_BAR/main/gui_top_bar_alpha.lua

[inland haven]

The UI scale issue should be fixed: it's now the same height as the default top bar, and it responds to the UI scale setting. And unless you set proMode=true, the BP bar is narrower than the metal and energy ones.

[inland haven]

Working on merging @signal forum 's options changes into my fork now.

[subtle plaza]

I don't think the math is working right... It also sometimes doesn't have any numbers and I have to use luaui reload to kick start it again...

[inland haven]

@subtle plaza , can you hover over the bar and take a screenshot that includes the whole tooltip, with the math for debugging?

[subtle plaza]

I have a lot of builders working, but it says I only am using 126 bp?

I have a theory that it has to do with commander. When he's walking to the next location, the BP bar seesm to fail? or it only cares about commander BP? Unclear...

After luaui reload:

[inland haven]

That looks like a bug alright. 😄 Any specific steps for me to reproduce this? Just start an AI game and build as many cons as possible?

[subtle plaza]

I just played normal? It seems to choke in the early game, where it only likes to display commander power. After lua reload it works sometimes hah

[inland haven]

That's really strange! I haven't seen those problems but will definitely take a look after I get the option load/save stuff working.

[inland haven]

@subtle plaza, fixed, it was a pretty bad bug! Let me know if it pops up again. Here you go: https://raw.githubusercontent.com/gmcnew/widgets_for_BAR/main/gui_top_bar_alpha.lua

[subtle plaza]

I'll try it out. Is there a way to swap between pro/nonpro without editing the lua?

[inland haven]

Done, mostly -- thanks @signal forum for the options work!

add widget options for drawBPBar, proMode, drawBPIndicators, and DebugMode
DebugMode and proMode are still treated as the same thing right now.

[inland haven]

Yeah, there's an option for that in-game now, but you have to reload the widget to fix the draw width. >_< I don't have time to fix that tonight.

[subtle plaza]

oh, and are the labels below the bars now or still up top?

[inland haven]

The warning labels are now at the top of the screen just like they are in the base game.

[subtle plaza]

ok, dang 🙂

[subtle plaza]

Can't see any of the numbers, which sorta defeats the purpose of the numbers

[inland haven]

I could see that being a useful option later.

Fair point. I'll try to look at that later.

[subtle plaza]

I'll give it a go!

[inland haven]

^ Download again, I pushed a quick fix to push the alerts back below the bar, I agree that having them at the top is terrible.

[inland haven]

I think your layer change was slightly incorrect (you had -999980) but I fixed it in my branch. The top bar (layer -99980) is now loaded only after the options bar (layer -99990) is.

[warped glade]

It might save you some time to ask why I made something before you change it 😉.
But on the other hand you are hammering out the changes so fast that it could slow you down, too. 😂

In any case. Great work!

[subtle plaza]

I think it's working properly now! The next question is... is it helpful? 🤔

I'll be honest, the pro bar is a lot. I'm unclear what my goal is. For E and M, I know I want to increase my energy and metal income and I want to know how much I have in the bank. For BP its much more fluid. I'm not sure which number I need to key in on or what my goal is with those numbers. I'm still not convinced that Idle BP needs to be in the bar. For me, I know it's idle... I paused my factory while I wait for other things to complete... I'm not sure I want the bar telling me I have too much/too little BP when I've made the choice to not use those cons on purpose. Also, sometimes I think that tag was just wrong. Maybe I had enough BP globally, but I certainly didn't have enough being applied to my factory.

I think the smaller bar is more my speed, but even on that thing, it has a number on it and I'm not sure what that number is trying to tell me other than bigger is better? I miss my simple % number that changed from green to yellow to red. That was a much more intuitive thing to help me know if I was under/over building. I still mentally picture BP as a buildSPEED indicator. It's the throttle on my constructions, and a throttle goes from 0%-100%.

I'll keep playing with it! As a noob, those were my initial thoughts. I'm super curious what our 30+OS players think though.

[warped glade]

The thing you are describing is very true. Idle BP can be a players decision. And it can be the right thing to do.

I also think the basic % has a lot of value. When we stick to the 80/20 principle the % is the right thing to include.

In the back of my mind there is still something that tells me there could be another way to show stuff and make it a bit more useful.

I still think it could be a good idea to show the player how much BP he has in the back of his hand to do stuff.
So if we could just show him: hey you have more than enough BP to build windmills and spend all your money. Do you need so much BP? Or: You have not enough BP to spend your money on Eco only, you will need more BP or build a bit of war stuff.

Perhaps we should not make symbols but put numbers behind it. Like 2m/100BP. In combination with the new grid menu that shows m/100BP it would give the user a sense of how much BP he actually needs.

In this example he has too much BP idling around and quite a lot BP running around. So he can only spend his money when he is mostly building fighting units.

This is just for 1 resource, of course right now.

[inland haven]

Add a comment next time! 🙂 I was pulling in recent changes from the base game's topbar and thought this was a case of us being behind the base game, not ahead of it.

[warped glade]

Well... I did some work there😉

[inland haven]

Bigger isn't necessarily better, it's showing you your BP surplus. I'm reconsidering the absolute numbers and leaning back toward a percentage that's color-coded: negative means you don't have enough BP to keep up with your eco, positive means you have more than you need. (You should aim for a slightly positive range, probably 10-50% surplus.) If you want to know the absolute number of BP that you're ahead/behind, that should be in the tooltip.

[subtle plaza]

I found that with the old percentage meter, anything below 50% felt like stalling. 60%+ felt like I was doing well. Watching some replays with the UI turned on reinforced that good players rarely drop below 50% and never for long.

[warped glade]

@inland haven
we will now begin to get the values out of the gadget.
So will have a freeze of our input values.
Please make a list of what values will need.

[inland haven]

I'm not sure what you mean, we have calculations for all of the numbers we need.

[warped glade]

I mean that the values we show are based on some numbers. Some of which can be calculated with the numbers that are used in Beherith's gadget. It is a necessity to calculate as much as possible in the gadget so we don't waste any performance for requesting the same numbers twice.

E.g. the gadget already calls the metal cost of all build projects. So we should use this info there and not call these numbers in the widget, again.

[inland haven]

Okay, I agree with this, but I thought that gadget wasn't in the base game yet.

[mild python]

Be sure to check performance as this feature gets closer to being "complete", the top bar is already a very expensive widget and I imagine that polling builders all the time for this new functionality is not cheap

This is the "widget profiler" widget, you can turn it on via the widget selector

[inland haven]

@sudden laurel, I'm adding some settings that will let people scale the top bar's height and width independently of the rest of the UI (while still considering the global ui_scale setting).

And after.

When you turn on the BP bar itself, it takes over some of the space that the metal/energy bars use.

[inland haven]

Absolutely! Feature-happy, then cleanup unused code, then optimization.

[inland haven]

Done:

use DebugMode instead of proMode to decide whether we should show the debug math in the tooltip

[sudden laurel]

This is great!

[warped glade]

Well when Beherith tells me, I should work with it, I will try work with it. And we all know that this makes sense performance wise. His improvements made a great leap in handling low prio cons and we should honor that and use it in our widget, too.

[steel hemlock]

This has come so far nice to see

[inland haven]

Pushed several changes. For one, I'm back on the bandwagon of showing a percentage-BP-reserved in non-pro mode. https://raw.githubusercontent.com/gmcnew/widgets_for_BAR/main/gui_top_bar_alpha.lua

I also looked a little into the profiler data (thanks @mild python), found a bug (when you have more than 100 cons) that I still need to fix (https://github.com/gmcnew/widgets_for_BAR/blob/main/gui_top_bar_alpha.lua#L1869-L1871)... mostly I think it just needs more playtesting and feedback.

[subtle plaza]

for some reason this isn't showing up in my F11 widget list... any ideas?

[warped glade]

There are 2 reasons

1. the name is already taken
2. there is a tiny typo in the code and the widget doesn't load.

If 2) look at the loginfo.txt search for the FILE name ( not the shown name in the widget selector). There will be something like ... In line 1583 there is something...

[warped glade]

First things first: I don't want to interrupt your work, it feels like you are in the flow now.

With that said: I think we should really take this data from Beherith's gadget, when you are ready. I made a maxUnits value and set it to 100 units per %2 frames and cached that data, added them up and only sent it to the BP[x] when all units were looked at. Just to save performance. But this won't be necessary anymore when we send this data via sendLuaUiMsg to our Widget.

When you are ready: update the values you are working with. Then I can give you what you need. That will give us a performance boost.

[mild python]

You'll need to wait until the changes to the build priority gadget are merged, then you will need to figure out a way to get that gadget data into a widget, which may require further refactoring to move the data collection pieces out of the build priority gadget and into some shared wupget. it's the right move for sure, but it will be a project in and of itself.

It should be merged pretty soon since it's gone through a few revisions and just got approved

[warped glade]

Is there a possibility to load it in a dev - version?

I am honest:
I am quite happy to have a pause. At the same time I am looking towards the implementation it would make me extremely happy to see this in the base game.

[mild python]

yes, but gadgets and widgets operate in different spaces and you can't just pull data out like you would from another widget. As of now, this is the only upget in BAR https://github.com/beyond-all-reason/Beyond-All-Reason/blob/master/common/upgets/api_resource_spot_finder.lua

(dont ask me about the upget name, i have no idea lol)

[warped glade]

I asked how to do it and it looks pretty straightforward.
#🔩｜dev-main message

[mild python]

Ah, very good

[warped glade]

I have found this in the top bar already:

        Spring.SendLuaRulesMsg(sformat(string.char(137) .. '%i', convValue))

[subtle plaza]

[t=00:04:16.402750][f=-000001] Failed to load: gui_top_bar_alpha.lua ([string "LuaUI\Widgets\gui_top_bar_alpha.lua"]:2818: main function has more than 200 local variables)

I can understand 199 variables. Do we really need 200+? 😛

I'm not a programmer, but I'm going to assume it's mad about this: -- precomputed average wind values, from wind random monte carlo simulation, given minWind and maxWind

[hybrid mulch]

Not sure if this is relevant/useful but it is interesting :D, so for reference Spring Engine wind : https://gist.github.com/badosu/5e584c7ac1ee1036cd96133489cb3f25

[warped glade]

I ran into this problem, too.
The Top Bar already does many things at once. (Wind, Coms, tidal, setup)
And the BP calculations are quite complicated.

[olive musk]

can widget be nested? Shouldn't top bar be split into separate ones for resources, bp, wind etc? 😄

[warped glade]

Perhaps the new version, but certainly not this one.

There will be a new way of handling UI graphics, as far as I understand. It will make it easier to add elements. But up until this change of internal interface is thought and rolled out I'd rather not invest unnecessary work in a way of handling stuff that is already outdated.

Long story short:
Make it modular: great idea
Make it modular with after the new way of handling UI was introduced: even better 😉

[warped glade]

Quick fix might be:
Remove Debugmode...

local Debugmode = false
function Log(Message)
    if Debugmode==true then
        Spring.Echo(Message)
    end
end
local Debugmode1 = false
function Log1(Message)
    if Debugmode1 == true then
        Spring.Echo(Message)
    end
end

Just add "--" in front of all lines

The pres Ctrl+h
Then substitute
"Log" with
"-- Log"
Where it makes sense 😉
@subtle plaza

[inland haven]

Fixed, @subtle plaza -- I had already removed Debugmode1 and Log1 from my local code (nothing uses them) but hadn't pushed those changes, so my local version was under 200 variables but the pushed version wasn't. Sorry! 🙂

[inland haven]

I made a maxUnits value and set it to 100 units per %2 frames and cached that data, added them up and only sent it to the BP[x] when all units were looked at. Just to save performance
Yep, and something like this (only updating a subset of units on a given gameframe) is a really good idea! It will smooth out load across multiple gameframes. But the current code needs to be fixed, because if you have 102 cons, the first frame is calculating 1..100 and then the second is calculating 1..2 again (instead of 101..102). So some cons end up being double-counted and some end up being not counted at all. 🙂

[warped glade]

Well that was a problem once, but I thought I ironed out that flaw.

trackPosBase = trackPosBase + unitsPerFrame

It is still in the code, it seems.

Looks strongly as if it should work from 0-100, then 101-102 when we stay at you example.

But perhaps something else changed.

[inland haven]

The code didn't look obviously wrong, I just know that it was definitely failing for me. 🙂 You could test this more easily by changing unitsPerFrame to 5 or something and then noticing that cons 6+ don't have their actions reflected in the bar.

The refactor I want to make is to not wait until all cons are recalculated before producing another summary datapoint for smoothing purposes. We should be able to recalc a subset of cons, generate new summary datapoints (total usedBP, reservedBP, stallingM, stallingE across all cons) even with mostly-stale data, and then continue to smooth the data that we present to users. (The current code waits until enough frames have passed to recalc all cons before it produces a new set of datapoints.)

The basic data we need for each con is:

• how much buildpower is it using (with stalling taken into account)?
• does the con have any orders at all? (if so, all of its BP is reserved)
• how much metal/energy is it being prevented from spending due to being low-priority?

The Spring calls we currently make for each calculated unit (in every other GameFrame() call) are:

Always:

• ValidUnitID (can be removed, as GetUnitIsDead returns nil for invalid unit IDs)
• GetUnitIsDead
• GetFactoryCommands or GetUnitCommands

Sometimes:

• GetUnitIsBuilding (if the unit has a command but we're not sure if it's building anything)
• GetUnitDefId (if the unit is building something)
• GetUnitResources (again, if we're building)
• GetUnitCurrentBuildPower (if we're building)
• FindUnitCmdDesc (to see if we're low-priority -- this should perhaps be integrated with our GetFactoryCommands/GetUnitCommands calls above edit: never mind, CmdDescs are not the same as Commands)
• GetUnitCmdDescs (if the unit has a priority command, find out what the priority actually is)

[warped glade]

Kk. Could be that this went under my radar, even though I tested it wildly with many different cons doing different stuff. But it sure felt ok.

True. This was the way I was able to come up with back then.

But your idea would make this smoother.

So if I understand it right we would need to know not only the total number of cons. We would need to track each con specially. Because if there is a fast drop of con numbers (e.g. an air raid that destroys all con planes working on a loo cannon) things would get messy in an unpredictable way.

[warped glade]

So we would need to transfer the calculations from the widget to the gadget...

This will be a challenge. Even more so when the calculations are still in a state of constant change.

I think this is a topic about which many books were already written. Do you have an idea of how to solve that? I mean the easy way out is always: one thing at a time.

[inland haven]

Looking at the code: we can probably skip ValidUnitID, as GetUnitIsDead returns nil for invalid unit IDs. We can further remove GetUnitIsDead, as GetFactoryCommands/GetUnitCommands return nil on error (invalid unit ID or unit is not a factory).

[warped glade]

@inland haven
So we can just

If  getUnitCommand(unitID) or getFactoryCommand(unitID) then
...
else
remove unitID and stuff
end

?

That sounds cool.

But do we need it in the widget? Would this even be needed in the gadget?

[silver pendant]

Dont rely on unitcreated/unitdestroyed in widget space

[inland haven]

I'm not relying on UnitCreated/UnitDestroyed being invoked immediately. I'm just saying that explicit ValidUnitID/GetUnitIsDead calls seem redundant given those checks are already performed by GetFactoryCommands/GetUnitCommands.

[warped glade]

There is just one thing:
How do we make sure that not every single unit gets checked every time, then?
I used the unitCreated/uniDestroyed and so on as a way to limit the amount of units that are looked at to the factories and cons.

[inland haven]

I'm working on this. For example, the high/low priority check is pretty expensive but also not something likely to change often, so I figure checking a unit only once per 10 seconds will be fine.

I don't think @silver pendant was saying we should get rid of the unitcreated/unitdestroyed hooks, just that we shouldn't rely on them to be called promptly enough that our trackedUnits table will never have dead units in it.

[warped glade]

Well the change is triggered by something, can we fetch the trigger itself? That could be even more effective, right?

[warped glade]

Yes zombie units exist. That's why I made a:

if unitID is BAD then
Delete it from the table
End```

[inland haven]

Yep, I'm just saying it seems that can be streamlined with a slight change to findBPCommand, so we get:

if not unitExists then
    UntrackUnit(unitID)
elseif foundActivity then
    ...```

where findBPCommand returns false for unitExists if GetFactoryCommands/GetUnitCommands returned nil. (A 0-element list is returned for idle units.)

[silver pendant]

Please, look into the builder priority gadget imo 🙂

[inland haven]

You mean this PR? https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2536 I have looked at it, but I'm not sure what I'm supposed to do with it considering it's not in the base game yet. And even when it is in the base game, isn't the mechanism for determining whether a con is low-priority going to be exactly the same (FindUnitCmdDesc, then GetUnitCmdDescs)?

[silver pendant]

Its getunitrulesparam to get if its passive

And please help test the gadget so it can go in game faster, and give you easy access to active, passive and actually allocates resources 🙂

[inland haven]

I see that now, thanks. That'll be awesome and should be a very easy change in the topbar once the unitrulesparam is available in the base game.

[silver pendant]

here are the rules that I wish to expose:

-- Available Info to Widgets:
--Number is build speed number, and means low priority, otherwise nil means high
--Spring.GetUnitRulesParam(unitID, "builderPriorityLow")
local ruleName = "builderPriorityLow" -- So that non-nil means low prio, and the actual build speed number, nil means high

--TeamRulesParams
local totalBuildPowerRule = "totalBuildPower" -- total build power of a team
local highPrioBuildPowerRule = "highPrioBuildPower" -- The total buildpower of constructors set to high priority
local lowPrioBuildPowerRule = "lowPrioBuildPower"    -- The total buildpower of constructors set to low  priority 
local highPrioBuildPowerWantedRule = "highPrioBuildPowerUsed" -- The total buildpower of constructors set to high priority that are building things
local lowPrioBuildPowerWantedRule = "lowPrioBuildPowerUsed"  -- The total buildpower of constructors set to low priority that are building things
local highPrioBuildPowerUsedRule = "highPrioBuildPowerUsed" -- The total buildpower of constructors set to high priority that is actually spent on building stuff
local lowPrioBuildPowerUsedRule = "lowPrioBuildPowerUsed" -- The total buildpower of constructors set to low priority that is actually spent on building stuff```

[inland haven]

Looks good, minor typos:

local highPrioBuildPowerWantedRule = "highPrioBuildPowerWanted"
local lowPrioBuildPowerWantedRule = "lowPrioBuildPowerWanted"

The topbar also surfaces to users how much buildpower is reserved, which is basically all buildpower for units that have at least one command. Not sure if that's something the builder priority widget needs to concern itself with. And finally the topbar also figures out how much M/E would be spent if all low-prio builders could build at full-speed and updates the M/E pull numbers accordingly.

(The current code only considers guard, repair, reclaim, and capture orders to count as non-idle, but I think for simplicity I'm going to make move be allowed. If your commander or con are actively moving somewhere I don't think you need to get dinged for them being idle.)

So, in the future topbar:

totalBP = GetTeamRulesParam(teamID, "totalBuildPower")

usedBP = GetTeamRulesParam(teamID, "highPrioBuildPowerUsed") + GetTeamRulesParam(teamID, "lowPrioBuildPowerUsed")

reservedBP = -- iterate through builders, sum(unitTotalBP) for all non-idle builders

extraMLowPrioBuildersCouldConsume = -- iterate through builders, if GetUnitRulesParam(builderID, "builderPriorityLow") returns true, then sum(builderMetalUse / GetUnitCurrentBuildPower())

extraELowPrioBuildersCouldConsume = -- same as above for M

[silver pendant]

Pushed these to the PR

you shouldnt ever need to iterate builders

what is missing?

[silver pendant]

wanted == is building shit

used = actually got resources to build with

so three tiers for low and high prio:
Total, wanted, actually used.

[inland haven]

The topbar has a notion of "reserved BP", which is the sum of all buildpower for non-idle cons.

[silver pendant]

reserved BP == highPrioBuildPowerWanted + lowPrioBuildPowerWanted

[inland haven]

... only if the unit is operating on a build order.

[silver pendant]

of course

future has no place in this imo

[inland haven]

If my cons are reclaiming, repairing, guarding, or even just moving, the BP bar as-written shows that BP in a dark-green color to be distinguished from red that represents truly idle cons.

[silver pendant]

ugh

[inland haven]

Again, maybe this isn't something the builder priority widget should concern itself with.

[silver pendant]

sounds terribly iteration expensive

[inland haven]

I don't think it's going to be that bad as long as we're content to re-check each con's orders just once per second or so.

[silver pendant]

We shall see, use Tracy if in doubt. I know I will 🙂

[inland haven]

Just do some subset of cons on each gameframe. Is Tracy the widget profiler? 🙂

I've just been looking at the widget profiler's CPU/allocations numbers and wishing those numbers were averaged over longer timespans.

[silver pendant]

Tracy is the full-fat profiler

Which averages as you desire

[inland haven]

Scanned through your PR, I don't see any issues. How do I test it?

[inland haven]

@silver pendant , can UnitCreated be called in the middle of the execution of another function, like GameFrame or Update? Or will it be delayed until GameFrame/Update complete?

[mild python]

No it cannot. Lua is synchronous and i'm pretty certain there is no kind of multi threaded behavior

any block of code will finish running before it moves onto the next thing

[inland haven]

Cool, that's what I figured. This way probably leads to fewer widget bugs. 🙂

[patent crystal]

This doesn't affect the code in question at all, but technically coroutines can lead to jumping around in the middle of functions. That's only if there's a coroutine.yield() in the function, though. Still not multithreaded, of course, but you can do cooperative multitasking with coroutines.

My test framework does this to let the game simulation progress in the middle of tests.

[subtle plaza]

I finally got to play a game with this on! I may be in the minority, but I still think this percentage should reflect the light green / dark green. Otherwise it isn’t reflecting back to me that I’m stalling and over building. Ya, 100% of my stuff is active, but they are only operating at 30%… the 30% feels like the more important number. Otherwise this is just telling me if anything is idle. The idle units grid already does that IMO. What do others think?

[warped glade]

In my head it still makes most sense to show light green/total BP.

Light green/dark green can be quite confusing for the player. At least I struggle with it. (Tooltip info for this additional info?)

[subtle plaza]

Light green over total or light green over dark green. But not dark green over total

Is that something I can easily edit in the lua?

[warped glade]

It always was like that...
So it is easy to edit in the lua
@inland haven is it dark green over total, now?

[warped glade]

I was always unsure about the future... But somehow it felt right to show that a con has an order to use it's BP.

@inland haven does it now include waking for all units? I remember that there was an idea to include the com and the commando into dark green when they do anything but idling, because they are fighting units.

#1167027291440812063 message

[silver pendant]

Nope, in fact, if you try Tracy, you will learn more about how the engine works in the shortest amount of time possible:
https://github.com/beyond-all-reason/spring/wiki/Tracy-Profiling

Please give feedback on the truthiness of my above statement 🙂

[silver pendant]

Imo the future there is too fuzzy, while not specifically idle, its just not requesting any BP right now, but could maybe in [1-120] seconds.

[warped glade]

I get your point.
The "reserved BP" is a bit fuzzy. It combines two things:
stalling BP and will be used BP

while these two have a similarity because it is BP that "wants to be used asap" the reasons for this are different.

There were thoughts of "do I introduce a forth color?". I dumped that because it would even more info to process while looking at the bar.
There were thoughts of "do I even include future projects?". Back then I was very feature happy so I went with yes.

For the sake of simplicity (and performance) we can exclude this now.

While we are at it:
what do we handle the different kinds of spending the BP?
building and resurrecting does need resources so they must be included.
but what about reclaiming, repairing and repairing unfinished units (a "hidden" building command)?

Do we include the first two?
If we drop reclaiming and repairing (for free) we could even get rid of the
function findBPCommand(...)
that way we could only use the data from the gadget, since it handles everything that draws resources.
All this would indeed make it easier to handle BP as a whole.

That would be in line with @sudden laurel . He suggested that the income and output should just show the "normal" income and only the resources pulled by BP.

@subtle plaza and @sudden laurel if we go with this: could we just put a recycle icon beside the income (perhaps with a tooltip info with the precise number) so the player knows, that he is reclaiming? Or would there be any better way to show the total input/output/difference in in-and output?

[inland haven]

Sounds like I should enable the "treat stalling as idle" switch I added recently. That will cause stalled BP to show up as red in the bar and make the percentage drop.

[inland haven]

The reason I'm calculating the percentage as reserved (dark green) over total, instead of used (light green) over total, is that yelling at the user for low used/total seemed too opinionated. (What if your commander is in a combat role instead of building? What if your cons are moving somewhere, perhaps away from incoming raiders?) But I see the case for making sure stalled BP is shown as idle.

Another reason to consider moving as non-idle: in cases where a con has multiple orders queued -- move, then move, then build -- it should be more performant to only retrieve and check their first command than to check their whole command list.

[warped glade]

I am not so deep into all this, so maybe I am asking dumb questions.

1. Won't we get info of 50%-90% of the cons from the gadget anyways? The remaining few % of cons without an actual build/support command will be less of an issue then.
2. Does it make much of a difference when we call the first command only or x (until first BP command is found) ? Isn't finding the first element more performance intensive than finding the rest?
3. Does getCommand even make a difference doesn't it always look up all the info in the queue? Should we make one call of the function, store the command table and then go through the stored data?

[warped glade]

As soon as a human calculates a number it will be opinionated 😉.
And when more than one number is compared it can get philosophical.
So for my personal taste I'd like to know how much of my stuff I build to use its BP is currently able to do so.
If you are saying you want to know what is the % of BP that has orders that makes sense, too. It just does not fit my taste.

[inland haven]

(1) The gadget will only return BP for actively building cons, not for cons on their way to a job, so we'll still need to get commands to preserve current behavior of the BP bar.

(2, 3) I haven't tested this, but fewer allocations should need to happen if we're only retrieving one command vs all of them.

[warped glade]

Stalling for me is very much the reason I made this widget. So I'd strongly recommend that stalling is not set equal to idle.

[warped glade]

1. sure but the gadget can give us the IDs it already checked so we can leave them out for the findCommand function, right?

2. fewer sounds better, but how big is the difference in numbers? does this really matter? I ask because I just don't know.

[inland haven]

IMO stalling as reserved makes it unnoticeable to the user.

Is "reserved" something the user is supposed to reduce? I think not. Walking to a build job is fine. Guarding and reclaiming and repairing are fine too. But if stalling is lumped in with reserved, suddenly some reserved BP is okay and other reserved BP is bad and you can't see which is which.

[warped glade]

In essence the user should make sure that the BP he built gets actually used.
I personally don't care too much what kind of ineffective stuff my BP is doing.
I bundled it up in

1. actually does useful stuff, perfect
2. I gave orders so it will be useful, when it's ready (reserved BP is almost never a great thing, because if I am already stalling... The cons that will get to the build site will stall, too). The only exception is repairing and reclaim. And as I mentioned earlier: I am not so sure anymore if these two are supposed to be counted as reserved, when running towards a project.
3. I forgot to give orders... That sucks!
   And the extra cherry on top:
4. How many seconds of metal income did I use for useless BP?

[inland haven]

How many seconds of metal income did I use for useless BP?
This does not seem like a metric whose significance would be easy to explain to new players.

[inland haven]

You said stalling is very important to you, which of these 4 numbers will tell you that you have too much stalling BP?

[warped glade]

I know, it is hard to explain. But I started this widget so I can use it. I thought it was good to know that.

Now, that widget got more attention and it is supposed to work for everyone. So "time you are behind" isn't a metric I'd go for anymore.

[warped glade]

I started it because of stalling BP.
And then it evolved. As soon as I introduced the sliders everything changed. They are essentially doing what stalling BP does. They are just better in multiple ways.

https://discord.com/channels/549281623154229250/1166261686991335475

I still love how sprEEEzy just called it cheating 🙂

[subtle plaza]

I feel like we are retreading old ground again, but IMO the simple bar would be “done” if the % was light green over dark green. That’s effectively telling me how bad I’m stalling. I think in most games you want to be at like 60-70. When it drops to <50, that’s when you really feel like you’re stalling out. Idle BP is kindda player choice. But telling the player that you’re trying to apply X but only actually applying Y is important.

[warped glade]

Well this one is new. No one thought about "dark green excludes idle and is the base the total BP" yet.

But other than that: Of course we are 😉.
We are still the same ppl and everyone has his own taste and another inthusiast entered the scene. At the end switches could be a possibility. We just need to make sure that there aren't two dozen of them.
We have proMode and normal mode, now. Perhaps a simple mode can be the solution.
And if the light green over total gets voted out, so be it. I will code it in again for my PC then. 😉

[subtle plaza]

Everything can be solved with toggle switches in settings! BP shows percentage of applied, Percentage of total, or percentage of active

[warped glade]

And all three options sound totally intuitive.

[subtle plaza]

I would definitely choose to see % of applied. But it sounds like other folks would want to see one of the other options

I still dig the sliders.

[inland haven]

Here's the thing though: used over reserved doesn't tell you how badly you're stalling. Because a con driving to its next build is reserved, not active. One con building and two cons driving would be 33% used, and probably shown in red, even though you aren't stalling and don't need to give anyone different orders.

"how badly am I stalling" would be active / (active + stalled), which is a different calculation than anyone has proposed so far. 🙂

[subtle plaza]

Oh really? I thought the dark green was total BP that is trying to build. Eg commander trying to build a tower at 300bp. If you have enough M/E, then commander can apply all of that 300bp. The percentage shows 100%. However if you’re out of M/E, then we show “you’re trying to apply 300bp, but since you have no metal or energy, you’re only able to apply 100bp” the light green bar drops, and the percentage says 30%

[warped glade]

Pls look at the picture 😉 and read the instructions.
#1167027291440812063 message

We can easily pull the "future" out of the calculations.
That's what Beherith suggested and I kind of agree with it.

[inland haven]

Currently, yes, stalled BP shows as reserved (dark green). But a lot of other things show as reserved, too, which is why I'm thinking stalled should instead show as idle (red) so it's clear to the user that it's a problem.

IMO, we should have:

• light green: actively building
• dark green: not building but still following orders
• red: wasted (due to stall -or- lack of orders)

[subtle plaza]

Try it out and I’ll play test.

I hope everyone else is playtesting each iteration!

[inland haven]

@silver pendant , I have an idea for an improvement on your low-prio work, not sure when I'll have time to code it but I'll try to at least get some pseudocode up for discussion this evening.

[silver pendant]

About round robin?

[inland haven]

Yeah, about the distribution of resources. How can I test my changes? I don't see a file of this name in my BAR install, nor a gadgets folder.

[mild python]

You need to have a dev env set up, and then you need to check out the remote branch

[inland haven]

I see the readme now. 😅

[inland haven]

@silver pendant, here you go. Doesn't work yet, but hopefully the code and comments are enough for you to see where I'm going with this. https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2600

[silver pendant]

That's also a possible solution too. Would need input from the gdt 🙂

[inland haven]

Finished implementing the idea, @silver pendant. Basic testing seems reasonable. With an E-stall and everyone on low-priority, a commander who tries to build a mex gets 0 BP, while the same commander trying to build a solar or wind gets first priority (and my other build, a Mammoth from a T2 lab, has its ETA turn turn to "???" because that build is more energy-intensive and thus deprioritized).

Everyone on low-prio, E-stall: metal extractor is given less priority than the Mammoth.

Same eco, but now the commander builds a wind and the wind is given priority over the Mammoth, since the wind turbine's resource burden (taking into account what it will produce+consume for 30 seconds after being built) is a better match for our current resources.

Is there another channel/thread that I should bring this up in for review by the greater development team?

[silver pendant]

Yeah, there is a thread in gdt

[mild python]

They don't have access to that without the contributor role

[silver pendant]

Oh, ill bring it up then

But to be honest, i like the fair round robin distribution more than resource weighted one, despite being a little bit less optimal regarding resource use, its easier to understand and more consistent.

Elembis's implementation would result in inexplicable stalling depending on the structure of your economy

[inland haven]

Harder to explain than "shared evenly", I agree, but I think not inexplicable. And IMO more useful, which means it's worth explaining. Something like:

Low-priority builders aren't guaranteed resources. When leftover resources are available, they're first given out to the builds whose costs best match remaining resources. For example, in a metal stall, the first leftovers will be given to energy-intensive builds (like metal makers and metal extractors). Resources a unit will produce and draw after completion are taken into account when determining metal- or energy-intensity of a build.

[subtle plaza]

Is there a new version of the bar? I’m getting “efficient use of resources” awards more frequently now 😉

[inland haven]

No big changes in the last few days. I'm working on implementing stalled-as-idle, right now the problem is that guarding an idle factory counts as reserved -- IMO if the thing you're guarding is an idle builder, your BP should be treated as idle, too.

[subtle plaza]

Got it. I’d love to also play with a version where the % number is what we talked about. Light green over total or light green over dark green.

[silver pendant]

Best match, however is soooo subjective

And requires a lot of number juggling in the head

So why is building a blitz tank preferred over building a stout.

Cause of a slight e/m ratio advantage?

Round robin is both fair and easy on the performance aspect

[inland haven]

I would be surprised if there was any performance difference between these two approaches.

How does high-prio work -- are resources shared equally among all builds?

[inland haven]

IMO the point of low-prio is efficient use of any remaining resources. Low-prio is inherently unfair, since it's not guaranteed any resources at all.

How about this as a goal statement and/or bit of documentation in a tooltip?

Low-priority builders are not guaranteed any resources. When there aren't enough resources for all low-prio builders, priority will be given to builds that will increase production and reduce overflow.

[inland haven]

I just pushed a commit (builder priority refactor) with some tooltip updates.

[warped glade]

For me this approach looks quite helpful.

Just add
"increase production of the missing resource and reduce overflow"

[hybrid mulch]

What happens if something is being built by low prio builders and you stall. But its ratio is unfavourable, and it just sits there on 99% while a builder pushes at it and nothing happens - that is extremely counter-intuitive imo

[warped glade]

That can happen now, too

[hybrid mulch]

yes, but it happens equally now, rather than somethings magically finishing, while others sit there. Its a none-desirable temporary state, it should hurt and be consistent imo

[warped glade]

1. this is the edge of an edge case
2. there are high prio builders. The settings can give factories and cons high prio. Then only the con towers are low prio.
3. we are implementing a new bar to improve the handling of BP. So hopefully that will make this edge case even less common.

That being said:
It is easy to implement something like "if finishing the project is easy. Then finish it"

[inland haven]

Okay, I pushed some changes to the topbar. If con 1 is guarding con 2, and con 2 is idle, then con 1 will be treated as idle, too. https://raw.githubusercontent.com/gmcnew/widgets_for_BAR/main/gui_top_bar_alpha.lua

There is also a config option now to treat stalled BP as idle (which I think is the right behavior, but it's off by default for now).

[inland haven]

Yes, this sucks, but IMO you signed yourself up for the potential of infinite stalling when you set the builder to low-priority.

[hybrid mulch]

I just think it being any more complicated than "whatever is left over after high prio is split equally amoungst low prio buildpower" is simpler to understand.

[inland haven]

If you're metal-stalled and have two low-prio builds going on -- a metal extractor, and a wind generator -- doesn't it make sense to give the metal extractor priority?

This is the tooltip I have right now:

And: wouldn't it be cool to be able to set a con to low-priority, order them to build a field of wind generators, and know that whenever you metal-stall they'll automatically pause and use absolutely no resources (since the build's resource burden is 100% metal after taking eventual production into account)?

[subtle plaza]

I think it's a mistake to consider "low priority" like it was the players choice. Low priority is the default setting. If you're going to change how that works, then I believe you need to introduce a 3rd setting called "Default Priority" in addition to Low and High.

Also, this sounds like it introduces the possibility of a player screwing themselves if they forget which thing is set to low or high. Will there be a way for the player to quickly find the Cons set to Low or the cons set to High?

Perhaps an artwork change on the unit itself? Brighter or dimmer glow? Bigger or smaller nano particles?

[inland haven]

Looks like high-priority is the default for commanders and construction units, low-priority is the default for factories and construction turrets.

[hybrid mulch]

Yes, and it is configurable in Settings>Game(Advanced)>Behavior:

[warped glade]

Low prio already IS the most common possibility to screw up.

It literally takes most of your build power, doesn't show the resources needed properly anymore. On top of that a random generator decides what to build and what not. It goes so far that some blueprints can literally take forever if only low prio builders are at it.

So this is the current situation. We improved it by

1. making the resources needed visible
2. making the BP visible
   And now the suggestion comes to do
3. let low BP get handled in a more intelligent way

How this way can look like is a whole new story, but I definitely think we can make more intelligent decisions than 100% random.

I think there are arguments for a completely different way of handling low prio, too.

Right now every con and every turret has it's prio. That makes little sense to me. New player will have a hard time to understand and know what kind of con puts how much resources into a blue print.

In my opinion it would be way cooler if the player could generally decidewhat he wants to build instead of thinking about setting the helping units to the right prio.
This could be handled in an easy manner:

1. a possibility to give high prio to war or eco or distribute BP evenly.
2. a possibility to click on a single blue print and give it high prio

Sounds super simple to explain to new players. And this is a great indicator if something is simple.

If we want to get super fancy we could think about retargeting turrets to the blueprint.

What do you say?

[warped glade]

Would be great, if you can set the prio with the UI and not in the settings.

[subtle plaza]

So, if you work in software development, you know how priority goes. P1: we will do it, P2: we want to do it, P3: let’s be real, it’s never going to happen. And then… “oh crap the ceo wants a new feature, it’s uhhh P0! Stop what you’re doing and do that!

Then eventually there are more and more P0s, and the whole thing has lost all meaning

[warped glade]

It isn't split equally. It is: one low prio after another gets 100% then one gets x% and the rest of low prio gets 0%...

[subtle plaza]

So what if, you can only set one thing on the board to Hi-Priority? If it’s a building blueprint, when that building is done, you will have nothing on hi priority. You can also set one and only one con or building to go priority

[warped glade]

Nope it will return to the global setting:

1. Eco high
2. war high
3. equally distributed

[hybrid mulch]

Well that sucks

[warped glade]

The player may choose with a nice button

[warped glade]

Yes, it does.

[subtle plaza]

A single global setting works too. I just don’t like how the current game lets you set multiple things to hi priority, and it’s easy to forget which thing was change from low to high

[warped glade]

Absolutely.

"Nobody" knows that there is a setting to automatically set cons, turrets, fabs, and Coms on high or low prio at the first place.

And then you need to track every single unit to know if it is on high or low prio... It just is a pain to remember that you set your nanos on high to rush out 1 unit and then forget to set them to low again. Or any other scenario

I'd argue a global setting and a panic button are very easy to understand and to handle. I would improve QoL hugely

[subtle plaza]

Yes exactly

Lol

[silver pendant]

Right now it's unfair and uneven 😄

[silver pendant]

Yes, i have parts of the framework for gpu driven nano particles

[inland haven]

@silver pendant , instead of assigning leftovers round-robin, why not give fractional BP to all low-prio builders (where the fractions are determined as (available leftover resources / sum of wanted resources across all low-prio builders))?

[inland haven]

I'm going to think about this some more, maybe the best of both worlds will be fractional BP to low-prio workers, with econ-friendly builds getting extra weight.

[silver pendant]

Changing it is non-free in perf, thus we want to minimize state changes.

[inland haven]

In the best-case (completely steady income and build orders), the econ-support approach in my PR would require no changes to any units' build speeds and thus 0 calls to SetUnitBuildSpeed or SetUnitRulesParam.

[inland haven]

On the other hand, it does require calling GetUnitDefID for each active builder (could easily be optimized to once per unit being built). Not sure how expensive these calls are relative to each other. No it doesn't, I can add a value to the costIDOverride table to map unitID to unitDefID and then replace GetUnitDefID with lookups in the costIDOverride table.

[inland haven]

@silver pendant: I found what I think are two bugs in your PR, I'll try to drop some comments as well as push fixes to my branch later.

[silver pendant]

Oooh im intrigued

[inland haven]

What time zone are you on?

[silver pendant]

Gmt + 1, getting ready for bed

Can you mark them in the pr?

[inland haven]

Yes, I'll mark them in the PR, gotta break now for dinner though (I'm GMT-6 and the kids are hungry).

[inland haven]

One false alarm, one still looks like a bug. But it's a preexisting one: https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2536#pullrequestreview-1876809684

Okay, two bugs. This one is in code you introduced: https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2536#pullrequestreview-1876827461

[inland haven]

@silver pendant , in the worst case where resources are bouncing around wildly, both the econ-ideal and round-robin approaches may alter BP for every single low-prio builder on each update interval, right? (If at t0, t2, t4 you have enough resources for nobody, yet at t1, t3, t5 you have enough for everyone.)

[silver pendant]

Yes, it is the worst case of round-robin

Ive not been able to get interval below 6 though 😄

[inland haven]

In a different scenario, where resource income/expense are completely constant and provide enough resources for exactly half of the low-prio builders, round-robin still has to update BP for every single low-prio builder on each update, right? (First one half gets resources, then the second half, then the first half, etc.)

[silver pendant]

The worst case is the best case of the previous implementation

[silver pendant]

Yes, the only way to ensure fairness.

[inland haven]

I would like to suggest a limited round-robin (where we only assign BP to at most K builders, perhaps 1..3), followed by the econ-ideal approach in my PR for any remaining resources.

This would:

• have better worst-case constant-eco performance (K * 2 updates for the round-robin plus another ~K for any variability in resources the round-robin leaves for the econ-ideal pass to assign)
• still provide some eventual BP to every low-prio builder
• still try to prioritize builds that will help mitigate stalls and overflow (and not just solars and metalmakers, but any eco structure)

[inland haven]

(Note that in the econ-ideal approach, constant income+spending should result in very few BP updates. The low-prio builder which was assigned resources last will be turned on/off repeatedly, but the others should get to stay on.)

[fleet anchor]

Should this still go into your bar folder/luaui/widgets and Widgets/topbar ?

just cos the current luaui path seems to be in /data/

[inland haven]

The file should be data/luaui/widgets/gui_top_bar_alpha.lua

[fleet anchor]

thanks

I am not great at reading the BP bar, how do I know if I need more BP than I have by eyeing it?

[inland haven]

The little yellow and grey markers show you how much of your buildpower could be sustained by your income. If those markers are all the way to the right (or close), you need more BP, because you're in danger of having more resources than you can spend.

[fleet anchor]

I don't see little yellow and grey markers, maybe I'm being blind

unless you're being facecious and you mean the metal and E bar 😄

[subtle plaza]

I believe there are some associated pngs you need to install as well.

[inland haven]

Nope, not with my version. @fleet anchor, can you share a screenshot that includes your settings (Custom tab, I believe, for top bar settings)?

[fleet anchor]

the custom settings just seem to be widget on/off

@inland haven

[inland haven]

Ah, you're not using my branch. Try this: https://raw.githubusercontent.com/gmcnew/widgets_for_BAR/main/gui_top_bar_alpha.lua

[fleet anchor]

is this the maintained branch?

surprised they're not merged!"

[inland haven]

I have my own fork with a bunch of changes that haven't been merged into @warped glade 's yet.

[fleet anchor]

does his branch contain updates yours doesn't have too or have you been merging them all in?

[inland haven]

I've merged them all in as of a couple weeks ago, not sure if he's made any changes since. Let me check.

[fleet anchor]

have a github.com link? just so there's a file download

[inland haven]

https://github.com/gmcnew/widgets_for_BAR/blob/main/gui_top_bar_alpha.lua

My fork has all of @warped glade 's changes in it.

[fleet anchor]

sweet

thanks

[fleet anchor]

How to interpret the two markers?

not 100% sure what they denote

also for some reason a full metal bar turned from silver to dark grey

and flashed a bit between the two colours?

howcomes the green BP icon has been replaced? it was pretty !

[inland haven]

That shouldn't happen, I'll see if I can reproduce it. It only flashes when full?

[inland haven]

For consistency with the rest of the game, I decided to use a texture that's already used in-game to mark constructors and build progress indicators.

[inland haven]

Hover over them and tell me if the tooltip gives you enough of an explanation.

[fleet anchor]

IDK if it's reproduceable or not it happened after I had been fiddling with the options sliders

[warped glade]

That could help 😉

#1167027291440812063 message

[inland haven]

Figured out how I want to do this. Stay tuned on my PR, meanwhile I think the comments I left on yours are still relevant (maxInterval not being updated correctly; active builders not being set in buildTargets).

[inland haven]

@silver pendant, have you noticed the BP changing from 0.0001 to 100% causing crazy ETAs like this? The factory is low-prio.

Just a bot lab building a Thug, the ETAs don't settle down until the unit gets over 50% built.

[inland haven]

Took a rough first pass at my idea, this is what a metal-stall looks like with constant eco -- each builder's BP number bounces around a little, but they're roughly equal.

Why does nanospray look just as dense (to my eye) at 1 BP as at 80?

[steel hemlock]

Because it is

I don't think they have different animations that or your graphics settings are at play

[subtle plaza]

Does the latest version of the bar change the % number to show the light green bar? I’ve been playing and I feel even more strongly that showing the dark green bar % just isn’t useful. It’s almost always at 100%, but that’s not really helping me avoid stalling or getting maximum output of my builders.

[steel hemlock]

I want to see what happens with the widget when you pause a builder

[warped glade]

I don't know the current state. In my version it would still search the queue of the builder and add it to the dark green bar.

[steel hemlock]

Mm

Funny thing though if you pasue the builder any blueprint it is assigned to won't decay useful trick I use it all the time

But it also won't take any resources

[warped glade]

True.
It "only" costs you build power and the resources put into the blueprint are slowing down the process of the other projects.

Uhhhhhhhhhhhhh...
@subtle plaza @knotty escarp
WHAT IF we put the info about the"stored metal" inside a blueprint into the metal storage bar (while hovering over a blueprint)? With dark grey and a number in (). That would tell the player in a convenient way how much he could be ahead when he stops the blueprint.

[steel hemlock]

Yes but it's not actively taking more I use it all the time on front especially since my needs change all the time

[warped glade]

Sure. It is a good idea.
That's why I'd love to have a panic button: all resources go to this blueprint until it is finished.

[inland haven]

I suggest you re-download (I pushed a small bugfix last night) and then enable the feature to treat stalled BP as idle.

[subtle plaza]

So here is my issue with the % number. I'm playing front, and I'm trying to microunits while things build in the back. I went t2 too early, with not enough metal in the bank, and I stalled while building my lab. the % number is a happy green 93%. But the reality is, I'm using like 15% of the BP because of my metal stall. A quick glance at this widget doesn't tell me anything is wrong because it's all green. I think it should be a red 15%.

[inland haven]

I agree with you. You should go into Settings > Custom > Top Bar with Buildpower and enable "count stalled buildpower as idle".

Once that setting gets some more testing I can make it on by default.

[subtle plaza]

Oh well crap I didn’t realize I had to toggle it on, apologies. I’ll give that a go and report back!

[subtle plaza]

Same point in the game with "Stalled as Idle" turned on. I like that it's yelling at me now. Although I'm not sure what changed between the 48% and the 25% moment

[warped glade]

@subtle plaza
I can tell you what happened most likely:
There were moving cons with some BP related tasks. They are dark green. Then they arrived at the build site.... Surprise: they realized they have not enough metal, too.

This is the reason I use the terms used, reserved and idle. It just makes so much more sense to me to combine stalling and BP command in queue than stalling with idle...

[subtle plaza]

Well, it's way more useful now! I feel like it's at least reflecting back to me when I make bad choices

[warped glade]

Well it tells you that when/if your con arrives. That is too late for me. And it is hard to explain.
Your con is walking that's why he is dark green. Now it arrives and realizes it can't build that's why it is shown as idle.

In my eyes it easier to say: your con is walking towards a blueprint and wants to build but he can't -> dark green. It now arrives but it can't (stall) -> still dark green.
A forth color or any kind of other indicator could be introduced (pulsing of the corresponding stalling BP?)
But as I said earlier it is something which is highly subjective.

[inland haven]

The reason I don't like this is that stalling is a problem that the user needs to notice. (I think we can agree on this.) So it shouldn't take the same color (dark green) as other actions which are not problematic, such as guarding, repairing, reclaiming, attacking (for coms), or simply moving (perhaps to evade danger).

[warped glade]

We absolutely agree with that 😉

The stalling problem is noticed... Flags appear, %ages drop. The light green corresponds with a slider.

And as I said I understand that for your taste it is devided in problematic and not problematic and for me it is used and reserved.

What I don't like about the un-/problematic set up is:
A con that is walking towards a blueprint is problematic while you are stalling. And you will only see this when it arrives. So it is inconsistent.

Dark green isn't problematic or unproblematic for me. It is: a con wants to build asap. And when I am stalling this is a reason for it that it has to wait until resources are there. If it is walking it needs to wait until it is there.

Clearly both ways of thinking have their benefits. And I am not trying to convince you, that mine is better or something. I just say it suits me better and I'd like to have this away of showing stuff in this widget as an option. I hope you can understand that.

[warped glade]

Well the positions of the sliders tell you about your building decisions, too.
The light green, dark green, reddish colored bar is just an "% of units with an order" indicator 😉

[subtle plaza]

Sliders are great too! But in a split second I’m mainly just looking at a red/yellow/green number to see if I’m messing up

[warped glade]

And I like the number to be influenced by the used BP only 😉

[subtle plaza]

I think we agree on that

[inland haven]

A con that is walking towards a blueprint is problematic while you are stalling. And you will only see this when it arrives.
This isn't necessarily true, as the stall may be resolved by the time the con gets there (due to an increase in income or other builds finishing). Showing this as red would require looking into the future in complicated ways.

[warped glade]

I know, it is a simplification.

And I don't want to say that looking into the future is a thing to include...

Let's try to look at it another way:
10 cons are stalling. The dark green is very low. Now you send them for a walk. The walk makes no sense. But the dark green will be happily fill. Sounds odd to me.

But I am fine with it as long as light green stays the indicator for the %.
The dark green is not so important to me.
We can in or exclude walking or the stall.

.
It feels quite good to look at it like that:
Lite green: actually building
Dark green: active but not building
Red: standing around (stall or no commands)
And it is almost perfect that way...
My head still has one problem...
If you have 5 cons on high prio all are at the site and you can only support 50% of your BP... The bar will be half light green and half red... Where do you see that all of your cons have orders? In a separate widget?
Is it just me or is that odd?

[subtle plaza]

I think that’s been my position the whole time, so I agree with that 🙂 does the dark green bar misrepresent your BP if you have long build queues or does the length of a build queue have no affect? Eg: I have a con set to build one solar vs a con set to build 15 solars.

[inland haven]

The walk makes no sense
I don't think we can fairly evaluate how sensible the players' orders are. Regardless of which numbers we display, there are lots of odd/useless orders that would make the numbers look good yet be a bad idea. For example, building bunches of radar towers right next to each other (to use up your BP), or building metal storage when you're metal-stalled. We should not try to get too clever about whether the players' orders are good ones and instead just indicate how much BP is wasted due to idling or stalling.

[inland haven]

The length of the queue has no effect.

[inland haven]

Yes, in a separate widget. There are already widgets that show idle cons.

[inland haven]

@silver pendant, how much memory is saved by using a single table for metal+energy+buildtime instead of three separate tables? I'm new to Lua but haven't found any performance guides that recommend this. https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2536/files#diff-a22e4d49c40dc23cb8b0682f0d66ac984c2d033fca7a23dc8d615e3827b85e6dR149

[hybrid mulch]

Elembis this might go someway answering that query if i understand it right #1202958107907465216 message

[warped glade]

That is true.
So I would keep it absolutely simple either take the dark green as "has any order" or as "as a BP related order at some time".
Following that logic stalling would be included in dark green.
But your switch does give the opportunity to in or exclude it. So I am fine.

Just to be sure: right now the percentage shows light green + dark green or just the light green? Because light green, only is the way to go.

Other than that:
How is your gut feeling about merging the code?
I have paused my actions for quite some time now so you could play around with my code without interference. As far as I can see you did quite some work.

Looking at the to do list we are getting closer...
#1167027291440812063 message

1. looks like you are fully emerging into this
2. @subtle plaza is this still your proposal? We should design freeze it then and make sure the hover over info is including everything you want.
3. looks like it is mostly done
4. tooltips need to be defined and translated and implemented in the corresponding file
5. the explanation needs to be adapted to the actual design

What else needs to be done to get this thing into the game?

[inland haven]

My todo list:
(a) get Beherith's code merged to the base game (I have some performance improvements in mind but they shouldn't be a blocker)
(b) use Beherith's code in the widget
(c) make sure tooltips work properly (correct bounding boxes on each tooltip)
(d) provide tooltip translations
(e) fix unitsPerFrame
(f) general profiling pass (using Tracy)
(g) look at the various Top Bar options and figure out which ones really need to be presented -- there are a ton of options right now and that hurts maintainability

[inland haven]

Regarding (g): more options generally means:

• more chances for users to be confused,
• more documentation/translation work, and
• more bugs.

Here are the current options and what I think should be done with them (✅ means no changes):

• drawBPBar ✅
• countStalledAsIdle (remove from options but leave as a boolean flag, true, in the code)
• proMode (remove from options but leave as a boolean flag, false, in the code -- AFAIK the only high-OS player that's weighed in on this, @sudden laurel, has expressed a preference for the simpler, non-pro-mode presentation)
• drawBPIndicators (these are the metal- and energy-supported BP markers; remove from options but leave as a boolean flag, true, in the code)
• drawBPWindRangeIndicators (remove from options but leave as a boolean flag, false, in the code. I'm not sure a buildpower widget is the right place to present this, and it attempts to show the risk of low-wind E-stalls but doesn't take energy storage into account. A better widget would look at current energy, energy pull (minus metal-makers), energy storage, and min/current/max wind speed, and output a single number which is the percentage of time that it expects you to be E-stalled.)
• autoHideButtons ✅ (in the base game)
• debugTooltip (should be removed from options but left as a boolean flag, false, in the code)
• barScale ✅ (not related to BP but a nice addition)
• barWidth ✅ (ditto)

All of this in addition to adding a boolean in the code (not exposed in the UI as an option) for making the non-pro-mode percentage as used/total instead of reserved/total (at @warped glade's request).

[warped glade]

That sounds great.

[warped glade]

just a few thoughts regarding the maintainability and the players confusion.

1. makes sense

[subtle plaza]

There are a lot of typography issues with pro-mode. Pro mode also doesn't have the x% number on the BP bar. I think pro's would still appreciate that, but maybe @sudden laurel can chime in since he's now our resident pro player on this initiative 🙂

What can we do about the numbers overlapping? Is the total bar width something we can extend?

[inland haven]

See above, I want to just remove the pro-mode option. Anyone who's really excited about it can reenable it (in the code) and fix the alignment issues themselves. 🙂 (Notice even the energy bar is affected.)

[inland haven]

Yes, look at the "top bar width" option in the widget settings.

[subtle plaza]

If we think pro mode isn't useful, I'm happy with a less-is-more approach

If robert is still championing that version, we should try to fix the text alignment though

The simple BP bar would allow us to go in this direction in the new HUD design

I still dig the center radial bar design

[inland haven]

I like the arc too, I just didn't have a DrawArcedLine() at my disposal. 🙂

[subtle plaza]

I mean, for current HUD what you made is perfect

I want more people to use it and I want to hear that it's helpful!

[warped glade]

@subtle plaza @inland haven
I am fine with the simple mode, too.
Pro mode can be something to "fix" after the release.
As is the idea with "time you are behind".

But I really think we should focus on less features right now to not get lost in feature happiness 😉 and get ppl to use it. The more feedback we get the better.

Oh one thing that we could consider (which isn't that hard to code) is "time until empty" is an idea that got nodded at by @tidal sandal (he is 50+). So @subtle plaza it would be nice if you told us where to up this number 😉

[warped glade]

So do I!

Center...

Should the current BP bar be in the middle?

[subtle plaza]

IMO with the current hud design, it’s fine to have it on the side… but if it’s an easy change I’d like to try it out in the center.

[mild python]

even with the new UI framework there's a good chance something like this will need to be drawn with raw GL

i have some code for drawing arcs I can give to you if you want

[inland haven]

Thanks, but I've got my hands full enough for now.

[mild python]

no worries, we'll save it for the new UI 😄

[subtle plaza]

I’m planning for arcs, overlapping angles, drop shadows, glows, outlines, and animated gradients! All at the same time!

And at least 10 fonts each with different weights

😄

[warped glade]

After taking a bit to gpt and Gemini they agreed that this should work to draw a partial ring.

local gl = require('gl')
local GL_TRIANGLE_STRIP = gl.TRIANGLE_STRIP
local glColor = gl.Color
local glVertex = gl.Vertex
local glBegin = gl.Begin
local glEnd = gl.End
local glPushMatrix = gl.PushMatrix
local glPopMatrix = gl.PopMatrix
local glTranslate = gl.Translate

-- Constants for the full circle
local FULL_CIRCLE_DEGREES = 360
local FULL_CIRCLE_RADIANS = math.pi * 2
local DEGREE_TO_RADIAN = math.pi / 180

-- Precompute sine and cosine values for a full circle
local sinTable = {}
local cosTable = {}
for i = 0, FULL_CIRCLE_DEGREES do
    local angle = FULL_CIRCLE_RADIANS * (i / FULL_CIRCLE_DEGREES)
    sinTable[i+1] = math.sin(angle) -- Lua tables are 1-indexed
    cosTable[i+1] = math.cos(angle)
end
-- Add an extra value for wrapping around to avoid modulo in the loop
sinTable[FULL_CIRCLE_DEGREES+1] = sinTable[1]
cosTable[FULL_CIRCLE_DEGREES+1] = cosTable[1]

-- Function to draw a partial ring
function drawPartialRing(centerX, centerY, innerRadius, outerRadius, startAngleDeg, endAngleDeg, segments)
    glColor(0, 1, 1, 1) -- Set color to turquoise

    -- Convert start and end angles from degrees to radians
    local startAngleRad = startAngleDeg * DEGREE_TO_RADIAN
    local endAngleRad = endAngleDeg * DEGREE_TO_RADIAN

    local startSegment = math.floor((startAngleRad / FULL_CIRCLE_RADIANS) * FULL_CIRCLE_DEGREES) + 1
    local endSegment = math.floor((endAngleRad / FULL_CIRCLE_RADIANS) * FULL_CIRCLE_DEGREES) + 1

    glBegin(GL_TRIANGLE_STRIP)
    for i = startSegment, endSegment do
        local outerX = centerX + cosTable[i] * outerRadius
        local outerY = centerY + sinTable[i] * outerRadius
        local innerX = centerX + cosTable[i] * innerRadius
        local innerY = centerY + sinTable[i] * innerRadius

        glVertex(outerX, outerY)
        glVertex(innerX, innerY)
    end
    glEnd()
end

Does this make sense?

[mild python]

would need to test it out, some of that rotation code looks a little sus

[olive musk]

I noticed that the top bar and energy converter widgets crash when I share a con which is still being built.

[warped glade]

Which version?

[olive musk]

gui_top_bar_alpha

[inland haven]

Thanks @olive musk, I'm guessing we're calling TrackUnit() for the unit's new team and then UntrackUnit() for the unit's old team, and the highlighted lines in the following link are the problem. They should be pulled up into the if (myTeam == unitTeam and unitDef then block just above so that we don't do any un-tracking work at all if the team ID doesn't match:https://github.com/gmcnew/widgets_for_BAR/blob/b36f85499680638d6f13a6c24012a8c47730bedd/gui_top_bar_alpha.lua#L3461C3-L3463C8

[inland haven]

@olive musk, I wasn't able to reproduce this but pushed what I hope will be a fix. Please re-download and tell me if it comes back.

[warped glade]

Any news?

[warped glade]

@knotty escarp @subtle plaza @silver pendant @inland haven
Where are we right now?
Are there any changes in your file, Beherith?
@inland haven, are you still in?
What ever the state is:
I want to finally finish the pull request.

[knotty escarp]

where/how can I test it?

[warped glade]

@knotty escarp
TBH
I have lost track of the changes and the way they interact.
As far as I understand this version of Elembis should be the current one.

https://github.com/gmcnew/widgets_for_BAR/blob/b36f85499680638d6f13a6c24012a8c47730bedd/gui_top_bar_alpha.lua#L3461C3-L3463C8

My interpretation is, that this is still a standalone version without the desired interaction with Beherith's low prio gadget.

It follows the visual wish of Scopa.

To test it you just need to download it, like a normal widget. Then you deactivate the normal Top Bar and activate the new one.

[knotty escarp]

holy moly 3.5k LOC

[warped glade]

That's 800 more than I had.

I think it all began with 2.2k or something...

Looks like a whole lot of cleaning needs to be done...

[knotty escarp]

overlapping text should be fixed, possibly by aligning the the left, and expanding to the right

i would also like a little added shadow to the arrow indicators

so they dont blend too much with the bright green

[warped glade]

I thought the overlapping was already fixed.
And the label isn't even right. It should say you are not using enough BP. Because you DO have enough BP. I'd argue it is even a bit too much.

I will have a look at the indicator sliders and try to include the shadows.

I still think Elembis did quite some good work. He had many ideas I would never have been able to come up with/implement by my own. But the current state looks a bit messy from what I have seen so far.

So it means clean up time!

We finally need to implement the connection between the gadget and the widget. That should save a huge amount of code in the widget.

[small spade]

Widget does not gets affected by interface scale, is this a known issue?

[mild python]

might be worth checking if a reload fixes it. I haven't looked at the code but it's common for UI's to support config changes like this but not have the reactivity to change real-time

[small spade]

right when i enabled, i noticed it being than the default bar too, and i use default interface value too, (my resoution is quite odd, it might messing with scaling in some way 768p)

[olive musk]

https://github.com/gmcnew/widgets_for_BAR/blob/main/gui_top_bar_alpha.lua this is correct link. You linked the commit before the latest fix (I also got caught by it :D)

[warped glade]

Thx.

[warped glade]

Can you send a picture, pls?

Oh boy. It feels like some progress (in terms of graphic enhancement) was made and the toggles seem to work, but there are some new issues.

I think it is time for me to understand what Elembis did and fix all the new bugs that were created by the new code.

YAY!

[olive musk]

this it not fixed btw 😛 #1167027291440812063 message

[warped glade]

YAYYY!

MORE BUGS!

🤮

Does anybody have a motivational speech for me?
I need it.
This will be some work.

[terse obsidian]

I believe in you and your ability to make an amazing top bar

[olive musk]

Buggy top bar breaks my heart and my wife said that I'm a different person since it started acting up

[warped glade]

I have looked at the code a bit, now.
In addition I looked at the Beherith's Gadget and thought about the possibilities to use Beherith's parameters.

Long story short. Currently it looks as if we could save many many many lines of code and performance if we use the new possibilities. But we would loose "some" features and the top bar will get "a bit" less accurate. I can't fully estimate yet how big the differences will be.

I think there is no real other way than just trying it out. Are you able to articulate any goals/features you want to keep? If not, no problem. I'll find a way.

Do you know anything about Scopa and or Elembis?
They went silent for some time now...

[inland haven]

Sorry! I've been pretty busy with other stuff. The todo list I posted on Feb 20 is still reasonable as far as I know, I just haven't had time to get back to it. Fixing unitsPerFrame and doing a profiling pass in particular are going to be pretty time-consuming.

[warped glade]

Np.

Welcome back, you mad man! 45 contributions and over 800 additional lines in 30 days... How are we supposed to keep up with this pace? 😉

I am not sure if the units per frame function is still needed. We now have access to new, parameters. We should use them and delete most of the initial data collecting code that is used for cons that are at the build site.

https://github.com/beyond-all-reason/Beyond-All-Reason/blob/3c79653259fe4b04204e7624c1f42367fd53230a/luarules/gadgets/unit_builder_priority.lua#L589

As far as I can see the new parameters will hugely improve performance. And I think it is desirable to shorten the code.

This widget was extremely long to begin with but now it just looks humongous. Despite the name "major clean up..." 😉

What is your gut feeling about the new parameters?
Do you think there is another way to shorten the code?

[knotty escarp]

sorry for my little time here - i've not been on top of this for some time and tbh i don't have a complete overview of the new topbar - especially the pro stats. I've played a couple of rounds with the simple version.

I think Scopa has a better view on this and hope he can jump in to advice here

[subtle plaza]

Hey also been busy elsewhere. How can I help? When I last left this project, I thought we had settled on a non-pro version of the BP bar tucked to the right of the metal and energy bars. I believe we also said to remove the “you need more/less” messages? I was playing game with that small bar and it seemed useful for me. I don’t know the process of taking that and making it part of the main game. The PRO version seemed to be on hold. So I haven’t looked at that at all. There were a lot of text issues.

[warped glade]

Welcome back.

Everything is still the same here. It became very silent, though. So I wanted to make sure everyone is alive. 😉

So, after this break we can now finish this part of the project.

Let's go!

[silk surge]

Does this work yet?

[warped glade]

It does.
There are some minor details that need to be improved, but it definitely works.

There are different versions with different focuses. If you need anything, just ask.

[warped glade]

I placed the BP in the middle now (on my PC).
The thing is: the Top Bar is and always was off center. With two bars, only it doesn't bother me too much, but with three bars, it does.

What do you say?

[olive musk]

lack of symmetry bothers me 😄
maybe on the left? But it will still be off with converter usage widget enabled

[warped glade]

yes.
All windows in the top bar are drawn from left to right, currently.
IF we descide to change that, that would open a huge problem in its own, I fear.

currently I am learning to use the dev loby and the tooltips from I18 and so on...

[olive musk]

I would keep in on the right then. I guess it's off center because the converter usage is hidden?

and how does it look on maps with different shape?

btw, is the crash when sharing units fixed in this version? I like the looks of small bar but it doesn't work :<

[warped glade]

Well there is just one thing to say about all this:
I am on it.

A shit load of new dependencies was introduced. At least one bug might still be alive and quite some locations of flags are off, now. Inconsistencies in the names are were found, too.
In short it went from"I just want to fix some ethetical problems" to "oh shit where do I start".
I see much potential in some of the new code so it isn't just a "I'll just take my version and edit it a bit"-solution anymore.

[terse obsidian]

configurable order to draw the sections in?

as in, edit some list at the very top of the file

[subtle plaza]

Is the energy conversion widget a default element now? It’s roughly the same size as the BP widget and it’s drawn to the right of the energy bar. IMO, the current design style of the bars lends itself to left to right rendering starting with the currencies. Doing it that way kind of hides the asymmetry. In the new UI proposal where BP is centered, I also reduced the size of the supplemental information like wind speed and tidal power so it doesn’t look as heavy on the right

[warped glade]

As in: save the space for a widget that isn't in the file of the top bar.
It is doable, and I already have an idea how it would be done. But given the fact that the whole code is a humongous mess this will be at the buttom of my priority list.

I now have a version on my PC that can communicate from Beherith's gadget to my widget.
I included a few more variables to get the most out of the calculations Beherith is already making.

In addition I managed to include a few lines in the language pack. So the tooltips can now be multilangual, I guess.

[warped glade]

As far as I can see, the converter widget is still a widget and not included in the base game.
Would you go for the BP bar in the middle right now, or in a later iteration?

I just found out:

the individual scaling of the individual scaling of the top bar works.... most of the time...

ahhh a thing of beauty!

and so the joury begins, again...

[subtle plaza]

I don’t know how it’s built in code, but it seems to me that the entire top UI should be in the same container. Minimap, economy, and menu. Set the whole thing to fit the width of the screen. Have two empty spacer containers between the map and eco and the eco and the menu

Rendering them as three independent elements seems to be prone to overlap errors

[warped glade]

I have been told, that the UI will get something like containers, but right now it is more like:
the minimap has a max width.
the TopBar will be on the very edge of it (they do not communicate with each other)
Then all the other infos are shown. everybody hopes that they won't get to long and
then the Menu exists on the right side. it will be influenced by the scaling, how far it reaches.

While we are at it: It still bothers me, that the higher number of the wind is on the bottom. Should we change that?
This would be easy.

and I found out that the % is now corresponding with the reseved BP, that makes no sense. especially, when stalling is counted as idle. "Almost ready code" everywhere. 🤮

[mild python]

Putting them in an actual shared container is not really possible with our current UI tools, but you can get similar results by putting a little communication between the widgets, to tell each other how much space they are taking so everything can position accordingly. A lot of pieces of the current UI do this to make sure things still work when switching around things like buildmenu position, order menu position, etc.

[warped glade]

If I am not mistaken this is what WG"TopbarArea" does. (Might be a slightly different name.)

Right now I am going out for a big bug hunt and cleaning process. I think we need to have a solid foundation before we add more features/improve anything.

[inland haven]

@warped glade: I am out of steam and out of time for this project for now. I think my branch has a lot of improvements in it -- UI, math, options. Is there anything small I can do to get this PR merged? https://github.com/roberthartmann/widgets_for_BAR/pull/2

[warped glade]

Yeah, I felt that way, np.

It does have some improvements, I will merge it.

It is still some work to do, but it helped a lot that it wasn't a one man show all the time. THX for your help.

[inland haven]

Of course. I hope to be able to come back to it before too long, I just can't guarantee when that might happen and don't want to be blocking progress in the meantime. 🙂

[terse obsidian]

having used this widget for pretty much my entire time playing multiplayer...

It was very helpful when I was picking up BAR, but less now that I have a feel for things.

I'll probably be checking it more if/when I am trying to optimize my play.

very useful for low and high skill players- less so for mid skill players in my personal experience with it

it's a very good indicator of what's stalling your production

[sturdy yarrow]

2) Download the picture leads to an invalid link.

[warped glade]

@sturdy yarrow
True...
too many versions...
I will upload the images again, some day.

Meanwhile you can use the alpha version.

[hybrid mulch]

@warped glade do you have anywhere handy the ramp up speed of buildpower on conturrets??

[warped glade]

Nope.
I think the widget of Masterbel might be able to show it. Then you could print out the ramp up frame by frame.
Be careful though:
BP spend is NOT always equal to the real build speed. It is safer to look at the metal spend.

[warped glade]

I am back and working on the widget, again.

And it now works as intended, again.

That was a huge step. Further steps will follow.

Feel free to try it out.

https://github.com/roberthartmann/widgets_for_BAR

[warped glade]

@subtle plaza

Long time no see.
I am on the widget, again.
It made big internal progress. And I have a new guy that seems to be interested in putting solid work into the design.

And Idiot pointed out that the symbol in the middle looks like a T2 Core energy converter.

[compact mango]

This topbar is beautiful

[subtle plaza]

Oh cool! Ok. We probably shouldn’t go with that symbol for now. Should probably be the construction icon.

[warped glade]

Will tell him.

I managed to do this: btw

It can be % dependent and overlapping and everything we need.

[warped glade]

I made a pull request before my vacation and it got closed.
It seems as if it isn't really wanted/ the final visualization isn't agreed on 100% yet.

[compact mango]

How do you make a pull request @warped glade ?

[warped glade]

you have to make a branch under your name on github and then you can create a pull request

[dense basalt]

Is it this widget that removes the converter usage widget? I can't enable both together

[clever oyster]

I'm getting Emergency garbage collection due to exceeding 1.2GB LuaRAM errors because of this widget all of a sudden

[clever oyster]

Yea, it broke my converter usage widget too. Now I can't even load it.

[solid lantern]

Same here... It took a while to notice 😕

[warped glade]

wow that's new

someone must have changed something...

[steady bone]

auto

[warped glade]

well this was an older version

this one is working and shouldn't have the garbage problem, nor the converter problem

[warped glade]

fixed

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar_alpha_0.4.008.lua

[wise gust]

@warped glade still broken with this error code

for not showing the converter image

[warped glade]

Strange...
It works for me.

Can you hit F11 and make sure the version 4.008 is active?

[warped glade]

Strange...
I am away atm.
Will look into it next week.

[storm dagger]

me too~

[warped glade]

@wise gust @solid lantern
this version works for me...

1. copy paste the widget into your widget folder
2. deactivate the original top bar
3. activate the version 4.010
4. hit "Enter" type " /luaui reload "
5. enjoy

[warped glade]

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar_alpha_0.4.010.lua

[wise gust]

yep working correctly now

[warped glade]

yay!!!

i can tell you there were some changes in the way widget are handling things, in general...

[solid lantern]

mine is working now too, except i am seeing several hundred overlapping range indicators when i get to late game now. only started happening when i updated this widget.

[solid lantern]

I have been fiddling with the settings and the vanilla widgets that are active to try and fix it. i'll try reproduce it and get you a screenie.

[warped glade]

logs are better, than screenshots

[warped glade]

In this case a replay would be even better.

[smoky kindle]

Would it be possible to increase the display speed of the widget? Right now it lags so much behind that the a unit is done (so lab is for a second idle) before the bar displayed the BP that was used during unit production due to i guess animation speed.

[warped glade]

Valid question.
It is a thing of balance. I had complaints about BP jumping all over the place (which it does in reality) so I went with a gliding average. Sure enough it can be made more responsive.
Simply open the Lua file (with any text editor) search for
initWeightedAverage(30)
And change it to your liking.
30 means 30 game frames (exactly 1 second) so if you want to have it in 0.333 just replace 30 with 10(all of them)

[fringe thorn]

[sour stream]

.

[warped glade]

..

Anything to say, or do you just want to tell us, that you like it? 😁

[sour stream]

yes, i like it. Using it right now 😄

[umbral stratus]

Is there a way to have the side options enabled while disabling the top bar? I like to be able to have the options there because I can't remember the buttons for them. ESC doesn't bring me to the lobby screen so I don't know what to press for it

[warped glade]

I don't think so.

What is your use case?

[warped glade]

Do you mean bringing the options up, when the new bar is enabled?
Move your mouse to the position the options are and they will appear.
If not, tell me.

[umbral stratus]

Sometimes when a game starts it won't show you the number of commanders that are in the match. Restarting the widget fixes it but still annoying to deal with.

[warped glade]

Kk. Thx, good to know.

Replay could help

[umbral stratus]

Ill get one to you tomorrow but its like this every game and you have to re-enable the widget once the match actually starts with all the commanders in. Otherwise the commander counter is blank.

[warped glade]

That's strange since I didn't change anything for months now and I don't even know the problem, but I will have a look at it.
I am currently on holiday and don't have a PC with me so it will take some time until I can actually look into it

[warped glade]

I have two things I want to ask you:

1. can you deactivate every custom widget except the top bar for a new game please? If the problem persists them it's the top bar itself
2. if the problem doesn't appear with everything else turned off, the please send me a list of widgets you are using

That would help immensely

[umbral stratus]

ill try this out later im playing with some buddies rn

[warped glade]

There is a second top bar widget...
And are all of them turned on simultaneously?
They are only important if they are turned on.

[umbral stratus]

no i turned one of them off

there should only be 1 top bar widget on

[warped glade]

I hate you 🤣 ❤️
Soooo many possible interactions

[umbral stratus]

https://tenor.com/view/its-time-gif-7187193397279150206

[warped glade]

It would be awesome if you could test which of the other widgets causes the problem (if any)

[umbral stratus]

more console error logs

a lot of the widgets i have are like completely new boxes that show different info, they shouldn't conflict at all with the top bar

this is the other top bar thing i have disabled because the ui doesn't match up with your build bar
https://discord.com/channels/549281623154229250/1406718438801543339

later ill just restart every game with a widget turned off which will be tedious but im unemployed so idgaf lol

[umbral stratus]

@warped glade this is a issue with the widget itself, problem still persists with all other widgets removed

im using "gui_top_bar_alpha0.4.010.lua"

seems to just not update the commander count when the game starts

[warped glade]

Thx.

[grim slate]

This bar seems cool, but my Settings panel stops working with it active..

[grim slate]

Also, some games don't accept custom widgets, so you have to manually turn on the old bar. And it's glitchy (chat stops working)

Ideally it should swap the 2 automatically