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

[JyeGuru]

It's semi-cheating as you can see where biter bases are all time. Even without radar

Yeah, it is. I've since turned it off, it REALLY gets in the way trying to look at things on the map.
Unfortunately it doesn't save settings per-game, and I had it on for a MP game I was playing recently and just forgot to turn it off again.

I also use the grid view sometimes, especially when trying to lay out train stations!

[LordFedora]

While we're on the topic of debug settings you can change the basic tab, and toggle it with F5...

[Narc]

Found another bug for you!

The invisible "remote viewing" things that are on the ore patches are targets for biters.
This means they end up attacking the beacon in the middle of the ore patch instead of the miners a lot of the time.
Additionally, even after deleting the ore patches from the sidebar, the remote viewer thing stays there - and is still a target.

That's weird, 'cause the remote viewers are supposed to be destroyed as soon as you leave them. I'll take a look at what's going on; maybe I forgot a case. Edit: Yup, found it -- somewhere in the reshuffling of the code, I managed to break the case where you return from a remote viewer, leaving the viewer around with no way to destroy it. I'll fix that as soon as possible and make it a new release -- be aware, I will also be bumping the minimum Factorio version to 0.12.9, as it fixes a rather heinous (if rare) bug related to remote viewing.

In the meantime, if you can find them in the world and highlight them with your cursor, you can do `/c game.local_player.selected.destroy()` to remove them.

The reason I left them effectively invulnerable (the original code came from The Fat Controller) is because:
- in single-player, it would really suck if your game was terminated just because you happened to be viewing the wrong site at the wrong time; and
- in multi-player, if you "died" while in a remote viewer, you'd then respawn in a new character but the old one would still be in the world somewhere. Even if you could return to it, you'd still have two characters, both "you", which would be really confusing.

[Narc]

Edit: Yup, found it -- somewhere in the reshuffling of the code, I managed to break the case where you return from a remote viewer, leaving the viewer around with no way to destroy it. I'll fix that as soon as possible and make it a new release -- be aware, I will also be bumping the minimum Factorio version to 0.12.9, as it fixes a rather heinous (if rare) bug related to remote viewing

"As soon as possible" has just happened. Build 23 (direct download) fixes the following two issues:

The console was spammed with "Invalid color value (resmon.lua line 455)
It was for a Bob's Mods tin ore field that was being punished by miners and god module 5's. It happened just as the field finished.

The invisible "remote viewing" things that are on the ore patches are targets for biters.
This means they end up attacking the beacon in the middle of the ore patch instead of the miners a lot of the time.
Additionally, even after deleting the ore patches from the sidebar, the remote viewer thing stays there - and is still a target.

It also makes the minimum Factorio version 0.12.9 -- but you should probably be using 0.12.10, as it includes a hotfix for a nasty multiplayer bug.

There is a remaining known issue: YARM sometimes fails to notice mineral entities, and in the next half-hour or so I will be filling out the issues list with the enhancements and future plans remaining. If you'd like to contribute, pull requests are appreciated and will be happily reviewed!

[Choumiko]

I love how it's not freezing when adding an ore field, might have to use that in resource combinator too.

Some suggestions i haven't found on your issues:

• Calculate mining rate a bit like the production screen: Right now if you happen to mine nothing between 2 update cycles it shows 0/m. In this case i think it would be better to take the tick from the last rate that was not 0 and calculate the rate based on the old delta/current tick - last mined tick.
• Add a way to add entities to an existing one. I had an outpost with 3 different patches of ore and didn't manage to get there quick enough to add them into a single site (Same for an oil outpost with oilspots a couple hundreds tiles apart. So a button for each site to reenable adding a new patch would be great

[Narc]

I love how it's not freezing when adding an ore field, might have to use that in resource combinator too.

Yes, feel free! But be aware I do currently have a known bug where sometimes an ore gets missed; I haven't looked into it yet, though it's probably as simple as adding 0.5 to the coordinates so the hit test checks the center of the tile instead of its top-left corner.

Some suggestions i haven't found on your issues:

• Calculate mining rate a bit like the production screen: Right now if you happen to mine nothing between 2 update cycles it shows 0/m. In this case i think it would be better to take the tick from the last rate that was not 0 and calculate the rate based on the old delta/current tick - last mined tick.
• Add a way to add entities to an existing one. I had an outpost with 3 different patches of ore and didn't manage to get there quick enough to add them into a single site (Same for an oil outpost with oilspots a couple hundreds tiles apart. So a button for each site to reenable adding a new patch would be great

Both of these sound good, thank you. I will create them as issues.

I, too, have been considering a better mining rate calculation method, perhaps taking advantage of multiple samples reaching as much as a minute back and doing some (possibly weighted) averaging -- but I like the last non-zero tick idea, too.

Very much agreed on the ability to put an ore site back into "add" mode (which would also give an opportunity to reduce its duration -- 10 seconds is a long time to wait, and the only way to bypass the wait is to have another kind of ore handy).

[Boogieman14]

(which would also give an opportunity to reduce its duration -- 10 seconds is a long time to wait, and the only way to bypass the wait is to have another kind of ore handy).

Some kind of documentation probably couldn't hurt either. Only from this statement did I gather that the delay is there to allow adding multiple separate patches, I figured it was the counting that caused a delay

[Narc]

(which would also give an opportunity to reduce its duration -- 10 seconds is a long time to wait, and the only way to bypass the wait is to have another kind of ore handy).

Some kind of documentation probably couldn't hurt either. Only from this statement did I gather that the delay is there to allow adding multiple separate patches, I figured it was the counting that caused a delay

I, uh, did write that in the release notes linked from the OP, but I didn't really feel like copy/pasting and reformatting for BBCode, so it's only mentioned as "a more detailed text change log". Guess I should get around to fixing that.

[Choumiko]

But be aware I do currently have a known bug where sometimes an ore gets missed; I haven't looked into it yet, though it's probably as simple as adding 0.5 to the coordinates so the hit test checks the center of the tile instead of its top-left corner.
I, too, have been considering a better mining rate calculation method, perhaps taking advantage of multiple samples reaching as much as a minute back and doing some (possibly weighted) averaging -- but I like the last non-zero tick idea, too.

I noticed the bug while testing my quick+dirty try at the non-zero tick. Too lazy for a pr so:

Code: Select all

local function find_resource_at(surface, position)
    local area = {{position.x - 0.51, position.y - 0.51}, {position.x + 0.51, position.y + 0.51}}
    local stuff = surface.find_entities_filtered{area=area, type='resource'}
    if #stuff < 1 then return nil end

    return stuff[1] -- there should never be another resource at the exact same coordinates
end

Fixed it for the patch where i noticed it. (don't know why it's 0.51, that's what i use in my mod)

I think in the end the rate/m should be more or less the same as the consumption of the corresponding ore, even if the miners get backed up from time to time. The zero tick variant makes it a bit better, but not perfect.

[Boogieman14]

So clearly I completely missed that

[Narc]

Code: Select all

local area = {{position.x - 0.51, position.y - 0.51}, {position.x + 0.51, position.y + 0.51}}

Yeah, I'm explicitly trying not to make a lot of extra Lua tables in a tight loop like that, but that's most likely the right place. I expect it'll work with {position.x + 0.5, position.y + 0.5} reused for both corners of the area. Kept in a local reference, of course.

I think in the end the rate/m should be more or less the same as the consumption of the corresponding ore, even if the miners get backed up from time to time. The zero tick variant makes it a bit better, but not perfect.

Well, now, if you want "perfect", we know when we added the site and what the initial ore amount was, we could just calculate ore/m over the duration of the site's existence -- including providing a reset button to make the site pretend it was just deleted and recreated.

Trouble is, it's perfectly reasonable for a site to stop being mined for various reasons (e.g., output chest backed up due to insufficient consumption of the resource), and if I'm showing a consumption that's not 0/m while no mining is happening, that *will* confuse people.

So clearly I completely missed that

No worries, it happens a lot, especially with long bullet-pointed lists. I really do need to just write some descriptive prose.

[Peter34]

I love how it's not freezing when adding an ore field, might have to use that in resource combinator too.

Cool! Because I actually think it's more in the spirit of Factorio to handle the issue via the Combinator/Wire system (and output to a rack of Nixie Tubes) than to handle it via a new UI element. So I'm hoping you'll update your mod to use this new (and presumably a lot more MP-stable) approach.

[Narc]

With Factorio 0.12.11 breaking all the things, I went ahead and updated: version 0.7 build 6 (direct download) is available from the usual spot.

This also fixes the issue where YARM sometimes fails to notice mineral entities, and retains a mitigation for GUI button clicks often being missed, by changing the GUI update rate (unrelated to the site ore amount updates) to be every five seconds -- the GUI will update less often, but should be more responsive.

If, for some reason, you haven't yet updated to Factorio 0.12.11, YARM 0.6 build 23 (direct download) is still available.

[PiggyWhiskey]

With Factorio 0.12.11 breaking all the things, I went ahead and updated...snip

YES! Amazing work. Off all the mods, This one I miss the most.

I'll test it immediately.

[Narc]

With Factorio 0.12.11 breaking all the things, I went ahead and updated...snip

YES! Amazing work. Off all the mods, This one I miss the most.

I'll test it immediately.

Excellent, thank you. I only tested to the extent of verifying that it launches and sites can be added to the tracker -- in single-player, at that -- but I can't spare the attention to test it thoroughly. Please do let me know if you run into any problems, either here or as a Github issue (the latter being preferable, but not at all required).

[Narc]

Because I was using the feature that lets me get (and display) entity localised names, Factorio 0.12.12 requires another update: YARM v0.7 build 7 (direct download).

If you're still on Factorio 0.12.11, use build 6 (direct download). Less than that, and you should be using 0.6 build 23 (direct download). Next update, I probably won't be repeating these old links anymore.

[ccik]

First of all, thanks for the awesome mod.

But, for some reason, after loading a saved game, YARM shows all previously mapped ressource fields as depleted. (0 Ore left, -0 ores/min, never depleting). The only fix for this is to delete the fields, and remap everyone of them. After remapping the percentages reset to 100%, which takes a little bit of functionality away, but nothing game breaking.
I don't know if this is a known issue, can't be avoided althougether, or I just found a bug.
If it is for some reason not possible to store this information in the savegame some kind of function to modifiy existing ore fields, as mentioned in an earlier post, would at least save the hassle to rename all the fields every time you load a game.

[Narc]

But, for some reason, after loading a saved game, YARM shows all previously mapped ressource fields as depleted. (0 Ore left, -0 ores/min, never depleting). The only fix for this is to delete the fields, and remap everyone of them.

Hi there, I'm guessing you're on Factorio 0.12.13. In which case, you've definitely found a bug, but not in YARM: [0.12.13] Lua data de-serialization doesn't work.

As Choumiko has stated over in the EvoGUI thread, if you can downgrade to 0.12.12, it would probably be best if you did.

[ccik]

But, for some reason, after loading a saved game, YARM shows all previously mapped ressource fields as depleted. (0 Ore left, -0 ores/min, never depleting). The only fix for this is to delete the fields, and remap everyone of them.

Hi there, I'm guessing you're on Factorio 0.12.13. In which case, you've definitely found a bug, but not in YARM: [0.12.13] Lua data de-serialization doesn't work.

As Choumiko has stated over in the EvoGUI thread, if you can downgrade to 0.12.12, it would probably be best if you did.

I never used YARM in anything below 0.12.13, but thanks for the heads up. I will just work around this issue for now, as i don't want to loose my savegame with the downgrade.

[Boogieman14]

Very much agreed on the ability to put an ore site back into "add" mode (which would also give an opportunity to reduce its duration -- 10 seconds is a long time to wait, and the only way to bypass the wait is to have another kind of ore handy).

I had a thought on this 'add' mode. Would it be possible to detect when you release the item from the cursor and complete the deposit at that moment?