-
Notifications
You must be signed in to change notification settings - Fork 29
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
fix some crashes. #158
fix some crashes. #158
Conversation
Hey, can you give me some additional info about the crashes? I want to inspect the problem and see if there are other places that need fixing too. |
@peter-kish Yes, sorry, this is just the same thing as the PR I closed. I'm not sure if you saw my comment on it. Basically this happens when switching scenes (which deletes the current scene) because you are then trying to access something that doesn't exist in memory and has already been freed (because I assume it doesn't delete everything at once). From my understanding, you have to check for null because I would recommend reading through this PR for a better explanation: godotengine/godot#73896 Also, All good if you just want to make the changes yourself if that's easier than me opening PRs. |
@LeeWannacott Cool, thanks! This gives me some additional insights:
|
@peter-kish here is your two bugs reproduced (one for the inventory grid and one for when item is in item slot) in minimal project with video attached: Minimal reproduced project (WASD to move, you are a blue square your inventory is a blue square, the next world is a bluer square IGN reviews 10/10). It also has the dragging item is no where near the cursor bug as a bonus #160 😅 Note: I deleted my prior comment because it was misleading there are two bugs not one (well three if you count the drag item one) |
Great, thanks! Seems like some unnecessary |
Ok, I figured out that the main reason why these crashes were happening in your examples but not in mine is the scene structure. The order/hierarchy of nodes determines the order of their deletion and there were some cases I didn't cover when testing (cases where you'd get a crash) because I was always using the same scene structure, which was different from yours. But I think I came up with a more general solution to this problem: Instead of adding such checks on places where the plugin crashes, I added the checks in all classes that can be created by the user and also depend on some nodes inside the scene tree to function properly. This is because it is difficult to guarantee that any of those nodes will be alive and in proper state at any point, especially when switching scenes. Another thing I did was to do explicit I pushed the changes to the dev_v2.4.2 branch: 3f784f8 (I might include a few more fixes in v2.4.2 before I merge it to |
v2.4.2 has been merged. Will re-open this one if crashes still happen. |
No description provided.