FTL has been very static for awhile, but we're going to be pushing out some big changes on the backend that will break some of your work. I'm concerned about the Slipstream Mod Manager, as the structure of the games data files is changing.
[...]
It'd be good to be able to let the modding community know what's happening and for us to be able to help out making any changes that may be necessary.
Code: Select all
<mod:findLike type="event">
<mod:findLike type="choice">
<mod:findComposite>
<mod:par op="OR">
<mod:findWithChildLike child-type="ship" panic="true">
<mod:selector hostile="true"/>
</mod:findWithChildLike>
</mod:par>
<mod-append:stupid>YESMAN</mod-append:stupid>
</mod:findComposite>
</mod:findLike>
</mod:findLike>If I read that right, you're telling SMM...fdagpigj wrote:I did also find a bug related to panicking in 1.6; specificially, the code below (when placed in events_rebel.xml.append as the sole file in a mod) fails because of the panic even though if you remove the panic, it clearly works
Vhati wrote:If I read that right, you're telling SMM...fdagpigj wrote:I did also find a bug related to panicking in 1.6; specificially, the code below (when placed in events_rebel.xml.append as the sole file in a mod) fails because of the panic even though if you remove the panic, it clearly works
For each event, find a choice. For each choice, find children containing a hostile ship. If *any* choice lacks a [child containing a hostile ship], then panic. Working as intended. If you remove the panic, choices lacking desired children will be silently unaffected, and SMM will continue on, altering any other choice's children that DO match on successive iterations of the outer event or choice loops.
That innermost findWithChildLike is running multiple times, independently, and panic quits whenever an instance fails to match.
IIRC mod tags act at the scope of their immediate parent. Each find tag further restricts the scope, allowing action on deeper elements, each match processed iteratively. They can't see the entire file at once. An inner tag will not know what's beyond the currently examined event/choice/etc context it inherited. You can drill down, but if you want to know that *all* attempts to drill everywhere in the file had failed, that isn't possible. A particular find instance can only panic when *it* fails.fdagpigj wrote:So what would be the "correct" way of achieving the same thing?
Yeah, I know findComposite is intended for acting on results that satisfy all or any nested finds, I was just simplifying it for this specific case to better demonstrate the issue.Vhati wrote:Oh another possible misunderstanding: findComposite delegates its criteria to *two or more* nested find tags, to act on the results of both. A composite/par with only a single nested find doesn't do anything special.
Yeah, I know find tags don't find nested elements unless the find tag is nested at the same level as the element to be found. But I didn't realise that the panic will be tested for every time the find runs, I guess this just means there is no easy way to panic if there is no matching element at any level other than the top level, you can only panic if not every single matched parent element contains such a child element, or if no top-level matching parent element is found (could you nest a crapload of findWithChildLikes to test if it has the desired children and only on a match on that, do "real" finds for the children? Hmmm).IIRC mod tags act at the scope of their immediate parent. Each find tag further restricts the scope, allowing action on deeper elements, each match processed iteratively. They can't see the entire file at once. An inner tag will not know what's beyond the currently examined event/choice/etc context it inherited. You can drill down, but if you want to know that *all* attempts to drill everywhere in the file had failed, that isn't possible. A particular find instance can only panic when *it* fails.
I don't think a find ever matches grandchildren, you would need several nested finds for that. Which is actually quite burdenous at times since if you want to match any elements of a type at any level, you have to make a massive number of similar but differently deeply nested finds, but I guess it can also be desirable sometimes - I was actually thinking of maybe adding some kind of feature to have some mod attribute that tells the patcher to look at the children of non-matching elements - maybe even children of matching elements, too. But it might be tricky to program that feature. And yeah, the by far biggest problem with advanced SMM tags is that basically nobody really understands and remembers exactly how they behave, which leads to people avoiding them or struggling for hours just to use them for something simple. But to be honest, I don't really know how to change that.Edit: I suppose you could do two passes. Make scattered modifications in the first set of nested finds, and insert a dummy tag in the process, wherever they succeed. Then after all that, do a find for all such dummy tags, remove them, and panic if none were found? Unless finds only shallowly scan immediate children, in which case no? I'm rusty.
Matthew wrote:The big change that hurts mods is that resource.dat and data.dat no longer exist, and instead they're packaged together in ftl.dat which is packaged in a new way. We're using the custom engine that the iPad version of FTL runs for PC now, which means new data files. The (limited) documentation for this is here.
http://achurch.org/SIL/current/src/resource/
http://achurch.org/SIL/
I know a lot of XML typos were fixed in this update, but there still might be some. FTL XML data is also wrapped in an <FTL> tag now, which adds a minor complication to generating, editing, and inserting XML files.
Matthew wrote:the new version of FTL is available on Steam on a beta branch. You can read more about it here:
http://www.subsetgames.com/ftl_changelog.html
Code: Select all
* The basic format of a PKG file is as follows:
* - Package header (struct PKGHeader).
* - File index (struct PKGIndexEntry * 1 for each file in the package),
* sorted by pathname hash, then by lowercased (y/A-Z/a-z/) pathname
* for files with the same pathname hash.
* - File pathname buffer, containing the pathname of each file (in
* arbitrary order) as a null-terminated string.
* - File data. The start of each file may be freely adjusted to any
* desired alignment as long as the file's index entry points to the
* correct offset.
Vhati wrote:I haven't diff'd, but the extracted contents basically look like "data.dat" and "resource.dat" had been extracted to the same place. XML has <FTL> root tags enclosing everything.
Sleeper Service wrote:Like will the new <FTL> root tag be handled by the mod manager or will people need to add this? Just asking for the MML sakes, really any changes required would mean that a lot of old mods with no one around to update them would be lost.
