Optimized Alfheim portal multiblock and pylon validation #4469
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also cleaned up portal particle logic and portal AABB creation code a bit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As per #4388, the Alfheim portal block entity remembers its orientation and caches its pylon location until either the number of valid cached pylons drops below the minimum required amount or mana is supposed to be consumed.
There is a functional change with this PR, which should not be relevant in most cases:
If you were to build two intersecting portal structures sharing the core block, the portal would originally prefer the one opening in Z direction, and would jump to the one in X direction only if the other had missing frame blocks.
Now the portal will still prefer the Z direction, if both are an option when opening the portal, but it will no longer jump between the two as the Z portal's frame is broken or repaired. Instead, if the active portal's frame is broken, the portal always shuts down. If it is opened again while the "Z frame" is still broken, it will use the "X frame" instead and stick with that for as long as it stays open, even if the Z frame is repaired later.