Multiple non-conflicting mods

[Bobingabout]

looks good.

hunty, want to try to intergrate the online update thing in our CP?
want to even use the online update thing? i think its a good idea. update, not so sure about, but the download new version would be good.

[DCoder]

Those tabs look ... fugly, the rest is great.

(I will put the dll and a sample frontend up here sometime this week, damn persistent bug refuses to be fixed.)

[Renegade]

What if a mod doesn't have an update version?

Like, Current is 0.4, Previous is 0.3, I have 0.3, but there is no update url saved, because there is no update.
Will it automatically take the full download, or will it go into meditation and shoot itself?

[Marshall]

Those tabs look ... fugly, the rest is great.

Can you elaborate on why you don't like the tabs and what you would suggest to improve/replace them?

What if a mod doesn't have an update version?

...or the "Update Download URL" is not specified, then the "Full Download" will be downloaded and executed.

[DCoder]

Sorry, I didn't mean the concept of tabs, I meant the way they're drawn. They look like something from Win 3.1...

Word 6.0 (above) vs Word 95 (below), from User Interface Hall of Shame.

I realise that this might be just one more of the things VB imposes on you, but they still are ... not pretty.

[Marshall]

I see what you mean. I'll see what I can do about that.

[Marshall]

Question about plugins:

Traditionally, plugin installers have been handled by me or had no conflict issues (TX, RP, YR maps, Assault maps)

I am presently working on the Install-Maker program for the mod manager [I am planning on calling the mod manager "YR Launch Base" unless anyone has any better suggestions].

One user setting is 'Mod Type', for which the value can be "Mod", "Plugin", or "FA2 Mod".

With this program, the TX guys, for example, can be responsible for their own Launch Base installer by choosing 'Plugin'.

The problem with this is, a non-TX person could easily make and distribute their own TX plugin under the name of the original. It would confuse users and Launch Base could assume that this was THE TX for prerequisite purposes.

Solutions:
A) Password system so that only authorised users can create Plugins.
B) Plugins can only be created by Marshall. Plugins option unavailable from Installer-Maker.
C) Trust everyone in the community to do the right thing.

Without the install-maker, people could easily see how the TX is installed and create their own installer anyway, just like they can already, so maybe I'm just worrying too much. I think 'C' is probably okay.

Opinions?

Also, attached are some screen shots of the install-maker program as it looks at the moment. [Btw, DCoder, I haven't found a way around the tabs issue yet - I wonder if the tabs look different between ME and XP?]

[Nighthawk]

Looks good, but I wouldn't personally go for option C, there are still quite a few gits around the community that would jump at the chance to take credit for a major mod or project like the TX. I would go for A, I'm assuming it would let the plugin creator password protect the plugin so only they can view install info and edit it, anyone who doesn't have the password could only install / uninstall it.

[FS-21]

What about an incompatible plugin list for mods? a TC mod can be incompatible with official YR maps, Assault maps etc
And a list of optional "mod plugins" (optional plugins that only works with a specific mod but aren't required to play) ?
Will to be possible to install "manually" multiple versions of the same mod?

[Bobingabout]

like the survivor map pack, its not required, but R:ROTC can use it. R:ROTC is not compatible with assault map packs(having it won't harm anything though). i could dig up and fix the survivor map pack i have if you want, the project apears to have been abandoned.

[Marshall]

The problem with option A is that a password system is quite difficult to implement and ultimately doesn't help - anyone can create an installer without using this program (this program just makes it easier).
The setup of the TX itself within Launch Base is not a single, self contained file, but essentially the extracted mod files held on standby for transfer to the RA2 folder.

My plan for Plugins is that they can be either active or available (not active). Mods can specify what version of the TX and/or Rock Patch plugins are required, other than that it is assumed that a plugin will be acceptable to any mod (YR maps, Assault maps, etc). Multiple plugins can therefore be active simultaneously (whereas only one mod can be active at a time).

It would be possible for multiple versions of a mod to be available, although the install-maker is designed to detect and overwrite older versions of the same mod. The author can force separate installations by changing the installation directory, but users cannot do this at install time.
Users can, if they want, rename the mod's folder [after installation] in order to keep an older version alongside a newer version - this would stop a new installer from detecting the mod.

Some of what I have discussed may seem slightly complicated, but should become clear when the two programs are released.

Right now, my main concern is with how to handle plugins. Because the files of a mod/plugin are laid bare within the mod's folder, there is no security to prevent malicious replacement of the TX. The only real way I can see is to put the TX into a special unique system (such as a self contained, password protected file) This would almost certainly require myself to continue to generate the TX installer on behalf of the TX team.

[DCoder]

The tab style issue could also be VB-version dependant, I'm not sure. Or, if you have time to spare, you could make them OwnerDrawn...

As for fake TX, you could come up with function magicKey(plugin official name, version, secret phrase, size, archive md5) that generates a magic key (one way generation, preferably), then the mod's information file could contain a line "Auth=<magic key>" and when multiple mods have the same official name, the ones with valid Auth should get priority over non-properly-Auth'd ones, with possibly some visual identification. Authors of plugins wanting to get the magic key would just contact you with that information, and you would send them the key. (Imperatively, this should require your action, and not be a simple generator function in the Install-Maker, for obvious reasons.) Granted, this requires some small work on both your and the author's part, but it prevents people tampering with official releases, doesn't limit who can create plugins, and visual identification of Auth'd mods gives users a sense of trust and security. Just need to come up with a safe way to generate the Auth.
Although this process is interceptable with a debugger, if you can use a debugger to that extent, you deserve to get the reward.

[Marshall]

Sounds good. However, I would have to receive the plugin's file archive in order to caluculate the md5 which would mean a very slow turn around for plugin authors to be able to realease updates.

I could provide a separate auth generator program to resolve this - I would only provide it to authorised authors. The problem would be if it were leaked somehow. I suppose the plugin author could send me the md5 - although this has to be generated from multiple individual files, not a single archive file.

One other problem is that I don't know how to generate an md5 or the subsequent auth key. Although I'm sure I can research this.

[DCoder]

How to Calculate MD5 in VB
On the author side, Total Commander can calculate MD5 sums, WinRAR can calculate CRC32 checksums, etc.
As for Auth, there are infinite ways to create that, most logically it should be one or more MD5/CRC32/etc hashes (eg, combine arguments into one string in a certain way, split that string into chunks, and get hashes of each chunk in reverse order).

[Marshall]

Thanks for that DCoder.

My next request for input is regarding packaging and deployment of mods: how should this be done?


Deployment: (Launch Base)
Should the mod folder contain a "modfiles" folder that just lumps everything together - the entire content of the folder is just copied to the RA2 folder (with certain restrictions of course) ?

Should the mod folder contain several folders: ini, cameo, shp, hva, vxl, etc...
which are A) all copied as is to the RA2 folder
or B) compiled into appropriate mix files (like XCC Mod Launcher).


Packaging: (the install-maker)
The install-maker will have several folders in a similar layout to XCC Mod Creator. Should the files just be installed as is to the specified folders or should they be compiled into appropriate mix files (like XCC Mod Creator) ?


And finally, if any mix file generation is required then I'm going to need something like DCoder's audio.bag/idx dll but for mix files. I wonder if DCoder would be able to offer his skills once more or if I'm making too many cheeky requests. I also haven't broached the subject of CSF files yet...