Pokemon Emerald: Adjust options

[Zunawe]

What is this fixing or adding?

In anticipation of #2614 being able to display more options on the main options page, I went through the Emerald options to add clarity and make things look a little nicer.

• Removing the newlines adjacent to the """s I guess makes them render differently on the site, to get the automatic intents between lines. Figured out why this is; reverted the change.
• Fixed the easter_egg option not having a display name.
• Made things more consistent overall.
• Clarified some options. Especially to add information that you wouldn't know without having seen the changelog.
• Changed valid_keys to lists so that they're ordered for the user's benefit.
• Removed some sections on OptionSets that don't need to exist on the website.
• Added a full alias for HM and TM compatibility.
• Downgraded HmRequirements from TextChoice to Choice, since custom entries have no effect.

How was this tested?

Generated templates, read through the options page on the site in a branch with #2614 also merged.

[PoryGone]

Removing the newlines adjacent to the """s I guess makes them render differently on the site, to get the automatic intents between lines.

Is this behavior not a WebHost bug?

[Zunawe]

I'm unsure. I didn't try to track down why the appearance is different, I only saw that it was when comparing my own option tooltips with the one for progression balancing.

[Exempt-Medic]

That definitely should be some kind of bug, since it means violating PEP8 is ideal

[Exempt-Medic]

I assume you're aware of this, but just in case, removing the lists of valid keys from the option descriptions means that template yamls will not be easily usable on their own

[Zunawe]

Yeah. The tooltip is just cluttered and long with the list of possible values included. I'm considering inverting the option so that including the value makes the roadblock present, and then setting the default value to all true. That way the template automatically shows all options. But that's a breaking change, so I wouldn't want to do it in this PR.

I'm removing waiting-on: other because this PR isn't dependent on 2614, it's just relevant to a future where 2614 is merged. It would be better if it didn't have to wait on 2614 so that the clarifications make it in.

I also might even consider this a docs PR instead of an enhancement, but that distinction isn't really important here.

[Exempt-Medic]

It's definitely mostly docs. But there's also valid_keys, TextChoice, and the full aliases. I also will still say that several of these options now violate PEP 8:

Note that most importantly, the """ that ends a multiline docstring should be on a line by itself:

[Exempt-Medic]

Since option set are now sorted on webhost, you could remove those changes

[Exempt-Medic]

There is also no display difference between these, so your multiline docstrings are fine to put the closing """ on a separate line.

    """Adds Badges to the pool

    Vanilla: Gym leaders give their own badge
    Shuffle: Gym leaders give a random badge
    Completely Random: Badges can be found anywhere"""

    """Adds Badges to the pool

    Vanilla: Gym leaders give their own badge
    Shuffle: Gym leaders give a random badge
    Completely Random: Badges can be found anywhere
    """

[Exempt-Medic]

Several of these changes are also 120-character line length violations that don't actually change the display.

    """Adds most key items to the pool. These are usually required to unlock a location or region (e.g. Devon Scope, Letter, Basement Key)"""

    """
    Adds most key items to the pool.
    These are usually required to unlock a location or region (e.g. Devon Scope, Letter, Basement Key)
    """

    """Adds berry trees to the pool. Empty soil patches are converted to locations and contribute Sitrus Berries to the pool."""

    """
    Adds berry trees to the pool. Empty soil patches are converted to locations and contribute Sitrus Berries to the pool.
    """

[Zunawe]

Since option set are now sorted on webhost, you could remove those changes

While technically true (now that it would also retain order if keys are ordered), I see no real harm in keeping them explicitly sorted. If I add other "shortcuts" to the blacklists, I may want to order them in a manner other than alphabetical.

---

There is also no display difference between these, so your multiline docstrings are fine to put the closing """ on a separate line.

I did a little more investigating and found out why there's a difference if you have a new line between the opening """ and the first sentence. (I think this is only relevant behavior for 2614.) It's the use and behavior of textwrap.dedent, which removes whitespace after a newline according to how much whitespace there is on the first line. So if your docstring starts with \n , it strips 4 spaces from the start of every line. And if your docstring starts with an alphabetical character, it does not strip any whitespace. Which is why the progression balancing docstring looks indented, because it still is.

So one could add extra indentation in their own descriptions if they wanted that behavior. I think I'm going to settle on using - as bullet points to distinguish lines with option values and say that the docstrings for generic options should probably eventually get updated.

---

Several of these changes are also 120-character line length violations that don't actually change the display.

As long as linebreaks in the docstring correspond with linebreaks on the web page, I'm probably going to mostly ignore the 120-character limit for specifically these docstrings. Maybe I'll set a hard limit of like 180, since most long sentences or groups of long sentences can probably fit in there or be split into new sentences or paragraphs. I also don't want to add custom "matching" line breaks because it doesn't work if the CSS changes out from under me. The better option would be for the webhost code to support merging multi-line sentences somehow.

[Exempt-Medic]

Looks awesome to me!