Split Tracker Services & Regions

[MattEqualsCoder]

Still a WIP. UI is pretty broken, and I need to do a ton of testing.

Basically, this implements the following:

• Split tracker functionality into multiple services
• Split dungeons into four interfaces IHasTreasure, IHasReward, IHasBoss, and IHasPrerequisite
• Updated the database and lots of the code to reflect this
• Rather than listen to larger events from the tracker, I'm updating it to listen to events on specific locations, bosses, etc.

Todos:

• Fix UI (bosses not showing up properly, Hyrule Castle's key logic seems messed up)
• Test, test, test
  • Make sure works with keysanity turned on
  • Make sure multiplayer still works
  • Make sure autotracking all types of things works (items, bosses, & rewards)
  • Make sure plandos still work
• Convert old database entries to the new format
• Try to see if I can get it so that the unit test matches up

[CPColin]

This all seems sensible so far!

[Vivelin]

Almost there!

So far, I'm a fan of moving more logic into the object classes themselves (Boss, Item, etc.).

I am more than a little confused now about the existence of ItemService and TrackerItemService, or WorldService and TrackerLocationService. Could these be consolidated somehow? Or at least a name that doesn't make it feel like we duplicated them?

[Vivelin]

I feel like the "ForArea" in the name here just adds confusion. Wouldn't just "IsKeysanity" be enough?

[MattEqualsCoder]

So TrackerItemService and TrackerLocationService are for tracking things, and the ItemService and WorldService are more for querying data from the world(s), so to speak.

I do think there's a bit of shuffling things around a bit, though. The ItemService also weirdly enough also has stuff to get Rewards and Bosses. We could move all of that stuff into the WorldService, and if we want to rename it to be like "WorldQueryService" or something, I think that would make sense. It's for looking up locations, items, rewards, and bosses in the world (or worlds if playing a multiworld).

That would leave the main important thing in the ItemService the creation and caching of the two progression states. So maybe that could be renamed "ProgressionService"?