Add Partial Form flag warnings for CELL & QUST records about fallout4

[Ortham]

LOOT can't detect ITM records itself, so this functionality can't be supported without significant changes to plugin parsing.

[Glitchfinder]

That's fair, though it works under the assumption that the warning would be automated. Many of LOOT's warnings and ordering rules are user-submitted and rely on checksums. Is that not a viable approach here?

[Ortham]

That's fair, though it works under the assumption that the warning would be automated. Many of LOOT's warnings and ordering rules are user-submitted and rely on checksums. Is that not a viable approach here?

Yes, that would be viable. If you just want messages added for certain CRCs, you can supply the relevant plugin names and CRCs similar to how dirty plugins can be reported, so that the masterlist maintainers know what to add - I think the technical detail you've provided is mostly unecessary for that (which is partly why I assumed you wanted this automated).

[pStyl3]

possibly referring to a document on the partial form flag in the process

Is there any official/unofficial documentation regarding the Partial Form flag that we could link to, apart from the mentioned xEdit GitHub issue? Maybe @VlitS could help us here?

[VlitS]

Not really anything official, sorry. There is some discussion of it on the xEdit discord that resulted in that Github issue. The extent of my testing was verifying that it can be used to bypass the .esl bug with new CELLs in SSE*, and confirming that is is a decent idea to use it for ITM DIAL, CELL, and WRLD overrides when you are changing child records (e.g. editing/adding/removing REFRs) in general.

That said, the original use of it by Bethesda seems to be primarily for the version control system. That Github issue is the most concentrated info on it that I can find.

Discord link to the start of the discussion that led to me making that issue (there were some earlier discussions I found using "partial form" as the search term that I read while writing it): https://discord.com/channels/471930020454072348/486317996344868864/647821372378054656.

If we want semi-official "documentation", someone should probably start a thread (on Nexusmods or elsewhere) with a summary of the info we know about it, should probably first discuss it on the xEdit discord to make sure the current consensus on it is accurate. Maybe check if DavidJCobb has any more info (digging into the program code is a little more accurate than just a handful of tests by one or two people :D )

*an interior CELL created by a plugin flagged both ESL and ESM (which all .esl plugins are treated by the game as having) will have all non-persistent placed objects fail to load if a later plugin overrides the CELL

[pStyl3]

Thanks for the detailed response @VlitS. In this case I agree that there first should be a consensus regarding the topic. Once that is reached the only question is, where that agreed upon consensus should be posted. Perhaps within the Tome of xEdit?

Here's a first suggestion on how this could be done within LOOT. We could create these two message anchors in the prelude, notice that I've given &partialFormSet the type say and &partialFormReset the type warn. Both messages are written with the assumption, that we can link to some sort of documentation for the flag.

prelude.yaml

  - &partialFormSet
    type: say
    content:
      - lang: en
        text: 'The record **%1%** of this plugin can benefit from the Partial Form / Unknown 14 flag. See the [documentation](http://example.com/) for more information.

  - &partialFormReset
    type: warn
    content:
      - lang: en
        text: 'The exterior CELL record **%1%** of this plugin has the Partial Form flag set, which can result in the removal of objects from the world. As such the Partial Form flag should be removed. See the [documentation](http://example.com/) for more information.

Then, within the masterlist:

masterlist.yaml

  - name: 'ExamplePlugin1.esp'
    msg:
      - <<: *partialFormSet
        subs: [ '02001408' ]
        condition: 'checksum("ExamplePlugin1.esp", 1AE8D648)'

  - name: 'ExamplePlugin2.esp'
    msg:
      - <<: *partialFormReset
        subs: [ '02001408' ]
        condition: 'checksum("ExamplePlugin2.esp", 1AE8D648)'

With the above we could add these notifications on a checksum basis. What I'm asking myself is, if there are plugins with more than just a few of those incorrectly flagged records .. because if yes, that would mean that for n incorrectly flagged records we would need to assign these messages n times. If n is in the low single digits, no problem. If there are dozens of them or more, this wouldn't be practically anymore. So an even more generalised message might be better.

prelude.yaml

  - &partialFormSet
    type: say
    content:
      - lang: en
        text: 'One or multiple records from this plugin can benefit from the Partial Form / Unknown 14 flag. See the [documentation](http://example.com/) for more information.

  - &partialFormReset
    type: warn
    content:
      - lang: en
        text: 'One or multiple exterior CELL records of this plugin have the Partial Form flag set, which can result in the removal of objects from the world. As such the Partial Form flag should be removed. See the [documentation](http://example.com/) for more information.

And the corresponding entries in the masterlist for this variant:

masterlist.yaml

  - name: 'ExamplePlugin3.esp'
    msg:
      - <<: *partialFormSet
        condition: 'checksum("ExamplePlugin3.esp", 1AE8D648)'

  - name: 'ExamplePlugin4.esp'
    msg:
      - <<: *partialFormReset
        condition: 'checksum("ExamplePlugin4.esp", 1AE8D648)'

[pStyl3]

Actually, if the number of incorrectly flagged records is not in the dozens or more, then no, we wouldn't necessarily need to assign the message n times for n records that are incorrectly flagged. We could write them all within the subs text in the masterlist.

So

        subs: [ '02001408' ]

could then become

        subs: [ '02001408 and 02001409 and 02001410' ]

We also could write them (and only them) bold, so

  - name: 'ExamplePlugin1.esp'
    msg:
      - <<: *partialFormSet
        subs: [ '**02001408** and **02001409** and **02001410**' ]
        condition: 'checksum("ExamplePlugin1.esp", 1AE8D648)'

In that case the message anchors within the prelude would need to be changed so that they are written with %1% instead of **%1%**.

[Glitchfinder]

This is a case where the number of relevant records can easily balloon into the dozens and potentially even hundreds depending on how many cells or quests a mod touches. So while normal use case is probably only going to be a few records, there will be exceptions to that.

Edit: As an example of the above, Project Valkyrie has 7 CELL records and 1 WRLD record that could benefit from this flag. Conversely, Sim Settlements 2 already makes use of it on 27 CELL records and 1 WRLD record.

[sibir-ine]

We could also take the same approach that we do to deleted navmeshes where we inform users of their existence but recommend that they inform the author & let them resolve it. However, I personally would like a bit more consensus & documentation on the issue before adding any messages.

I'll also move this issue back to the FO4 repo since an automated message isn't feasible at the moment.

[Glitchfinder]

Additional information regarding CELL records has been inferred via heavy ingame testing, and detailed here. Eckserah on the xedit discord server is looking into decompiling the Fallout 4 cell loader for verification on the matter, as well.

[sibir-ine]

Sorry for the late reply, & thanks for the extra detail & testing. Given how inconsistent the behavior of the flag is, a generic warning doesn't appear to be appropriate. Maybe when it's been fully decoded, we can revisit this, but, as it stands, it may not be the best idea to inform users or mod authors about it with so many gaps in our knowledge. People misunderstanding when it can be used may hinder more than help at this point.