Convert absurd buildtime values into seconds

[aegis]

not every mod has buildtime/workertime, but the ones who don't shouldn't care about whether it's calculated properly in the ui or not...

[Forboding Angel]

every mod has buildtime/workertime, its not just TA derivates

And some games do it right... Others (like BA) Do it very very wrong.

[Das Bruce]

Don't make feature requests to cover for sloppy development processes.

[aegis]

it's more like a sloppy development process to cover for a nonexistent feature, there's no reason spring can't report the actual time for the selected number of workers, or the factory + builders with guard on the factory in the queue

[TradeMark]

yeah, if you dont have buildtime or workertime used in your mod, you probably dont even use the default UI.

so all you whiners can go to hell and stop trolling me.

[Forboding Angel]

In BA to fix it here is what needs to be done.

Divide all buildtimes by 90.86
Set arm con kbot workertime to 1
set arm con vehicle workertime to 1
set arm air con workertime to 0.5
set arm con ship workertime to 2.7
set con seaplane to workertime 0.6

advanced air con workertime 0.8
advanced kbot con workertime 1.5
advanced vehicle con workertime 2.7
advanced con sub to workertime 3.3
etc etc etc for all workers
....

The base value for workertime in BA is 90, so in essence consider 90 as 1 workertime, then take buildtimes of all units divided by 90.86 (might just wanna use 91 for the sake of it).

I'll spell out the calculations....

First you have to establish a baseline. The only cons that share a commonality are the basic kbot and vehicle constructors. Both have a buildtime of 90.

I used the kbot as my baseline, but you could use any con and arrive at the same eventual outcome.
buildTime=3453; / workerTime=90; = 38.36

So with a workertime of 1 the new buildtime would be 38.36 (at this point, rounding wouldn't be a bad idea as it will not affect the outcome enough to matter, but, your choice.

Next you need to establish a baseline of how much to divide workertime. For this, we take the old buildtime divided by the new buildtime.

So, in effect:
3453 / 38 = 90.86
or if you wanna be super anal:
3453 / 38.36 = 90.01

Pick one, either way, rounding at one point or another is a way to save needless complication that will not matter at all in the long run.

So based upon the above calculations, you need to divide all unit buildtimes either by 91 or 90, whichever you choose won't really matter in the long run because at the end of the day after rounding you will end up at the same number (because the difference is milliseconds).

Now...

Take the current workertime and divide by 90, that is the new value of workertime.

Take the current buildtime of units and divide that by 90.86

Now, buildtime in the tooltip will be much more helpful. The buildtime in seconds in the tooltip won't be right in all cases due to the fact that BA uses some really arbitrary (read: wonky) values (for example, if buildtime = seconds, when building with an advanced con you can effectively figure on 1/3rd of listed time). Regardless, it's a super simple "fix" and won't change the way BA plays at all. Not one bit. It's exactly the same ratio as it was before, but the values will start making a lot more sense, and it will be easier for the maintainers to balance.

I'd like to point out that it doesn't take a genius to figure all this stuff out, nor is it even remotely difficult.

Edit: Don't hold your breath for improvements like this to actually happen, *A modders are notoriously lazy.

[aegis]

The buildtime in seconds in the tooltip won't be right in all cases due to the fact that BA uses some really arbitrary (read: wonky) values (for example, if buildtime = seconds, when building with an advanced con you can effectively figure on 1/3rd of listed time).

uh you can base the seconds on the worker(s) currently selected with the proposed system - that was half of the idea. no mental math required.

[knorke]

In BA to fix it here is what needs to be done.

I do not think any mod will do this and that is ok. For new mods its a usefull hint maybe. But to modify all mods is an ugly workaround...

I think some mods already use lua to display in seconds (kernel panic i think?) but that should not be needed. It is not even a real feature, its just a bug and lua is used to work around it. Or make it a lua that comes with the engine but then you have the problem that soon the f11 list will be filled with lots of "bugfix" entries.

[zwzsg]

Forb: Is there no more flooring to nearest multiple of 30?

I think some mods already use lua to display in seconds (kernel panic i think?)

Yeah but it's fairly ugly, the widget use a hard coded workertime value of 128 for everything. (Even though sockets only have a workertime of 64).

Because when I parse a tooltip info, I don't know from which builder comes the build button. So I would have to travel through the list of selected units, looking for cons or factories that have the item in their buildmenu, but then what if I find that both a kernel and a socket are selected? Both can build bits, but one has twice the buildpower of the other!

No one here adressed this question, which alone make the request impossible.

[knorke]

what does it display at the moment in such a case?
maybe display both the highest and lowest time?

[zwzsg]

At the moment, the engine shows the raw buildtime, which is independant of who builds it. >_>

That's the core of the problem: There is no answer to the question "who builds?"

You cannot do x/y when y is potentially unknownable.

[Forboding Angel]

I do not think any mod will do this and that is ok. For new mods its a usefull hint maybe. But to modify all mods is an ugly workaround...

We're not talking about all mods. We're talking about BA. Yes the proposed system would be nifty, but the fact is that you can have something close without needing a new version of spring or any luaz.

Evo and CA already use similar sensible systems for buildtime and workertime and most of the other games have their own systems.

Forb: Is there no more flooring to nearest multiple of 30?

Didn't understand this, sorry

[TradeMark]

You cannot do x/y when y is potentially unknownable.

Code: Select all

if(y) return x/y; else return 0;

its not that hard to program really

[zwzsg]

It misses the line where you assign a value to y.

[TradeMark]

Code: Select all

y = 0;
read_file();
if(y) return x/y; else return 0;

happy now?

[Jazcash]

Code: Select all

y = 0;
read_file();
if(y) return x/y; else return 0;

[TradeMark]

Theres no div0 here

[zwzsg]

Jazcash: In C, 0 is false, so if(y) means if y is not 0, so the division is not done when y is zero.

Code: Select all

y = 0;
read_file();
if(y) return x/y; else return 0;

happy now?

Okay you want the tooltip to always display 0 instead of buildtime. Sure, that's doable. Totally useless, but doable.

Also you want to read a file, always the same file, and god only know which, about a dozen time per rendering frame. I can only hope our OS handle caching well.

[Google_Frog]

The issue is what do you do when you have multiple cons that cannot assist?

If assisting there is a strong argument for displaying raw BT as users can then easily calculate the changes in time when if different units build the same thing. That is it can be easily calculated if you use sane workertime values.

A bit offtopic but I thought I'd mention that you can set terrain height to 1/0 and that is exactly what happens . If a unit walks into the hole Spring crashes.

[zwzsg]

The buildtime is a property of the unit-to-be-built. It is fixed, entirely determinated for a given unit.

But to convert that into seconds, you need to know the workertime of who will builds it. And one unit may be built by a wide variety of builders, and even by combination of builders, and each would give a different buildtime, using rules so complex you can't even list them all.

The tooltip shows the stats of a single unit. It doesn't, nah, it shouldn't, take into account something that depends on other units, lest we found ourself in a hornet nest of issues. The tooltip info is independent of who builds. This is good, pretty, elegant, simple, and handle all cases with ease. Introducing dependence to the builder is to introduce kludge, risks, and bugs in the engine.

You are all only taking into account the simple case, one mobile cons build one structure. But the relationship between to-be-built unit and builder unit can be much more complex than a couple! And if it is to be hard coded, then it must handle every situation, not just the basic one.

If two builders are selected, we could show both numbers. Or the highest number. Or the lowest. Or the mean. Or maybe the sum of the two builders. Save if buildassist is forbidden. Save if one cons is so far it'll arrive after the first cons is finished. Save if one cons is busy already and shift is pressed. Save if they are factories and not mobile cons. But if they are factories then you should add nanoturrets in range. If you can find an elegant hardcodable criterion to detect what a nanoturret is. And determine range automatically. But of course remove nanoturrets that are already busy helping another factory. Or that will be busy helping another factory. And if you count nanoturrets, it's only fair that you count cons guarding the factories. And patrolling cons that lend a hand. If their waypoint make them pass the factories. And if they are close enough from the factories on their patrolling loop. But make sure the engine check for damaged planes that would land on the cons path, and don't count the cons if there's one. Unless it's very lightly damaged and reparing it won't take long. And check for walls that would prevent a patrolling cons to reach a factories... okay there it starts getting too stupid. But where do you draw the line?


IMO the better idea would be to take the sum of the workertime of every selected units: If you select two factories, the buildtime in seconds would be divided by two, but that sorta make sense, since effectively two kbot labs build twice as many peewees per seconds than one. If you select two cons, or one cons one factory, that'll assume one cons will assist, which can be wrong, but most often isn't. So, summing up workertime of all selected units is simple enough to cover every case, bar the case of a zero sum, without needing weird rules, and while it'll gives incorrect answers in some case, at least the value to be displayed won't be undecidable or abitrary.


Still, that begs the question: If I select both a factory and a mobile cons that can build a unit, and click that unit buildbutton, does the engine ask for location (assuming the builder is the mobile cons) or not (assuming the builder is the factory)? I should run the Cursed and try. Because that's a case where the engine already has to determine who's the builder on the GUI level.

Maybe it just has two builbuttons? But I wouldn't want every buildbutton to be multiplied by the number of builder with different workertime. That'll solve the issue, but make the GUI messy.