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

Suggested FLMM fixes/enhancements (some for modders to do)

Here you can find news, get help and comment about the ?Freelancer Mod Manager (FLMM)? for activating/deactivating Mods for Freelancer

Post Sun May 08, 2005 4:59 am

Suggested FLMM fixes/enhancements (some for modders to do)

Some minor enhancements to FLMM could help make modding easier and more trouble-free. I'm mentioning a few items I've noticed in the past few weeks; many CAN be worked with by using other tools, of course. In fact, the primary hurdle to many issues is just that we don't know all the internal details of how FLMM operates; in some ways it's "mod magic".

I don't know if Matthew is planning to do much more with this - he's done plenty already - but a few of the items below can be done by FLMM _users_, and some of the others can be done by Matthew with minimal work I suspect.

A central issue here is that FLMM actually fills 2 distinct roles. It was designed to allow players to manage mods; but it ends up also acting for many of us as a "modder's manager"! The two roles really are distinct because players have different needs from modders.

+ More documentation on "good" FLMM mod building style
(user fix)
Several people have posted excellent discussions of how to do things "correctly". For example, using append operations instead of just copying raw INI files makes mods smaller, faster, and more cooperative. Using xmldata and stringdata tags have been minimally explored, and need more talk. People also need to understand the uses of _internally_ modular builds (using multiple XML files as Argh has demonstrated to break mods into easily debugged/revised "objects" and when it is important to tell FLMM to ignore errors (I've seen massive mods break because someone had already commented out the Freelancer.ini movies).

+ FLMM Script Debugger
(user fix)
Although this wouldn't instinctively _think_ like FLMM, a debugger that looks for obvious issues would be an excellent tool. It would essentially parse all the .xml files in a mod folder, looking for items such as mismatched/missing tags, and flagging the line where they happen. This may be "my" project later.

+ Case-Insensitive Text Comparison
(FLMM revision)
FLMM uses strict casing when checking content - to it, [ship and [Ship are different. Probably FLMM does binary comparison of INI against the <section>...</section> data. If searching could be forced to text comparison, Li01_01_Base (as in newcharacter.ini, mBases.ini, and news.ini) would appear to be the same as Li01_01_base (as in market_*.ini files).
This is most directly an issue for modders entering data from memory, but it also can produce hiccups for otherwise well-built mods stacked on top of each other. Due to FLMM's critical role in mod application, the case-sensitivity also means that tools such as the FL SDK and Buck Danny's FlPatch cannot choose to make case consistent in the FL files at a later date.
If this is done, it WILL almost certainly make FLMM slower - possibly not significantly so, though.

+ WhatIf Mode
(FLMM revision - might be easy)
It would be VERY nice to see what FLMM would do with a mod without it actually DOING it. In other words, it would either do the mod and roll back immediately, or else not bother writing the files. The usability would come in it spewing out each operation: parses of an XML file, matches it finds, errors it encounters. This would help flush out problems due to people misunderstanding FLMM since they then have specific clues about why mod application fails.



+ Documentation on "Good" section-building
(modder fix)
FLMM has only a limited concept of INI file "sections" - e.g., [Ship and [Loadout sections in files apparently are treated as long text chunks. There are good reasons for this approach - any other approach would take a lot more processing, be bug-vulnerable, and would have taken much longer to implement.
Due to this, nicely built sections can make incremental modding easier, and bad ones can make it much harder. A couple of examples of "bad practices" that I've used myself are putting comments on the same line as the section header (breaks header matching since [Ship is not the same as [Ship;somecomment) and putting something other than the nickname as the first line of a section (makes unique identification via FLMM very difficult).

+ LIMITED Support For "Strict" XML via optional CDATA tags
(FLMM revision - minor)
If FLMM would allow and ignore CDATA tags delimiting literal content, XML parsers could easily read the data sections. This would probably be simple to implement, even if it just comes down to preprocessing the FLMM files and stripping out all CDATA open/close tags without regard to counting/matching. Presumably if someone is using them, they should already know what they're doing.

+ LIMITED Support For "Strict" XML via character entities
(FLMM revision - could be difficult)
This would be an alternative to CDATA usage, allowing use of character entities such as &amp; for the "&" sign - then quotes, '<', ">', and other characters wouldn't cause XML parsers to puke. This might be very difficult to implement globally, but allowing it within xmldata or stringdata could be simple and also resolve some difficulties with creating strings.

+ Fix GENERATESTRRES/GENERATEXMLSTRRES line truncation
(FLMM revision - minor)
Right now, the GENERATE functions rip out all data on a line after the "=" sign, making pure FLMM-based rumor-adding impossible (2 critical pieces of data on the line are stripped out). Fixing this so it only backtracks to an "=" or a "," would probably be sufficient.

+ Exclusions
(FLMM fix - could be ugly)
I would like to see FLMM support some specific method for excluding files. The simplest thing, assuming it builds a work queue from all XML files in the directory, might be to add a fileexclude tag, like this:
<fileexclude path="data/constants.backup"/>
Making it do wildcards would rock.

Post Tue May 10, 2005 11:16 am

One feature that should be considered a must is to prevent any operations (activate/deactivate) from happening if either the game (freelancer.exe) or the server (flserver.exe) are running. A lot of people currupt the game and mods by deactivating a mod before the game processes have completely shut down.

A second feature that should be a must is that FLMM not try to backup any files that were already backed up (.flmmbak) by preceding package. Granted this feature could be used for cheating but I don't think it would make things any worse than they already are. It only affects the auto-backup function in FLMM to prevent game/mod curruption.

Check out the latest beta's of the Freelancer S.D.K. 1.5 and Freelancer Explorer v2.x

Edited by - Louva-Deus on 5/10/2005 12:20:03 PM

Post Tue May 10, 2005 12:49 pm

It already does throw an error if you try to activate or deactivate a mod whilst Freelancer.exe is running.

The Server, however, does not.

I would suggest you guys email Matt if you wish to bring the items to his attention, because I don't think he checks here that regularly anymore...

Post Tue May 10, 2005 1:13 pm

I have sent him the link to this thread.

Check out the latest beta's of the Freelancer S.D.K. 1.5 and Freelancer Explorer v2.x

Post Wed May 11, 2005 7:52 am

(thanks for the e-mail Louva-Deus; Chips was right )


+ Case-Insensitive Text Comparison
(FLMM revision)
FLMM uses strict casing when checking content - to it, [ship and [Ship are different. Probably FLMM does binary comparison of INI against the <section>...</section> data. If searching could be forced to text comparison, Li01_01_Base (as in newcharacter.ini, mBases.ini, and news.ini) would appear to be the same as Li01_01_base (as in market_*.ini files).
This is most directly an issue for modders entering data from memory, but it also can produce hiccups for otherwise well-built mods stacked on top of each other. Due to FLMM's critical role in mod application, the case-sensitivity also means that tools such as the FL SDK and Buck Danny's FlPatch cannot choose to make case consistent in the FL files at a later date.
If this is done, it WILL almost certainly make FLMM slower - possibly not significantly so, though.


Looking through my code, it appears that FLMM ignores case on the first search line but doesn't ignore case when comparing the rest of the lines. I think I can safely chalk that up as a bug .


+ WhatIf Mode
(FLMM revision - might be easy)
It would be VERY nice to see what FLMM would do with a mod without it actually DOING it. In other words, it would either do the mod and roll back immediately, or else not bother writing the files. The usability would come in it spewing out each operation: parses of an XML file, matches it finds, errors it encounters. This would help flush out problems due to people misunderstanding FLMM since they then have specific clues about why mod application fails.


FLMM already does a complete test run without modifying any files, telling the user if it encounters any problems and putting the details of the problems in the log window. Or are you getting at something else?


+ Documentation on "Good" section-building
(modder fix)
FLMM has only a limited concept of INI file "sections" - e.g., [Ship and [Loadout sections in files apparently are treated as long text chunks. There are good reasons for this approach - any other approach would take a lot more processing, be bug-vulnerable, and would have taken much longer to implement.
Due to this, nicely built sections can make incremental modding easier, and bad ones can make it much harder. A couple of examples of "bad practices" that I've used myself are putting comments on the same line as the section header (breaks header matching since [Ship is not the same as [Ship;somecomment) and putting something other than the nickname as the first line of a section (makes unique identification via FLMM very difficult).


Stripping comments off of sections could be put on my todo list. It definitely would take a little more processing, but probably not enough to cause a significant slowdown.

As for putting something other than nicknames as the first line of a section, I don't know if there's anything I can do to work around that.


+ LIMITED Support For "Strict" XML via optional CDATA tags
(FLMM revision - minor)
If FLMM would allow and ignore CDATA tags delimiting literal content, XML parsers could easily read the data sections. This would probably be simple to implement, even if it just comes down to preprocessing the FLMM files and stripping out all CDATA open/close tags without regard to counting/matching. Presumably if someone is using them, they should already know what they're doing.


Adding CDATA parsing should be pretty easy; I'll add it to the todo list.


+ LIMITED Support For "Strict" XML via character entities
(FLMM revision - could be difficult)
This would be an alternative to CDATA usage, allowing use of character entities such as &amp; for the "&" sign - then quotes, '<', ">', and other characters wouldn't cause XML parsers to puke. This might be very difficult to implement globally, but allowing it within xmldata or stringdata could be simple and also resolve some difficulties with creating strings.


I *could* add that parsing into the parser, but it would definitely slow it down. Would it be acceptable to just implement CDATA parsing instead?


+ Fix GENERATESTRRES/GENERATEXMLSTRRES line truncation
(FLMM revision - minor)
Right now, the GENERATE functions rip out all data on a line after the "=" sign, making pure FLMM-based rumor-adding impossible (2 critical pieces of data on the line are stripped out). Fixing this so it only backtracks to an "=" or a "," would probably be sufficient.


Hmm, I remember something about that, but can't find the details at the moment. Could you give me an example of one of those lines that FLMM messes up?


+ Exclusions
(FLMM fix - could be ugly)
I would like to see FLMM support some specific method for excluding files. The simplest thing, assuming it builds a work queue from all XML files in the directory, might be to add a fileexclude tag, like this:
<fileexclude path="data/constants.backup"/>
Making it do wildcards would rock.


Do you mean adding a way to flag files in the mod's directory that FLMM shouldn't copy to the Freelancer directory when the mod is activated?


A second feature that should be a must is that FLMM not try to backup any files that were already backed up (.flmmbak) by preceding package. Granted this feature could be used for cheating but I don't think it would make things any worse than they already are. It only affects the auto-backup function in FLMM to prevent game/mod curruption.


I just looked through the code, and it appears that FLMM already does that? I couldn't find any place where it overwrites a .flmmbak file.


The Server, however, does not.


That'd be quite easy to detect; added to the todo list.


Phew, think I got through everything; now I'll hit Reply and find out how many quote brackets I forgot to add...

I know I talk about a todo list a lot, but never have a public listing; I'll try to compile a list of all the possible changes and post it in the forum as soon as I get the time.

I'm sorry about my absense from the Freelancer scene the last year or so, but a job, college, new interesting programming projects, the Halo competitive scene, and getting a little tired of working on FLMM all combined to pull me away from any FLMM development. But now I'm done with college until the fall and don't start up work until the 23rd, so I might possibly have time to get a new version of FLMM out in the next couple weeks. I do have a couple other programming projects to polish up first, a Halo (2) tourny on Saturday, and a website that I'd really like to finish up (I'm having the most difficult time finding any CSS stylesheets (not layouts); I'd make my own, but I'm horrible at choosing colors :/ ), so unfortunately I can't promise anything .

------------------------------------
Freelancer Mod Manager: newbies' dreams come true
Belief in Jesus: the only way to Heaven

Edited by - IGx89 on 5/11/2005 8:54:44 AM

Post Thu May 12, 2005 7:56 pm

+WhatIf Mode

FLMM already does a complete test run without modifying any files, telling the user if it encounters any problems and putting the details of the problems in the log window. Or are you getting at something else?


This was for a fully automated smoke test, which it looks like /activateandlaunchserver already handles.



Stripping comments off of sections could be put on my todo list. It definitely would take a little more processing, but probably not enough to cause a significant slowdown.
As for putting something other than nicknames as the first line of a section, I don't know if there's anything I can do to work around that.

There is very little you can do realistically, which is why I think this is most important as a "modder education" item, getting them to understand that FLMM is really identifying a text sequence.

LIMITED Support For "Strict" XML via character entities

I *could* add that parsing into the parser, but it would definitely slow it down. Would it be acceptable to just implement CDATA parsing instead?


Having the CDATA tags will allow all the tricks I want. I'm not so much concerned about the slowdown from doing this as the odd cases it could introduce if we demanded really fancy parsing.

+ Fix GENERATESTRRES/GENERATEXMLSTRRES line truncation

Hmm, I remember something about that, but can't find the details at the moment. Could you give me an example of one of those lines that FLMM messes up?

Given this:
<source>
rumor = base_0_rank, mission_end, 1, 0 ;GENERATESTRRES(stringdataX)
</source>
the actual line written to a file is
rumor = 1234567
stripping out the "base_0_rank, mission_end, 1," bit.

+ Exclusions

Do you mean adding a way to flag files in the mod's directory that FLMM shouldn't copy to the Freelancer directory when the mod is activated?


Scratch this. It was exactly what I meant, but it was intended as a hack for my working style when doing "group modding" that requires zipping/sharing XML files via email regularly. There are better ways to handle this which don't involve FLMM directly - e.g., I can script automatic deactivation, file copy to the FLMM folder, followed by automatic mod activation.

Post Fri May 13, 2005 8:03 pm


A second feature that should be a must is that FLMM not try to backup any files that were already backed up (.flmmbak) by preceding package. Granted this feature could be used for cheating but I don't think it would make things any worse than they already are. It only affects the auto-backup function in FLMM to prevent game/mod curruption.

I think I know what he's getting at here - I've actually had some problems with this. I made a ship package with multiple scripts that each edit shiparch.ini. The mod activates just fine, but it always causes an error turning it off which asks you to restore backups. The log says:

<pre><font size=1 face=Courier>Warning: unable to restore 'c:\program files\microsoft games\freelancer\data/ships/shiparch.ini' because no backup exists! </font></pre>

This only happens when you modify the same ini multiple times.

<unrelated banter>BTW, I love FLMM - you're the man IGx89!</unrelated banter>

I have become one with my computer. It is a feeling of ecstasy...the perfect blend of logic and emotion. I have reached...Nerdvana!

Post Fri May 13, 2005 8:51 pm

Um, if we're throwing ideas into the wind... could I request something?

I'd like FLMM to have an "evaluate=yes" tag for replace operations. Here's what I mean:

Say, for example... you'd like to change all of the guns with a muzzle_velocity between 400 and 700 to 750. How hard would it be for FLMM to read everything that qualified and alter it?

I had to do this with grep parsing, and it was a royal pain. If such a feature was built right into FLMM, it'd really open up a lot of possibilities.

In addition, if it could also evaluate strings with wildcards... FLMM would more-or-less totally replace INI editing, at least for me.

Here's how I think that the syntax should look:

<data file="data\equipment\engine_equip.ini" method="sectionreplace" evaluate="true" find="string">
<section>
[Engine
</section>
<dest>
flame_effect = gf_li_smallengine*
</dest>
<source>
flame_effect = gf_br_smallengine01_fire
</source>
</data>

That's a crude example, but basically what the code above would do is replace all of the strings that started with flame_effect = gf_li_smallengine and ended with any number of characters with gf_br_smallengine01_fire.

For numerical evaluation, mainly what we need is something that can strip the spaces and anything after a comment (to reduce errors) and then evaluate anything after the "=" as a number. It needs only to evaluate whether something is > < = >= <= a given number, and it needs to "understand" floats.

Sooo... here's a sample:

<data file="data\equipment\engine_equip.ini" method="sectionreplace" evaluate="true" find="expression" >
<section>
[Engine
</section>
<dest>
max_force = "<48000>10000"
</dest>
<source>
max_force = 48000
</source>
</data>

The script above would evaluate every number following the "=" for max_force, check to see if it was less than 48000 but greater than 10000, and then if it qualified, change it to 48000.

Putting these two features into FLMM would make a lot of modding that's barely practical (I should know, I rebuilt FL's weapons tables from scratch, but it was painful) much, much, MUCH easier. Just a thought

Post Thu May 26, 2005 3:11 pm

Easier resource handling (RDL and plain strings both)

I have another wish, focusing on this. Resources are very difficult to handle correctly. Probably the very best solution so far is the xmldata/stringdata tags, but those can be quirky and according to the docs, 2000 is the upper limit on them. I've just checked 2 mods I have handy - WTS-World 2.53 and the in-process Asgard 3 beta - and they have respectively 1528 and 1174 resource generation statements in them.

Admittedly these are drastic cases. Also, since many of those are hardcoded resources, the distinct resources used for sellable items would generally be cut in half (ids data used in both an equipment item's technical definition and good definition, forexample).

I can't thing of many reasonable things to do differently with this, but here's a couple that go above and beyond the call of duty which could be very handy.

1. Simple auto-tagging of xmldata
The vast majority of infocards are very simple - they SHOULD be very simple, for legibility. Generally they're technical documentation of an item. A nice feature would be having FLMM automatically insert tagging for untagged xmldata. The classical \n (which works fine with stringtable resources) could be parsed into paragraph separators. First paragraph would automatically be bolded, following paragraphs standard RDL markup. This would make professional infocards easy for beginners without preventing creativity; it would also significantly reduce scripting errors.

2. Autonaming
Given an item which clearly should have a resource but is missing it - say an ids_* line with nothing following the '=' - what about automatically doing lookup for stringdata and xmldata resources with the same base name and a "generic" identifier added? For example, let's say I have a new weapon fc_foo_gun01_mk01. FLMM sees this:
<pre><font size=1 face=Courier>nickname = fc_foo_gun01_mk01
ids_name
ids_info =
</font></pre>
Since there should be something there, but there isn't, FLMM would then look for a resource named name_fc_foo_gun01_mk01 to fill in ids_name and another one named info_fc_foo_gun01_mk01 to fill in the ids_info.

The second suggestion is probably a bit rough to do. It looks dead simple in terms of the amount of processing power required, but I can see it adding a new level of "look-here for this, there for that" to FLMM itself. I would almost prefer at that point that Matthew start looking at having FLMM host the Script Control and tell us to do it ourselves.

Post Thu May 26, 2005 6:31 pm

You know, the autotagging thing may be best done in some sort of generic xml generator; That may be a bit out of the scope of FLMM. If I'm understanding you correctly, a better way to do this may be to make a second program that takes an input like:

J10P - 15P "Dragon" Kusari Heavy Fighter

"The serpents tooth," this ship is the razor sharp maw of Kusari military knowledge and technology. The Dragon is the coalescence of form and function, blending unbeatable offensive and defensive capabilities and significant cargo space. In the hands of an experienced pilot this ship is not so much a weapon as a force of nature.

and turns it into the output:

<xml>
<RDL>
<PUSH/>
<TRA data="1" mask="1" def="-2"/>
<JUST loc="center"/>
<TEXT>
J10P - 15P "Dragon" Kusari Heavy Fighter
</TEXT>
<PARA/>
<TRA data="0" mask="1" def="-1"/>
<JUST loc="left"/>
<TEXT>
</TEXT>
<PARA/>
<TEXT>
"The serpents tooth," this ship is the razor sharp maw of Kusari military knowledge and technology. The Dragon is the coalescence of form and function, blending unbeatable offensive and defensive capabilities and significant cargo space. In the hands of an experienced pilot this ship is not so much a weapon as a force of nature.
</TEXT>
<PARA/>
<POP/>
</RDL>
</xml>

Such a program would be fairly easy to implement, and the output could just be copied into the mod of your choice. If something like this would be particularly helpful, I could probably write it myself, so I'm just not sure if it would really be necessary to implement it in FLMM. But, hey, that's just my opinion

I have become one with my computer. It is a feeling of ecstasy...the perfect blend of logic and emotion. I have reached...Nerdvana!

Post Fri May 27, 2005 8:29 am


...You know, the autotagging thing may be best done in some sort of generic xml generator; That may be a bit out of the scope of FLMM. If I'm understanding you correctly, a better way to do this may be to make a second program that takes an input like:...


Er... right, right, and more right. How embarrassing, I always complain about software that throws in the kitchen sink and you caught me asking for it with gold-plated handles.

This could probably be done pretty easily with a tool that takes 3 items as input: a nickname, a "friendly name", and a description with embedded line feeds. It then outputs an automatically named stringdata and xmldata pair and the item nickname. If the core is designed to do that, it can be easily surfaced as a GUI for interactive 1-by-1 use, or you can put in a pile of data at once.

No changes are even needed in FLMM, and you don't need to touch your main script file since you can push the xmldata and stringdata into a separate file. The main file stays nice and neat, and editing the stuff the player sees is always distinct from touching the crunchy inside specs.

Post Sat Oct 22, 2005 5:59 pm

I think what is meant by a test mode is that instead of FLMM running the mod install after testing it out first, halt after the test and report whether the mod install WOULD be successful, or what errors would be encountered.

Return to Freelancer Mod Manager