Friday Facts #337 - Statistics GUI and Mod Debugger

[vedrit]

What if we need to... you know... test if things are multiplayer safe?

Or if you're testing a mod that requires another mod? Like an add-on to Bob's or Angels

[peternlewis]

Given that producing Science is pretty much the essence of the game, I'd love to see an additional tab between Item and Fluid for Science that just showed science items (or even science-related items if you like).

And yes, clearly you can do it with a search, even the example in the post shows you can search for “pack”, and coincidently that finds all the science packs, and luckily does not find anything else. The fact that it is used as the example just makes it obvious that this would be beneficial, and make it clearer that one aim of the game is creating ever-expanding factories that generate ever expanding amounts of science.

Absolutely also remember the time period please! Who cares about the last five seconds!?

[Bauer]

+1 for

- Satisfaction --> Demand
- Displaying the actual demand (=100%) and a %-value (green-red bar) if the demand is not fulfilled.
- Displaying the max production (=100%) and a %-value (green-red bar) what's acutally been used.
- Same logic for accumulators: capacity and %-value charge.

[justarandomgeek]

What if we need to... you know... test if things are multiplayer safe?

Or if you're testing a mod that requires another mod? Like an add-on to Bob's or Angels

Then you enable those mods too? the *debugger* is the one running in instrument mode.

[Shingen]

i like most of the ideas here, so to sum up:

+1 for a logarithmic scale switch

+1 for a statistics pause button (yes, i know, i'm kinda +1-ing myself here)

+1 for more precise values (at least this one additional digit)

+1 for default interval being about 10 minutes and remembering the last choice

+1 for more intervals (like 30 minutes) or some field to specify a custom one.

+1 for net production section

+1 for a single bar of power production/consumption. as RobertTerwilliger wrote: it makes no sense to always show 2 bars if one is always full and only the other informs us of anything.
however, to be clear, i would see it with these colors:
when production > demand green bar of demand fills up a full white bar of possible production.
when demand > production, a green or white bar of full production(/satisfied demand) "fills up", or rather is lowered by, a full red bar of total demand.

+1 for clearing up the "potency" of the power producing structure types (frugal10191's post)

[BattleFluffy]

If kills is merging into production statistics, why not go all the way and have one unified statistics window with a single keybind?

This was my inital thought as well, but on reflection, it's possible to have multiple different electrical networks and you need to click a pole on the network you want to view the stats for. So merging this into the rest of the stats views would not work well, because it won't be clear which electrical network should be displayed.
I guess we could number the networks and have a dropdown to choose between them, but actually I quite like clicking the pole and it's quite intuitive - I'm not sure it's worth the development effort to change it.


One thing I would really like though is to be able to name logistic networks. In some large megabases I have 15-20 different networks, each with a significant amount of stuff in them. It would be useful to be able to rename them "Old Town" and "Labs" and so forth, instead of "Network #3" and "Network #4", so I can make it easier for myself to figure out which zone's items I'm looking at.

[DoubleThought]

Custom time period statistics? Hmm... possible, but tough. If the Factorio devs are as much of optimisation wizards as I think they are, then this is a reasonable summation of how the production stats are done.

Each item type has a pointer to a forward single linked list. Each linked list element is a struct containing the number of frames since some epoch that the item was created.

Each duration-item pair has an associated struct, with a pointer to a linked list element and a ulong (not a pointer) representing how many items were created in that duration. This is likely stored in a flat array, for efficiency's sake. Initially, all are initialized to 0. We'll consider the iron plate without loss of generality.

When an iron plate is produced, the linked list has an item appended to the front; this is the number of frames since the epoch.

We'll consider the 5-second duration without loss of generality.

At the end of each frame, the pointer to the linked list element is checked. While the pointer is not the null pointer and the linked list element time stamp is more than 5 seconds ago, the pointer moves one element forward on the linked list, and the number of items produced in the duration is decremented.

Of course, instead of a linked list, they might instead use a circular array, but aside from the expansion logic, this is much the same. They likely allocate linked list elements from a memory pool to reduce calls to malloc, at least if they do use such a system with a linked list.

I personally lean towards the linked list idea since it's worst case constant time, while the circular array is only asymptotically constant time, and in the worst case, the time complexity is linear in the number of items created.

They might also coalesce the elements for longer durations, since the resolution may be lower. Actually, scratch that; they can't.

What this means is that it's relatively difficult to make the duration thing actually work for variable amounts, at least in constant time.

Notes on time complexity:
Creating an item: O(1)
Get number of items created in the last (predetermined) frames: O(1)
Get number of items created in the last (variable) frames: O(n) — need to traverse linked list
Maintain existing durations production statistics: O(1)
Plot on graph number of items created: O(n) in number of frames of history to draw.

And Factorio devs: if you read this and it isn't how you do it, and you want to use this, go ahead. This algorithm is free for anyone who reads it to use (but no warrantees apply).

EDIT:

Well. I posted this and instantly came up with a better algorithm.

You could do away with the concept of an epoch altogether, and instead store the time difference between the last item created. Augment each item-duration pair with an integer. Define a new invariant: that the sum of delta-time in the linked list elements after the item-duration linked list pointer minus the augmenting integer plus an integer representing how long since the last item was created equals to the number of frames in the duration.

The number of frames since the last item was created is increments every frame, so the augmenting integer decrements every frame.

When the augmenting integer reaches 0, the augmenting integer is assigned to the value of the linked list element pointed to by the item-duration pair, then the pointer moves to the next element... there may be an off-by-one error there somewhere.

[Iccor56]

can we get an option to set the scales on both sides to the same values? this would make comparing consumption to production much easier.

[vedrit]

What if we need to... you know... test if things are multiplayer safe?

Or if you're testing a mod that requires another mod? Like an add-on to Bob's or Angels

Then you enable those mods too? the *debugger* is the one running in instrument mode.

I'm confused, then

...a special mode which allows a selected mod to hook all the Lua instances Factorio creates, at the cost of disabling multiplayer and only allowing one Instrument at once.

doesn't mean ONE mod?

[Nidan]

...a special mode which allows a selected mod to hook all the Lua instances Factorio creates, at the cost of disabling multiplayer and only allowing one Instrument at once.

doesn't mean ONE mod?

One mod that's doing the instrumentation, not one mod that's being instrumented.

[justarandomgeek]

...a special mode which allows a selected mod to hook all the Lua instances Factorio creates, at the cost of disabling multiplayer and only allowing one Instrument at once.

doesn't mean ONE mod?

One mod that's doing the instrumentation, not one mod that's being instrumented.

Yes, exactly - one mod with superpowers. Two would just step on each other and break everything (it's pretty easy for one to break everything, which is why you have to jump through some hoops for the power). But one mod total would be pretty useless, since the debugger *is* a mod!

[Quarnozian]

Wish we had something more like this...



The scale of the chart is determined by the max output of all power production (Steam Engines + Steam Turbines + Solar Panels + Accumulators) and the max consumption if every single entity was at absolute peak power usage (excluding accumulators).

Possibly add a toggle to show/hide max power usage, and only show current usage.... it's unlikely that everything in the base would ever be at max power usage. The biters don't (yet) have the coordination to overwhelm the base power supply by triggering every single laser turret on the map to activate simultaneously.

[jamiechi1]

Overall, the Gui looks nice. But the active tabs should be lighter color and the inactive tabs should be darker. For most of us who have been using Windows for years the way you color the active tabs is confusing. Also, the menus need to remember the last settings. For instance when going to the Keyboard Binding Settings dialog, I usually need to go to the settings for mods which is way at the bottom. And the sections I minimized are always maximized again. And like someone else said about the power view dialog. The dialog needs to remember the time period I select. Such as 1 minute or 5 minutes. Alos 5 seconds is pretty much useless.

[Darkehart]

If kills is merging into production statistics, why not go all the way and have one unified statistics window with a single keybind?

This was my inital thought as well, but on reflection, it's possible to have multiple different electrical networks and you need to click a pole on the network you want to view the stats for. So merging this into the rest of the stats views would not work well, because it won't be clear which electrical network should be displayed.
I guess we could number the networks and have a dropdown to choose between them, but actually I quite like clicking the pole and it's quite intuitive - I'm not sure it's worth the development effort to change it.


One thing I would really like though is to be able to name logistic networks. In some large megabases I have 15-20 different networks, each with a significant amount of stuff in them. It would be useful to be able to rename them "Old Town" and "Labs" and so forth, instead of "Network #3" and "Network #4", so I can make it easier for myself to figure out which zone's items I'm looking at.

Certainly, it would be a low priority task, but I think the ideal would be if you can still go directly to the power network in question by clicking on the pole, but you have the option within the statistics window to look at the other ones - much like the logistics networks. The ability to name the logistics networks would be super useful, but that also applies to the power networks, and the presence of the ability for one type of network highlights the absence of it for the other, imo.

Again, low priority, but it would be a good quality of life feature for those of us that segment our networks a lot.

[bman212121]

So I'm surprised no one bumped this. We just downloaded the 18.18 version and noticed the new Stats GUI. I'm glad you guys decided to tweak it slightly and add totals for the power stats. What crazy is just how intuitive it is now. I looked at the satisfaction graph, and you could see the satisfaction number peak, but what was really interesting was the total for satisfaction was wavering. That instantly made me think there was likely a supply problem of coal into the boilers, because that would cause that number to jump around. Sure enough I went over to the power part of the base and could see we weren't getting enough coal into the boilers, which explains why the base should be able to handle the satisfaction, but it wasn't.

So major props from me and my friends for making a last minute tweak! It's greatly appreciated and we really love how much more useful the graphs are now.