Darkhog made a similar thread a few months back (and so did Thansin in 2010 (!)), but it's still worth discussing as the work on it is getting closer and closer.
Reworking the mod structure in classic as well to match with whatever Workshop needs, would be the most sound option.
My guess is that all Workshop does is provide the mod files when you click the "subscribe" button, and which one should be removed when you click "unsubscribe",
This is exactly what happens, but:
and then it's up to the game's handler to actually put the files somewhere sensible/install them. I doubt there is a standardized structure for mods on Steam.
There is a steam workshop folder for a given app, where mods are downloaded to by default, and:
That said, both versions could have a folder with subfolders for each mod, and a logging file.
Steam workshop has build in logging, which is separate from any game logging as it is handled by the client, and:
Using Workshop as an interface, you could install mods to this folder, as well as remove them. If you don't have premium, you can either manually put mods in that folder, or do it through whatever in-game interface allows you to enable/disable/order the installed mods. Darkhog made the comparison to how Minecraft handles resource packs, and I think it's a pretty good one.
Workshop is basically a centralized internal file download system that has very few rules (game id, mod id, basic location, having a game etc).
How the game handles modding, how the game handles scripts depends on how modding is implemented in a given game.
For example: in my mod EvansDF my 'CAT' entity can be different from VoliolDF 'CAT' entity due to the virtue of belonging to separate pack.
Or they could be the same entity conflicting. Or they could be the same entity loaded in the order depending on how mods are loaded.
Or they could use 'override' system, and your would override default cat, mine would be a separate entity.
Considering that modders creating mods rarely keep their files neatly organized and their entities properly named, while we will name ours EVANSDF_CAT and VOLIOLDF_CAT to make them stand out, I assure you the next hundred guys from steam will go with just a 'CAT'.
This is a rather serious issue to be considered, as there are tons of DF mods out there already. Setting up the stage for massive mod conflicts is bad idea.
I wonder how such a system would work for applying mods to already generated worlds though. It's important that saves are allowed to use different sets of mods, especially as downloading whole versions of DF will no longer be an "easy" way to try out mods, as getting that modded version into Steam won't be easy, and the mods themselves can't contain Mephday/the new music. Removing a mod because you don't want it in your new world can't break older saves either.
That is another issue here. Saves could use mod list to load rather than copy-paste of raws (that was dumb idea to begin with, even tho I understand why it made sense back then). Some sort of default item/creature/recipe for replacing missing definition could be present. It's
not that hard really, to prevent game from crashing because some CAT definition is missing, but it could make game act funny later.
Another issue is that Steam Worshop has you "subscribe" to the mods, instead of simply installing them. This means modders can update their mods and the subscriber automatically gets the updated version, without any further downloads. This is generally a good thing, but if you allow active saves to have their mods updated, there is a risk of them breaking due to this, and if you don't people will miss out on minor updates that would be compatible with their saves, which is a shame.
Aye, and DF saves are not for 15 minute long games either. So copying raws makes sense here. Or not.
The thing is, the way game treats definitions NOW is as if they were hardcoded once world is created. Its bad.
It was bad to begin with (we can still hear a cry of thousand modder souls for being unable to add in one recipe into an existing world).
This will have to be changed and handled somehow.
I think leaving references to '1001 sun berry dishes' in the save game, while disabling the recipes when mod is uninstalled, instead of outright deleting these references and/or crashing (so that when mod is re downloaded later it just re-enables them) would be the right way to go.
I'm not talking about workshop logging and functionality, but in game script handling 
The steam workshop cannot work with an overhaul of in-game mod handling. Mods cannot be combined as of now, but they must be combined for the steam workshop. That's what's being said here. The way mods are loaded needs to be changed in and of itself.
Aye, exactly.
If Putnam adds ten new cat types, they need to be loaded along the base game files. If I want to give these Putnam cats poison spitting attack later, I don't want to copy-paste his whole file (as he may want to add few new cats later on) I'd rather use 'append' option and simply insert that attack into their creature definition. That way Putnam may work on his cats as he sees fit, and my mod only adds extra feature to his work. Or If I want to make a mod pack but one of Putnam's cat does not fit into the setting, I just set my mod later in loading order and disable that particular cat with append [DISABLED] tag.
Sounds easy enough, but all this has to be implemented for long term mod support.
And yes, before someone asks, there are games that do all that, even more. See Rimworld with harmony dll extension.
Author
Topic: Add 'mod' folder and its handling. Add detailed log output for mod loading (Read 2364 times)