Godot: "core\class_db.cpp:324 - Condition ' !ti ' is true. returned: StringName()" is spammed to console.

[hilfazer]

Godot version:

525384d8cc45a0976e0afb862c8a54244bbd72e7,
v3.1-alpha1
06667b2fcfcf130a9b9e8974c1c7ac0c9ae1de0a - 12-09-2018

OS/device including version:

Windows 7 Pro SP1

Issue description:

Message "core\class_db.cpp:325 - Condition ' !ti ' is true. returned: StringName()
" gets spammed to output console when game is running and node gets selected in Scene/Remote tab.

Some nodes like Node / Node2D will produce this message if any script is attached to them but will not without a script.

Steps to reproduce:
Create new project, add a 'Node' to scene, add default script to it, run the game and select 'Node' node in Scene/Remote. Message starts appearing in console.

If 'Node' is already selected, select 'root' and 'Node' again.

Minimal reproduction project:

https://github.com/hilfazer/Projects/tree/EngineIssues/Godot/ConditionNotTiIsTrue

[hilfazer]

It happens with 32 and 64 bit builds. It happens with 'release_debug' and 'debug' configurations.

[akien-mga]

Fixed by #21021.

[hilfazer]

I still have this issue.
SHA1 ID: 8c435a343e9739f30cb2e347df95835c91c1ff1a
I just compiled Godot, created new project and clicking 'root' still causes error spam.

[Skaruts]

I have this issue too (using latest nightly build downloaded about 15 hours ago).

I noticed it while testing a 3D scene. I can't perceive a pattern, but it happened to me as I selected the root node, which obviously doesn't have a script. Also when I selected any of the singletons. Then it stops on selecting a spatial that does nothing but hold other spatials in it.

[hilfazer]

There's a progress - i'm not getting error spam when selecting 'root'.
Node with attached script still causes message spam.
I've updated issue's description.

[akien-mga]

I saw that today in the remote scene tree too.

CC @willnationsdev, I don't have any direct clue about it but I think it started around the time class_name and related ClassDB features were implemented.

[willnationsdev]

I'm not sure if #21717 will fix this, but I know there's at least one is_parent_class() call that the PR fixes which could be related to this. It also simplifies any icon fetching that the remote scene tree might be doing.

[Piet-G]

This issue just won't die :( If someone confirms @willnationsdev 's pr doesn't fix things I'll go and take a look again.

[hilfazer]

Compiled it today and no change :(

[Piet-G]

I've been trying stuff all day and I just can't do it sorry guys. The root cause seems to be the wrong value winding up in the hint_string of a property so it's not a bug in get_parent_class. But I wouldn't know where it came from or how to fix it. So someone else has to figure this out.

[pixelriot]

I can confirm the bug for Linux and Windows build of 3.1.alpha.official.

[willnationsdev]

Ok, I don't know quite yet what the reason for the bug is, but I know this much.

In editor_properties, in the case where it is running the "parse_property" operation on the "script" property for the Node, there is a section where it gets the "should I open this in the new inspector" information for the property.

The slices of the open_in_new string and the p_hint_string string that it is accessing collide at a point where type is "SpatialMaterial" and inherits is "RES:res://Node.gd". Clearly, when the ClassDB then attempts to check whether the inherits 'type' is a SpatialMaterial, it will fail since inherits is a resource path rather than an actual type. HOW the p_hint_text for the "script" property on these nodes came to have a slice with the value of "RES:res://Node.gd", I have no idea. Is the hint string supposed to have that value, and if so, is there maybe some kind of indexing problem on fetching the appropriate slice?

Edit: Just checked, and the p_hint_string value itself is also "RES:res://Node.gd", so it's not a "fetch the appropriate slice" kind of problem.

Edit 2: The editor settings list that it's being compared to is "SpatialMaterial,Script", so it should eventualy get to comparing the "Script" portion with the type of the script, ideally resulting in something like ClassDB::is_parent_class("GDScript", "Script").

[Piet-G]

No the hint_string isn't supposed to have that value, in that case it is supposed to contain the type of the resource.

[willnationsdev]

Okay, so, during EditorInspector::update_tree(), it fetches the object property list. During this method, it calls _get_property_listv(p_list, p_reversed) on my Node with a default template GDScript at "res://Node.gd". By the end of this function, it has a script property with the "RES:res://Node.gd" value in the hint string. So, something about this line's internal content is getting funky.

Edit: buried within the GDClass macro for ScriptEditorDebuggerInspectedObject, we end up at ScriptEditorDebuggerInspectedObject::_get_property_list(List *p_list) and here as well, we encounter the "script" property already in the list with an incorrect hint string. Will have to check and see where this property list is initialized.

[willnationsdev]

Here's the culprit! Not sure why it's doing that...

[Piet-G]

@willnationsdev Yeah, the rabbit hole goes deeper, I got untill that point and then the question was where the value in pinfo came from. As long property usage is 17 hint string should be a type, which isn't the case there.

I'm sorry I forgot to report my findings here

[willnationsdev]

Seems like the data is being created in script_debugger_remote.cpp. Just forcing it to give just the path seems to mess other stuff up though, so will need to look into it further.

[Piet-G]

I wonder why adding the path is needed? It's so odd it just adds it without paying attention to propery_usage. I'll go take a look and see what I can find myself

[pixelriot]

Unfortunately the issue still exists, even with Godot 3.1 stable.
However, it only occurs for projects that where created with v2.1 and later ported to 3.0 or 3.1.

Any hints on how to track the error further would be much appreciated.

[holzmb]

Can confirm.
Ported from 2.1, now using 3.1stable and the errors are still here

[R0adRunn3r]

I can confirm this too, just ported a project from 2.1 to 3.0 and then to 3.1 stable and the console is flooded with those errors (even if the game plays without problems):

[pixelriot]

I was able to resolve the error spam for my case:

The scene that threw the error (my player scene) was preloading a resource like
var fireball = preload("res://player/Fireball.scn")

The _Fireball.scn_ had a Particles2D-child node that didn't have a propper particle material set up.
After fixing the particles material, the error spam stopped.

Maybe that hint can help others having the same issue.