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

Interacting With Previous State Prevents Placement #97

Closed
MMosley502 opened this issue Apr 18, 2022 · 7 comments · Fixed by #113
Closed

Interacting With Previous State Prevents Placement #97

MMosley502 opened this issue Apr 18, 2022 · 7 comments · Fixed by #113
Assignees
Labels
bug Something isn't working priority This issue should be focused on first

Comments

@MMosley502
Copy link
Collaborator

Current Behavior

If a previous state in the tree is accessed after a case rule has been used part or all of the current board will become unmodifiable. Image of unmodifiable state included:
image

Expected Behavior

The current state should still be modifiable.

Steps to Reproduce

Open a nurikabe a file. Create at least one valid state then use case rule. Once case rule has been used select a state before case rule and change and revert a tile in it. The current state after the case rule will now be unmodifiable.
Attached files with unmodifiable states:
CaseRuleError.zip

@MMosley502 MMosley502 added bug Something isn't working nurikabe labels Apr 18, 2022
@cjreed121
Copy link
Collaborator

Looking at your image, it appears you were selected on the blue circle in the TreePanel. If you want to make a change to the board you would do it on an arrow which can be assigned a rule. So this is actually expected behavior that you receive the unmodifiable state message. I'm closing this issue due to this.

@Bram28 Bram28 reopened this Jun 6, 2022
@Bram28
Copy link
Member

Bram28 commented Jun 6, 2022

No, this is a real and annoying bug: if you are on the transition you still cannot select squares at times ... and I think it indeed has to do with the case rule. I myself and several students have run into this.

@charlestian23 charlestian23 added the priority This issue should be focused on first label Jun 6, 2022
@charlestian23 charlestian23 self-assigned this Jun 6, 2022
@charlestian23 charlestian23 changed the title Interacting With Previous State After Using Case Rule Prevents Placement Interacting With Previous State Prevents Placement Jun 6, 2022
@charlestian23
Copy link
Collaborator

charlestian23 commented Jun 6, 2022

A separate occurrence of the same bug:

Current Behavior

Modifying the previous transition of some node renders the node after that node unmodifiable.

Expected Behavior

Modifying the previous transition of some node should not render that node unmodifiable.

Steps to Reproduce

2022-06-06.16-49-09.mp4

unmodifiable_bug.zip

@charlestian23 charlestian23 pinned this issue Jun 6, 2022
@charlestian23
Copy link
Collaborator

I'm going to remove the Nurikabe label since this bug isn't related to something about Nurikabe, and I think it's moreso related how Legup in general deals with users modifying transitions.

@Bram28
Copy link
Member

Bram28 commented Jun 9, 2022

Here is a very easy reproduction. Start with:

image

Finish the 1 room (it also works if you just make 2 of the 4 squares around it black)

image

Go back to transition:

image

Take back some of the changes you made:

image

Select board state:

image

... and now you cannot modify the other squares around the 1!

Note: I had thought earlier that it has something to do with the Case rule (that's what Matt thought as well when he created this issue), but it doesn't seem to have anything to do with that. It's what Charles says: something with taking back modifications to squares in an earlier transition ... when you do that, the squares should become modifiable again, but they don't

@Bram28
Copy link
Member

Bram28 commented Jun 9, 2022

And yes, it took me 10 second to reproduce something similar in Light-Up... this is a general LEGUP issue!

@cjreed121
Copy link
Collaborator

Thanks for the steps. I was able to reproduce it with @charlestian23 steps. I think I have a fix for it though in #113.

@charlestian23 charlestian23 unpinned this issue Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority This issue should be focused on first
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants