-
Notifications
You must be signed in to change notification settings - Fork 185
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
Removing/Renaming a file causes patch viewer to crash #710
Comments
I have determined the cause. The remove list in a patch contains either string IDs or Instances, but when writing the patch visualizers I forgot and only handled Instances. Edit: This was the source of the locking up, but even with this fixed the patch viewer still has more problems discovered below that are now tracked in #714. |
Oh, this gets tricky. When viewing the patch that was just applied, the instanceMap will no longer have a mapping for that ID, since it was just removed. |
The only way to be able to display information that has since been deleted is to store it, but I really don't want Rojo to need to store tree info on every object you have just in case you delete/rename it... Perhaps the act of deleting could be modified so that when deleting something, we grab its info right before sending it to the abyss. Then that info it given to the patch viewer until the next patch comes in. |
I'm going to solve this in two PRs, since the string/instance handling is one fix and the tracking post-removal is a whole other big problem |
I created #714 because these are two distinct problems. |
When an object is deleted in a patch, it is either represented with an ID or an Instance. On initial sync, removals are instances since the map does not contain those instances. Later removals of managed objects use an ID. The patch visualizer only handled instances, so this fixes that. Closes #710.
…x#713) When an object is deleted in a patch, it is either represented with an ID or an Instance. On initial sync, removals are instances since the map does not contain those instances. Later removals of managed objects use an ID. The patch visualizer only handled instances, so this fixes that. Closes rojo-rbx#710.
When renaming a file that's tracked by Rojo, the patch viewer breaks. I'm not sure when this behavior was introduced but it was probably recently.
This can be easily reproduced:
rojo init
If the patch viewer is not open, the rest of the plugin will continue to function but the patch viewer will no longer function.
The text was updated successfully, but these errors were encountered: