Add Charge Boots to logic

[Pecomare]

This PR adds an option to place the Charge Boots in the logic.

For those unaware of the exploit: when the charge of the boots ends, there is a forward momentum. If you strike with the wrench right afterwards (which can be done in the air and is performed as if you were on the ground), you can momentarily keep that momentum with a side-jump or a dash with the Heli-pack. This speed gain allows you to gain access to some platforms without having the intended item (e.g. Maktar Jamming Array being reachable without the Tractor Beam)

I noticed I made some mistakes with some FPM logic so I fixed them in the PR.

[evilwb]

Taking this function as an example, I think it would be cleaner to do somthing more like this:

def maktar_photo_booth_rule(state: CollectionState, player: int) -> bool:
  if can_electrolyze(state, player):
    return True

  options = get_options(state, player)

  if options.first_person_mode_glitch_in_logic >= FIRST_PERSON_MEDIUM:
    if can_heli(state, player):
      return True    

  if options.charge_boots_in_logic:
    if can_charge(state, player):
      return True  

  return False

Putting the vanilla (usually most strict) logic at the top of the function and early escaping if true. From there, we can catch the less strict logic that is enabled, and if uncaught return False at the end. To me, this seems like a good strategy for handling these rule functions.

[evilwb]

Since we're starting to include multiple glitches, I think it's a good time to bring up my thoughts on how these options will be displayed to users.

Having each trick/glitch enableable piecemeal in the options (like OOT) is too much in my opinion. I would rather have global glitch logic difficulty with options Easy/Medium/Hard. This would be separate from any eventual combat logic difficulty which would also likely be split into Easy/Medium/Hard.

[Dinopony]

On other APWorlds I've worked on, using one global logic difficulty option helped a lot reducing logic complexity.
I started with Easy / Medium / Hard, and we ended up adding another Expert level because 3 wasn't enough.

The reasoning behind it was the following, with examples that would apply for RaC2:

• Beginner: Intended way of doing things, or things you can deduce from a casual playthrough
• Medium: Obscure knowledge, out-of-the-box thinking, unintuitive usage of game mechanics but no glitch involved (e.g. tight heli-pack glide, tight hyperstrike wrench jumps, simple macaroni & sideflip movement tech etc...)
• Hard: Simple to intermediate glitches allowed (e.g. most decoy glove clip-outs, most charge boots tech, most decoy proxies, pack switch, etc...)
• Expert: All known glitches allowed (e.g. hardest clip-outs, complex movement chains where keeping momentum is required, etc...)

This video is a pretty good showcase of most existing movement tech (and a bit more)

[Pecomare]

I understand how complex having so many options for each glitch can become.
I wanted each glitch to have its option so players can choose which they want to perform. I know I don't want to be forced to perform hard FPM exploits even if I'm okay with some other hard tricks.

But as long as things are clearly defined, I think we can go for that route of a single option for everything.
Maybe some exploits could be split into multiple difficulties depending on how tight they are at specific locations, as I did for FPM.

I haven't researched movement tech yet, so I like that linked video.

[Pecomare]

I refactored the logic according to your suggestion of having a global option with multiple difficulties.

I still have to look at the movement tech.
Do you prefer having these implemented in this PR or should I add them in another one / multiple ones ?

[evilwb]

I see going from FIRST_PERSON_EASY to GLITCH_LOGIC_HARD in a few places. Is this intended?

[Pecomare]

I looked at Dinopony's examples and thought most FPM should go in the same difficulty as Charge Boots tech, as I consider it some kind of glitch and not a simple movement tech.

[evilwb]

I've had some more time to think about this and it brings up some major problems with considering FPM in logic. It basically undercuts other more interesting tricks and glitches that we want to add into logic later. There are going to be many places where a location could be reached with some precise jump are movement tech but with FPM could done very easily making the overall glitch logic easy.

Obviously I've changed my mind on this so I'm not necessarily set in stone but here's what I think should be done.

1. Add FPM back as an option
2. Ignore FPM in glitch logic and treat it like a fun bonus option.

I think without other glitch logic this feels like removing a feature but as glitch logic gets more fleshed out, it will become more clear that FPM makes things less interesting. It is a least clear to me now that if FPM is in logic at all, it should be completely separate like you had it originally. I'm just not convinced that having special glitch logic just for FPM is worth the complexity, especially once other glitch logic gets implemented.

There's definitely more room for discussion on this. Just wanted to get my thoughts out there.

[Pecomare]

I agree on FPM being broken and making so much of the game trivial.
I like the idea of it being an option, but depending on the complexity increase of having it separated, maybe we could remove it altogether.
I think it might be as simple as adding something like the following in most checks:

if options.fpm and options.glitch_logic_difficulty >= GLITCH_LOGIC_MEDIUM:
    return True

[evilwb]

Looking pretty good so far.

Do you prefer having these implemented in this PR or should I add them in another one / multiple ones ?

Whatever works best for your workflow.

[Pecomare]

In that case, since I didn't know of all Charge Boots tech, I think I will add more to the PR, so that the feature makes much more sense than having only some FPM and some Charge Boots.

[cloudofdarkhole6]

Since i noticed this in updating the tracker for the previous change that only had FPM glitches in logic: with the locations on Tabora and Aranos each having gotten their own set of access_rules for logic, the special access_rules in Regions.py could potentially be removed as the base logic is included in the functions in Logic.py. Not sure if the overlap can cause any unwanted/unintended logic to happen.
Especially on Aranos since the "vanilla" logic in the function deviates from the general access of the planet

Access via region:
state.has_all([Items.GRAVITY_BOOTS.name, Items.LEVITATOR.name, Items.INFILTRATOR.name], world.player )

Example Plumber:
if (can_gravity(state, player) and can_levitate(state, player)): return True

Would Plumber require the Infiltrator or not? region says yes, location itself says no