Lets talk about the mod content persistence this time. While working on APX it came in my mind. As it's currently the situation, the game applies the mod permanentely if the client connects to a server. This allows the game to avoid having to download mods multiple times of course, but also adds a layer of updates, if used, to the installed mods. As long as mod packaging is done right (even numbers instead of taking latest) for example, everything is fine. But at the point where the packaging is not done according to the manual, base mods gone missing, mods getting broken, the client runs into - nowadays less verbose - error messages which are quite cryptic and especially hard to understand for the user. Also, this makes debugging quite a high effort. I am not part of an opinion that the package system needs an replacement, but I am thinking more about an transactional approach. The package system remains the same, but works similar to a database transaction. After the transaction is done (the client leaves the server), the applied mods are removed again. This keeps the installation clean and on a base image. No mod overlaps anymore, yay! Apropos base image. That is the important and also tricky question. What is the base image and what not. As rFactor relies heavily on Steam as a CDN. As the mods as packages remain present inside of workshop\content\365960, we still have an source of subscribed data to read from. So the result/ extracted artefacts could be considered as the wanted state. As a lot of rfcmp updates are distributed via steam, it's hard do make a difference here, so my idea has no answer for this use-case. Another point is loading time. At the point where you need to unpack everything at connect may take time. Especially if your computer is a toaster. Here another idea to locate the packaging artefacts in venv-like folder structures. If the user chooses to go singleplayer, it uses like the default (current) Packages/Installed/Manifests directories. If just Windows would support filesystem layers like Docker ..but that is OT. If the user chooses to go onto a multiplayer session, the folder structures could be derived from the default Packages/Installed/Manifests folder (e. g. hardlinks) and located the server-needed mod artefacts there. The game then launched into this folder structure as a context to work with. Either when the game disconnects or on user/ scheduled task, this gets removed. A timeout might be a good idea to prevent the context from getting binned if the game crashes/disconnects. This whole idea might have a lot of flaws, but I thought I might share it anyways.
