How many commands can FLMM process?

[Bullwinkle]

Crazy wrote:
I think it would be worth to restart the FLMM 1.5 project by not adding new features but by fixing the 1.4 bugs (cause I still dunno why most ppl are still using FLMM 1.31)

I completely agree, Crazy. An issue-free version of FLMM would be terrific for the community. It would be the best thing since… well… FLMM.

In the Issues Department (not new features):

In addition to generating two IDs on one line, there are times when it is necessary to use the same ID in more than one INI file.

InfoCardMaps is also an example of this issue.

Regarding issues with making reliable backups, one alternative would be to simply backup and restore the Freelancer tree. It would not be dramatically slower than the current system when used with complex mods. Many people already do this manually. If FLMM is going to attempt to make backups, then it might as well make backups that really work.

[Moonhead]

Bullwinkle wrote:

Crazy wrote:

In the Issues Department (not new features):

In addition to generating two IDs on one line, there are times when it is necessary to use the same ID in more than one INI file.

InfoCardMaps is also an example of this issue.

FLMM 1.4 does assign the same number to identical multiple instances of ids_names and ids_infos! Without this, there would indeed be no point in managing InfoCardMap.ini thru FLMM XML scripting.

[Moonhead]

Btw, here is an example of how I’m organizing stuff. Argh’s Toolkit was a big example (although I didn’t care much for what seemed Argh’s one true passion: his ship handling modifications)

[Bullwinkle]

Moonhead wrote:
FLMM 1.4 does assign the same number to identical multiple instances of ids_names and ids_infos!

In the Deja Vu Department, I see that you made the same request, and received the same response, four years ago! (about using the same ID in multiple files)

I started to do the same thing as you with my data but stopped because of limitations in FLMM 1.31. Now you have me persuaded to pick it up again with 1.4.

Thanks for the tip, Moonhead. I’m a convert.

So you have been doing this for a while… what do you do about InfoCardMap?

PS: The FLMM Mod Guide (Help/How do I make a mod work with FLMM?) says that the limit is arbitrary, so adoxa’s offset may solve that problem.

Don’t forget that you will then have to distribute your customized version of FLMM with your mod… and maybe support problems that could be caused by changing a user’s FLMM.

.

[Gisteron]

you could store multiple xml’s in one file, that would probably make it simplier to overlook.
kill me for this comment but this amount of xml based changes is just… weird…

[Moonhead]

Gisteron wrote:
you could store multiple xml’s in one file, that would probably make it simplier to overlook.

That would be defeating the purpose.

Gisteron wrote:
kill me for this comment but this amount of xml based changes is just… weird…

I can only agree on that :lol:

[Moonhead]

Bullwinkle wrote:

So you have been doing this for a while… what do you do about InfoCardMap?

Make sure the first ids_info in InfoCardMap.ini is identical to the one you use in the starsystem’s ini (and also, make sure there is no other base using an exactly identical text):

 <data file="Data\Interface\InfocardMap.ini" method="append"><source>
Map = 0;GENERATEXMLRES("<xml><rdl><push><text>CLASS: Cocoon</text><para><text>AMENITIES: Yes</text><para><text>POPULATION: 120</text><para></para></para></para></push></rdl></xml>"), 0;GENERATEXMLRES("<xml><rdl><push><text>Whatever Station.</text><para><para><text>In order to retain its geostationary orbit, the quick brown fox jumps over the lazy dog.</text><para></para></para></para></push></rdl></xml>")</data> 

from the file that writes the starsystem’s .ini :

;
;================================{ Whatever Station }
;
[Object]
nickname = Aa00_01
ids_name = 0;GENERATESTRRES("Whatever Station")
pos = 0, 0, 80000
rotate = 0, 180, 0
Archetype = outpost
ids_info = 0;GENERATEXMLRES("<xml><rdl><push><text>CLASS: cocoon</text><para><text>AMENITIES: Yes</text><para><text>POPULATION: 120</text><para></para></para></para></push></rdl></xml>")
base = Aa00_01_base
dock_with = Aa00_01_base
voice = atc_leg_f01
space_costume = pl_female5_head, pi_order_female_body
reputation = fc_or_grp
behavior = NOTHING
difficulty_level = 3
loadout = trading_outpost_co_03
pilot = pilot_solar_easy
visit = 1

I use one XML file for each base, containing all the stuff that makes up a base, to be written to:

• Data\Interface\InfocardMap.ini

• Data\Universe\Universe.ini

• Data\Missions\mBases.ini

• Data\Equipment\Market_Commodities.ini

• Data\Equipment\Market_Misc.ini

• Data\Equipment\Market_Ships.ini

Bullwinkle wrote:
Don’t forget that you will then have to distribute your customized version of FLMM with your mod… and maybe support problems that could be caused by changing a user’s FLMM.

A distributed version of such a mod would preferablybe the files as installed, copied from the game folder when the XML plethora version is installed. So, in the distributed version, the XML scripting will be brought back to a minimum, and the mod can be sort of FLMM-version-independant.

[Bullwinkle]

OK, so you only make the first entry in InfoCardMap? I guess that makes sense, based on your request to Crazy.

And that is a fine solution for distribution.

This is really awesome, Moonhead. Not at all weird in a bad sense… just unique. Or uncommon, at least, because I see in the archived thread that Lancer Solurus does/did this, as well.

So what did you wind up doing about rumors? Comment out MiscText.dll from Freelancer.ini and replace it with your own IDs in script?

Maintaining rumors along with base, system, and markets would be awesome… it is so annoying to read bar rumors that are just plain wrong (because the IDs were copied from another system)!

Looking at your list, you have done a remarkable amount of work on this. Very cool.

(@Gisteron: Imagine a universe in which all ship infocards actually match ship specs because the original data is stored in a single XML script. )

.

[Gisteron]

er, i don’t think single xml’s are needed for this. in early stages of my mod i made also every ship via xml (though due to bugs i stored the infocards in dlls and wrote the numbers into the xml’s as regular entries) and written stats are independant from actual stats. you can manipulate both to make them match less.
however, it is more sensible not to make multiple xml’s changing the same file but store all changes on one single file into one xml. this is just safer though organization and order are more complicated this way. besides if you get deeper into developing where it starts annoying you that you have to reactivate your mod each time to test single features, you will apply changes directly into backuped files within your FL directory (made them not read-only). in this case it is just faster and simplier to copy the changed files once they work as you wish it into your mods directory instead of remembering what xml you have to change to synchronize the two packages. trust me, you will come up to this once the changes have a certain amount of hard drive requirement. every copying, every deleting, every activation and deactivation stores useless cache files and the day will come when you will start to want to work around this as much as possible.
:D:D

[Bullwinkle]

Sorry, Gisteron, I used a poor choice of words. I meant that a data-driven approach (using a single source of data) is both more elegant and more reliable than modifying INIs and DLLs separately. The advantage to a data-driven approach grows with the complexity of the mod. Nobody is suggesting putting an entire mod into a single script.

In fact, with multiple scripts, it is easy to separate one into a separate mod. In that case, activating is very quick during development.

I began working on an approach similar to Moonhead’s, but I used a separate mod for each script. I found that easier and quicker to keep organized, and it avoids the 2,000 item limit. I put only the header into script.xml to make it easy to merge or separate the mods.

I only paused that development because of the problem with assigning the same ID in multiple locations (which is now solved, thanks to Moonhead and FLMM 1.4). Now I can resume!

I find it much easier to keep my work organized this way than to keep track of all of the changes made to raw files.

.

[Moonhead]

Gisteron wrote:
if you get deeper into developing where it starts annoying you that you have to reactivate your mod each time to test single features, you will apply changes directly into backuped files within your FL directory (made them not read-only). in this case it is just faster and simplier to copy the changed files once they work as you wish it into your mods directory instead of remembering what xml you have to change to synchronize the two packages

Wel, giving the XML files clear and proper names is essential. Besides, I can use the Windows Explorer search function (although this, unfortunately, does not work 100% as it should)

In addition, the files are as modular as they can be, meaning I could copy parts of the mod to a separate mod, and handle that as if it’s a standalone. That means, among other things, that I need to use stock factions when working on new systems, and only replace those by custom factions when I’m satisfied.

I admit it’s a lot of work, and there’s much to say against it. But it’s not like I’m not pushing this method upon you.

[Moonhead]

I just replied but my connection crashed :-x So if I might sound impatient in the following, you know why

Bullwinkle wrote:
OK, so you only make the first entry in InfoCardMap? I guess that makes sense, based on your request to Crazy.

Yes, these are the kind of entries InfoCardMap.ini is meant for, right?

There is a pair of two ids_infos in InfoCardMap.ini , and the first of these should also be used in the base entry in the starsystem .ini file.

Bullwinkle wrote:
This is really awesome, Moonhead. Not at all weird in a bad sense… just unique. Or uncommon, at least, because I see in the archived thread that Lancer Solurus does/did this, as well.

Well it’s a lot of work, and as long as i haven’t even finsihed the foundations, it’s a little early to celebrate this method. I might run into limitations, or into other nastiness i didn’t foresee, or just get demoralized and quit…

Bullwinkle wrote:

So what did you wind up doing about rumors? Comment out MiscText.dll from Freelancer.ini and replace it with your own IDs in script?

No need to comment out MiscText.dll. Besides wouldn’t that screw up many stock ids_names and ids_infos?

Haven’t really looked into rumours and news yet (since “I’m back”) but it’s possible to do that with XML. Note that the first character is cut off, so start with a space or a _ or an X, whatever.

Bullwinkle wrote:
Maintaining rumors along with base, system, and markets would be awesome…

Yep. And it can be done.

There’s two things were XML created ids_names and _infos don’t work: Factions and Fields (Asteroids and Nebulas) because the game uses multiple occurences of these names at fixed intervals from each other (with small variations) in bribes and missions. So these still need to be done by hand, using FLED-Ids or a similar tool. You can add about 50 of each (50 factions and 50 fileds, more or less).

[Moonhead]

adoxa wrote:

You’ll need upx (or equivalent) to unpack it first,

Ouch.

I’m afraid I have no idea how to use this… There is some info included, but the person who wrote it assumes the reader is familiar with how to use command line utilities.

I could trail-and-error if the program with indeed open a command line window… But when i run it, it seems to open and close within a quarter of a second.

Care to talke me thru it?

Or better, can’t I just use Hex Workshop on the un-unpacked file (prolly not, but it would be so nice)?

[Bullwinkle]

Right, the only reason to comment out MiscText.dll would be to change existing items. Otherwise, as you say, just make new ones.

Here is FLMM 1.4beta4, unpacked and hacked to a 20,000 limit per adoxa’s offsets.

I only tested that it runs… beyond that you will have to test yourself.

And, yes, it is OK to leave it unpacked. This version is unpacked, so you can see the changes (or change them yourself).

Regarding searching XML files, you might appreciate a programmer’s editor. NotePad++ is free. UltraEdit has an excellent help file and support. Both are extremely popular editors that can, among many other things, quickly search a tree for files containing a string of text.

Either are terrific tools for working with multiple INI files or XML scripts.

EDIT: For others reading this thread, if you need the full FLMM 1.4 installer, it is here: http://igx89.home.comcast.net/~igx89/FLMM_Downloads.html

.

[Moonhead]

Bullwinkle wrote:
Right, the only reason to comment out MiscText.dll would be to change existing items. Otherwise, as you say, just make new ones.

Here is FLMM 1.4beta4, unpacked and hacked to a 20,000 limit per adoxa’s offsets.

I only tested that it runs… beyond that you will have to test yourself.

And, yes, it is OK to leave it unpacked. This version is unpacked, so you can see the changes (or change them yourself).

Regarding searching XML files, you might appreciate a programmer’s editor. NotePad++ is free. UltraEdit has an excellent help file and support. Both are extremely popular editors that can, among many other things, quickly search a tree for files containing a string of text.

Either are terrific tools for working with multiple INI files or XML scripts.

EDIT: For others reading this thread, if you need the full FLMM 1.4 installer, it is here: http://igx89.home.comcast.net/~igx89/FLMM_Downloads.html

.

Hey Bullwinkle, thanksalot man!! I’m a true commandline-analphabetic. I guess I can still use Adoxa’s recipe to hack your version up to 50,000, if necessary. Btw the only reasonable way to find out if it works, is by not ever running into a limit; else I would have to create some sort of dummy mod, that just puts FLMM to work… Well maybe I can do that… I’ll see.

I’ll switch to my other comp to try it out later (my new modem is about to arrive just about right now).

I remember once having used a text editor that was able to do bulk replacements of more than one line (the same you can do in NotePad and WordPad with ctrl+H, but not limited to edits within a single line). Can NotePad++ do such stuff? Well, I’ll find out within some hours.

[Bas]

Do not forget that your clients will need the same hacked FLMM as well.

[Bullwinkle]

Moonhead wrote:
Hey Bullwinkle, thanksalot man!! I’m a true commandline-analphabetic. I guess I can still use Adoxa’s recipe to hack your version up to 50,000, if necessary. …

I remember once having used a text editor that was able to do bulk replacements of more than one line (the same you can do in NotePad and WordPad with ctrl+H, but not limited to edits within a single line). Can NotePad++ do such stuff?

You are welcome, and thank you for the paradigm-shifting info about FLMM 1.4. And thanks to adoxa who did the hard part regarding the hack!

FLMM -> 64k
Attached is the 1.4 EXE hacked to 64k (minus a few just to be safe). 64k is the maximum number of entries to a single Freelancer infocard DLL.

As adoxa said, there are no guarantees that this will work. The FLMM docs say that the limit is arbitrary, so we are assuming that it is simply a limit to prevent infinite loops.

Multi-Line Search and Replace
Sure, that is a cinch with Notepad++, and it is also possible with Word (although not Wordpad or Notepad).

The trick is to know the search expressions that the editor uses to represent hidden characters. The most common hidden characters that you will need are:

Tab
CR (Carriage Return)
LF (Line Feed)

Windows programs typically mark the end of a line with CR+LF or just a CR. Unix-style is an LF. So, when working with files from unknown sources, you may have to try a couple of tests to make sure that you know the correct end-of-line character(s) for that file.

In Notepad++, the Search expressions are:

Tab = \t
CR = \r
LF = \n

For example, lets say that you want to sell your new whizzy_gun at all Bases. In market_misc.ini:

Search for:
_base\r\n

Replace with:
_base\r\nMarketGood = whizzy_gun, 0, -1, 10, 10, 0, 1\r\n

Note that in Search Mode, you want to select “Extended”. I attached a picture so that you can see what it looks like.

.

[Bullwinkle]

Bas wrote:
Do not forget that your clients will need the same hacked FLMM as well.

Yes, we talked about that earlier in the thread. Moonhead pointed out that it would be easy enough to use the xml scripts to create a DLL, then distribute the DLL as part of a release mod (in 1.31 format).

As an organization and test environment, this is pretty cool. It is a huge improvement over modifying files in place and trying to keep track of the changes.

Also, the ability to use the same generated ID in multiple places gives this technique an advantage over the current version of FLDev, as far as I can tell from the limited docs. Maybe FriendlyFire will address that ability in the future, if he has not already done so.

[Bullwinkle]

Since we have been talking about programmer’s tools for Freelancer modding, another priceless tool is a good “diff” program, such as WinMerge.

WinMerge lets you compare two versions of a file. It lets you see the differences between the files, and allows you to selectively update one file from another.

WinMerge is pretty awesome by itself, but it becomes even more powerful when used with a version control system such as SubVersion (SVN). Sushi wrote a nice tutorial on SubVersion.

Note that Notepad++ and WinMerge are client-side tools. SubVersion is a client-server system, so you will need to have a host server for the repository. There are quite a few free hosts, including:

TheStarport Forge: http://forge.the-starport.net/
http://code.google.com/
http://xp-dev.com/
www.fireforge.net

.

[Moonhead]

Bas wrote:
Do not forget that your clients will need the same hacked FLMM as well.

As pointed out, they won’t: a distributional (is that a word?) version of such a mod, can consist of the modified .ini files (and maybe some other modified files, like the .fl files), the DLLs and additional .cmp’s, .3db’s, .txm’s etc. It would not have to contain any more .xml files than a simple script.xml, and will therefore be FLMM-version independent. (I am curious whether this .xml-free version will be signifcantly smaller in size.)

In effect, the distributional version would simply be a zipped copy of the entire Freelancer folder while the mod is installed, minus any files that were not modified.

Of course, the .xml-plethora version of the mod could also be distributed - and indeed the package would then have to include the hacked FLMM, instructions how to use it etc. Not a big deal.

Note that this is all hypothetical. For various reasons (re-learning certain things, learning new things, other things I like to do, other things I need to do, etc.) my progress has been and will be rather slow. I’d be happy to have it finished some years before NASA establises their base at the Moon’s southpole (Maybe I should speed things up though, in case that 2012 Maya Doomsday hype proves to be true)