Haha, these boards are just GREAT! You donät even need an answer to get to a solution! Whilst writing the post above, I thought about the problem.

The solution is pretty easy:

When using an FLMM-script with "sectionreplace", you just have to match the "section" and "dest" to the decompilation error, so let it search for "offers_missions" instead of "offers_missions = true". The script will find the error, believing it is correct, and once it does, you can correct the error using the right entry in "source".

Of course you still have to create one of these tags for every entry in the rather large mbases.ini. But in my case, with a script already 5200 lines long and 150 kb big (20 per cent finished ), it won't make much of a difference. And you don't have to rely on the SDK.

LOL... yikes. You do know that you can break scripts up into multiple scripts and they'll be executed sequentially by FLMM, right?

And one other thing... to solve your problem, you could've dumped your entire Mbases.ini into one XML file, and then put a totally blank Mbases.ini file into the appropriate folder... try it, and you'll see that FLMM will overwrite the default Mbases.ini file with the blank one first, and then overwrite it with the INI information contained in your XML. I've been using that trick to put Names and Descriptions into my mod without having to hand-code a DLL or reference any strids, and it works just fine. Download Beta 1 of Warriors of the Sky and look at my Oceania.xml file to see how this works...

Right, that would be another good solution, maybe even better. Thanks.

Well, I WAS thinking about splitting my script. I know this is possible, but time is also a factor. And it is also the resource I have the least of all.

I've actually found that splitting up the scripts saves a lot've time, and really helps one to isolate coding errors . It's a little painful when you're getting started, but making everything modular really will help you to fix an area at a time. Think about it- what if Freelancer was just one long INI? It would've made perfect sense, from an efficiency standpoint... but modifying it would've ranged from painful to masochistic

I totally agree, looking over 5100 lines just to find out the error is a missing </data>... It's a real pain in the ass.

Er, this won't work.

If I put a totally empty mbases.ini into "mymod/DATA/MISSIONS" and then create a script called "mbases.xml" and put my entire modified and corrected mbases.ini in there using only <data> and <source>, the result after activating the mod is an empty mbases.ini.

What am I doing wrong?

Here's how I do it:

<script>
<scriptversion>
1.3
</scriptversion>
<data file="data\missions\mbases.ini" method="append">
<source>
[MBase
nickname = Oceania_City_Base
------------------------------------->the rest of Mbases.ini follows
</source>
</data>
</script>

Is the "scriptversion" important? Cuz I dropped that...

Otherwise, I did it exactly the same. However, it seems your mbases.ini-script only contains new files, or am I mistaken? Cuz my script contains the entire mbases.ini. Never the less, the result is an empty mbases.ini.

So what am I doing wrong?

Well, I'm doing this to append all new data to the original Mbases.ini, in my mod. I'm using it to fill up my System entries (Oceania.xml and BR07.ini are the relevant files to look at in Beta 1).

If you're seeing an empty file after running the script... I'd check a few things:

1. I don't suppose you've set anything to read-only? That'd do it.
2. Check your paths. The path should be data\missions\mbases.ini
3. Replace the double-quote marks in the path and append statements ( " ), and make darn sure that they're just regular ol' double-quotes. I had this problem before, where apparantly I'd added Unicode "smart quotes" into a script, and it took an email to IGx89 to figure that out.
4. Try another, smaller INI file to test with. Make a folder in your data folder called "test", and put a blank file called test.ini in it. Then make an XML script, put it in your mod's root, and call it TEST.xml, with a script like this:

<script>
<scriptversion>
1.3
</scriptversion>
<data file="data\test\test.ini" method="append">
<source>
This is just a test-script to make sure that Append operations are occuring as required.
</source>
</data>
</script>

Edited by - Argh on 3/12/2005 2:40:51 PM

Doesn't work, even with your script copied + pasted into the xml.

I think it is because the script is executed first and the files are copied after that, therefore overwriting any changes made before that.

Erm, if you have a blank mbases.ini file - and a script that appends it to it - then why on earth don't you just use an mbases.ini file?

For one, it only has to create a backup and copy it across - instead of creating backup, copying file, opening file, appending information, closing file.

I do it that way for my Systems so that FLMM can create the proper DLL entries for each game entity... and I don't have to code/memorize the IDs of such entries for the many, many, many named objects in my mod. I do it only for *new* objects in Mbases.ini. But there's really no reason why you cannot do an entire Mbases.ini in FLMM...

Manhatten... I dunno what to tell you, if you cannot get a simple test Append to work. I'd guess that:

1. You have a virus/adware/spyware/crappy-soft that's interfering with FLMM.
2. You're doing something wrong, that I cannot see from here.
3. You don't have the current version of FLMM (1.31, if I recall correctly).
4. I'm some sort've psychic-supra-alien-genius, and FLMM does things for me that it won't do for anybody else (muahahaha).

Edited by - Argh on 3/12/2005 4:30:09 PM

For one thing, I wanted maximum compability, therefore using scripts wherever I can. But I understand my changes to mbases.ini are so huge, even with a script I could not achieve the mod to be compatible with other mods. Every base has some sort of change and so the scripts of following mods would not find some things. And if the following mod uses a simple "copy" then the changes would be gone anyway.

So I will use a copied mbases.ini, cuz even with a script, following mods couldn't be activated correctly.

As for Argh, I'd say it's 4.

And through some experiments, I now know definetly that the scripts are executed first and then the files are copied. Your mod seems to do that the other way round, if your mbases.ini works.

Hmm, shame I cannot see quite where Mbases.ini is referenced for bases information. Maybe its hardcoded, otherwise you could have added a reference to the freelancer.ini file - pointing at an mbases2.ini instead.

AFAIK this can be done with any file they already have referenced in there.....