Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darkhog]

What I mean is that something that would lead to more mods that are compatible with each other and easier mod installation/uninstalling. I'm thinking about how Minecraft handles resource packs or how Minecraft Forge handles MC mods.

Basically a mod stack. On the very bottom is the base game and each mod (housed either in its own folder or in a zip file) would be loaded on top of it overloading any raws/graphics if necessary without actually replacing them.

Such stack, if implemented would mean three things:
- Easier way to install/uninstall mods
- Better compatibility and smaller downloads as most mods won't need their separate DF installation, only will contain the raws/graphics they're replacing. If two or more mods are trying to replace same raw, DF could warn the player about potential compatibility issue.
- Easier mod development because mod authors won't have to have a backup of DF in case their mod goes FUBAR or re-download it, just fix their mod or start over with it if it really can't be saved.


Obviously, like with all big changes the existing "big mods" would need to be adjusted to the new system and it's definitely something to do after the big wait as it may involve touching several internal bits of the engine, but if implemented it would be a net positive for the DF.

[Strik3r]

Something like this might actually happen soonish, depending on how the Steam version will handle mods, considering that the Steam version will have Steam Workshop support IIRC.
The current hacky way of installing mods wont really be sufficent for steam workshop mod installation. Of course i'm not counting on anything.

Even just folder loading for mods would make modding so much better.

[darkhog]

Well, it might be that the Workshop would require players to upload entire customized DF installation (including exes) and there being some kind of launcher that would handle that (launching separate installations based on which mod user wants to play). That's how I'd do it if I needed money fast and wanted to release ASAP.

But of course, it'd be great if something like mod stack happens.

[voliol]

Well, it might be that the Workshop would require players to upload entire customized DF installation (including exes) and there being some kind of launcher that would handle that (launching separate installations based on which mod user wants to play). That's how I'd do it if I needed money fast and wanted to release ASAP.

But of course, it'd be great if something like mod stack happens.

Yikes, that would be horrible. I much prefer your mod-stack idea. +1

If we are having a mod-stack though, I foresee some structural changes to the raws themselves.
For one, why not simply consider the vanilla raws mod #0? This way most of the code would be the same for dealing with vanilla items and other mods (for mods of mods, or compatibility mods). The vanilla raws could also be turned off fully for total conversion mods.

To allow for maximum compatibility, and easy editing, the mods could use three different types of object-related declaration tokens, instead of just the existing OBJECT_TYPE (a short I will use for CREATURE, ENTITY, ITEM etc. tokens, that declare a new object) declaration:

[NEW:OBJECT_TYPE:NAME] - What we have now. To avoid duplication errors, objects declared this way should overwrite objects earlier in the mod-stack. For the sake of compatibility with older mods, [OBJECT_TYPE:NAME] acts as a valid synonym.

[EDIT:OBJECT_TYPE:NAME] - Allows for the editing of previously declared objects, by adding tokens. Useful for mods that edit the same objects, e.g. adding modded reactions to the vanilla entities, or compatibility mods. Could have SUB-TOKENS similar to the creature variant ones (ADD_TOKEN, REMOVE_TOKEN, something for further editing castes/materials/tissues within the object). Otherwise, simply adds tokens. If no object of the OBJECT_TYPE and NAME exists, returns a compatibility error message.

[REMOVE:OBJECT_TYPE:NAME] - Removes an object. For those that don't like a certain object, especially useful if the vanilla raws are considered the top mod of the mod-stack, and vanilla objects thus cannot be otherwise removed. May or may not return an error if there is no such object.

The vanilla raws would of course not include any of these two latter declaration types, as they are only useful for mods further down the mod-stack, but I believe a system using something like them would be optimal in case of a mod-stack.