BuildETA

[AreaFire]

This is a great widget, I know everyone uses it heavily. Thanks to whoever made it

Can we get more integral gain added to it? If feels like:

[CarRepairer]

lol@comic.

That's life. That happens because the economy in the mod you're playing isn't normalized. It's not an issue in Complete Annihilation. All costs are metal=energy=buildtime (Rocko costs 90m/90e/90bt). So if your metal income hovers at M and your energy income hovers at E and all your builders are building at the same time, they will drain the same amount of resources no matter what they are building at any time.

[SirMaverick]

they will drain the same amount of resources no matter what they are building at any time.

Eta depends on available resources and build power.

[CarRepairer]

they will drain the same amount of resources no matter what they are building at any time.

Eta depends on available resources and build power.

I said in my example that we assume your income is hovering at a general number. For energy income the biggest variation would be windpower, but ideally you have energy in storage so it's irrelevant. For metal, reclaim levels could vary, but like I said for simplicity I am not taking that into account in my example. As for buildpower, I'm responding to the OP and assuming a constant number of builders are building something and why that ETA would vacillate in some mods but not in CA.

[JohannesH]

Except that theres no real reason the ETA wouldn't stutter in CA. Way to go making simplified examples about CA gameplay that actually dont work in real, non-simplified game.

[CarRepairer]

Except that theres no real reason the ETA wouldn't stutter in CA. Way to go making simplified examples about CA gameplay that actually dont work in real, non-simplified game.

The only simplification I made is no reclaim. The other factors should be commonplace. Energy should always be in excess and metal stalled.

[SirMaverick]

CarRepairer, the stutter is not a caused by the mod, it's caused by the engine. You get your income every second (every 30 seconds). The ETA is calculated more than once each second.
Simple example: income +5, drain -10 (steady values, m only, you excess everything else). So you stall. At the beginning of each second you have metal and builder build at full speed. Half a second later you have 0 resources. You can't build. The ETA is updated more then once per second (depending on current resources) -> you see different numbers.

In this simple example with steady resources you see stutter. Even in CA.

[CarRepairer]

CarRepairer, the stutter is not a caused by the mod, it's caused by the engine. You get your income every second (every 30 seconds). The ETA is calculated more than once each second.
Simple example: income +5, drain -10 (steady values, m only, you excess everything else). So you stall. At the beginning of each second you have metal and builder build at full speed. Half a second later you have 0 resources. You can't build. The ETA is updated more then once per second (depending on current resources) -> you see different numbers.

In this simple example with steady resources you see stutter. Even in CA.

You say stutter which implies a stuttering of the exact seconds. The OP didn't seem like he was talking about seconds stuttering we see even in CA, but rather something like ETA 10 minutes, 3 minute, 5 minutes, 8 minutes, 2 minutes.

[Argh]

The only way to make it not stutter is to use a different economic model, where you either have constant buildspeed and some drain along the way, but have to pay the "balance remaining" of E/M before it finishes (this may be possible via Lua, but it would be tricky) or you have to pay the full M/E at the start, but buildtime can be arbitrary (this is easy, and I've done several variations).

[Niobium]

Or you could actually look at the widget to see what it does.

At which point, you would see that it does: rate = (rate + newRate) / 2.

And then you could think, hey, that's pretty basic averaging, and can result in rate being halved just from 1 frame of stalling. At which point that is probably the cause of the varying ETA, rather than this mods economic model vs my favorite mods superior economic model etc.

There's even a variable to change the weightings in the widget, perhaps make it; rate = 0.9*rate + 0.1*newRate. Now rate can only decrease 10% per update, so it's going to be a lot more stable. Of course there might be even better ways to fix it, but this way only requires changing a single character.

[Argh]

Oh, sure. You can get a number that's more likely to be like Reality by using 10-second slices to compose the average, and only bothering to collect new data every SlowUpdate or so, but it's still going to be wildly inaccurate a lot of the time, simply because Spring's econ means that things can suddenly take a lot less / more time. At best, it'd be a lagging indicator of events that have already happened.

Try it, then see what happens to the ETA when you start doing transients that change the scope a lot, like having a shield generator recharge or firing Bert / Tim, or when you suck up a lot of M.

[Niobium]

Oh, sure. You can get a number that's more likely to be like Reality by using 10-second slices to compose the average, and only bothering to collect new data every SlowUpdate or so, but it's still going to be wildly inaccurate a lot of the time, simply because Spring's econ means that things can suddenly take a lot less / more time. At best, it'd be a lagging indicator of events that have already happened.

Try it, then see what happens to the ETA when you start doing transients that change the scope a lot, like having a shield generator recharge or firing Bert / Tim, or when you suck up a lot of M.

Correct. It is very difficult to get accurate ETA's when things are changing unpredictably.

However imo it is possible to do better than the current build ETA widget does. Which displays a varying ETA even when income/drain/buildpower is constant, due to stall-frames.

[JohannesH]

Except that theres no real reason the ETA wouldn't stutter in CA. Way to go making simplified examples about CA gameplay that actually dont work in real, non-simplified game.

The only simplification I made is no reclaim. The other factors should be commonplace. Energy should always be in excess and metal stalled.

Noob. Why would you excess buildpower constantly, and why would you always be in this "optimal" situation even if you strive for it. Your mexes never get killed, your cons never do anything but build, your overdrived e is a constant, and yes you never reclaim? Cool

[Mav]

Unless you add Integral.

The engine may look at your build power once per 1/30th of a second... average it out over a 1 second, 2 second, or 5 second time. For more information, see PID Controller

P and D are more or less useless in this case; we need I!!!!

[AF]

Estimated Time of Arrival

[CarRepairer]

You guys missed my entire point about CA. Example:

You have a game where constructor A is building structure B. It says ETA is 2 minutes.

Your factory C is building unit D which costs 10 m and 100 bt. Factory is draining, say, 1 metal per tick.

Factory finishes D (or you cancel it) and is now building E which costs 100 m and 100 bt. Hey guess what, your factory is now draining 10 m per tick instead of 1 and your constructor A suddenly has a lot less money to work with, ETA jumps to 10 minutes.

What if Factory C stops building E and builds another D again, metal drain goes down and Constructor A suddenly tells you ETA is 1:30. In other words, ETA is impossible to estimate in this econ, because with every new unit you build, ETA of all the others will change.

However, With standardizes costs, where all units cost was metal = buildtime (same goes for energy) then factory C will always drain the same amount of metal, no matter what, so long as it's building. (and we assume the factory is building least 99% of the time or you're a newb). So unless your income drastically changes, or your builders die, your ETA numbers are stable in such an econ. I already explained above about the changes in income being a small issue and you can scroll up (basically excess energy and stalling metal should be norm).

[BrainDamage]

and you guys all missed the post of the OT, all he wants is a lowpass filter (averaging) effect on the digits so IF they'd start jumping they'd do much less, regardless of the mod chosen.

Mav: why don't you try to implement it yourself? to edit the widget all you need is a text editor