Multiple non-conflicting mods

[Marshall]

I might be able to work on a new system for mods that was independent of the Rock Patch - a program that worked pretty much as I described, but actually copied/moved the appropriate modfiles into the ra2 folder, and then removed them afterwards.

I would of course have to majorly rewrite the MIM.

Something of a dream perhaps, but what about this:
A mod selector, with built in Clean Up and YRPM - one program to control everything.

[Bobingabout]

I don't use YRPM, but it sounds like a good project.

only problem i have is with taunt files. what if a mod replaces taunts? (i don't think R:ROTC will, atleast not for a while, but we replaced yuricountry with yuri prime, and added yuri elite, yuricountry is a different "Hero" country that will be in a different position.)

[Hunt7s]

Reading about the mod choosing system, i much prefer the idea of the HL2 method, of a "Steam" type sytem, and a read the mod files from the relevent folder. This would pose the most work, as RP would have to be extended to a sence that it must load files form extended folder structures, not just the same folder as the exe.

So...

As you said the other way to look at it would be a progrma that would move about the files for the user, so they didnt have to understand what files there should be and what there shouldnt be for one of the mods to work. This is really what my mod loading program does... if you choose disable, then it changes all our mod files extensions to .rotc. Thus making it disabled, But can be easily differenciated from the other files within the folder.
A naming structure, or a naming ini file to store the relevent file tables, disabled extensions / folder to move to and from, can be writen to by a custom installer for the mods.

if this makes sence to people.

ps: i think i have found some info for a folder content moval, but notn really got an idea to remember what has been moved, to allow it to be removed after the game has ended.

[Renegade]

Isn't the source of Olaf's progs mostly open?
Couldn't we expand XCML to have this functionality, instead of trying to replace it?

[Marshall]

It's probably easier to write something new from scratch - if it is to control all installed mods. Although, the audio.bag/idx thing would be useful.

[Renegade]

But the point is, if you're trying to convince dozens of mods to switch systems, while theirs work just fine, you'll be looking at a hard time. Why would they help you help other people to play mods other than their own?
If the new system is integrated in a new version of XCML, all you have to do is say "Hey, did you know there's a new version of Mod Launcher available?"

Given that mods can be exported as .xmlf files to be read by Mod Launcher already, I imagine all it'd have to be is that, on startup, Mod Launcher (i.e. any .exe generated by Mod Creator) checks for .xmlf files in the RA2 folder. If it finds some, it gives a prompt like

"Mod Launcher has detected more mods than the currently selected in your RA2 folder. Would you like to select a different one from a list?
[ ] Don't show me this again"

All mods would and could still use the old .exe based system, but it'd be only one change in drop-down options to create an additional, user-friendly .xmlf that makes their mod easily managable with others.

So, what do you think is more likely to work:
- "We're trying to push a new RA2YR mod installation system; would you please abandon all you have and use our system? kthxbye" or
- "Hey, just in cases you wanted to update, there's a new version of Mod Launcher out. Oh, and when you package your mod next time, could you also release an .xmlf file for it? It's just two options down and it's soooo much easier to manage.... thank you."

?

[Bobingabout]

since an XMLF file contains everything needed to create the mod, i don't see why you can't intergrate XMLF into the new launcher system. just add an extra feature that the mod file can also be in folders, this new mod launcher could then be added into yuri.lcf and ra2md.lcf to open a menu every time you run YR that asks you what mod you want enabled.

encorperate marshals cleanup program to restore original YR once done, and bingo.

I'd still like to include mod subfolders, for those mods not using mod launcher. basicly, it copies the entire contents of that folder into your RA2 folder, then removes it with cleanup if you select a different mod or raw YR. i supose this doesn't have to be limited to YR, but could also work with RA2.

i think i've thought up a way to determine if mods are installed in subfolders or not. have some kind of keyfile, with the same name as the mod folder, which is basicly some kind of ini, which lists the name of the mod, and the name of the folder it is stored in, but it has some unique file extention that the new launcher looks for. an idea for the file extentions could be YRM meaning "Yuri's Revenge Mod keyfile". Tags in this special ini could be, using an example of "ROTC.YRM": "ModName="Revolution: Retaliation of the Civilians" and "ModFolder=ROTC"

i supose the complexity is all in the organisation. for example, all XMLF files and keyfiles can be in a specially named folder, that the new mod launcher looks in to see what is installed. maybe call the folder "New Mod Launcher Files". all you need is a readme file, although no noobs ever seem to read them...

summery. a new mod launcher, to be embedded into YR launching, by editing the LCF files, encorperating marshalls cleanup program, that will install and remove a mod, capable of using mod launcher XMLF files, and raw mods in subfolders, using a keyfile.

sounds good to me.

also note, the keyfiles could hold a special tag (UsesTX=yes), that can add in special enables, such as the TX.

[Marshall]

Whilst I understand Renegade's point about convincing authors to switch systems, I think the effort would be worth it.

I've also recently been working on the whole 'final alert 2 integration' problem, and how to manage multiple mods with that.

I have already started working on a new program that would scan all subfolders for a liblist.gam file (much like in Half-Life 1), which lists the details of a mod.
The subfolder would also contain all the appropriate mod files too, including a Taunts folder if applicable (containing new/replacement taunts), and mod documentation (if any).

Now, people can create installers for this subfolder however they see fit, and the Mod Manager program takes care of the rest.
The Mod Install-Maker I am working on will be geared to this new system and will provide a gui for creating executable installers with ease.
Anyone willing to create and distribute an xmlf file are most likely willing to support this new system.

Now, the Mod Manager program itself will list all Mods and (here's the clever part) also list Plugins (like the TX, YR map packs, Assault maps, Rock Patch, etc) and FA2YR Mods.
When the user selects one of the above, it's details are displayed along with a 'View Manual' button and a 'Launch Mod / Install Plugin / Uninstall Plugin' button as appropriate.

On Launching a Mod, residual modfiles can be temporarily moved to a backup folder, the Mod files moved into the RA2 folder, the game launched, and when the game finishes, remove the mod and restore the original files. This will allow seamless integration with existing methods.

Attached is an example image of the program I am working on. Please note that this was knocked up quite quickly in order to test the liblist.gam scanning, it does not neccessarily reflect the final interface.

PS. This also has the potential to be extended to include an internet lookup for up-to-date versions of installed mods.

[Bobingabout]

cool, a nice start.

[DCoder]

One thing to note, Ren, people stick with older versions of XCC MC/L because the new ones have certain bugs. On the other hand, MC/L performance is inversely proportional to the size of the mod, mods exceeding ~20MB lag the system when launched via MC/L and work fine when launched otherwise.

Marshall: Nice. What happens if this manager crashes (ie, hard reboot) in the middle of a game? Will the manager detect that on next load (ie. by creating a game.lock file when started and deleting it when shutting down) and suggest a cleanup? Remembering certain mods such as DZ, which patch core files, will it offer something like "Insert your YR cd to restore certain files that this mod has changed"?

[Marshall]

An interesting point DCoder,

At present, I don't actually know how to launch RA2MD.exe and then wait for GAMEMD.exe to close, although I can probably figure such a thing out.
As for what to do in the event the files are not restored, your suggestion seems like a good way to go. If the program stores removed files in it's own backup folder, then on launch of the program it will detect that these files are present and restore them then. Such an event should of course be documented in the program's documentation.

Patched files are more tricky, because I don't know what files are patched. So far for the Clean Up program, I have assumed that langmd.mix is the only file modified and is only modified by DeeZire AND an appropriate backup exists. I would probably go on the same assumptions here.
The only other patched file I am aware of is gamemd.exe. I am hoping to have this program replace the Rock Patch installer, by having users only download the latest patch file and letting the Mod Manager control whether or not the Rock Patch is installed. [I will also write a small program for pd to generate the patch file so that he can upload it without having to wait for me to generate the installer.]

[DCoder]

To wait for gamemd, you should use WaitForSingleObject, eg: http://vb-helper.com/howto_shell_wait.html

Calculating CRC32 on the main mix/exe files takes just a few seconds, you could do that to determine if any of them have been modified. But storing backups of them is not necessary, since the user is bound to have them on his install media (albeit some of the core files are compressed).

(P.S.)

[Renegade]

While I still see the problem of wide-spread adoption (it being "worth the effort" doesn't mean people will obey thy word), especially in regard to audio.bag/idx modification, I have to admit what you plan sounds good.

About D's post: I would imagine restoring game files from installation media when they are most likely 1.001 modified versions could cause some problems...

[Marshall]

DCoder: I am familiar with that code, however it does not help with the problem of running ra2md and then waiting for gamemd to stop, because i don't have a process id for gamemd. Unless ra2md remains running until YR closes - haven't looked into that yet.

With regard to patched files, I am not aware of any relevant changes other than those to gamemd.exe or langmd.mix
I can't make a backup of a file after it has been changed, and restoring from the CD has the 1.001 problem
langmd and gamemd I can handle by checking the files for originality and restoring backups where appropriate. If there are problems because of unforseen third part interactions then the ra2 folder can be left untouched and an error message presented.
Any other files I'll need to know about, but most file changes shouldn't affect the introduction of new mod files.

[Bobingabout]

I've missed a bit of the convo, but the reason i sugested copying files, not moveing them, is incase of hard reset, therefore instead of trying to put it back, just run the cleanup program to delete any mod files, then you can re-apply the mod from the subfolder.

development work? well, obviously, anyone doing dev work can place their entire mod in 1 of these subfolders, its easier to find files, and cleanup won't delete any of your hard work.