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. Hmm, I remember something about that, but can´t find the details at the moment. Fixing this so it only backtracks to an '=' or a ',' would probably be sufficient. 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). I *could* add that parsing into the parser, but it would definitely slow it down. 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. + 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.Adding CDATA parsing should be pretty easy I´ll add it to the todo list. Presumably if someone is using them, they should already know what they´re doing. 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. + 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. 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. It definitely would take a little more processing, but probably not enough to cause a significant slowdown. Stripping comments off of sections could be put on my todo list. 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). Due to this, nicely built sections can make incremental modding easier, and bad ones can make it much harder. 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. 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. 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. This would help flush out problems due to people misunderstanding FLMM since they then have specific clues about why mod application fails. The usability would come in it spewing out each operation: parses of an XML file, matches it finds, errors it encounters. In other words, it would either do the mod and roll back immediately, or else not bother writing the files. + 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. I think I can safely chalk that up as a bug. 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. If this is done, it WILL almost certainly make FLMM slower - possibly not significantly so, though. ![]() 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. 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. 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). ![]() (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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |