Renegade Projects Network Forums

No worries - just as and when you can. In the meantime I will try to get to work on the update-only installer generator.

FinalAlert 2 mods will just have to go with not using any encryption.
I should make a note of this in the LBMC documentation.

DCoder, could you possibly give us a summary of the two encryption methods - what they're called, how they work, what they ultimately achieve. I don't need anything long and technical, just a short overview for the help files. Thanks.

== MIX Protection Methods ==
At the moment there are two methods to protect your MIX files:

1. LeechKiller method (developed in June 2005 by Saberhawk)
   
2. (working title) MIX Scramble (developed in October/November 2006 by DCoder).

=== Purpose ===
They both make your MIXes unreadable by any XCC tools or tools using their MIX reading code, such as FinalSun/FinalAlert, while retaining their compatibility with both TS/FS and RA2/YR. The reasons for or against using these encryption methods are beyond the scope of this document. Their internal working methods are related to the MIX format and XCC's LMD. Allow me not to disclose those exact methods, since an intelligent person armed with a simple hex-editor and MIX format documentation can already reverse engineer them with little difficulty. The reason they work is because the game is more lenient with MIX loading than XCC code is.

=== Caveats ===
As said, these methods work because the game is more lenient with MIX loading than XCC code is. Furthermore, both methods use the same technique with different levels of, err, "aggression". Therefore, should XCC one day update its code to fully match the method used by the games themselves, neither method will protect the MIXes successfully.

== Appendix A: Caveats caused by the MIX format itself ==
The MIX format doesn't pack the file contents, therefore anyone with a hex editor can see the plain INI codes in the MIXes. It is certainly not impossible to determine the internal identifiers the graphics assets have, and from there it is short work to write custom INI code addressing those identifiers, distribute it with your (encrypted or not) MIX file, and have it work.

Thanks DCoder, most helpful.

Attached is an example image of the Check For Updates facility in action.

New feature: On the Tools tab, programs that allow command line switches can have a text box to allow the user to input such swiches in Launch Base.

How does launch base handle files that the game generates itself as part of playing a mod, but that might not be compatible between mods. The main things I'd think of would be save games and sed files for random maps.

Good point Blade. At present, saves and seeds are left as they are, but screenshots and ipb videos are moved and renamed.
I will make Launch Base handle saves for sure.
However seeds are often compatible between mods so they should probably be left alone.

you are forgetting about mods that include new tech structures on the map. these new tech structures would make them incompatable. also, don't forget TCs.

compatible, god damnit

However many mods do have compatible seeds. I could add another option to the mod that tells LB whether or not it produces standard rmg seeds. LB will then copy in and out the seeds as appropriate. This will mean the <.sed> filenames will have to be renamed using an internal numbering system, rather than by the user.

It is now possible to include a mod with an empty version number. This means that only the most basic files (info, banner image, display sound, and possibly the manual) are included. The mod files themselves are not included so you have to 'check for updates' in order to download the mod.
This will mainly be used by me for including with the standard Launch Base installation, things like the LB Mod Creator, UMP, YR map packs, YRPM, RA2YR Clean Up (and possibly the TX and RP too). They aren't actually forced upon you if you don't need/want them, but you don't have to go hunting for the LB-installers for these things if you do want them.

LB currently has three skins. Two of these are crappy looking windows grey skins that are almost identical. The third is one I have just finished making. Attached is a preview.

The horizontal lines in the background of the text are problematic, apart from that, fine.
However, what's that icon you're using there?

Oh, and post the necessary information to create a skin, so I can try to come up with one.

Idea for your installer:
add a "packs" support
Under word "Pack" I mean YR expansions (but not mods)
a lot of  packs can be installed to one game
pack can have dependences from another.
for example: someone create a map pack, but maps need TX,
another packet.

Renegade Wrote:The horizontal lines in the background of the text are problematic, apart from that, fine. Smile

The image is a jpg so that makes it a bit less clear. If the lines are problematic I can darken the background.

Renegade Wrote:However, what's that icon you're using there?

It is a temporary icon that will be replaced. It was going to be the Yuri Rocket Pad but it doesn't work very well. I will probably use an image if a floppy disk on fire unless I can come up with anything better.

Renegade Wrote:Oh, and post the necessary information to create a skin, so I can try to come up with one.

I thought I'd already provided that above somewhere?
There are 4 images - one for each tab. The zip file includes a sample skin. I need to provide a screenshot of the program on each tab so that you can see the position of the controls.
Some text colours can be controlled by skin.ini (see the sample skin).
Image format should be bitmap (any colour depth), although I can probably make the skins support jpeg too if neccessary.

CnCVK Wrote:Idea for your installer:
add a "packs" support
Under word "Pack" I mean YR expansions (but not mods)
a lot of packs can be installed to one game
pack can have dependences from another.
for example: someone create a map pack, but maps need TX,
another packet.

The 'Plugins' tab is for things like the TX, RockPatch, map packs, etc.
However, I hadn't implemented any prerequisites for these because the plugins were the prerequisites. The only example I can think of where this would be neccessary is a TX map pack requiring the TX. The current method of dealing with this is all maps having *TX* in the name - I think this is probably sufficient.

Quote:However, I hadn't implemented any prerequisites for these because the plugins were the prerequisites. The only example I can think of where this would be neccessary is a TX map pack requiring the TX. The current method of dealing with this is all maps having *TX* in the name - I think this is probably sufficient.

I think that you should do a prerequisites system

I am open to suggestions and will implement a prerequisite system for the plugins if it is neccessary, but: Why do you think it is needed?