Diggernaut fight not properly ending

[dyceron]

I don't know if this is a fluke, but I've killed Diggernaut twice this seed and both times it just stands there and the cutscene doesn't play, and the item isn't obtainable.

patcher.json

[dyceron]

Tested this a bit more

• 60fps cheat made no difference
• Removed PBs from inventory, still failed
• Regenned with the MEDS changes, nothing

Maybe I did hit the lottery with this one. I'll gen a completely new seed at some point to fight diggernaut to see if it breaks again.

[dyceron]

Reproduced on another seed. Something is breaking and I don't know what.

[dyceron]

Bug occured again on 8.1.0dev226 playing door lock and elevator rando 🥲. Those might not be related but posting in case.

[dyceron]

Turns out its a dependency/package issue again. Will look into.

[ThanatosGit]

The last time I fought Diggernaut was a door lock seed with/when only ice beam as custom door lock exists. But there was no ice beam lock on this scenario. Without patcher.json I can't look into it but I guess you had custom door locks there? Maybe they also need to or only should be placed in the pkgs.

[dyceron]

The seed that had issues had a bunch if locks. Setting all to pb worked fine, so it's definitely the asset issue like before. Which is weird because the assets should be ensured when they are patched in no?

[dyceron]

Yeah it's the custom shields. Here is a patcher file which breaks: patcher.json

I tried adding these to the add_custom_shields function and it still breaks

Attempt 1:

for level_pkg in editor.get_all_level_pkgs():
    for asset in editor.get_asset_names_in_folder(f"actors/props/doorshield{new_shield.shield_name}"):
        editor.ensure_present(get_package_name(level_pkg, asset), asset)

Attempt 2:

for asset in editor.get_asset_names_in_folder(f"actors/props/doorshield{new_shield.shield_name}"):
    for scenario in ALL_SCENARIOS:
        editor.ensure_present_in_scenario(scenario, asset)

[ThanatosGit]

Attempt 2 is calling editor.ensure_present_in_scenario(scenario, asset) which is doing what Attempt 1 does. Essentially they are the same.

Maybe one of those helps: a. If you intially add the assets via editor.add_new_asset(new_bmsad, template_shield, []) they are placed into the "naked" RomFS. Might try to delete them manually in the output romfs for testing purposes because they should be placed by your Attempt 2 into the correct pkgs. And we know from issues before here with diggernaut, that it was very picky from where it reads the files.

b. This will be a very annoying thing. I don't know if it helps but thought at least I write it down. I looked at what has been modified in the models, for e.g. this:

This is usually a "don't" because it just overwrites bytes. Even they are only "00"s. (Also usually) the strings are not fixed lenght but have a length field somewhere. As it's loading correctly, there might be no length field here and it just reads until a string terminating character but still the overwritten 00 might be relevant. Extending the file could work but this might mess up every required alignment. A workaround for this issue is to make every change in a string the same length as it was before. Of course, the best would be to reproduce it with only a single placed custom door lock and try it with only that one because - from what I saw - there were a lot of strings edited in the models.

Btw we are doing the same thing in dread. E.g. take the names

powerup_doublejump_mp_magnet01.bsmat
powerup_doublejump_mp_white__01.bsmat

They are named that weird way (first one is missing a _ while the second as two consecutives __ to match the name length of the original file names

powerup_doublejump_mp_glass_01.bsmat
powerup_doublejump_mp_opaque_01.bsmat

But better to try a) first :D

[dyceron]

Deleted all the custom door folders from the output romfs and it still broke.

[dyceron]

Update: not every shield is broken. Will test each one.

[dyceron]

I tested them all individually and they all work? But combining them all breaks. This doesn't make sense.

[dyceron]

This issue was fixed with #356