Mysterious C++ errors without any stack trace

kuligs2

jobrant try to find when it starts to throw and breakpoints from that code part.

try deleting .godot directory inside your project dir and let it rebuild cache or something

Toxe

jobrant You could build the engine + editor yourself, run it in an IDE (or debugger actually), set a breakpoint at that specific line and then look at the stack trace.

Or, if your project structure supports this, you could run individual scenes instead of running the whole project.

xyz

Other than compiling the debug version of the engine, your best bet is to simply strip the project down piece by piece until the error disappears.

Zini

Actually the best bet would be a git bisect. Was really easy on Godot 3. Haven't tried it with Godot 4 yet, but I assume it won't be much worse.

xyz

Zini I suspect the OP might not be using version control at all.

Zini

xyz This is possible. That would be an opportunity to learn about the importance of always using version control.

xyz

Looking at the source. Assuming your script code is not directly calling Node::is_greater_than(), it's internally only called from scene/2d/skeleton_2d.h, scene/gui/control.h and scene/main/viewport.cpp.

Start with viewports if you use them.

jobrant

I do use version control! But it's something that started happening silently in a long time ago, I go really far back and it still happens. I suspect that it's something that appeared when a new version of Godot showed up on Steam.

Thanks @xyz this really helps me!

xyz

jobrant Don't change engine versions mid-project.

Toxe

xyz Nah, always keep up to date. (But do it wisely.)

jobrant Don't use the Steam version. Download the versions from the Godot page and try older versions of the engine and your code.

xyz

Toxe xyz Nah, always keep up to date. (But do it wisely.)

Fine for relaxed hobbyist projects. If you're building an actual product on a schedule though and more so if a team is involved - not a very wise idea. Game engines are not bog standard consumer apps. The concept of "up to date" doesn't really apply to them.

Toxe

xyz Fine for relaxed hobbyist projects.

I assume that is what most people here are doing who ask questions. But as I said: Wisely. 😉

xyz

Toxe It's a bad habit in any case. Nothing to be gained from constantly updating to the newest version during a project. Nothing than potential problems that is.

Toxe

xyz Nothing to be gained from constantly updating to the newest version during a project

Generally speaking that's a hard disagree. In terms of game engines it might be tricky though, yes.

xyz

Toxe In terms of game engines it might be tricky though, yes.

The main problem is that every update will cost you a mostly unknowable amount of additional resources you wouldn't need to spend otherwise. Resources are precious when developing a game, especially for indies. Going nonchalantly on resource expenditure can break the project entirely. Updating also increases various other types of risk. For example the risk of problems showing up way after the update has been done and tracking back would just waste even more resources. The cost of adapting the project to an update also increases as the project grows and attains more and more nooks and crannies. The rational approach is to find the fully adequate engine/version beforehand, and stick to it throughout the production.