So first up there is so much awesome work been done here and it truly transforms the game into a much better game
The innovation is awesome and the sheer dedication involved in tasks like the extreme mods with disassembling the executable and offering assembly patches, just wow
The subsim community should be proud
It is my hope, that in that spirit, the following suggestions are considered in the light that I'm genuinely trying to explain what I see to be serious problems preventing all this awesomeness for getting into users hands in a useful state
The core problems as I see it are:
1. Source code and configuration management practices are poor
2. Release distribution and end user configuration practices are poor
3. The impacts of 1 and 2 has ripple effects in that testing efforts are diluted and confused from what they would otherwise be able to contribute to mod Authors
There's been numerous posts in the past about users being frustrated with not knowing how to obtain the mods, then not knowing how to install them properly. Sober has put forth a yardstick with a mod list. If people subscribe to the site they can get out of date binaries from the all in one download and then be forced into downloading more files to update it.
Then once the users have done that, the real "fun" for them begins when they try to configure each mod to the install instructions supplied. I initially started out by trying to setup Sobers mod list so that I could:
a) Personally enjoy what seemed to be a baseline set of mods that I assumed would have compatibility between each other cos it's in his stickied and popular mod list
b) Document every detail from a user perspective so that others could have deeper instructions as with respect to Sober, theres much detail missing on how to configure each and every mod to work with his modlist. While each mod discussion thread has some degree of install instructions its relevant for that mod in itself and not an actual complete mod list.
Some of the issues I experienced with doing this is:
i) Sobers mod list referencing package versions which dont exist
ii) Inconsistencies between the mod list profile and differences in how mod authors release their mods that are likely to cause a "corrupted" mod list setup
iii) Multiple mods needing the same original dependencies and the behaviour of the mod enabler tool where
configuration items are overwritten
iv) In working around these problems, I am now actually doing development in simply trying to get myself to the point where Sobers mod list is configured where every mod is correct and working as a whole
I was reflecting on these problems last night. I know, I can get my own system to the point where I've hard coded and fiddled with directories and done all sorts of things to configure my own setup. However, no normal user is every going to follow my instructions even if I detail them specifically. They'll get lost in it all. What tends to happen is either the user will complain on the forum and give up, or ask for help about crashes and general weirdness as they have an unstable and improperly configured "mod list".
The community tried the approach of an all in one download before, and while I was happy to pay for my subsim subscription to help out, the all in one is out of date where its missing important fixes. So you have to start a new cycle of manual updates which leads to all the problems again. Your not fixing the root cause with this approach and this band aid fix wont ever deal with the updates problem.
There is a way to fix the root cause. These problems are nothing new to software projects. There is tried and true methods for dealing with all this.
What I propose is:
1. SH5 Modders sign up at source forge or some other open facility and we establish subversion source code and configuration management procedures.
2. Invite testers to sign up too, for both SVN trunk and "release" testing.
3. As an initial step, integrate those mods that are common and popular with each other.
4. Testers would grab SVN, do a single mod enable in the mod tool, patch the exe as needed (not releasing modded exe avoids legal issues) and be positioned to test on a known standard to reinforce the inherent quality of this method.
5. In such a scenario people could still customise and modify as they want, but they do so at the expense of not being on the standard build
6. From time to time where it makes sense, releases could be issued to make it even easier to distribute a specific build version.
7. Meritocracy to be applied to competing mods that offer the same end user effect. Such as deciding which UI mod to use. I know sometimes this can be contentious but it is very important for establishing a standard build. And, if pockets of the community really felt strongly about specific decisions in this space, there would be nothing stopping a fork of SVN to occur on another project. This happens in open source development, like with Ubuntu and Kbuntu.
It's not as involved as it might seem to those who arent used to working like this. I genuinely consider if key modders got on board with it, such as TDW, Trevally, Steel Viking, Gap etcetc soon enough everyone would use it.
Thanks for reading
