-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add puzzle 012 #19
Merged
Add puzzle 012 #19
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
When there are multiple options for an exit portal, the user must decide, and the decision gets stored in beam state. That state was only being cleared when the beam was turned off, but it should be cleared whenever the step that decision is related to changes (for example, if the entry portal is rotated). This also cleans up the storage of these decisions in beam state, moving them into a portal specific key that the portal item will maintain.
After adding the ability to 'merge beams' using a single exit portal, I've noticed it introduces some unintended complexity such as allowing a single beam to merge into itself over and over. Perahaps instead of adding more complexity to check the beam to make sure it isn't self, this functionality should instead be split into a separate item which allows for the merging/splitting of beams, and portals should retain their much simpler 'only one beam can exist in a given direction at a time' rule.
Items can now specify 'immutable' in the state configuration, which should basically act the same as setting each individual modifier key to false (e.g. movable, toggleable, rotatable, etc). Beam and wall items will have immutable set by default. Item IDs are now retained in cache, making them stable IDs. Previously, item IDs were re-generated when the page was refreshed, which meant that if an item had been moved its ID could change. The generation and storage of item IDs on the loading of a puzzle is not stored as a delta, so it won't show up as a move and won't be undo-able. Portal logic has been reverted back to just checking if a direction is already occupied. This means beams cannot be merged through an exit portal. That functionality will be added later as a separate item. Additionally, portal directions cache is now cleared if a portal is moved, since the beams connected to that portal will need to re-evaluate their histories. Swap now requires tiles to contain movable items, instead of any items.
This allows the mask to be re-evaluated when it gets dequeued, with the potential to cancel the mask. This is because state can change in between when the mask is queued and when it gets processed. For example, if multiple portals are reached at the same time, the resolution of one of the portals may cause a subsequent portal mask to no longer be valid.
Still needs test coverage, but I have confirmed that it is solvable as is. An additional change in this commit is the addition of an "is not immutable" filter for modifiers when displaying the indicator badge on tiles. I think the primary purpose of the indicator is to show the user they can interact with something in that tile, and immutable modifiers are not interactable, so it just creates noise. The lock and immutable modifiers mostly apply when moving something anyways.
This also fixes a few bugs: - when getting color elements for a newly selected tile, if it contained merge beams it was throwing an error using step.color instead of step.colors. - the portal collision logic in beam.onCollision was not handling every case. - state index wasn't being updated correctly if keepDelta was false on update. - state actions like undo and redo weren't properly prevented even if they were disabled visually. The reset action was also never disabled in cases where it should be. - the puzzle mask queue was not being emptied when the puzzle was reloaded, which caused some strange undo/redo behaviors.
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.
This puzzle further strengthens the rules introduced in previous portal puzzles. It is also the most difficult portal puzzle to this point.
This PR also includes a number of other bug fixes and improvements:
step.color
instead ofstep.colors
(which is an array).beam.onCollision
was not handling every case.keepDelta
was false on state update.