Client and host based mods

[y.petremann]

The main idea is to separate mods into 3 categories (more precisely part of resources) in addition to control, prototype and world : Client, Host and Common

This mainly could permit to have texture pack, without needing other client to have them, server manager without needing the clients to have them, to make clients processing less data (because somebody else is using a client process hungry script to show him some data, that his computer can afford bbut not yours ... :lol: )

Here is a complete diagram about how it would works :

Diagram

I consider that actual mods could works the same way they do for now, there simply two main things to consider :

• mods could provide control-host.lua and control-client.lua for respectively host and client only mods:
  • Visualy work on the same workspace but would be sandboxed and so couldn't cause a desync. For example, a client mod couldn't add, modify or delete any common gui.
  • If a client or host script need to interface with common script (blueprint manager for example), would use remote interface, game would detect that it's a defined common interface and so would broadcast to everybody.
  • Host scripts would get disabled if bot the host. Same for client script if a headless server.
  • Host could interface directly with a specified client without informing other clients.
  • Host could see in debug informations data size transmission from each client, a data limit in specified time could also be set to prevent spam (set to 0 to disallow such functionnality).
• mods would only provide data.lua and data-updates.lua:
  • Host, Client and Common prototype would be "separated" at startup
  • A mod than only modify client stuff would be considered as client mod. Same for host mods. For ease of use, any mod could set metadata to inform the player if it contain client, common and host content, but this data is totatly irelevant when connecting.
  • Every cosmetic (graphics, audio, particles ...) property is considered client.
  • Unless something is in place, to help with texture packs and variation, if client have less variation, then "actual variant" modulo "max client variant" rule could be applied.
  • Some entities could be defined as client side, they could be used for helpers mods to planify, see range of turret,
  • Gui would have inheritence to parent elements (so if the client don't have the wanted style, it takes his nearest defined parent)

I couldn't see this as a lot of small sugestions, this is for that that I needed to put all together.

Please ask if anything is not clear.

[minno]

Someone on reddit just requested a feature like this, so that they could change the graphics in their client to be easier for them to understand with their impaired eyesight. Has there been any more discussion on this topic?

https://www.reddit.com/r/factorio/comme ... ?context=1

[ptx0]

seems like a bad idea. wonder how long until the devs come along and tell everyone that this won't happen because of Factorio's strong guarantees for determinism?

[Silari]

Mods that only replace graphic files like the reddit poster did wouldn't break determinism. If they did, the edits they made wouldn't allow them to play MP games - they'd have desynced. Whether or not you could change the actual prototype animation properties without issue I don't know - depends on how much is considered game state. Without that you'd be very limited in what you can do, but you could still manage some changes just as they did.

The OP's suggestions seems way over complicated for that though.

[minno]

The really useful and relatively simple part of this suggestion is to define some subset of mods that can be installed for some players but not others without causing desyncs (image/audio file replacements, scripts that generate user input) and then allow users to play together even when their mod lists differ as long as it's only those kinds of mods.

[bormand]

subset of mods that can be installed for some players but not others without causing desyncs

Yeah, basically load them last, so other mods can never see what was changed, and forbid them from changing non-visual properties.

The hard part is to exclude them from all checksums, though. And to define a subset of properties that can be safely changed.

P.S. Since these mods will never be compared with server, they can easily become outdated and broken.

[Taurondir]

I have been running modified, client-side graphics in Factorio for over a year now.

I just go on and just edit the PNG files directly. I keep the original file dimensions and depth, and Factorio just loads them, as there is not CRC checking for the graphics files. The names are the same, the size is the same, so it just does not care.

I run a single terrain type, so everything looks like clean snow, I "blanked" a ton of decoratives, including tree stumps, and all the Biter type corpses, which means that the game still actually PUTS THEM DOWN on screen, it's just that now it's just a clear PNG, so nothing shows, also, all my concrete is modded

I have some vision issues, so I need a nice clear map in order to see everything properly as the over use of brown terrain and dark concrete just messes with me something shocking, and because its client side, everyone else sees the "normal" game, and no one elses game is effected.

[ptx0]

Mods that only replace graphic files like the reddit poster did wouldn't break determinism. If they did, the edits they made wouldn't allow them to play MP games - they'd have desynced. Whether or not you could change the actual prototype animation properties without issue I don't know - depends on how much is considered game state. Without that you'd be very limited in what you can do, but you could still manage some changes just as they did.

The OP's suggestions seems way over complicated for that though.

graphics are one thing... control scripting changes are another