C20170101 is unbeatable.

[thatguycore]

[dungeon-D6-B1] Misery Mire - compass.....................................................Lamp

Heart Container (Moldorm).................................................................Fire Rod [dungeon-L3-1F] Tower of Hera - first floor...............................................Big Key

You need lamp or fire rod to get the big key in Hera to get to Moldorm to get the fire rod. You need fire rod or lamp to get to the compass room in Misery Mire.

[BlueViper85]

This seems related to #266 since it involves Moldorm having the fire rod and MiseryMire having Lamp

Does this room have CanLightTorches associated with it?

[BlueViper85]

Yes it does, so I'm guessing this is the same bug after all.

[BlueViper85]

Looking further at the logic for the TowerOfHera I noticed something.

CanDefeatTowerOfHera(have) has this:

return CanEnterTowerOfHera(have) && (!LocationHasItem("[dungeon-L3-1F] Tower of Hera - first floor", InventoryItemType.BigKey) || CanLightTorches(have));

So effectively it's first checking to make sure you can enter Hera, obvious enough. Then it checks EITHER that the big key is NOT on the first floor OR that you can light torches.

What it DOESN'T do is check to make sure that if the Key is on the first floor that you can access it. That's technically handled by the logic for that chest. HOWEVER, by changing CanDefeatTowerOfHera to check this, it's also confirming that Moldorm can't be beat unless you can access that chest (if it has the key in it).

I changed it to this: return CanEnterTowerOfHera(have) && ((LocationHasItem("[dungeon-L3-1F] Tower of Hera - first floor", InventoryItemType.BigKey) && CanLightTorches(have)) || LocationHasItem("[dungeon-L3-2F] Tower of Hera - Entrance", InventoryItemType.BigKey));

I tested this code change and it seemed to resolve the issues with this seed and the other seed.

Can anyone see any flaw in my logic or otherwise have any concerns?

Edit: I didn't add the actual code changes I made, so I added that.

For the sake of clarity, I also wanted to add that the && before the CanLightTorches(have) would only be evaluated if the Big Key IS in the 1F chest. If it's not then it won't worry about if you can light torches and then double-checks that the chest does NOT have the Big Key so that if 1F doesn't have the BigKey this function will still return True.

[Radagast81]

I reviewed this logic as well and have no concerns with your changes. Nonetheless it's now clear why these logic problems now appear and haven't before: The original version of the check returns true as long as the big key isn't put into a chest and changes to false afterwards, whereas the second logic allways gets the right solution (false) as long as the big key isn't put. So there are in generel 2 aproaches to solve this issue: 1) Review all the logic that contain keys and consider the temporary changes through the randomizer process (also the logic becomes more complex through this). 2) First place all the keys (big and small) without considering the can_access logic and afterwards place the items (then the 2 logics are equivalent and the issues will no longer accure).

I would prefere the second aproach, as the logic keeps to be simple and you don't have to worry that through the placement of a key the seed becomes unbeatable...

[ChristosOwen]

Same bug as #266 so going to link this one there and close this, and paste Radagast81's comment.