Ok, so spring is out and people have started porting mods to it all over the place. With only XTA, OTA, and AA, there's already a high probabilty that some player won't have the same mod as the others and crash the game. Trying to impose XTA to everybody isn't the solution. Spring needs a mod management interface, and it needs it quickly. Some people would like overbloated mod management system with new format, but I think that, at least fo now, it's not a good choice because:
- Mods can take multiple form and shape and have multiple purpose. A full TC, a new additional unit, and a rebalance can't be treated the same way.
- Some very good mods are years old, their author have long left and won't port them to Spring.
- Not enough time! Not enough workforce!
So here's a really simple idea to manage mod:
- The host seen in a windows the list of all .hpi .ufo .ccx .gp? files he has in his Spring folder. Files are simply referred by their filename.
For a later realease:
- The spring lobby also open them and looks for .txt in the root of the .hpi .ufo .ccx .gp?. The first txt found in the root of .hpi etc... is displayed in another windows. That way when mouseovering over the filename, that other window show the readme that many modders have already left in their data files. And if not, it's easy to include a .txt in an .hpi/.ufo/.ccx/.gp? If possible do a window with a little scroller, if not show at least the first lines.
- By clicking on a filename, the host enable it. By clicking again, he disable it. Enabled files have their filemane looks like selected text, , white on blue instead of black on white (or any other color change you want). It is important that: The lobby client store the list of selected files as soon as "start" is clicked (before any crash could occur) and reuse it for the next game. I'd say new files should be enabled by default, (so when installing a new mod, you just copy the files and play it, instead of copying the mod, running spring, see OTA, remember that you have to enable it, exit, rerun the client, go throught the list of file and try to remember what was their name, etc...), but that is matter of discussion.
- At every instant, the other people on the battleroom see the list of files enabled by the host.
- Before the game launch, the host send the name and checksum of all enabled files to the other players.
- The other players compare the name and checksum with the file they have. (I say checksum, but of course use some sort of MD5 hash)
- If he has the same file, fine.
- If he has not the same file, the client see a choice between leaving the game or downloading the file. If he has a file with the same name but different checksum, the client get the choice between leaving the game, getting the file overwritting the one he already has, or getting the file while keeping his own version on his hard drive for later use. In that last choice, the new file is dumped in spring folder with a _ appended to the name. Like rev31_.gp3 if rev31.gp3 already exist, rev31__.gp3 if rev31_.gp3 and rev31.gp3 already exist. Which bring us to the little point that _ should be ignored while comparing files. Maybe just ignore filename altogether and just only check for files with same checksum, I don't know.
- The host would then proceed to distribute the file to every client that not have it. It would be best if each client contribute to distributing the file, or the got file parts, but we can't ask jouninkomiko to create a full P2P network system overnight, so just do whatever you have time to implement.
So, in a game of Spring,the host would select any mod, any unit, anything he want, and the client would either leave or get the exact same files.
For instance, to play XTA, the host would select:
- interface.hpi (crosshair, etc...)
- OTA_Textures.hpi
- OTA_Models.hpi
- XTA_Units.ufo
And would deselect OTA_units.hpi and any other things. If someone wants to play Uberhack, fine, he would just download the old version for old TA and dump them into his spring folder, that would work. However, for a better job, he can rename them to add uberhack to their filename. Even pure newbies know how to change a filename while keeping the suffix. So any basic user can rename the rev31.gp3 from Uberhack into Uberhack_rev31.gp3 so it's easy to spot it in the list of files. (Another reason to check only for similar checksum and not similar names). And if the mod author is alive and wants to do real good job, he would just merge all his file into a single .hpi, and leave a notice in the readme (the readme in the root of the .hpi too!) reading: "Enable interface.hpi, OTA_Textures.hpi, my_mod_units.hpi to run.". Note that it is important that files use .hpi suffix whenever possible, as it is the lowest priority in TA files, and so leave the more room for improvement and patching and tweaking via others files. While you cannot change the contents of rev31.gp3, you can easily patch a .hpi with an .ufo, an .ufo with a .ccx, and a .ccx with a .gp3.
A similar system could be implemented for maps, save that only one map can be selected at a time. That system doesn't work with unpacked file. Either treat unpacked TA files just like packed file, but putting them at the end of the list in the window, or ignore them. Mods usually use a custom gp3 instead of unpacked /gamedata/ anyway.
Really simple mod management interface idea
Moderator: Moderators
That just sounds waay to complicated tbh, especially for people who aren's ure what they're doing.
A simpler way to do it would be:
- 3rd party addon units are handled as before, just drop the ufo files into the TA spring directory
- rebalances and TC's get isolated from the main Spring filebase in their own directory set (something like TASpring/mods/modname/ - one directory for each mod - anything that doesn't have a complete fileset e.g. a rebalance would have the missing files loaded from the main Spring filebase)
- when hosting a game you are allowed to choose from a list of installed mods
This would be a move away from the traditional method of installing mods for TA, but since most mods are going to need some reworking to be compatible with Spring anyway I don't see why it couldn't be done. It would definitely make mod management a lot easier.
A simpler way to do it would be:
- 3rd party addon units are handled as before, just drop the ufo files into the TA spring directory
- rebalances and TC's get isolated from the main Spring filebase in their own directory set (something like TASpring/mods/modname/ - one directory for each mod - anything that doesn't have a complete fileset e.g. a rebalance would have the missing files loaded from the main Spring filebase)
- when hosting a game you are allowed to choose from a list of installed mods
This would be a move away from the traditional method of installing mods for TA, but since most mods are going to need some reworking to be compatible with Spring anyway I don't see why it couldn't be done. It would definitely make mod management a lot easier.
I've got an idea :
For each mod, make a txt files of wich files have to be enabled when you start a game. Then, just make a shortcut with the name of the exe to play your mod :
spring.exe -"myMod.txt" launch the game and enable all the file you need
in myMod.txt :
\unit.hpi
\grep.ttd
\graph\tud.bmp
etc...(all the files you need)
Of course, is spring detect these texte file and ask you wich mod you want to play, it even better.
For each mod, make a txt files of wich files have to be enabled when you start a game. Then, just make a shortcut with the name of the exe to play your mod :
spring.exe -"myMod.txt" launch the game and enable all the file you need
in myMod.txt :
\unit.hpi
\grep.ttd
\graph\tud.bmp
etc...(all the files you need)
Of course, is spring detect these texte file and ask you wich mod you want to play, it even better.
-
Sean Mirrsen
- Posts: 578
- Joined: 19 Aug 2004, 17:38
Ok, my suggestion: Make distributed archives containing certain unit sets. For example, an archive for OTA containing all OTA data, units, and textures. Then an archive for AA, containing all needed files as well. Then an archive for TA:FF, and so on. The point is, when such archives become standart throughout the community, it will be a)a lot easier for people to set up their mods, and avoid sync problems, and b) it will be a lot easier to make a very simple mod manager program, that has those archives stored in a temp directory, and copies them in as necessary.
Alternative: Have it the same way, but instead of having archives, all files are piled together into one set of folders. It is presumed all these files are the same on all computers. Then the mod manager could copy all needed files using their names (and maybe some sort of CRC for checking) from a 'mod list', a mere txt file that can be easily sent over network. After the program is closed, it deletes all the files it copied, leaving only the core Spring files in place.
Alternative: Have it the same way, but instead of having archives, all files are piled together into one set of folders. It is presumed all these files are the same on all computers. Then the mod manager could copy all needed files using their names (and maybe some sort of CRC for checking) from a 'mod list', a mere txt file that can be easily sent over network. After the program is closed, it deletes all the files it copied, leaving only the core Spring files in place.
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
I was thinking of something around that. Your idea is good and i will deepen it a little.Torrasque wrote:... For each mod, make a txt files of wich files have to be ...
- Have a folder named "mod" just as a standard.
- Have .mod files in the root of TA::Spring, which are nothing more than text files where is writen something like this:
File named "AA"
units pack: /mod/aa.units
textures pack: /mod/aa.textures
This way, it doesn't matter where the mods files are, they can use /mod if they want or not. It would be the mods/players responsibility to have the files properly located. But they would probably use the standard /mod.
- To start the game, execute
spring.exe -mod aa.mod
spring.exe -mod aa
spring.exe -aa.mod
Or whatever...
Spring would just look in the root folder for the file aa.mod and would interpret the instructions for the modifications. This would lead to a somewhat easy way of upgrading the functionalities of what could be interpreted by the mod interpreter while keeping old .mod files compatible.
Sounds good.PauloMorfeo wrote:I was thinking of something around that. Your idea is good and i will deepen it a little.Torrasque wrote:... For each mod, make a txt files of wich files have to be ...
- Have a folder named "mod" just as a standard.
- Have .mod files in the root of TA::Spring, which are nothing more than text files where is writen something like this:
File named "AA"
units pack: /mod/aa.units
textures pack: /mod/aa.textures
This way, it doesn't matter where the mods files are, they can use /mod if they want or not. It would be the mods/players responsibility to have the files properly located. But they would probably use the standard /mod.
- To start the game, execute
spring.exe -mod aa.mod
spring.exe -mod aa
spring.exe -aa.mod
Or whatever...
Spring would just look in the root folder for the file aa.mod and would interpret the instructions for the modifications. This would lead to a somewhat easy way of upgrading the functionalities of what could be interpreted by the mod interpreter while keeping old .mod files compatible.
In the meantime I may begin working on a small switcher app.
Yeah, but don't forget that you have to be able to add directory!PauloMorfeo wrote:I was thinking of something around that. Your idea is good and i will deepen it a little.Torrasque wrote:... For each mod, make a txt files of wich files have to be ...
- Have a folder named "mod" just as a standard.
- Have .mod files in the root of TA::Spring, which are nothing more than text files where is writen something like this:
File named "AA"
units pack: /mod/aa.units
textures pack: /mod/aa.textures
This way, it doesn't matter where the mods files are, they can use /mod if they want or not. It would be the mods/players responsibility to have the files properly located. But they would probably use the standard /mod.
- To start the game, execute
spring.exe -mod aa.mod
spring.exe -mod aa
spring.exe -aa.mod
Or whatever...
Spring would just look in the root folder for the file aa.mod and would interpret the instructions for the modifications. This would lead to a somewhat easy way of upgrading the functionalities of what could be interpreted by the mod interpreter while keeping old .mod files compatible.
I don't want to edit all my mod when I add a new map
then you can make more organised directories :
\map\common
\map\FinalFrontier
etc...
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
Yes, you are right. I should have been more explicit.
In the file named "aa.mod":
units_pack:/mod/AA/aa.units
textures_pack:/mod/AA/aa.textures
And,
I should have said:PauloMorfeo wrote:...
- Have .mod files in the root of TA::Spring, which are nothing more than text files where is writen something like this:
File named "AA"
units pack: /mod/aa.units
textures pack: /mod/aa.textures
...
In the file named "aa.mod":
units_pack:/mod/AA/aa.units
textures_pack:/mod/AA/aa.textures
And,
And here i should have said: "But they would probably use the standard /mod/xxx".PauloMorfeo wrote:...It would be the mods/players responsibility to have the files properly located. But they would probably use the standard /mod....