I see Lou. Well, at the moment FW 1.65 (the current version) causes problems for some people on uninstall. FW 1.66, because of how much we have put into it, will be even more problematic on this front. But I am working on a solution that might be able to by pass this whole problem, enabling FW 1.66 to be installed but will not interfer with the opertion of Freelancer so other mods can also be loaded from the one copy. I don't know fully yet if it will work, but we shall see, early days yet.

One thing you can try.. a split-install where the bulk of your content files (cmp, thn, etc) are installed to a uniquely named folder in the game dir (something that will not conflict with anything else and is designed to stay there). The second part of the install is a FLMM package that contains all your xml scripting and ini files that when activated will link to the permanent content in the game folder.

You can use a single installer to accomplish both, I use Inno Setup myself. Although I have only mentioned a brief idea on how to make it work, properly developed this could be a desireable solution for large mod projects.

Actually, that was the same thinking I was having. By having the majority pre-installed into the Freelancer directory in different locations to the Freelancer files and then have an FLMM install which was only the basic stuff (exe with v number change, the freelancer.ini file etc...) then it would get around all these issues in one sweep. In addition to this, it would also be far, far quicker when installing and uninstalling the mod via FLMM and should make it more compactable with other mods being activated and deactivated. It is probably an idea for most big mods to function like this, we just need to ensure that the big mods don't install their files in the Freelancer directory to the same place (this could be easily done with say, for example, all Freeworlds files carrying the prefix fw_ then as long as no other mod uses that prefix, they should sit well together).

Also, another thing on this point, it would actually probably save space on peoples Hard Disk Drives, because the bulk of the files are only installed once, to their own directory in Freelancer, rather than being installed to two locations when the mod installed (once in FLMM and once in Freelancer).

This is also an alternative to requiring people to have dedicated copies of the game for various mods. I will work on a sample ISS script for Inno Setup to make this easier for mod makers.

That would be fantastic Lou. If you need a hand with at all, let me know. The advantage of this for big mods like Freeworlds (and the other biggun's out there) will be astronomical... no more 3 minutes activations for a start... plus the other advantages (like being more compactable with other mods).

What I am thinking of is making a sub folder in the data folder that will contain all of a mods permanent content. So for Freeworlds it would be 'Data\Freeworlds'. For those wanting to use this system they have to build their mods with this in mind so they are not getting confused about where the files will be linked to.

The content that will be permanent will be limited to the following file types: model related - cmp, 3db, sph, sur, txm, and mat; scene/animation related - ale and thn; images - tga and bmp; sound files - wav and utf; video files - avi and wmv.

All ini, dll, and exe files will be included in the FLMM portion of the package.

Because of the way this will be set up the name of the folder used for the permanent content and the FLMM folder must remain static, not released with version numbers in the name. All future updates must be installed over the existing versions, if necessary the installer can be set up to delete specific files as a part of a version update.

Surely a large number of the ini files could also be pre-installed. Things like room, base, system ini's can be pre-installed because the universe.ini defines the path for Freelancer to read for those. Indeed, the Freelancer.ini also defines where most ini files are contained. This would save even on space.

Dll wise as well, could not the DLL's be renamed to say fwinfocards and the Freelancer.ini set up to find it that way.

In this sense, 98% of the mod could be preinstalled. The only files you would need FLMM to operate with would be the EXE (for version number), XML and the Freelancer.ini file.

Sure.. if you want to make it 20 times harder for anyong using this system. INI, DLL, and EXE files are no biggy for FLMM so they should stay grouped together.

My little project will be delayed a bit since I'm having computer trouble and I am too worn out from work and little sleep to fix it right now.

DLL's are one of those that is sticking a little sometimes on large Mod removal (or is that just my experience). As someone mentioned above, they have even seen DLL's stay put after a Freelancer uninstall.

Perhaps it is just me and I am on a mission now to see how much space on a HDD a large mod can save (even the small ini files, every bit counts) and speed up activation and deactivation of a mod. Personally, I don't see how much harder it will be for those with the mod knowledge to create, say two pseudo-directories inside the DATA and EXE directory and move everything in their mod up one level. For example, the current tree path to the Bastion ini in Freeworlds is DATA\UNIVERSE\SYSTEMS\BAST\BAST.INI but in this new version, we could change this to DATA\FW_DATA\UNIVERSE\SYSTEMS\BAST\BAST.INI. All it would mean is spending a day going through all the ini files and adding FWDATA\ in front of every line looking for that particular data. Considering I would have to do this for probably over 500 model entries in Freeworlds (if you count where some models like the ISD's are repeated as Weapon Defence Platforms, Stations and flyable player and NPC ships), to do it for the couple of hundred INI files as well is going to make no difference to myself. Off course, with a system like this, it is down to the individual mod makers as to how much you store in a pre-installed directory and how much you store in the FLMod side. And as noted, patching a mod will be some what more streamlined as you could just create patches to activate via Mod Manager without the need for activating a main mod first.

Take your time on it though Lou, it is no immediate rush for it and I understand that RL comes first. I appreciate your efforts to crack this, as this will mean bigger mods in the future will have an alternate system that is going to be not only of benefit to them, but to anyone using Freelancer and wishing to use other mods without having to reinstall Freelancer every single time.

I will be thinking about what the best solution will be.

Try Visual Patch. We use it for the Asylum51 mod and it works great! It's pricy but not as pricy as some others.
Just search for it on the net. It can use it's own scripting language so you can have it delete stuff like the FLMM Exe to prevent tampering....did I type that? Sorry.

It will require a separate install of freelancer for just your mod and you will lose about half your players in the process because they will refuse to use it.

Better DDS all your ship mat files and just get rid of the ships that won't allow you to DDS them.



Glock36
"No Comment"

Glock, we are working on making it so that mods will never require their own copy of the game again. That was why I linked you here

I am working on adapting Freeworlds over at the moment to this new system. It is not that hard to do, the biggest issue comes if you are transferring ini files (like I want to do) because you have to go into each and every system file and alter those, but beyond that, I would altering the shiparch.ini and solararch.ini easy any thing. There are a few ini files I am unsure as to where they are defined, but that's ok because they can just be left in the FLMM side of things.

@ Glock, this new system is for larger mods. It will mean the following:

A) Big Mods will no longer need they own install of Freelancer because they stop other mods from activating after they have been used. Instead, the majority of their information is pre-installed in their own unique directories (for example, freeworlds will be using directories labelled fw_data, fw_exe etc.... I'd imagine other mods could create simalar labelling as long as the big mods ensure that they don't label their mods the same way (Tides of War for example, if it grows that big, could be tow_data, The Next Generation might be tng_data, Evo Mod might evo_data)).

Less Hard Disk Drive Space is required to store the mod when it is activated (for example, when you activate a mod that is 300meg (uncompressed) that is ~600meg the mod is asking for in TC mods, 300meg for it's original directory and the ~300meg extra it is taking up in the Freelancer directory when activated. Now it would only ask for about 310meg in total when activated (because the FLMM side would only be about ~10meg, the rest is pre-installed).

C) Quicker Activation and Deactivation of the mod. Take Freeworlds at the moment. Our current test mod for 1.66 takes ~3-4 minutes to activate on a 3.04ghz machine. With the pre-installer, the same mod will take seconds as only ~10meg worth of files will need to be transferred by FLMM.

D) Patches will be easier to apply. Instead of activating the mod and then activating another 'mod' patch on top in FLMM, Patches for big mods can be written so that players will only need to activate the patch.

E) Cleaner activation of larger mods, because most of the files don't need to be copied over to Freelancer each time, just a few.

These are just some of the benefits we are looking at with this kind of system. It is not meant for smaller mods, just the larger ones which are hitting over the 100meg compressed mark.


EDIT: And yes, we are DDSing our ships as well, but even with that, bearing in mind the complete station change over with modular station in 1.66, we are still going to be having quite a large mod.

Edited by - Aldebaran28 on 8/5/2005 10:21:05 AM

Ok the example installer package is ready, the first version of it anyway.

Things to know:

All the permanent data needs to go in the second subfolder (it must match the ModFolder entry in the .iss file). Your final path to your permanent data will be Data\<ModFolder>\ (without the < > obviously).

The rest of the mod goes in the FLMM folder. Your readme, changelog, and license files go in this folder as well and you just put in the filenames in the appropriate spot in the .iss file.

Most importantly! You need to download the Inno Setup QuickStart Pack from the following website: http://www.jrsoftware.org/isdl.php

This installer is designed with an uninstaller to remove the mod if anyong so chooses to do so. The link to it is in the Start Menu along with a game launching icon (that you can add commandline options to preload servers running your mod).

The installer is designed so that you only need to customize the first section of the .iss file to fit your mod, the rest is entirely automated. I wouldn't recommend trying to change anything in the code unless you know what you are doing.

So Download Now!

@Aldeberan28 - Your item D is incorrect, patches should be installed using this same installer package but only including the updated files. The script is designed specifically to append/overwrite to the existing install (if it exists), just remember to rename the installer file to add '-patch' to the name.

Edited by - Louva-Deus on 8/5/2005 6:41:51 PM