Fluid Filtering


Adds ability to set filter for pumps, works the same as filter for inserters. Can be set from circuit network as well. Adds ability to set filter for fluid wagons.

Utilities
5 months ago
1.1
749
Logistics Trains Fluids Circuit network

i [Fixed] Some desync unsafe code

7 months ago

Hello,

This is a really cool idea for a mod, so I had a look at your code. I saw some things that might cause desyncs so I thought I'd let you know. I hope you don't mind :)

Some of these globals are unsafe. Specifically looking at g_RecentlyDeletedEntities‎. A basic rule of thumb is that if any event could change the variable, and you want it to persist between events, then it needs to be placed in the global variable that Factorio provides. If you don't do this and the player saves/exists the game at the wrong time then the information won't exist when the game is loaded again.

The easy way is to create these "globals" in on_init and verified that it exists in on_configuration_changed. And then it's always accessable in events. Something like:

script.on_init(function()
    global.g_RecentlyDeletedEntities‎ = {}
end)

script.on_configuration_changed(function (event)
    global.g_RecentlyDeletedEntities‎ = global.g_RecentlyDeletedEntities‎ or {}
end)

If you follow the mentioned rule-of-thumb then it's relatively easy to keep your mod desync-safe. And you can catch most cases of where it might go wrong using /toggle-heavy-mode, which will basically save/reload your game every tick.

Hope this helps :)

7 months ago

Oh, right, thanks! I didn't realise that undo history survives through save/load so it did make sense to me to persist that info in global.

7 months ago

Fixed in 1.0.3

5 months ago
(updated 5 months ago)

Was watching this video where a player got a desync with your mod after opening a pump menu I think. I had a look at your code and you still seem to store state in locals, and not in the API provided global. I understand some of them don't save state and rather prototype information, which is fine of course :) But things like g_InputEvents look fishy, because it might be modified with one player, and then when other player B joins g_InputEvents will be different that player A's .

Honestly, I would put g_LocalizedSignalNames in global as well. This is what big mods like RecipeBook and FactoryPlanner do it, probably for a good reason, even though it increases save file size. Not sure if it's desync safe or not to do it like you do, but most likely it's not. For example on_string_translated will still be called for all players, even if only one player is out of sync and the others are not. Could be that the engine is immediatelly saying desync because it saw one client do an request_translation call, but another client not.

I would highly recommend using global if you're not 100% sure that information stored in that table will always be exactly the same between players, regardless of when they join the game, etc. Only thing I know is safe is storing prototype information.

Of course, I might be wrong, you look like you know what you're doing. But I saw a desync, and some code that triggers my spidy senses. And personally I would prefer to be notified of possible issues so I can fix it, because players don't always make bug reports XD

5 months ago
(updated 5 months ago)

Okay, I added both to global to be safer - in 1.0.8

Although I still don't see how g_LocalizedSignalNames may leed to desync, I tested in heavy mode and in multiplayer connecting and disconnecting a second player midway intentionally "desyncing" the table but it worked all the time - no desyncs were detected by the game. I'm just wondering how exactly it can break stuff rather than just following the guidline. Also this results in a rare issue

5 months ago

Desync still occurs in 1.0.8.
It occurs even if no other player is connected in multiplayer on a headless server.
In my environment, desync occurs every time after opening the pump menu and disconnects.

5 months ago

It could be related to timing? For example what if the translation is ready for one client but not the other? This should be solved with using global though, as all clients will then do the exact same thing

If konnnyaku963 can provide the desync report then it can determined which information is out of sync between clients. It can then be analyzed using https://github.com/Hornwitser/factorio_tools

5 months ago

Desync reports are not output.
The same phenomenon occurs when a player logs in as a solo player immediately after a server restart.
Regardless of the number of players or translation status, players who open the pump menu are disconnected.
https://i.imgur.com/7R68vpV.jpg

5 months ago
(updated 5 months ago)

Well, that's not a desync error.

Could you upload a save with your mods?

5 months ago

I'm sorry for the trouble but thank you for your cooperation.
https://drive.google.com/file/d/1a6KC2vJWnti3n5pRv84-AjrnV9cpQ8Li/view?usp=sharing

5 months ago

Apparently the problem is that headless server takes too long to load locale so your client disconnects. I use flib to load translations now. This should be fixed in 1.0.9

New response