It looks like we’re quite close to allow this, mostly due to new functionality in mod system. And yes - this is not coincidence
Right now the only remaining problem is files that were renamed in WoG (like HELP.TXT -> ZELP.TXT). What we should do with those?
Safest approach I found is to add remapping support on filesystem level (ISimpleResourceLoader interface) that will remap WoG files to their H3 versions.
I’ll try to finish this during next week unless there will be better ideas.
File remapping looks like a good idea. Are you going to push it to the point where VCMI can be installed on pure SoD installations?
That’s the idea. After renaming several files from H3 to their WoG name I’ve successfully started game using SoD data only without any apparent bugs.
Of course there still could be some bugs due to access to no longer present WoG data but not something that can be detected on start.
Great! I’m sure many people will like it. Not everybody likes WoG.
Done. WOG should be completely optional and if installed, it can be safely disabled in config/modSettings.json.
All files overriding happens in WoG/config/wogFileOverrides.json, engine side is in filesystem/CMappedFileLoader.cpp/h.
One more feature - defaultMods.json file.
Now it can be used by mods to change some of game settings. So instead of providing whole file mod can come with small version that contains only entries that should be changed. This means that multiple mods can provide this file without compatibility issues (unless they replace same settings). Already used to enable WoG features only if WoG is enabled.
so how do i disable wog Ivan?
IF you’re using built from source version (and NOT 0.92) then removing Mods/WoG directory will be enough. Another way is to open config/modSettings.json and set wog entry to false.
Good job! Now we have something for everybody, both all and new users
Are there any chances to further downgrades, AB or even plain RoA? I don’t know about all the game mechanics changes, but disabling new/combined artifacts, terrains, guarding mines etc. at least sounds easy and if that might be acomplished by some json file it would be nice to prepare and include abification.json and roafication.json (even if they won’t cover every single change these expansions introduced). Different story is playing VCMI with RoA/AB data files (campaigns? Conflux?), which might be pointless, unless easy to support.
As strange as it sounds disabling new campaigns and conflux is the easiest part. But mechanics changes and new arts/creatures are more difficult to remove - wog and sod/ab handle new objects a bit differently.
The main point behind wog optionality was due to fact that this add-on is not universally accepted. AB/SoD don’t suffer from this problem. Making them optional may be an interesting idea but right now is not an easy one to achieve - it will be better to wait for our engine to become more flexible.
I found out that you can’t however, play pure SoD with only WoG installed. VCMI can read either WoG or SoD files, but can’t run SoD on WoG installment.
So will VCMI 0.93 can run WOG as optional?
Warmonger, yeah, disabling wog installed via “good old” installer may not work - IIRC it completely replaces some of H3 files without any kind of backup copy that can be used by vcmi. Frankly, I failed to install it to begin with because it fails under Wine
Era is much better way to install wog anyway. And those who don’t want it can install wog from this archive: download.vcmi.eu/WoG/wog.zip
Yes, VCMI 0.93 when it will be out will have wog as optional. But disabling wog in 0.92 will NOT work.
(mostly saying all of this to avoid questions from users in future)
Out of curiosity: how far are we from making the entire game „optional”? I mean by that moving all that basic SoD parameters we have currently hardcoded (like text config files names and some constants) into the “SoD mod”. Not thinking about GUI-related stuff, just the game logic.
We still have too much hardcoded mechanics (towns, spells, adv map objects).
I think this is possible but it will need some time to implement. Personally I’d rather wait till modding system will have some more features - for example wog “mod” uses probably every single feature our modding system can offer. I think most of my 0.92-0.93 was centered around making wog optional.
Which config files? Those that come from H3? I don’t know what we can do with files with generic data (e.g. help.txt, general text.txt) but all files that have objects data (e.g. crtraits.txt) theoretically can be replaced with compete descriptions of objects in json.
Situation with our json files is quite similar - all files that contain objects data are referenced in gameConfig.json (no hardcode) and remaining files are generic texts that don’t fit anywhere.
Good to hear, that VCMI use SOD as base. I looked into H5 creatures format and each creature has individual file for stats and abilities, you should use this for H3 Creatures.
Maybe now all WoG data should be stored as a standalone mod for vcmi (like Cove)? Because now WoG files are partially installed with vcmi itself and for other part you need to download vcmi.zip. Also we could think about some global vcmi registry and some mod configuration tool (or ingame screen) for vcmi to easily download/add/remove/enable/disable/update mods.
I’d rather do it in reverse:
- Make some mod manager/launcher with central repository.
- Add wog into this repository.
Othervice it will unnecessary complicate installation: “Hey! I have wog installed but VCMI says that this is not a mod!”
As for mod manager - definitely yes. This was discussed here some time age: [forum.vcmi.eu/t/modding-system-discussion/451/149) But here goes usual question - who will write it?
At the moment WoG mod, when used, enables each of Commanders, Stack experience and Stack Artifacts and it is not possible to disable them via regular config file :?
It was probably meant to disable commanders / stack exp when their files are NOT present, but currently it doesn’t work that way.
Yeah. I couldn’t find any clear way to allow this
Any propositions on how to allow this? Implementing some kind of user override system should be simple enough but may cause issues - what if somebody enables stack experience without wog? What if some mod was designed for specific set of options and user breaks mod by overriding some of these options?
Current binary solution wog enabled/disabled does not have this issues.