Dynamic MOD Loading

Mark McCorkle shared this feedback 3 years ago
Submitted

Description:

Instead of having a world configured with all of its mods statically defined at world startup -- have blueprints and grids aware of the mods which they require while changing the game client to download mods when the player's area of perception is approaching a modded grid.

Benefits:

* This saves initial connection and loading time by allowing the game client to only need to load (stream) the mods when a player is approaching a grid or loading a blueprint which has a mod

* this will also allow for any modded ship to be uploaded to the workshop and then downloaded and built on any server with experimental/mods enabled without the server having to support the *specific* mods that this ship was designed with.

* This does not affect the behavior of the server who is aware of all grids at launch time, therefore has to load all mods the same as it does today.


Risks/Drawbacks:

* A large mod (or group of mods) appearing in an area of perception could impact player experience. Mitigation #1: A nondescript "loading" block could take the place of modded blocks while the mod was being downloading in the background. Mitigation #2: If the game client was aware of the download size of all mods on the server, it could dynamically calculate when to begin downloading the mods in the background to the game client.

* the "G" menu would need to be rethought, as this implies that a user can build any modded block available on the workshop. Mitigation #1: Require all modded blocks to be in their own tab, requiring the player to select the specific tab to view the modded block's available there. If they haven't yet downloaded that mod, a click on the tab shows the streaming icon as it downloads the mod's block icons. Mitigation #2: Only place tabs and items into the G menu after a user has discovered them on the server (similar to how Grind to Learn works).

* this implies that any mod on the workshop could potentially be loaded and the code within the mod would be run without the server admin having direct control. Mitigation #1: Allow the server admin to blacklist/whitelist mods or mod authors. Mitigation #2: Allow admin to limit PCU cost of mods imported to be run on server (once mod PCU cost evaluation is complete).

* this also implies that if a new projection or blueprint is pasted onto the server after server startup, the server needs to load those mods before instantiating the grid into the world, potentially affecting server performance.

Best Answer
photo

This would be a lot of work for devs, server admins and modders to result in more confusion and issues to players.


To go into details:


You're assuming clients have reliable connections... if someone takes a long time to download a mod or simply never downloads it, then what, you kick them from the game or they're stuck in a modless limbo?

And it will just be even more network traffic and hardware pressure (on everyone) when getting a grid streamed to the clients, that's really not ideal.


Right now saves/blueprints have no awareness of block size, only block start position, therefore a placeholder block won't really work until all blueprints are updated to contain block size. Also assuming that the block is fully opaque and solid, but what if the mod is simply a light in a corridor, you can't go past it, really not great...


Having a category where all modded (or edited vanilla) blocks are placed would be great, but not removed from all blocks... maybe a vanilla-only category as well, you should add that as a separate suggestion.

Problem remains people will be quite confused that blocks come (and go) from their UI and frustration ensures if they need to find a modded block or spawn a blueprint that has it in order to place it themselves.

Also what happens when a mod no longer is used by anything, does it just get removed from the mods list? It seems bad both ways, one one hand it'll just gather mods over mods, on the other hand people might want to build said block but it's no longer available because someone grinded it off or shot it... that really makes no sense, both game-wise or lore-wise.


As I said, a lot of work for admins which a lot of them will simply disable this feature (or use a whitelist and add nobody to it), who has time to research this.. if they have mods that they know and like they will just add them.

I don't see what PCU has anything to do with mod code.

Mods wouldn't be the only thing needed to be updated to work, the modAPI would need to be changed to support editing things mid-game that are currently only do-able before the game.

Mods also can edit definitions on vanilla blocks or other modded blocks, which can mean that blocks will suddenly change in behavior, visual or cost to build.


I'm not seeing this happening, it's too much complication for no real benefits.

Comments (3)

photo
1

Not sure how others think about dynamic mod loading, but I would like to have some control over the mods that are loaded to my machine. If we will still have the ability to see at least a list of mods and some details about them when hovered I would consider the idea.

Thx for the idea and for all the effort you make across different topics in general!

photo
1

Oh, absolutely, the player would be able to blacklist / whitelist mods -- much like you traditionally would be asked to install a "plugin" in your browser (or block / ignore it). Mods would still have to come from a "trusted source" either Steam or Keen's own hosting / cloud / cdn with some kind of md5 fingerprinting to protect players from dynamically executing potential malicious code on their machines.

photo
photo
1

I don't think that dynamic mod loading is feasible.

From the programming point of view it brings a lot of unnecessary complications, and game is complicated enough,


I think that current system is quite good (it will notify user that spawned ship will be incomplete), but I think it could be improved that it will list all the required mods so you can enable them manually later, if you want.

photo
1

Yeah, if I could try and paste a ship and just get the steam page to subscribe to all the missing mods, I'd take that in a heartbeat.

photo
photo
1

This would be a lot of work for devs, server admins and modders to result in more confusion and issues to players.


To go into details:


You're assuming clients have reliable connections... if someone takes a long time to download a mod or simply never downloads it, then what, you kick them from the game or they're stuck in a modless limbo?

And it will just be even more network traffic and hardware pressure (on everyone) when getting a grid streamed to the clients, that's really not ideal.


Right now saves/blueprints have no awareness of block size, only block start position, therefore a placeholder block won't really work until all blueprints are updated to contain block size. Also assuming that the block is fully opaque and solid, but what if the mod is simply a light in a corridor, you can't go past it, really not great...


Having a category where all modded (or edited vanilla) blocks are placed would be great, but not removed from all blocks... maybe a vanilla-only category as well, you should add that as a separate suggestion.

Problem remains people will be quite confused that blocks come (and go) from their UI and frustration ensures if they need to find a modded block or spawn a blueprint that has it in order to place it themselves.

Also what happens when a mod no longer is used by anything, does it just get removed from the mods list? It seems bad both ways, one one hand it'll just gather mods over mods, on the other hand people might want to build said block but it's no longer available because someone grinded it off or shot it... that really makes no sense, both game-wise or lore-wise.


As I said, a lot of work for admins which a lot of them will simply disable this feature (or use a whitelist and add nobody to it), who has time to research this.. if they have mods that they know and like they will just add them.

I don't see what PCU has anything to do with mod code.

Mods wouldn't be the only thing needed to be updated to work, the modAPI would need to be changed to support editing things mid-game that are currently only do-able before the game.

Mods also can edit definitions on vanilla blocks or other modded blocks, which can mean that blocks will suddenly change in behavior, visual or cost to build.


I'm not seeing this happening, it's too much complication for no real benefits.

photo
1

Thank you for such a well thought out response Digi. I still think PCU would be impacted dynamically (based on what mods were loaded as they could possibly generate work that the server has to track -- I'm thinking of Nanite Control Factory as good example).

Either way, after reading everyone's feedback and looking back at this I realize how much of a can of worms it is. This might be a much better idea to consider during the architecture of whatever game engine comes after SE instead of trying to retrofit the Space Engineers code and the user interface / player experience.

Take a look at how VRML (and ActiveWorlds, which somehow, as of this moment, still around) does dynamic object (mod) loading/unloading with smart area of interest calculations based on bandwidth/ping/machine performance in a 3d space as you move around. Though VRML doesn't by default simulate physics or provide multi-user experience, ActiveWorlds somehow pulled rudimentary versions of that with a client/server tech built back in the mid 90s (released the same year that Intel released the Pentium to boost your 486DX cpu to 63Mhz).

I'm just saying, its possible to build, but I totally agree that retrofitting SE at this point to dynamically load mods is a bad idea. Keen, please don't do it in this game. :-D

photo