Not sure if you're already doing this, but there should be buttons for FS2-Open and FRED, and the option to run the Debug and Release of either, all using the same MOD.
The current launcher needs quite a bit of background knowledge and doesn't do much handholding, which isn't great for new people.
On rebuilding from source:- On Linux, this feature is required due to the differences in APIs between distributions - a lot of apps don't work correctly (or at all) if not built from source.
- Under Windows, this feature is not a good idea:
- No build environments are included by default, so one would have to be provided. We can't provide MSVC which is the build environment currently used for Windows development as that's owned by MS.
- It would take a very long time compared to what Windows users are used to. My PC runs FS2-Open pretty well, but takes around half an hour to do a full build of FS2-Open 3.6.12 in MSVC 2008. Windows users don't expect to do this.
However, there does need to be a choice of Win32 Standard/SSE/SSE2 and Win64 builds under Windows - selection should be automatic based on the detected OS and CPU capabilities, but an 'advanced' user could override it (in case they want to try something or the detection is incorrect)
I don't use Macs so can't comment on that platform.
On old versions of MODsIs there any particular reason for not leveraging an existing proper version-control system that already handles the full revision history?
- Each individual MOD folder would be its own repository and thus have a contiguous revision history.
(Eg Updates to BP2 do not affect BP1 revision numbers)
Each 'commit' to these version control repositories would only ever be a proper release (
never beta), so all commits should be good. (At least as good as shrinkwrap software anyway)
Each MOD lists the revision numbers of all the dependencies that it has been tested with.
If the local version is older than the oldest 'tested' revision it warns and suggests updating to the newest or newest tested one.
Example:- MVP Revision 20 is released and I download it.
- BP1 Revision 5 was tested with MVP Revisions 12 thru 15.
- System defaults to MVP Rev 20, offering to switch to MVPs Rev 12 thru 15 as alternatives on user selection. Other MVP revisions would not be offered.
It would then be up to a given modder to test with a sensible range of versions of the items it depends on. We don't have multiple inheritance so this isn't an onerous task - eg BP2 depends on BP1 and MediaVPs, but not anything that BP1 says it depends on.
If a MOD is old and therefore completely untested, then the latest version of all dependencies is assumed, but the end user can roll any dependency back to any older version.
When a modder wishes to test their MOD with other revisions, they activate the 'Expert mode' to get the full, dated list of dependency revisions to consider which to test with.
- Administrators of the new system can also add tags to any MOD to indicate recommended versions, to handle orphaned and untested works (eg People can post here saying that MOD x doesn't work with MVP release y but is fine with z)
New MODs are self-evidently tested by the modder with the versions of the dependencies that they had at the time, even if they didn't want to bother testing with other versions.
I expect that only very large MODs would be tested with more than one version of dependencies at release.
As the new system offers automatic mod.ini creation anyway, this same automatic system can be used by the modder to generate the 'release' mod.ini (while in Expert Mode)
This gives the information required to determine when to archive/discard very old versions of things:
- There will be the meta-data available saying which revisions are no longer required by anything in the system.
- It will be possible to tell if a very old revision of something is only used by one or two MODs, and then user-testing can be done to determine if these can use the very newest version without problems.
- 'Untested' MODs are a problem, but they won't stay untested for long if anyone is playing them.
Otherwise we are likely to discard things that someone is relying on.
Selection of version control engine is left open. No holy wars please!
However, it should be something where you can switch between revisions without redownloading them, as otherwise testing across multiple revisions becomes a pain in the proverbial.
ScriptingLua is the only choice.
It's the one used in FS2-Open, so many people already know it from both ends.
There is no point in asking modders to learn a new language, or coders to learn new ways of handling hooks.
Further notesThe entire system is going to need fairly powerful Administrators.
This is going to be quite a lot of work.
Turey's Installer fell over for a while because nobody was doing the important work needed to keep that up to date.
So whatever system is built, there will need to be a very simple and easy to use multiplatform tool to handle the updates that can be taught to your average modder in a few minutes over IRC or similar.
Otherwise, sooner or later the new system will lose a key person (even if only temporarily) and fall apart.