WebHost: Refactor weighted-settings.js

[nex3]

What is this fixing or adding?

This moves most of the infrastructure into two classes:

• WeightedSettings covers the settings page as a whole. It tracks the
  user's current settings in local storage as well as the game data
  from the server so they don't need to be manually passed around from
  function to function.

• GameSettings covers the settings for a single game, and provides a
  view of the current settings and the game data just for that game.

How was this tested?

Manually tested adjusting settings, reloading from local storage, exporting to YAML, etc.

[LegendaryLinux]

Aside from moving everything into classes, what benefit do we gain from this? This doesn't necessarily improve readability, and there is no new functionality present.

[nex3]

In addition to being slightly more efficient thanks to loading from localStorage less frequently, it makes it a lot easier to access data and settings for the current game when building each block of settings for each game. For example, instead of having to pass settingData.games[game].gameLocations into buildWeightedSettingsDiv(), buildLocationsDiv(), and buildHintsDiv(), each of these functions can now access them through this.data.gameLocations.

This is particularly helpful when adding new data that needs to be passed through these functions. For example, I have a work-in-progress commit built on this that makes location_name_groups and item_name_groups available in location and item lists through the web UI (they're already available to YAML):

and another that adds the ability for worlds to provide descriptions for individual items and locations (the tooltip shows up on hover of course):

Both of these are much easier if you can just directly access the data from this.data rather than having to pipe it through the various functions. I'll send them out later, but I wanted to make sure this refactoring approach was good first.

[LegendaryLinux]

I was trying to prevent change for the sake of change. I'm down if you have work in the pipeline which depends on these features. I realized as I was typing this I forgot to test whether changing a single setting and reloading the page preserves the setting change. So I'll do that later tonight, and merge if all is good.

[LegendaryLinux]

During some testing, I discovered a bug. The item pool quantities are not preserved upon a reload, and will always revert to 1. When exporting a .yaml file, the quantities are always listed as 1, even if the input contains a different quantity. The games used for testing are:

• The Legend of Zelda: A Link to the Past
• Factorio

Link to the Past is visible in the screenshots below.

As seen on the weighted-settings page:

As seen in the exported .yaml file:

[nex3]

Oops, fixed! I'd missed one call to updateItemSetting() in a callback. I did a search to make sure there weren't any other update...() calls that I hadn't touched.