Closed IThisGuyHere closed 2 months ago
The modify_scrap_spawns true behavoir is intended, grabbing the custom ap apparatus at a custom moon will send that moon's check. That should also happen when modify_scrap_spawns is false, but instead generation fails, which definitely isnt intended. Ill see if I can make the custom apparatus change names per moon to try and make it more clear that custom apparatuses from different moons are meant to be different checks.
Thanks for the clarification. After reading your response, I tested a multiworld with modify_scrap_spawns set to True and observed some strange behavior in-game. I landed on the custom moon Gratar and found the AP Apparatus, but it had the wrong display name (AP Apparatus - Adamance). Taking off with it in the ship completes the check for AP Apparatus - Custom but not AP Apparatus - Gratar. I then landed on the custom moon Desolation and found its AP Apparatus, but taking off with it in the ship did not complete any check. Running "progress" in the terminal shows that I found the trophies for both moons, but the scrap checks are incomplete.
Should be fixed in the most recent version, reopen this issue if you run into any more bugs
Expected behavior: Multiworld generates a check "AP Apparatus - {moon}" for each vanilla moon and one check "AP Apparatus - Custom" if any custom moons are present.
Actual behavior: Multiworld attempts to generate a check "AP Apparatus - {moon}" for each vanilla and custom moon. If modify_scrap _spawns is true, the multiworld generates one impossible check for each custom moon (because custom moons do not have AP Apparatus items specific to their name). If modify_scrap_spawns is false, the multiworld fails to generate.
Description: When generating a multiworld with scrapsanity enabled and custom moons present in the logic string, the Lethal Company apworld attempts to create checks for an item called "AP Apparatus - {moon}" for each moon, where {moon} is replaced with the moon's name (in locations.py). This is expected for vanilla moons, but with custom moons, these checks reference nonexistent items. For instance, if Asteroid-13 is a custom moon, the multiworld tries to create a check for "AP Apparatus - Asteroid-13" but fails because the item does not exist. I suspect part of this problem originates from the current logic string, which groups all moons into the same "moons" category with no way to differentiate between vanilla and custom.
Possible fix: Introduce a portion of the logic string that includes only vanilla moons. Adjust locations.py to generate the checks for vanilla moons and check if any custom moons are present. If so, it would create one additional check for "AP Apparatus - Custom".
Log from recent generation: Generate_26898102850718062341_2024_08_06_13_36_25.txt