Multiple non-conflicting mods

[Marshall]

Copying is probably the best way to go as you say, the only reason I considered moving is because it is a lot quicker than copying.

[Marshall]

One main problem concerns me at this point:
People do not want to distribute audio.bag because it is a) large, and b) language-specific.
Has anyone got some detailed info on the bag/idx format and how to use it? Even then I'm not 100% sure that I could write the neccessary code. I would also like to be able to support ogg files as XCC does.

I would appreciate any assistance from anyone who is able and willing.

[DCoder]

I posted detailed info on those two formats back in my C-GEN forum a year or so ago I think writing the injector as a DLL would be a better idea so XRML or other programs can use it too. Heck, we'll be "learning" how to write DLLs and utilise them in our programs in Uni next month, so I might as well write a prog that does something useful instead of yet another useless bubble sort demo. You would know how to utilise a DLL, right?

[Marshall]

I believe so. That would be awesome.
What I would like to do is
On launching a mod, audio.bag/idx are extracted and "RA2\modname\sound\*.wav and *.ogg" are inserted into the bag/idx on a file per file basis.
Presumably there would be 2 significant DLL calls:
Insert file (in memory)
Save bag (to disk)

Getting the bag/idx out of langmd.mix in the first place, I would probably use the XCC MIX CLT, unless there's a more efficient way.

[DCoder]

Status report: reads/writes WAV data to BAG/IDX correctly. Including cases when a soundname that's already listed is added.
Now someone just needs to find a lightweight OGG>WAV converter...

[Bobingabout]

here's a question, can it also simply copy a pre-compiled bag and idx files?

[Marshall]

Already?! FanTastic.

When a filename is already listed, does it abort or does it replace the file? Either way is good.

I was thinking about the ogg side of things...
We don't actually need to be able to generate wavs from oggs on launch, rather, when the mod is installed. The point of ogg in this case is to reduce the filesize of downloads. I will try to find a CLT for this.

The only other thing from the sound side is that I'll need to extract audio.bag/idx. I plan to use the XCC MIX CLT for this.

Another note:
My plan is that the manager will not generate mix files as these should already be created by the author. If files are loose then loose they shall remain.
However, it would be nice for the install-maker I am working on to be able to generate mix files. Again, not sure how to go about this yet.

PS. New enhancements to interface:
Includes last updated date of mod, whether or not the Rock Patch is required and 2 [optional] sounds:
1 sound on displaying a mod's details, 1 on clicking launch.
Should the manager check if specific versions of the TX or RP are required for a mod? Or is it sufficient just to check that the TX/RP are present?

At Bobing: Yes, I will make it so the manager can handle a pre-compile bag/idx. Although note that this is only really useful for total conversions. And even then is less efficient in terms of filesize than the on-install compile.

[Bobingabout]

RP, check version, definitly, TX, i'd say also check version, but then you need some kind of version identifier on the TX.

although i can include .wav files to place in a /sounds subfolder, i would rather stick to .bag and .idx, as i plan to try and make our installer compatible with both stand alone and switcher (as people who would distribute an XCML file do)

which reminds me, you do plan to be able to decompress XCML data right? this will probably require the generation of .mix files.

[Marshall]

What do you mean by XCML data?

[DCoder]

When a filename is already listed, does it abort or does it replace the file? Either way is good.

It replaces, of course, if the modder actually included a replacement for ichratta.wav it would mean he actually wants the replacement to be used.

We don't actually need to be able to generate wavs from oggs on launch, rather, when the mod is installed.

Don't forget to notify the user if there is not enough space on the drive before decompressing, also a new BAG needs about 30 extra MB (I was greeted by XCC ML/C saying "Error activating mod." when I tried to run AR2 with only 10 MB free. Really useful... )

although i can include .wav files to place in a /sounds subfolder, i would rather stick to .bag and .idx, as i plan to try and make our installer compatible with both stand alone and switcher (as people who would distribute an XCML file do)

Why do you need a stand alone installer? I'm sure we can persuade Marshall into adding some extra features to his switcher

What do you mean by XCML data?

*.xmcf ? Which seem to be in Olaf's proprietary format... I don't think that is a priority/necessity.

[Marshall]

I will remember to check for sufficient space. I think there should be an extra safety margin of free space. Say, 500MB. Thoughts?

If you're talking about XCC Mod Creator launcher files (I think it's .xmlf), I wasn't planning on working with those. I've only ever used the executable launcher (which this program won't be handling either). The manager program (which still needs a proper name btw, open to suggestions) will be expecting loose files and/or mix files in appropriate subfolders.

The program will be designed to work so that if people use other launching methods (xcc executable, xcc launcher, or anything else) it won't jeopardise the working of this program.

With regard to installers, I think Bobing's point is that he wants to be able to distribute one installer that will work with or without the manager.
I will probably gear the install-maker I was working on to the manager only. For stand-alone installers, that's up to the author. Please note that you will be able to make your own installer without using my install-maker program, however you will need instructions on what and where you need to install (especially the content of the liblist.gam file)

With specific regard to Bobing's issue with distributing a complete audio.bag, maybe you can just distribute the audio files you need by incoporating DCoder's upcoming DLL into your installer.

If you want to detect if the manager program is installed or not it'll be difficult because I hadn't planned on making any registry entries for the program.
Ultimately, I hope that stand-alone installers will become obsolete.
I may consider including an option in the install-maker to bundle the Manager program with a mod installer - not sure what you think about that.

[Bobingabout]

olaf kindly modified for me XCC mod creator that compiles a program called bagbuilder, this is basicly mod creator, but when running the resultant program with the apropriate command compiles audio.bag and audio.idx for me.

if DCoder could provide me a program that converted all files in a sounds subdirectory to a bag and idx file, i could replace it, then the option for both standard install(dumping everything in the RA2 folder and compiling a bag) or new launcher folder(extracting files without creating a bag) would be possible.

and yes, that would mean i need information on how to install to the subfolder system.

I'll also have to speak to hunty about our mod control pannel. but it will probably not be needed unless they choose a stand alone install.

[Hunt7s]

As fasr as i am concerned, i can update our CP front end with their backend if needed, or simply just get rid as the uninstalled is built into my CP, and the disable is there as well, all ready for BOTH or ROTC choice in v3 wich i havnt shown you, but as said i can just get rid n not bother updating it.

[Bobingabout]

if you've put so much effort into our new CP, I'd rather not force us to not use it. as i said, probably stand alone.

[Marshall]

Progress update:
Attached are some images of how the interface is shaping up.
I will probably be including a 'check for updates' facility - as you can see from the interface design.

How will the update facility work?
1. Author specifies a url to an ini file. Program downloads and reads this ini file.
2. The ini file contains the "Previous Version", the "Latest Version", the "Update Download URL" and the "Full Download URL".
3. If the user already has the "Previous Version" or later, then the "Update Download" will be downloaded and executed. If the user has an earlier version, or the "Update Download URL" is not specified, then the "Full Download" will be downloaded and executed.

On clicking 'Tools > Check For Updates', the program will check for updates to all installed mods and display them in the grid. The user can then select an update to download or cancel and return to the main screen.


Questions:
In order for people to detect the presence of the program, I am thinking about including a single registry entry to identify the program's location. This entry will be maintained by the program - every time the program loads it will update the registry with the location of the program. This way, the user can wipe their registry without breaking the program.

This also begs the question of whether or not mods [subfolders] should be installed to the program's directory, or the Red Alert 2 directory?