Important Message

You are browsing the archived Lancers Reactor forums. You cannot register or login.
The content may be outdated and links may not be functional.


To get the latest in Freelancer news, mods, modding and downloads, go to
The-Starport

A Different approach to adding mods?

The general place to discuss MOD''ing Freelancer!

Post Mon May 16, 2005 9:53 am

A Different approach to adding mods?

Sure FLMM is nice. But do we really need to edit the ini files themselves?

I've been playing around with adding custom ini files and defining them in freelancer.ini

I added a file called extra_market.ini and defined it in freelancer.ini, i changed what was at manhattan using the new ini acting like market_misc.ini

Whatever was in my new ini was the visible market info. Defining the same base in both market_misc and extra_market diddnt cause a problem. It took the data from the ini file which was defined last in freelancer.ini

I'm going to play around adding mods in this way.

Surely it would be better to be able to add mods simply by adding new ini files rather than editing the existing ones.

I'm assuming someone must have tried this before. If so, why arent mods distributed in this way?

Post Mon May 16, 2005 10:47 am

The only problem with this is that some mods requre that we edit the origional INI files. Even the cruse mod, increasing it's speed, requires an edit to the origional INI files. I have no doubt you can add new market places, etc., by adding new INI files but when it comes down to it, even those will have to be referenced in the origional INI files. So why not just modify them to begin with?

Anyway, you might have come up with something different than what I'm thinking. In the long run, it might make it possible to have two mods active at the same time when the would have conflicted before. But to a modder that really isn't a concern as we would rather our mods be run the way they were designed to be, by themselves. Unless our mods are designed to be active with other mods, refering to the speed hacks again. But whatever, if you think it's a better way then by all means try it out and see what happens. You may be on to something. I have my doubts though.

~Jay~

I've just had the most disturbing encounter with a mad woman on the Holodeck. - Holographic Doc

Post Mon May 16, 2005 12:47 pm

The problem with that is that not all the files are referenced in freelancer.ini. The location of files such as the NPC ship files are hardcoded in the DLL's - content.dll in fact. This means you can only ever have one npcships.ini unless you want to try editing the executable code.

Post Mon May 16, 2005 3:37 pm

That's true. But for adding ships and equipment, surely this way makes more sense? You could easily have a ship pack which involves just copying and pasting files and adding a couple of lines to freelancer.ini

Maybe it's because i'm used to OO programming but it makes more sense to me not to edit the original files unless you have to.

Post Mon May 16, 2005 4:58 pm

I've been working with the "new file" concept for a while too, and it DOES offer possibilities for clean extension that people simply haven't exploited enough; however, it also has limits. Some paths are still apparently hardcoded in the binaries.

The real reason why everyone uses FLMM is that it's basically been the best all-around tool for this job that allows some degree of interaction between mods. It's still bloody ugly to work with for some problems because it is does "simple" exploiting of Freelancer's text-file-based data sources. It has now become the de facto standard because it generally "just works".

There definitely are some better ways to do this. You're exploring one that really could USE exploration. Another one is Bas Westerbaan's Intrepid.Corelib library that parses "ini" files and returns an abstract structure which can be updated on the fly.

The ultimate answer would be a project to actually treat the INI files as a database with real records and links. Datastorm does this in a weak way (the "datastorm.fl" file it creates is really just a simple Access database - unfortunately with no heavy link-creation done...). A 'real' tool could produce a reference Freelancer database, then apply mods as sets of database updates - with the ability to roll back directly from the transactions list. Of course it would still need to generate the ini files from itself when mod sets are applied, but it would bring us very close to a situation where mods could really be thought of in terms of objects - systems, bases, equipment, ships - without having to worry about careful insertion of all the crossreferences everywhere.

Post Mon May 16, 2005 5:34 pm

WatercoolerWarrior, that is a very nice idea. Of course it's a lot of work too.

The main advantage i can see to adding new ini files is that you could chain up mods.

Imagine 2 ship packs. They both need to edit shiparch.ini, market_ships.ini they could each have their own ini files. The only file they would both need to change is freelancer.ini even if the ships are sold at the same base the marketgood sections get added from each ini file referenced.

This would make adding and removing equipment mods as easy as commenting out lines in freelancer.ini but as you point out some things are unfortunatly hardcoded.

By my reckoning (although untested) you could add the following things without editing any file other than freelancer.ini

-Ships
-Weapons
-Commodites
-Universe

I'm going to see if i can change constants.ini values with the addition of a file too.

edit: Success. By adding another constants entry in freelancer.ini i changed the cruising speed by another file.

Edited by - TheJkWhoSaysNi on 5/16/2005 6:39:02 PM

Post Tue May 17, 2005 6:06 am

I've been playing around some more and the files dont even have to be in the correct folders.

I have converted 2 mods to work in this way. Flyable osiris (buyable at manhattan) and the cruise speed 1200 mod.

My directory structure is this:

DATA\MODS\osiris\ships\shiparch.ini
DATA\MODS\osiris\equipment\market_ships.ini
...etc...
DATA\MODS\cruise1200\constants.ini

All these files contain are the additions to the current files. Not new copies of all the ini files, just the mods. The directory structure doesnt actually matter. Infact all the market stuff can go in one file, all the equipment in another. I kept it like this for the sake of continuity.

My freelancer.ini is set up like this:

in the [data section:
<pre><font size=1 face=Courier>
;##############################################################################################
;Mods

;Osiris Mod
equipment = mods\osiris\equipment\st_equip.ini
equipment = mods\osiris\equipment\weapon_equip.ini
ships = mods\osiris\ships\shiparch.ini
goods = mods\osiris\equipment\goods.ini ;all the goods could go in the same file
goods = mods\osiris\equipment\st_good.ini
goods = mods\osiris\equipment\weapon_good.ini
markets = mods\osiris\equipment\market_misc.ini
markets = mods\osiris\equipment\market_ships.ini


;fast cruise speed
constants = mods\cruise1200\constants.ini

;##############################################################################################

</font></pre>


Is this method not a hell of a lot neater than modifying the original files every time?

A lot of mods could be done like this and they would all work together.

These are the things that cant be done in this way:
-Info cards
-HUD
-Random missions


Theres probably a lot more, but dont you think this method is a lot better for mods which add to the game?

Post Tue May 17, 2005 5:57 pm

Um... at the risk of sounding pretentious...

While this idea has some merit, it's not a panacea, and I'm not sure it gives us any advantages over what we can do with XML/FLMM.

Take, for example, your adding ships issue. If you make mods with properly modular XML/FLMM scripts, you could add ship mod on top of ship mod, without any problems. This is because things like ship mods are always using append methods (at least they should be, except for one crucial area- market_ships.ini). So that, at least to me, is a non-starter.

In addition, each mod would have to have a custom version of freelancer.ini in order to refer to the modules.

This would also tend to make such mods difficult to integrate with one another in practice. In theory, we'd just append new data to freelancer.ini for each addon mod with XML scripts... but how is that any different from having multiple pure XML mods add their code to FL's INIs sequentially? Ok, so now it's just one INI, not multiple- it's safer. But it's also pretty limited, since we cannot do a lot've things with it. Like, for example, create Infocards and Strings with sequentially-executed XML scripts.

I've been working on techniques to make mods fully-modular with XML/FLMM because it works, it's simple, and it greatly reduces the need to use outside resources, such as hand-hacking DLLs (yuck!). Anything that trends towards more specialization makes me skeptical.

Last but not least... there's the efficiency issue. I'm no computer-science genius by any means, but I suspect that it's less efficient for the FL game engine to refer to the various memory locations that each INI's contents are assigned, for searching out the variable values. IOW, this idea might work great for one ship... but what about one hundred? That's a lot of files!

At any rate... I'm not hating this idea... don't get me wrong here... I just think that there are some potential issues with it, and if we're going to explore it, then we need to keep that in mind. If you want to understand why I'm such a big fan of using XML/FLMM, check out my mod's current version, which can be found here.

Edited by - Argh on 5/17/2005 6:58:54 PM

Post Wed May 18, 2005 5:05 am

Um... at the risk of sounding pretentious...

yes you do

This is exploration of the file, Argh you sound so defensive over the XML /FLMM method that I had to smile.

I suggest that TheJkWhoSaysNi continues with this and sees what else can be done. Areas like this might appear on the surface to be limited, but its the other things that are learnt that help unlock other doors.

Post Wed May 18, 2005 5:18 am

You're right, there are some issues with the method, but they can be worked out or worked around, in my opinion.

As for installing the mods.... XML isnt the answer to everything, and definatly not the best solution here. It would be very easy to have a program read file names from mods/modname and put them in freelancer.ini without the author needing to code anything but the mod itself. If the author wanted custom file names, you could have the program read inside the file to see what secions it contains and find out its type from that. (goods, market, equipment, ship, constant, etc)

Infocards and strings, yes there is a problem here. If it were possible to edit the dlls on the fly (which i'm pretty sure it would be, with enough effort) you'd get the problem of ID clashes, again, with more complex programming, each mod which had ID cards could be given the next available id and the inis of the mod updated accordingly.

As for efficiency, if you look at freelancer.ini, you can see what freelancer does when it loads. It takes each file referenced in freelancer.ini and puts it into a data structure (a tree by the looks of it) so each markets = file gets put into a data structure that contains all the other markets info. Adding an extra file does not change this, it just means it reads another file when it loads. Adding to the original files just means it has more to load from each file. The only difference in speed is the negligible time it takes to move to the next ini file. But lets not forget it's already reading 100+ files anyway.



Edited by - TheJkWhoSaysNi on 5/18/2005 6:55:34 AM

Post Wed May 18, 2005 6:24 am

I can't honestly see an advantage to this method over Argh's XML method. What's the difference between having multiple versions of each file and using XML to add multiple entries? FLMM handles appending/removing the sections perfectly adequately.

Then there are the files that can't be duplicated. Sure, you can add new ships to a mod in this way, but how do you expect to get the NPC's to fly them. There's only one, hardcoded file that deals with the NPC ships, so you'd end up modifying this one anyway. In the same way this will prevent you from adding new factions, missions, NPC's and pilots, to name but a few.

Then there is of course the danger of multiple files with the same name. What happens when two authors name their new shiparch file "mod_shiparch_2.ini", for example?

The phrase "If it aint broke, don't fix it" springs to mind here...

Post Wed May 18, 2005 12:07 pm

What are the advantages? Ease of adding/removing, keeping everything seperate, no risk of needing to restore backup ini files if a mod messes up. It also keeps everything neater.

Yes, there are restrictions although I have been looking into ways of bypassing them with limited success so far.

As for name clashing, i already suggested giving mods their own directory so that shouldn't ever be a problem.

Post Wed May 18, 2005 12:29 pm

JkWhoSaysNi:

What are the advantages? Ease of adding/removing, keeping everything seperate, no risk of needing to restore backup ini files if a mod messes up. It also keeps everything neater..


I think its safe to say carry on with what you believe in. If you think there are advantages for this, then with any work that you do - you can show the advantages of the system... hoping it catches on.

However, contra to that - XML scripting can ensure mods can activate to be compatible. If its to 'build your own' - I exampled the then "new" options of FLMM to an extreme potential of making customised things available. The added bonus was that you activate one mod - choosing as you go along. Your method would be roughly the same (build your own) - but you will need to activate more and more versions...

Pursue it though, and demonstrate its use

Argh:

such as hand-hacking DLLs (yuck!)

Fraid some of us will never use the FLMM method. I cannot stand its generate IDS method - and much prefer to see my work in FLED-IDS. I have used it in the past, don't get me wrong. Its just I don't like it when compared to manually editing a DLL file.

Edited by - Chips on 5/18/2005 1:32:07 PM

Post Wed May 18, 2005 12:31 pm

I've taken a longer look... here's what I think. Strail... I'm not being defensive. I said that I was risking being pretentious because I rarely come down against somebody working on a wild and crazy idea- if we didn't have wild and crazy idea people around here, nothing would ever get done that was new. I really, really appreciate that
TheJkWhoSaysNi has shared this approach. He's more than welcome to build some test cases to prove my doubts wrong, just as I have done to deal with people's doubts about some of my crazier schemes- maybe I'm just not seeing something obvious, k? I try to remain objective about this stuff- it's all science, and if it works better than what I already know how to do, I'm going to rebuild my Toolkit to use this technique.

I just don't think it works any better than what we already know how to do.

Here's why.

The whole adding ships to have NPCs fly them problem referred to by Accushot is just the tip of the iceberg. You can solve that with XML in addition to the XML you'd already have to write to make a truely modular and extensible freelancer.ini... so why not go the whole way, and just make the whole thing XML? This chicken/egg scenario keeps coming up over and over again. Basically, you have to keep returning to XML to get things done, or hand-alter INIs all over again. Trust me... I am in total sympathy here. For the Toolkit, I had to also hand-edit a lot've INIs, or use very extensive grep find-and-replace techniques. I was building it to help others build things faster, though, so I figured that the work put in now would be worth it, in terms of time saved later.

But... there might be one use for this that is superior in the limited areas it can mod. You could leave your new "Argh_shiparch.ini" file blank, refer to it in freelancer.ini, and then have an XML script append your ship's script to the blank file... thus creating a clean, seperate shiparch entry with Infocards (this is a trick I've used extensively for new System names, among other things). This would give us a seperated shiparch ini that also generated DLL strings on execution.

I just don't think that would do much for us, other than slightly lowering the already-low chance that our data became corrupted along the way- but that could happen anywhere along the file-transfer process. FLMM doesn't corrupt data, in my experience, if you write your code correctly. That's why I wrote the Toolkit Mod... to demonstrate good coding practices with XML, including sequential operations and modularity. Since it appears that we will probably get at least one new version of FLMM (Matt is working on it now), we will have even more features to play with, which makes this approach even less attractive.

For things like ship CMPs and everything aside from INIs, Freelancer allows for users to define the directory locations, etc., at will. So we're just talking about the very few INIs that are important enough to mod, but not important enough that DA hard-coded them

And there's that problem with market_ships I was referring to earlier, whose implications seem to have been ignored.

Market_ships is one of the areas where you're going to run into serious trouble. Why? Because you cannot extend it, is why. Market_ships can only be modified by replacing existing entries, or by building entirely new Bases with Mbases entries, etc.... or adding Rooms to existing Bases (which is what i've been working out for awhile now).

So making a seperate market_ships for your ship to be sold on Manhatten, for example... is useless. There are already three entries there... it won't work. I dunno about even adding entries to shipdealers that already have one or more... and I certainly expect that if you had multiple mods with their own customized market_ships... surely they'd overwrite each other. It sounds like a mess to me I'd need to see a side-by-side pair of ship mods active to test with... but I have a feeling that one of the ships simply won't show up at the Shipdealer. Best to use XML and the stripped-down market_ships from my Toolkit to do this with, imo.

I've been working on a solution to that issue for the next version of the Toolkit- a better-organized and easier-to-mod market_ships for stock FL. It won't cover TC mods or system add-on mods, but it'll provide a better template for this kind've modding. But it still ultimately involves some modification of the core file- you simply cannot avoid it. You can get around it with things like ships or weapons, but when you're touching upon areas that are keys for gameplay... I think this approach breaks down. XML/FLMM allows us better code control and greater power, and with properly-prepared INIs (which was the bulk of work put into the Toolkit) you can do a lot more with it than people think.

Post Wed May 18, 2005 12:42 pm

Accushot keeps telling me that some files cannot be removed - but...


goods = mods\osiris\equipment\goods.ini ;all the goods could go in the same file
goods = mods\osiris\equipment\st_good.ini
goods = mods\osiris\equipment\weapon_good.ini
markets = mods\osiris\equipment\market_misc.ini
markets = mods\osiris\equipment\market_ships.ini



The goods files say in the square brackets what the object is, and also categorises it by its category line.

I think you could condense that to just one goods = file:
goods = mods\osiris\equipment\osiris_goods.ini

and then add all the goods into that file.
Same for markets... plonk ships and weapons and commodities all into one file. After all, I do not think its the filename that matters here - its the cross-referencing that makes the difference. Give it a go, it would cut down on file numbers etc. The worst that could happen is that it crashes - and I can finally (after about 2 years of speculation without trying) stop dribbling on about it (no - never bothered enough to actually try it).

Edited by - Chips on 5/18/2005 1:43:53 PM

Return to Freelancer General Editing Forum