-
-
Notifications
You must be signed in to change notification settings - Fork 20k
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
[TRACKER] Error macros with cryptic messages due to not having proper custom messages defined #42719
Comments
Add #41493 . I've also made a PR for the same |
Any idea where the error macro call should be? Is it at Line 1374 in 6c173e2
ERR_FAIL_COND_V_MSG(!f, String(), "File must be opened before use. In case you are on the Android, check if the app has file read-write permission."); .Or should the error be somewhere in Android platform-specific part of codebase? |
@Anutrix Maybe we should change the error message with an |
What's the difference between |
@Anutrix We probably want to use |
I would just like to point out that the links at the bottom of the error macros page in the master branch docs are dead as of #43385 |
Yes, most references to |
@LightningAA "high-end platform" means GLES3. We intentionally use a generic term as there may be several high-end platforms in the future (such as Metal or Direct3D 12). That said, "high-end renderer" or "high-end backend" would be a more fitting term here. Also, since 3.2.x won't get any additional renderers, it makes sense to reference GLES3 there instead. I just don't think this will apply to 4.x and later 🙂 |
I think it would make a lot more sense if it said something like |
|
This comment has been minimized.
This comment has been minimized.
JacobianEntrySW: Condition "mAdiag <= realt(0.0)" is true. I'm getting hundreds of these errors per second. I'm using lots of connected RigidBodys, with (mostly) 6DOA joints. GodotPhysics mode. I have absolutely no idea what this means. I know its something to do with joints, but no idea what. The message is too abstract to fix the issue. This clogs up memory - after 10 mins my project will crash. Here is the entire paste from the debugger E 0:00:00.967 JacobianEntrySW: Condition "mAdiag <= realt(0.0)" is true. |
Closing as there's not much actionable anymore in this old issue, so it's misleading as a |
|
Does it still happen in 4.2.2? |
And since this is basically always caused by changes in an edited scene, it should probably mention this. Telling a node has just vanished is pretty scary to a new user. I believe it was also changed to move the node to the root of the scene, so it should probably mention this instead. |
Regarding this "Response header too big." message, were you using an external script editor when it happened? If so, which one (and which version of their respective extension were you using)? Were you doing anything specific in the external editor when the editor printed the message? |
Nope, we only use the Godot Editor for our scripts. This error was something my co-developer had in Godot, and when I asked him if he had any clue what could be causing it, he said he had no idea. So I'm afraid I don't currently have any other info. If we ever figure it out, I'll let you know. |
Godot 4.2.2 This seems to mean that you're trying to set a Node's
|
No it means trying to set the owner of the node to itself, not its owner, it should have a description though saying that, it's equivalent to the GDScript |
You're completely right, we read the script wrong. Setting a node as it's own
Or something along those lines! |
Didn't add paths to the error messages in this PR, that's a major change in general to error messages so should be handled in a dedicated PR IMO (it's also not always helpful, or available) I think for adding node paths or names to errors it might be useful to instead add some helper macros or functions to make it standardized, rather than adding paths in various places, that would help clarify things and make it robust (the existing internal |
I completely agree, although such a large change will still take quite a while to be implemented, and would probably require a revisit to nearly all errors in the Engine. So for the meantime, if the information such as NodePaths or Node Names, etc are available, I would definitely add them. The manual additions can always be removed once a PR for such a standardized function/macro is implemented. Especially for extremely generic functions such as |
When calling
|
That's not what the error checks, the node replacing with cannot have a parent, will add it to my PR |
Somewhere along the line something failed to instantiate. Would love information on what resource or scene failed, so I can make sure to reimport/restart, etc. Pretty sure somewhere a script failed to parse temporarily, which caused multiple scenes to become invalid. While fixing the script would solve the errors, it would still be helpful to know which scenes failed and why. Otherwise these errors don't add much, apart from snowing under the real culprit. |
Please show the surrounding errors, they might say what's going on |
|
Ran an |
If you stumble upon difficult-to-understand error messages (regardless of your skill level with Godot), please report them here. In your comment, make sure to state:
Note that this issue isn't about reporting bugs, but reporting cryptic error messages. This issue is about improving error messages so users can figure things out by themselves more easily. If you stumble upon a bug, please open a dedicated issue instead of commenting in this tracker issue.
See #24199 for background.
Issues
File.eof_reached()
causes infinite while-loop on Android when read/write permissions aren't set #42959 (Added a more descriptive error message for file operations in core_bind.cpp #43076)Viewport
that is already active #50382For contributors
Even if you're a beginner in C++, you should be able to add error macros. This is why this issue has a
junior job
label 🙂To add error explanations to existing errors, search for their origin in the source code (by reading the automatically-generated error message), suffix the error macro with
_MSG
and add a parameter with a custom message at the end.We recommend adding context (such as provided arguments versus expected ones) whenever possible. Some examples:
Here are some real-world examples of improving error explanations: https://github.com/godotengine/godot/pull/41352/files, https://github.com/godotengine/godot/pull/35862/files
See Error macros in the documentation for more information.
The text was updated successfully, but these errors were encountered: