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