Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core: rip out RegionType and rework Region class #814

Merged
merged 59 commits into from
Feb 14, 2023

Conversation

alwaysintreble
Copy link
Collaborator

Unsure if the special handling in the spoiler class can be fully ripped out so I worked around it for now. Also unhappy with how I handled getting region entrances so maybe this could be changed to a Region method instead of a function in main?

@alwaysintreble
Copy link
Collaborator Author

Went ahead and added a Region class rewrite to this PR,

@alwaysintreble alwaysintreble changed the title core: rip out RegionType with special LTTP handling core: rip out RegionType and rework Region class Jul 24, 2022
@@ -1254,23 +1250,31 @@ def parse_data(self):

self.locations = OrderedDict()
listed_locations = set()
lw_locations = []
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of moving more data around within this function, please use or create World hooks

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire function is specific for LTTP handling as far as I can tell and out of scope for this PR. Planning to revisit it after moving each of the options it parses here.

Copy link
Member

@black-sliver black-sliver Feb 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree with treble on this one: getting rid of the lttp details in BaseClasses / other worlds is separate from getting rid of the handling here. Rewriting the whole function is kind of a bigger task (assuming we want to find a good, generic solution) and future change to this can be made without breaking the API once this is merged.

BaseClasses.py Outdated Show resolved Hide resolved
Copy link
Contributor

@Ijwu Ijwu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems good. Is it possible to get a generation to run for every game something like 30-50 times to ensure things look good logically? Or some other testing mechanism, if possible.

BaseClasses.py Outdated Show resolved Hide resolved
@@ -25,10 +25,12 @@ class ArchipIDLEWorld(World):
"""
game = "ArchipIDLE"
topology_present = False
data_version = 4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Member

@black-sliver black-sliver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think we should merge this sooner than later, as it removes a lot of jank from writing worlds.
However I think all of my (and zerk's) comments should be addressed plus I don't see and update to Docs. Was the current implementation never documented, or did you forget about updating world api.md?

worlds/zillion/region.py Outdated Show resolved Hide resolved
worlds/smw/Rom.py Outdated Show resolved Hide resolved
worlds/sc2wol/Regions.py Outdated Show resolved Hide resolved
worlds/archipidle/__init__.py Outdated Show resolved Hide resolved
worlds/dkc3/Regions.py Show resolved Hide resolved
worlds/hk/__init__.py Show resolved Hide resolved
worlds/archipidle/Rules.py Show resolved Hide resolved
worlds/archipidle/Rules.py Outdated Show resolved Hide resolved
@black-sliver
Copy link
Member

@Berserker66 this looks good now. The one big remaining question, besides merge order, is at what point we want to have the world API semi-stable (i.e. implement backwards compat and throw Deprecation Warnings): when we merge this, the APWorlds currently distributed will not work anymore, and when the APWorlds get updated, they won't work with current stable anymore.

# Conflicts:
#	worlds/lufia2ac/__init__.py
@Berserker66
Copy link
Member

@Berserker66 this looks good now. The one big remaining question, besides merge order, is at what point we want to have the world API semi-stable (i.e. implement backwards compat and throw Deprecation Warnings): when we merge this, the APWorlds currently distributed will not work anymore, and when the APWorlds get updated, they won't work with current stable anymore.

Not sure yet. I want to try and find time for the .apworld installer soonish, which could do some version checking in there - and would run unittests so it would bubble up some of these issues.

@Berserker66
Copy link
Member

image

@Berserker66
Copy link
Member

oh yeah, might as well ping @espeon65536 as the OoT changes go a bit beyond mere fixing.

Copy link
Member

@black-sliver black-sliver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but i did not test OoT either

@Berserker66 Berserker66 merged commit 7cbeb84 into ArchipelagoMW:main Feb 14, 2023
kindasneaki pushed a commit to kindasneaki/Archipelago that referenced this pull request Jun 28, 2023
@alwaysintreble alwaysintreble deleted the region_type branch July 19, 2023 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects: core Issues/PRs that touch core and may need additional validation. is: refactor/cleanup Improvements to code/output readability or organizization.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants