"GetTrait" cannot be performed if the first letter of the trait name is lowercase
Closed this issue · 17 comments
Description
The first letter of the trait name seems to have been replaced by upper case when compiled.
Therefore, "getTrait" cannot be performed if the original first letter is lowercase. There is no problem if the first letter of the trait name is originally uppercase.
Armory Forum Articles
https://forums.armory3d.org/t/why-does-pause-unpause-trait-not-work/3920/
To Reproduce
Run the test file and press the spacebar.
Expected behavior
I want to work properly even if the first letter of the trait name is lowercase.
System
Blender:2.81
Armory:2020.2
OS:Linux
Test File
https://forums.armory3d.org/uploads/short-url/iyOLvYIBmqdcWg9tWuiFkK5ASh1.blend
Unfortunately, there is no good way around this issue as Haxe requires class names (and traits are classes, logic nodes are converted to Haxe code) to begin with an uppercase letter. Node trees in Blender do not have that restriction.
One way would be to print a warning to the console during export and (maybe) print another warning if someone tries to call getTrait() with a lowercase string. The latter might be a bad idea as it introduces slightly more overhead to the getTrait() function.
Another, probably prettier solution would be to check the node tree name on every change (Blender properties have an update listener) and automatically change the first letter of the node tree's name to uppercase (or show a warning). What do you think?
Edit: I did some research and it looks like the second solution doesn't work because the node tree name is not stored inside a property but as an attribute of that node tree data block and there is no easy way of listening to changes here (maybe a scene update handler or a depsgraph update handler could work here but that's probably not so good style). So I think the best way is to print a warning during export and to document this limitation in the wiki.
Thanks for the answers and the various tries.
So I think the best way is to print a warning during export and to document this limitation in the wiki.
I think this is enough.
I opened a pull request at #1569, thanks for reporting :)
Now, a warning is printed to the console during export, for this particular case it looks like Armory Warning: Logic node tree and generated trait names differ! Node tree: "state1", trait: "State1"
The cause of the error is easy to understand and very good!
Close after updating the wiki page.
Hi,
after the pullrequest has been accepted, I now get an error message
Node tree: "a.B", trait: "A_B"
I am not sure if the changes made take into account that traits can contain the "." to split them into different folders; probably the message should not occur when a "." is converted to a "_"?
Oh, didn't think about that. I will try to find a solution for this (node tree names can also contain dots I think, so we need another solution) but I have no time until Wednesday because of two important exams on Monday and Tuesday.
@blackno666 Are you sure this is a wrong behaviour? Haxe traits with a dot in their names don't lead to that warning (it's node related only) and node tree names with a dot are indeed converted as in your warning, they aren't organized in folders. You can look into the generated krom.js file in build_*/debug/krom/krom.js and search for A_B, there should be two lines that look like this:
$hxClasses["arm.node.A_B"] = arm_node_A_B;
arm_node_A_B.__name__ = "arm.node.A_B";In case that I misunderstood you, do you have an example file?
In Armory v2020.2 (
I get the error on a NODE trait, not a haxe trait: Armory Warning: Logic node tree and generated trait names differ! Node tree: "my.node", trait: "My_node"
So, you're right, this is not organized in folders, but the warning should not appear, either. Or should it?
Best regards
Thanks for the file, I've looked into it and this is actually intended behaviour. The issue is (as explained in my first answer above) that node trees are converted to Haxe code during export. Haxe requires class names to have a certain syntax (first letter in uppercase, no dots, etc.) so the trait name needs to be converted (traits are objects of a class). Unfortunately there is no way around this.
The problem with this is that the trait will have a different name during runtime (start your file with the debug console and select the cube, at the bottom of the debug window you will see that the trait is named My_node instead of my.node). Because of that, functions like getTrait() or nodes that have a trait name input will not work with "my.node" but only with "My_node".
To inform the user about that behaviour, a warning is displayed. It is still lacking documentation (I will write that soon), but perhaps the message itself is a little bit ambiguous or misleading. It's very hard to compress such a complex issue into a short sentence. Do you have an idea for an alternative warning?
So there is nothing to worry about, it's just a warning that informs about possible errors but not an actual error :)
Thanks for the detailed explanation. I think a more meaningful warning would be helpful. Especially if it contained a hint on how to fix the problem. For example: Make sure your trait name starts with a capital letter and does not contain any dots (".")
The problem is the warning message should not be longer than one line (if it's possible) to keep the console output not too cluttered. And it must be more general than your example (I know that's just an example :)) because not only dots and lower case letters are problematic but many other things too. Its very difficult to find a short sentence that explains it so that everyone will understand whats going on.
Maybe we could add a short sentence that says to take a look at the wiki but that might just clutter the console. I think a better approach would be to add a page to the wiki dedicated to warnings and common issues that explains this in detail. If an user gets this warning, they will probably search for that and find the wiki page.
Im not sure, what do you think? @blackno666 @Sandy10000
I think a better approach would be to add a page to the wiki dedicated to warnings and common issues that explains this in detail.
This is good. Can use it to check the contents of the warning, and will know in advance what Armory does not like.
Suggest message content
Node tree name "state1" can cause problems. Good example: "State1". Details: wiki page item 1.
Node tree name "state1" can cause problems. Good example: "State1". Details: wiki page item 1.
Sounds good, but I think the problem with this is that it doesn't tell what the problems are that can happen.
I've added a paragraph to the wiki explaining this: https://github.com/armory3d/armory/wiki/troubleshooting#common-issues
I think the current message is sufficient enough as it is now explained in the wiki (If users have problems, that's the first place they should look). If you want to change the message, feel free to open a PR :)
No PR from me here, but yet three more suggestion on changing the warning:
- Node tree "xx" does not adhere to naming conventions. Use "xx" instead. See online wiki for details.
- Node tree "xx" violates naming conventions. Use "xx" instead". See online wiki for details.
- Possibly problematic node tree name "xx". Consider "xx". See online wiki for details.
I'd really like to see the hint to check the wiki. It's not obvious to look there (from my point of view - which now changed after reading the above discussion).
Thanks for the good wiki paragraph.
I really like all variants. I too changed my mind - the hint to the wiki might be important as the information about that warning is on the "Troubleshooting" page and that's not necessarily the first place to look for a warning message.
The third variant has the big advantage that it doesn't seem like it's just a convention issue, so we should probably stick to that.
Shall I open a PR for this?
Shall I open a PR for this?
If you feel it is better to do so, please do so. Thanks for adding an easy-to-understand wiki description page.