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

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...

(thanks for the e-mail Louva-Deus; Chips was right <img src=smilies/icon_smile_wink.gif width=15 height=15 border=0 align=middle> ) <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ 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 &lt;section&gt;...&lt;/section&gt; 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. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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 <img src=smilies/icon_smile.gif width=15 height=15 border=0 align=middle>. <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ 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. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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? <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ Documentation on &quot;Good&quot; section-building (modder fix) FLMM has only a limited concept of INI file &quot;sections&quot; - 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 &quot;bad practices&quot; 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). <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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. <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ LIMITED Support For &quot;Strict&quot; 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. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> Adding CDATA parsing should be pretty easy; I´ll add it to the todo list. <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ LIMITED Support For &quot;Strict&quot; 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;amp; for the &quot;&amp;&quot; sign - then quotes, ´&lt;´, &quot;&gt;´, 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. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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? <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ Fix GENERATESTRRES/GENERATEXMLSTRRES line truncation (FLMM revision - minor) Right now, the GENERATE functions rip out all data on a line after the &quot;=&quot; 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 &quot;=&quot; or a &quot;,&quot; would probably be sufficient. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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? <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>+ 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: &lt;fileexclude path=&quot;data/constants.backup&quot;/&gt; Making it do wildcards would rock. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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? <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>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. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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. <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>The Server, however, does not. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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... <img src=smilies/icon_smile_wink.gif width=15 height=15 border=0 align=middle> 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 <img src=smilies/icon_smile_sad.gif width=15 height=15 border=0 align=middle>. ------------------------------------ <A href=´http://flmm.hopto.org´ Target=_Blank>Freelancer Mod Manager</a>: newbies´ dreams come true Belief in <A href=´http://www.greatcom.org/resources/whoisjesusorig/´ Target=_Blank>Jesus</a>: the only way to Heaven Edited by - IGx89 on 5/11/2005 8:54:44 AM

+WhatIf Mode <font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>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 a

<font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>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. <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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 filesmicrosoft gamesfreelancerdata/ships/shiparch.ini´ because no backup exists! </font></pre> This only happens when you modify the same ini multiple times. &lt;unrelated banter&gt;BTW, I love FLMM - you´re the man IGx89!&lt;/unrelated banter&gt; I have become one with my computer. It is a feeling of ecstasy...the perfect blend of logic and emotion. I have reached...Nerdvana!

Um, if we´re throwing ideas into the wind... could I request something? I´d like FLMM to have an &quot;evaluate=yes&quot; 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: &lt;data file=&quot;dataequipmentengine_equip.ini&quot; method=&quot;sectionreplace&quot; evaluate=&quot;true&quot; find=&quot;string&quot;&gt; &lt;section&gt; [Engine &lt;/section&gt; &lt;dest&gt; flame_effect = gf_li_smallengine<b>* </b> &lt;/dest&gt; &lt;source&gt; flame_effect = gf_br_smallengine01_fire &lt;/source&gt; &lt;/data&gt; 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 &quot;=&quot; as a number. It needs only to evaluate whether something is &gt; &lt; = &gt;= &lt;= a given number, and it needs to &quot;understand&quot; floats. Sooo... here´s a sample: &lt;data file=&quot;dataequipmentengine_equip.ini&quot; method=&quot;sectionreplace&quot; evaluate=&quot;true&quot; find=&quot;expression&quot; &gt; &lt;section&gt; [Engine &lt;/section&gt; &lt;dest&gt; max_force = &quot;&lt;48000&gt;10000&quot; &lt;/dest&gt; &lt;source&gt; max_force = 48000 &lt;/source&gt; &lt;/data&gt; The script above would evaluate every number following the &quot;=&quot; 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 <img src=smilies/icon_smile.gif width=15 height=15 border=0 align=middle>

<b>Easier resource handling (RDL and plain strings both) </b> 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 <i>reasonable </i> 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
(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 &quot;generic&quot; 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 &quot;look-here for this, there for that&quot; 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. <img src=smilies/icon_smile.gif width=15 height=15 border=0 align=middle>

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 &quot;Dragon&quot; Kusari Heavy Fighter &quot;The serpents tooth,&quot; 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: &lt;xml&gt; &lt;RDL&gt; &lt;PUSH/&gt; &lt;TRA data=&quot;1&quot; mask=&quot;1&quot; def=&quot;-2&quot;/&gt; &lt;JUST loc=&quot;center&quot;/&gt; &lt;TEXT&gt; J10P - 15P &quot;Dragon&quot; Kusari Heavy Fighter &lt;/TEXT&gt; &lt;PARA/&gt; &lt;TRA data=&quot;0&quot; mask=&quot;1&quot; def=&quot;-1&quot;/&gt; &lt;JUST loc=&quot;left&quot;/&gt; &lt;TEXT&gt; &lt;/TEXT&gt; &lt;PARA/&gt; &lt;TEXT&gt; &quot;The serpents tooth,&quot; 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. &lt;/TEXT&gt; &lt;PARA/&gt; &lt;POP/&gt; &lt;/RDL&gt; &lt;/xml&gt; 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 <img src=smilies/icon_smile.gif width=15 height=15 border=0 align=middle> I have become one with my computer. It is a feeling of ecstasy...the perfect blend of logic and emotion. I have reached...Nerdvana!

<font size=1 face="trebuchet ms"><BLOCKQUOTE><hr size=1 noshade>...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:... <hr size=1 noshade></BLOCKQUOTE></font><font face=´trebuchet ms, Verdana, Arial, Helvetica´ size=2> 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 &quot;friendly name&quot;, 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.

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.