[MOD 0.12.12+] YARM (Yet Another Resource Monitor) v0.7.17

[Narc]

YARM (Your Adorable Resource Monitor)


Factorio 0.12?
Yes, this thread is for the Factorio 0.12 version of YARM. The new version is hosted on the mod portal: https://mods.factorio.com/mods/Narc/YARM.

Info:

• This is based on the original Resource Monitor via the unofficial update (but ultimately using only the assets from it). It monitors your resources.
• Name: YARM
• Latest Release: v0.7.17, June 10th, 2016
• Factorio Version: 0.12.12+
• Download: Current Version
• License: MIT license

Details
During development, I kept this Imgur album up to date. It contains brief descriptions of the most salient points. A more detailed text change log is available on the release page for 0.6.19. Or, if you prefer a video format, KaneHart made an excellent mod spotlight.

Older versions
The GitHub releases page for YARM has all the past releases, and also serves as a change log of sorts, so you can use it to tell what's different between all the releases.

Source
This mod is open source and lives on GitHub. Contributions and forks are appreciated.

Problems?
While I check back here from time to time, issues are more likely to get my attention if they're posted on GitHub. Having a problem? Post an issue right now!

Thanks

• Infinite thanks to drs9999, jorgenRe, and L0771 for creating and maintaining the original Resource Monitor, which served as excellent inspiration for YARM.
• Many thanks to #factorio IRC regulars for their assistance with both suggestions and testing of YARM, including multiplayer testing.
• Lots more thanks to JamesOFarrell for his Fat Controller remote viewing feature, which heavily inspired the one in YARM.
• A big round of applause for RikkiLook with the Russian translation, since YARM v0.7.12!
• Thanks to Afforess for massive performance tweaks in YARM v0.7.15!
• And thank you to jockeril for giving us a lovely Hebrew translation, since YARM v0.7.17.

[StoneLegion]

Great Mod but I have to give it 4/10 because I saw it used on a map that contained a loop.

screenshot

Spotlight Video:
https://www.youtube.com/watch?v=Y78S6s-WYuY

[jorgenRe]

Thanks for creating this new and improved resource monitor mod !

Edit:
Thank you for future proofing it aswell by using the surface the entity was placed in rather than just using nauvis no matter where it was placed !

[Narc]

Great Mod but I have to give it 4/10 because I saw it used on a map that contained a loop.

That's, like, the perfect score, isn't it?

Spotlight Video:
https://www.youtube.com/watch?v=Y78S6s-WYuY

Thank you so much, the OP has acquired that reference.

Thanks for creating this new and improved resource monitor mod !

Was my pleasure, anytime!

[Peter34]

Thanks, another super-looking mod that I'm hoping to be able to include in the grand alpha 13 MP game that I'm still prepping for.

[StoneLegion]

Thanks, another super-looking mod that I'm hoping to be able to include in the grand alpha 13 MP game that I'm still prepping for.

Yup it will work perfectly.

[Outsider]

Another great mod! love the new gui and how clean the code is, awesome work

[waduk]

At first seeing how pretty the GUI and the new feature, i have my doubt this will better (performance-wise) to old Resource Monitor Mod (RMM).

Looking at the script update on idle "confirm" my suspicion, this new version have twice script update rate on idle.
As someone with low spec-PC this is worrying, since this will become a fps hit.

But then, i tested extensively , boy,..i was wrong. YARM not only have better GUI/feature, but performance wise it was highly improvement as well !
Data on idle really didn't do justice.
I'm so glad i tested this out.

Here's the script update data i gathered:
RMM
Idle : 0.020
1 Monitor : 0.2
2 Monitor : 0.4
3 Monitor : 0.6
4 Monitor : 0.8
5 Monitor : 1.0 (-4 fps drop)

YARM
Idle : 0.05-0.09
1 Monitor : 0.10
2 Monitor : 0.13
3 Monitor : 0.15
4 Monitor : 0.18
5 Monitor : 0.3 -> This one is weird, big value jump unlike previous consecutive value.

Adding more monitor on YARM didn't exponentially increase the script-update like RMM did !

OK, feature request then, if possible.
Adding tons of monitor is obviously will become a problem, so, is it possible to make a custom update rate, say every x min ? LIke RMM did ? Or YARM work in different way ?
Or is it possible to calculate things even slower, so we can have a reduced script-update ?

[Narc]

At first seeing how pretty the GUI and the new feature, i have my doubt this will better (performance-wise) to old Resource Monitor Mod (RMM).[...]Adding more monitor on YARM didn't exponentially [sic; the data says it's linear --Narc] increase the script-update like RMM did !

Yes! Performance was definitely on my mind, but I didn't really have the patience to test against the old RMM; I just figured that spreading the updates over time based on the tick when the site was added would smooth things out -- RMM would update all the sites all at once(!) and then sit idle the remaining 599/1799/5999 ticks.

OK, feature request then, if possible.
Adding tons of monitor is obviously will become a problem, so, is it possible to make a custom update rate, say every x min ? LIke RMM did ? Or YARM work in different way ?
Or is it possible to calculate things even slower, so we can have a reduced script-update ?

Yes, I do plan on having the update rate be configurable (even as far as having it happen every tick, if you really wanted to). The settings screen didn't make it into the initial release, but it will be present sooner or later. Notable fact: the sites are force-bound rather than player-bound, so:

- on the one hand, any player on your force may change the update rate (and will change it for everyone), but
- on the other hand, you can have as many players as you like on your force and not see a major performance difference.


I also have in mind a way to spread out the updates further (by limiting each update cycle to 10 resource entities per site, and leaving the rest for the next update), but this would require a larger reworking of how site updates work; I am therefore trying to avoid it if possible.

Please keep me informed and if the current performance gets too bad for you, I'll see about setting that rework up. At present, changing the update rate in config.lua can help -- the `ticks_between_checks` duration is what drives the period of site updates, which is by far the most expensive operation the mod does.

[vlczero]

Really like this mod, looks nicer and better performance.

I have just 1 little "bug":

When adding ores from bobs ores i am having a percentage of over 100%
The ores are generated with RSO so they have a much greater richness ( don't know if that has anything to do with the calculations ). On setup it should not be able to go above 100% right?

Screenshot:

[Narc]

When adding ores from bobs ores i am having a percentage of over 100%
The ores are generated with RSO so they have a much greater richness ( don't know if that has anything to do with the calculations ). On setup it should not be able to go above 100% right?

Oh. I see what happened there. Apparently, I'm not checking the proper way for an infinite ore, and just assuming that if it has a minimum_resource_amount, it must be infinite. Oops.

Expect a fix within the next couple of hours, I just need to get a proper test world set up.

[Narc]

within the next couple of hours

That time being now. Build 20 of version 0.6 fixes the issue.

If you were affected by this bug, be aware, it will take up to 20 seconds for the values to visibly update.

[waduk]

Yes, I do plan on having the update rate be configurable (even as far as having it happen every tick, if you really wanted to). The settings screen didn't make it into the initial release, but it will be present sooner or later. Notable fact: the sites are force-bound rather than player-bound, so:
- on the one hand, any player on your force may change the update rate (and will change it for everyone), but
- on the other hand, you can have as many players as you like on your force and not see a major performance difference.

I've no problem with that, i play single player. But i think it's minor issues on MP, performance is more important than the ability to use different update rate.
This is great to hear.

I also have in mind a way to spread out the updates further (by limiting each update cycle to 10 resource entities per site, and leaving the rest for the next update), but this would require a larger reworking of how site updates work; I am therefore trying to avoid it if possible.

Wow, i hope it's get implemented in the future. But i understand the troublesome if it comes to large reworking. I'm really happy with current version.

Please keep me informed and if the current performance gets too bad for you, I'll see about setting that rework up. At present, changing the update rate in config.lua can help -- the `ticks_between_checks` duration is what drives the period of site updates, which is by far the most expensive operation the mod does.

OK, will do that, but currently (on test world), i see no problem at all.
But planning to add 32 sites on my real gameplay.
I changed the "ticks_between_checks" to 3600, now 5 monitor is barely on average 0.15 value. This is even lower than adding RMM on single monitor, wow,..just wow...
YARM has performed well beyond my expectation.

A bit of explanation though, the "ticks_between_checks", how does it works ? I know it's not working like RMM did (all at once on N th sec)
Current example : I set the value to 3600, so since you said the updates were spread out; on 5 monitor is being updated something like this ?
Monitor 1 : 12th sec
Monitor 2 : 24th sec
Monitor 3 : 36th sec
Monitor 4 : 48th sec
Monitor 5 : 60th sec

[Narc]

A bit of explanation though, the "ticks_between_checks", how does it works ?

It's simpler than it looks, or perhaps less so -- YARM doesn't really pay attention to how many sites exist, but instead remembers when you added each site (specifically, what game tick -- there are 60 ticks in a real-time second at 60 UPS; your playing time is based on this);

On every new tick:
1. YARM divides the current tick (e.g., tick 45612: 12 minutes 40 seconds 12 ticks into a game) by the `ticks_between_checks` number and takes the remainder (with the default 600, our example gives 12). This gets named our current update cycle.
2. YARM then does the same calculation for the birth tick of every site it knows about, which will give a number between 0 and `ticks_between_checks - 1` (e.g., 0-599). This defines that site's update cycle.
3. For each site whose update cycle matches the current one, it updates the resource amounts by querying every ore in that field about its remaining amount.

The end result is that each individual site will only be checked once every 600 ticks (or whatever your current value is), and that unless you're very unlucky, you should only be updating zero or one sites per tick.

Via Birthday paradox, with 32 sites you have about a 56% chance of two sites sharing the same update cycle at the default 600 between checks, assuming I did the approximation correctly and that I'm not skewing things in the code somehow. This should still be relatively tenable as long as you don't get too many sites clumping into the same update cycle.

More interestingly, if things do seem to have gotten clumped up, a simple change by a few ticks (e.g., setting it to 607 ticks, or 593) should fix that, as the wildly differing birth ticks should break up the clumps. This is just an assumption, however, and I am not a mathematician. I don't even play one on TV!

3600 ticks is a long time, but it should be better for calculating average ore consumption if you're okay with the slightly outdated information.

[waduk]

I think i understand half what you said
Gonna re-read your explanation when i go to bed.
I'm just curious how in the world you managed to increase the performance significantly.
I wonder if the same principle can be added/use to many various mod (i know some has really-really huge fps hits, have to uninstall some mod due unbearable script update value)

But basically, maybe this explains why my initial test when adding the 5th monitor, the script update is jumping significantly/weirdly, probably because that 5th monitor somehow get updated at the same time with one of the monitor i added earlier ?
Yeah i didn't need near realtime update on resources, an average outdated value is more than sufficient for me.

Edit :

...however, and I am not a mathematician. I don't even play one on TV!.

??? Are you an actor ???

Sorry, i'm not native english speaker.I don't get it.

[vlczero]

within the next couple of hours

That time being now. Build 20 of version 0.6 fixes the issue.

If you were affected by this bug, be aware, it will take up to 20 seconds for the values to visibly update.

Thank you the fix worked

[Narc]

But basically, maybe this explains why my initial test when adding the 5th monitor, the script update is jumping significantly/weirdly, probably because that 5th monitor somehow get updated at the same time with one of the monitor i added earlier ?

Yes, that's pretty much my thinking. You just got lucky.

...however, and I am not a mathematician. I don't even play one on TV!.

??? Are you an actor ???

Sorry, i'm not native english speaker.I don't get it.

Nor am I; this is an old joke: "I'm not a doctor, but I play one on TV." (this joke is as old as I am!)

[waduk]

Oh, never heard of that one. Only know the doctor lines jokes from Star Trek Original Series.

Yeah that weird result is what prompting my curiosity, i'm glad i bump into that unexpectedly.
i'm a lucky guy when it comes to bug testing.

OK, basically when the "clump" happen, to mitigate that, i can either :
- Remove and re-add the monitor (didn't have to exit game)
Or
- Changing the ticks between updates slightly, to add more randomness.

Another question :
Does it takes more time/script-update to do calculation on huge/rich ore fields compare to smaller one ?
I know i can test this, but you know, it's easier to ask question about it

[jorgenRe]

Oh, never heard of that one. Only know the doctor lines jokes from Star Trek Original Series.

Another question :
Does it takes more time/script-update to do calculation on huge/rich ore fields compare to smaller one ?
I know i can test this, but you know, it's easier to ask question about it

It certainly should because a bigger field means more entities to check per tick !
Though that's is also the place of the code to improve on if performance becomes an issue !

[Narc]

Oh, never heard of that one. Only know the doctor lines jokes from Star Trek Original Series.

"Dammit, Jim, I'm a coder, not a doctor!"

Does it takes more time/script-update to do calculation on huge/rich ore fields compare to smaller one ?

It takes more time the more surface the ore field covers -- the richness is immaterial. Small, extremely rich fields are faster to scan than large, very poor fields, even though the amount of ore may be very similar. See also my earlier statement about limiting checks to a small number entities per site per tick.