Inconsistent managing of config files and assets about opensoldat HOT 3 CLOSED

OK, I got around to this (sorry for the wait). I agree with your approach on almost all points. There will still be some amount of directory creating by Soldat, and synchronization between Soldat/base and Soldat/soldat. But this will decouple them to an extent. Having client.zip and server.zip to ship other accessory files will be useful as well.

Regenerating config files from soldat.smod is nice in theory, but realistically users are expected to modify those files. Once that happens, if they are deleted, I would say regenerating the default file is meager recompense. A descriptive error message might actually be more helpful in some cases.

I hope if anyone has a point they would like to raise they will comment on it. Otherwise I'll implement this in the next couple days.

from opensoldat.

Thank you for the detailed analysis. Your proposed solution makes sense. I'll make some time soon to think more about how the different files relate, and specifically about the mod creation workflow then made a decision on this.

from opensoldat.

I backed out of this approach, and went back to just having everything in soldat.smod. I wound up reimplementing the unpacking behavior twice (once in CMake for development, once in shell for AppImages) trying to make this work. Very difficult to see that kind of stuff coming if you don't have a clear picture of all the steps you will need to take. I think the original method was the right way to go about it. In order to have the full folder structure presented to users, we should run the client+server once, so they unpack their files, as part of the release process.

from opensoldat.