A stall indicator: how much % of the build power is actually used

[jagged canyon]

I find myself stalling more often than I want it to be true. Having too much build power and too many projects can be game losing.
So I would love to see is an indicator just like the energy converter one. A small box with the percentage of how much of your build power you are using.
Sure enough this could get complicated quickly. But I hope that it would be as easy as finding one builde with high priority and another builder with low pro priority which are building at the moment and take their numbers for the percentages. Maybe you could even store these numbers for thirty game frames and only show the average of the last second.
What do you think is such a widget possible?

[sturdy bluff]

We had such a widget in the distant past, but it wasn't any good or really used/usable.

Perhaps it needs a rethink, because I could imagine something like this being possible.

[lofty fern]

@sturdy bluff What were the issues with the previous widget, if you don't mind me asking? (and/or do you have a link to the old one?) I've been thinking about making a widget very similar to this request.

[sturdy bluff]

@scenic chasm made that - maybe he can tell a bit more?
I mean that buildpower bar you had next to the tooltip in bottom right

[glacial loom]

I suggest that if you hovered over the resource bars it would show all your income and expenses in a stellaris fashion. This way you’d have tables showing your deficit etc

[sturdy bluff]

do you have a screenshot / example?

[glacial loom]

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

[jagged canyon]

That sounds like great stuff!

I have put a bit of thinking into the code. Perhaps something like this could work as a base:

local myTeamID = Spring.GetMyTeamID()
local buildPowerData = {}
local avgBuildPower = 0
local builderUnits = {}

-- Called when a new unit is created
function widget:UnitCreated(unitID, unitDefID, unitTeam)
    local unitDef = UnitDefs[unitDefID]
    if unitDef and unitDef.buildSpeed and unitDef.buildSpeed > 0 then
        builderUnits[unitID] = unitDef.buildSpeed
    end
end

-- Called when a unit is destroyed
function widget:UnitDestroyed(unitID, unitDefID, unitTeam)
    if builderUnits[unitID] then
        builderUnits[unitID] = nil
    end
end

-- Called every game frame
function widget:GameFrame(n)
    local totalBuildPower = 0
    local usedBuildPower = 0

    for unitID, buildSpeed in pairs(builderUnits) do
        if Spring.GetUnitIsBuilding(unitID) then
            totalBuildPower = totalBuildPower + buildSpeed
            local currentBuildPower = Spring.GetUnitCurrentBuildPower(unitID)
            if currentBuildPower and currentBuildPower > 0 then
                usedBuildPower = usedBuildPower + currentBuildPower
            end
        end
    end

    local buildPowerPercentage = 0
    if totalBuildPower > 0 then
        buildPowerPercentage = (usedBuildPower / totalBuildPower) * 100
    end

    table.insert(buildPowerData, buildPowerPercentage)
    if #buildPowerData > 30 then
        table.remove(buildPowerData, 1)
    end

    avgBuildPower = 0
    for _, power in ipairs(buildPowerData) do
        avgBuildPower = avgBuildPower + power
    end
    avgBuildPower = avgBuildPower / #buildPowerData
end```

Note that this is only a rough idea without fine-tuning anything.

Further more I have some problems with the GetUnitDef."name" stuff.... I just guessed the def name "build speed". It could be workertime or God knows what.

[plain wigeon]

use triple backslashes(* * **) for code: like this`

single backslashes are single-line code

multi-line code```

[jagged canyon]

Done.

Any feedback considering the code?

[plain wigeon]

Remember, you still need to add the builders to the list even if the widget is activated after the units are created or if the units are given to you https://discord.com/channels/549281623154229250/1156277079311142983
use this for reference

The rest seems good, except some minor inefficiencies

for instance, you iterate through all builders every frame only to get their buildpower(which will never change).
Instead, when initializing the builder(in this case adding it to the list), just have a total buildpower, and remove from it once a unit has been destroyed

[jagged canyon]

Nice input.
I will try to include this.

[plain wigeon]

I also forgot, you forgot to check if the unit is from your team.

[jagged canyon]

That's true. I will copy that from other widgets.
We are getting closer 😉

[plain wigeon]

Cheap way to do it:

     return
 end```

Add at the beginning

~~And build power isn't buildspeed but workertime ~~

Use this for unitdefs reference https://github.com/beyond-all-reason/Beyond-All-Reason/blob/master/units/ArmBots/armck.lua

[plain wigeon]

This is actually wrong(I think) so use:

if (myTeamID == unitTeam) then
   if unitDef and unitDef.buildSpeed and unitDef.buildSpeed > 0 then
       builderUnits[unitID] = unitDef.buildSpeed
   end
end```

[lofty fern]

within widgets, it is actually buildSpeed. there's a processing layer where a lot of the fields in the unit lua files are converted to different names

[plain wigeon]

Oh thx

[lofty fern]

this is the code fragment I've been using to get the buildpower usage:

local function calculateBuildpowerUsed(unitIDs)
  local buildpowerAvailable = nil
  local buildpowerUsed = nil
  for _, unitID in ipairs(unitIDs) do
    local defID = Spring.GetUnitDefID(unitID)
    local buildSpeed = UnitDefs[defID].buildSpeed
    if buildSpeed > 0 then
      buildpowerAvailable = (buildpowerAvailable or 0) + buildSpeed
      buildpowerUsed = (buildpowerUsed or 0) + (Spring.GetUnitCurrentBuildPower(unitID) or 0) * buildSpeed
    end
  end

  return {
    buildpowerAvailable = buildpowerAvailable,
    buildpowerUsed = buildpowerUsed
  }
end

I've also found that averaging over time (probably a few seconds) is basically required, since buildpower used changes so much in between one unit finishing being built and the next one starting

[plain wigeon]

If you look at above, Robert actually averages for a second

[lofty fern]

right, just noting that it's something important I found when testing

[plain wigeon]

This currently works

Remember to change the language to lua

Spring.Echo is currently used to output how much bulidpower is being used

[jagged canyon]

@plain wigeon @lofty fern freaking amazing!

thx so much for getting it to work.

[jagged canyon]

i've added math.floor to have a better readable number
avgBuildPower = math.floor(avgBuildPower / #buildPowerData)

[jagged canyon]

@plain wigeon @lofty fern
after a long fight I managed to show ANYTHING on the screen regarding a UI.

there are some major problems:

1. the text is flickering at best... most of the time the % is not shown at all
2. there is still a tooltip from the converter widget
3. it's ugly

BUT
it "works"

[wooden oxide]

I'm having some overlapping issues, probably due to my UI scale, left side and right side both.
Not sure how to solve tho, top bar is just crowded. @jagged canyon
Will just reduce UI scale as workaround for now.

[wooden oxide]

Also, I seem to be unable to use 100% of my build power, getting max 97%.

[jagged canyon]

@wooden oxide
Good to know. I will tackle this tomorrow.
I can use 100% of my build power. At least when only my com is active. I will figure out a way to understand why this is happening.

Perhaps I will need your help in form of you downloading a file with some logs/spring echos activated and then posting the textlog.txt or however it might be called.

Regarding the overlapping: I haven't tested it with different scales nor resolutions... I'm playing with 2560x1440 and 0,8 scale... Surely not a standard setting 😉. So I guess the widget will need some more love, which it deserves.

[glacial loom]

Could it be that some units are not used in those 97%? Minelayers, com perhaps? And are rezzers counted?

[jagged canyon]

It has something to do with energy converters

[jagged canyon]

I will have to do quite some research, I guess...
Perhaps they have some hidden inefficiency or buildpower or something.

[jagged canyon]

@wooden oxide new version is out
I found an error in the logic to calculate the metal and somehow that seems to fix the BP problem, for me 😄
as allways files can be found here.
https://github.com/roberthartmann/widgets_for_BAR

if you can recreate the error, feel free to send me the infolog.txt of the widget with logging

with and with out MMs all seems fine ,now

[jagged canyon]

You can turn the widget on, if you see an unexpected behavior during the game so the infolog isn't 2000000 lines...
In fact I can only use the data if you turn the widget with log function on for only a few seconds otherwise the spam will make the data unreasonable to go through.

[jagged canyon]

@minor haven
the PoC is WORKING!^^^^!!!111!!1

internal stuff is just set to fixed numbers... BUT it shows as hoped!

[jagged canyon]

@wooden oxide @glacial loom @lofty fern @high prism @celest aspen

after a few more fights with the code i got it convinced that it shall show useful numbers...

be aware that the occupied buildpower is shown with the pale red number not, yet, shown on the bar.

the yellow and green numbers are
metal you are not using for building and total metal stuffed into building power

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar 02.lua

you will have to hit F11 unload the top bar and load the top bar 02 to get it

i hope this works for you

[jagged canyon]

made the two red numbers switch so they mean the "same" as the original bar

here is the new link

oh... and the yellow number is the metal you are putting to good use... not the inverted one...

but that's work for another day...

today i feel like this was enough!

most amazingly it even works while specing.... more or less... you have to turn the widget off and on again...

so it will reinitialisice

[high prism]

there is a whacky thing. Widget enabled:

widget disabled:

if default top bar is on and I enable and disable new one:

also, when I start the match with widget on it looks like this:

there is also a bug in tooltips:

would it be possible to ignore factories in the bar? I feel like I would use this widget to see if I overbuilt/underbuilt buildpower. In this situation im not stalling on anything but half of the bar is empty, because factory costs too much in comparision to cons/turrets

[jagged canyon]

regarding your pictures:

1. looks fine to me
2. that's the standard top bar, when no widgets are enableded. it's supposed to be like that
3. and 4) this happens (on my pc) when I load both bars at the same time and then disable 1. just don't ;). disable both and then switch on one.

tooltips are for another day

and for today my brain is empty.

[high prism]

Other than these, it looks great now and seems like ui overlaping bug was fixed in the process (i had to restart widget everytime for it to be in correct spot :D)

[high prism]

I mean, the first thing I did was to just enable this widget and I got 2 top bars. So I disabled the widget and was left with default top bar and this default-default bar

[jagged canyon]

sure thing it is possible to exclude factories aswell...

but surely not today 😉

[high prism]

I guess it's no issue if you dont turn it off but I guess if it crashed for some reason it would leave game in odd spot

[jagged canyon]

i'd recoment to use the version 0.21

well this look funny, too

[jagged canyon]

will need to fix it another day

[high prism]

played a match with that already and it felt very good. Althought I'm looking only at the bar - if it's full then build more bp 😄

[jagged canyon]

So it works as intended.

[jagged canyon]

@celest aspen @high prism
https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar 0.22.lua

1. It now has the second Bar
2. you can now exclude factories
3. the issues with the starting bar is fixed
4. now the time you are behind because of too much buildpower is shown
5. the time is shown in a color so you easily see if you have way to much BP

1. It now has the second Bar
2. you can now exclude factories
3. the issues with the starting bar is fixed
4. now the time you are behind because of too much buildpower is shown
5. the time is shown in a color so you easily see if you have way to much BP

pls put this file into this foder

AppData\Local\Programs\Beyond-All-Reason\data\LuaUI\Widgets\topbar

[high prism]

Great!

[jagged canyon]

@high prism

Oh and:
Now the widget uses the actual Buildpower, not the metal that is unproductive to calculate the % of the filling. As requested.😉

[wooden oxide]

great stuff @jagged canyon, just tested it and it works great!

[wooden oxide]

played a lot with it tonight, and it seemed to crash quite consistently late game. also seemed to take the converter widget down with it. re-enabling caused it to crash again instanly most times. not sure where to find the logfile tho:)

[minor haven]

AppData/Beyond All Reason/data/infolog.txt iirc

[jagged canyon]

Thx for the info and testing it.

When I hear "late game crash" many things jump into my mind. The two most important ones are:
Cool it seems to work quite OK and the other one is... OMG how am I supposed to find the error!

I will have a look at it on Monday. I'm off for the weekend in the mountains 🙂.

Until then: log files pls. Let's hope the issue can get fixed.

[wooden oxide]

Found the logfile and this seems to be the relevant info, popped up three times in the log file with same message every time. Seems the converter widget crashed because it depends on the topbar being there.

let me know if you need anything else

full log here

[wooden oxide]

Seems to work very well otherwise, happy to play with it and get some insights on my eco!

[jagged canyon]

happy to hear 🙂

you found the right lines of the log. good job.
Now I need to understand what is happening 😉

[wooden oxide]

was just about to test it more in a skirmish. it seemed to happen when we reached a certain point in our eco - me and a buddy used it playing vs raptors etc yesterday. he had the same issues

[jagged canyon]

kk

any chance to give me a savegame? so I can load it and test it on my pc.

Perhaps I have to devide the calculations into more frames.
Right now I hammer though everything in one frame and repeat this every 6 frames or so.

[wooden oxide]

will try to make it crash and make a save :D

[jagged canyon]

THX

the thing with the converter widget is:
it tries to get it's position by looking at the position of the top bar... and if it isn't there anymore. yeah this means it tries to get a number, which does not exist...

[wooden oxide]

yep, seemed like it from the log text, so no worries there

[wooden oxide]

here we are

when i set the air cons to assist t2 con, widget crashes.
if i pull them off i can re-enable

i can get it to crash consistently. 1 t2 air con + 83 t1 air cons = fine, 84 t1 air cons = crash. :)

[jagged canyon]

Very good observation!

This will save me a ton of time!

I will use your info as soon as I am back from the weekend.

Thx again

[agile star]

Making a bar for buildpower seems overly complicated for this.

Why not just make the metal/energy expenditure show the numbers you would actually (try to) drain, if all your constructors were set as Active?

[jagged canyon]

@agile star

It has been quite a journey up until this point and when I started I really couldn't forsee how far this would go.

Here are some reasons why this bar has some value and why I didn't "just" repair the age old active/passive worker issue (now that I thought about it I remember that this was already a problem before my 10+ year pause to play TA spring/BA)

1. Because I don't know if I can do it 😉
2. visuals are faster to read
3. ideling cons are considered with this bar
4. you now see how many seconds you could be ahead if you had built the perfect amount of buildpower

At the same time you can easily argue that this bar is overkill for some players. I know that I, myself was perfectly fine if all units being set to active/high priority so I could read the numbers... But everyone is different and things can change. So I guess I won't just throw my work out of the window and add both functionalities into my version of the top bar, making a switch to let each player decided if he wants to "only" fix the passive/low priority problem (if I can fix it!) or get the bar with a few extra goodies.

Hope this gives some insights.

[jagged canyon]

it seems as if I will would need the lua aswell, butt now I know what to do i will just hammer out an infinate amount of air cons 😉

[wooden oxide]

ah shoot, here they are just in case, should be the save

[wooden oxide]

it is useful info when learning the game, balancing income with cost (buildpower) is one of the hard things about BAR

[jagged canyon]

thx.

I tried a game on my own it is the exact same it is the difference between 83 -84 T1 cons

[jagged canyon]

it's DONE

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar 0.23.lua

[high prism]

If (Airconcount > 83)
dontCrash();

[jagged canyon]

👍

How did you figure out my solution? 😉

[jagged canyon]

if changeSpec == true then
don't crash

is activated

aswell as

if low prio == true then
still show somewhat ok resource drain

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar 0.5.lua

[wooden oxide]

Specced the engine test lobby yesterday and had a couple crashes. One was when the player i specced died. Can look for the log later if you want.

[jagged canyon]

@wooden oxide

Would be great!

Dying player, you say.... I have to consider that...

[wooden oxide]

this seems to be the relevant part

[t=01:20:40.337526][f=0017111] random_variable left a small crater
[t=01:20:40.468381][f=0017130] Error in Update(): [string "LuaUI\Widgets\gui_top_bar 0.5.lua"]:1410: attempt to index field '?' (a nil value)
[t=01:20:40.468411][f=0017130] Removed widget: Top Bar 0.5

[jagged canyon]

dirtiest fix of em all but it will now not crash anymore, i guess

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar 0.51.lua

i don't know about the dying player yet

[high prism]

just a comment, would be nice if you didn't change filename each time 😄

[jagged canyon]

ok, i will make one current version file and the rest is for me, as a backup then 😉

[high prism]

you have git, you dont need backups 😄

[jagged canyon]

Me==mechanical engineer in development
I have no clue of programming 😉

This code is 60%+ Floris
20% chatGPT
And the rest is 100% sweat and tears 😉

[wooden oxide]

and a 100% reason to remember the name :)

[jagged canyon]

❤️

[jagged canyon]

To activate the new top bar:

1. download the widget and put it into your widget folder
2. download the picture
   store it in "Widgets/topbar"
3. start a game deactivate the original top bar and start the new one (otherwise there will be graphic issues)
4. reactivate any widgets that are beside the top bar (they have to find the position beside the top bar again)

https://github.com/roberthartmann/widgets_for_BAR/blob/main/BP.png

@wooden oxide @high prism
a new version is out
It now shows the exact metal drawn value even with low priotity builders.
It now resists watching players die.
It now "ignores" units that can't assist (e.g rez bots)

It now won't change its name anymore 😉

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar_2.0.lua

if you don't find anymore bugs I'd hereby declare my mission as done 🙂

@minor haven
is it possible, that there were some changes in the resource calculations?

[jagged canyon]

time you are behind:

quite simply:
you are not using all of your BP, that is inefficient.
This is an easy indicator of how inefficient 🙂
green = good
red = bad
everything between that is between that

in detail:
It's the "total metal cost of unused for build power" divided by your metal income.
to calculate the amount of unused metal bound in builders you multiply the % of BP that are unused by each building unit with its metal cost. That's the amount of metal that is unproductive for that unit. Now you sum this up and you get your "total metal cost of unused build power"
you divide that with your metal income and you now know how many seconds of metal income are laying around unproductive. Or: how far you are behind if you hadn't any inefficiencies (which is impossible)

[minor haven]

I dont think Id know about changes to resource changes

Ohhh wait no I do remember seeing something

I cant find commit evidence though

Can you make sure you have tooltips for each of the numbers / bars (if possible?)

Im not sure how the tooltips work tbh, but theres some sort of existing infra for it

[jagged canyon]

@minor haven
I think the metal drawn got way better in the old top bar, now. It shows the draw of all active/high prio units, now. That messed up my calculations...
Still the low prio isn't considered with the old bar. It is in mine 😉

tooltips 🙂
totally forgot about them
I will have a look

[jagged canyon]

@minor haven @high prism

I have managed to find the tooltips and how to use them for the "existing" tooltipboxes... but the time behind is a different story... there are no existing tooltip boxes...

you can download it now

@minor haven
never mind 🙂
I managed to make a toop tip for it as well 😉
just download it

[abstract garden]

I wonder if there is a way to show the average efficiency of having 1 air lab vs 2 air lab

right now it just goes up and down between planes, so maybe increasing the average duration would do it?

[jagged canyon]

It is absolutely possible. I had an average of 5 seconds build in.
I'll see what I can do for you.

[jagged canyon]

@abstract garden
done

stalling indicator was added aswell 🙂

https://github.com/roberthartmann/widgets_for_BAR/blob/main/gui_top_bar_2.0.lua

[abstract garden]

cool, I'll give it a try

[abstract garden]

did some testing and the results are quite interesting - 1 air lab surrounded by nanos is quite inefficient like <20%, 2 air labs can reach 50% but after some time will reach equlibrium similar to 1 air lab as the nanos settle into a rhythm moving back and forth, but 3 labs introduces enough chaos to let it sustain 60-80% efficiency

[jagged canyon]

@high prism

If you want to, you could look at the exact numbers for your tutorial...

Just pump the value "10" up to 100 and you'll have a precise number of how much metal is used for how much bp

       end

       avgTotalReservedBP = 0

       for _, power in ipairs(totalReservedBPData) do
           avgTotalReservedBP = avgTotalReservedBP + power
       end
       avgTotalReservedBP = math.floor(avgTotalReservedBP / #totalReservedBPData)


       --usedBuildPowerPercentage = 0
       --if totalBP > 0 then
       --    usedBuildPowerPercentage = (totally_used_BP / totalBP) * 100
       --end

       table.insert(usedBuildPowerData, totally_used_BP)
       if #usedBuildPowerData > 10 then
           table.remove(usedBuildPowerData, 1)
       end

[high prism]

Need more explanation on that 😄

[jagged canyon]

Will follow, I am on the way to. My car now

[abstract garden]

#1123061060098863164 message

[jagged canyon]

Just wanted to do the same 😉

[shut summit]

I need it, pls

[jagged canyon]

@shut summit

#1167027291440812063 message

[shut summit]

Ahhhhh, ☕
Mein freund, We Shall remember you, Forever!

[jagged canyon]

@high prism @wooden oxide @high prism @shut summit
I got a new idea:

what if there was a indicator, that actually showed the the resource income relative to the possibility to spend it?

What came out is this:

a slider that shows you how much of your BP can be supplied by both resources.

It would take into account what you are currently building with how much build power.

The idea is to have the metal slider hover between 70% and 90% and the energy slider should stay at 100% most of the time.

What you you say?

[high prism]

Too many bits of information, no?

[jagged canyon]

I think they are there already, you even have to have them in your head...

Will make it toggleable

@atomic shadow

Could you pin this message, pls?
#1166261686991335475 message

@ancient sigil
Any feedback on the widget?

[ancient sigil]

Feels good so far!

[jagged canyon]

@ancient sigil
Thx.

I have an idea for more info... (Scroll up)

What do you think of that?

[ancient sigil]

One word: cheating!

[jagged canyon]

Nahh that is what lobsters do in their head.

I am an age old TA player and I did that...
But then nano came into play and the pull wasn't shown correctly anymore... I quit gaming for 10 years, came back, the issue still existed and I had to change it 😉.

I see it as lowering the entering hurdles.

Oh and thx for the compliment.

It seems as if this info is worth something 🙂

[atomic shadow]

I think this thread can be locked as the request is now completed

-remindme 24h lock?

[scarlet wolf]

Set a reminder in 1 day from now (<t:1702061103:f>)
View reminders with the reminders command