ambiera logo

Ambiera Forum

Discussions, Help and Support.

folder icon Ambiera Forum > CopperCube > Programming and Scripting
forum topic indicator CC source code bug ?
person icon
guest_Robbo
Guest
Quote
2026-06-17 01:45:29

Hi Niko - if your still there...

Im puting this bug report here as its all too easy to be dismissed if I contact you directly - like 98% of all previous emails I sent you.

I am comparing nodes to nodes in a for loop in JavaScript and I am getting a difference in nodes for the exact same mesh within my game. After very careful examination found this to be true even when the names of the items match exactly, so same mesh but its node not matching its node from an API using standard CC code in C++.

My API using ccbGetClosestNode() work perfectly and accessing all nodes within a scene - even newly cloned ones during the game. Yes the node returned back does not match the same mesh when placed inside a folder and retrieved using ccbGetChildSceneNode() - the node is different and cant be used to match off node to node in a for loop....

How can there be different nodes for the same mesh ?
Ive confirmed this is correct 100% from getting its name and then comparing name to name and then it matches off as expected. So no error on my side here - its a CC source engine bug it seems to me..

person icon
gazzauk
Registered User
Quote
2026-06-17 15:25:48

I've noticed this also and thought it was my code. Glad to here that you discovered it to be a problem with the editor.

Is this bug anything to do with folder nodes having the same or conflicting names as a mesh node ??

It's a pity the source code isn't available for the editor as I could add alot more functionality to editor and improve the tree node further. The tree nodes need a decent sorting or order system with the ability to drag and move nodes to any position within the tree list.

I have over 15 years C++ programming experience and windows forms application GUI design.

person icon
guest_Robbo
Guest
Quote
2026-06-23 02:55:25

Hi 'gazzauk' - glad you have such skills - maybe we can work together in the source code ? - I can share my work to you if you like.

I agree 100% - Niko ought to release the Editor code so it can be fixed up as sometimes I feel like its fighting me and an obstacle to getting things done.

My folder names are very different to the mesh names and I had only 2 different mesh with very different names in my test so no conflicts of multiple mesh with same name or anything else...

It had me stumped as same code that used to work perfectly stopped working when I used my new API to get the closest node and couldnt see why...after experimenting found the nodes dont match even when its name matches exactly so yeah....

person icon
JIC_IN_DISGUISE
Guest
Quote
2026-06-23 18:32:12

Are you working with animated meshes? if yes then that may also be the issue. Animated Meshes may consist of multiple names, for example the default Animated Man in coppercube prefab has a name veteran, so when you clone an animated mesh , it creates an instance of the same veteran, under a different scenenode name. However I am not totally sure if that's the actual issue. If you guys can send a sample ccb file then I can check it and tell you what's causing this and how to fix it.

person icon
gazzauk
Registered User
Quote
2026-06-23 23:02:53

I simply run the docs examples with nothing but a cube mesh in the scene and got these results that show hidden nodes not shown in the editor.

ccbGetSceneNodeChildCount Outputs:
Scene nodes in the top level of the scene graph: 5

ccbGetChildSceneNode Outputs:
node:cubeMesh1
node:editorSelectionArrow
node:editorSelectionArrow
node:editorSelectionArrow
node:Perspective

Looks to me the selection gizmo also forms part of the mesh but I have no idea what the Perspective node is (default camera maybe) ??

I don't have much in-depth knowledge of the Irrlicht engine itself. But having used quite a few game engines over the years, I've found it to be the most robust and lightweight engine there is. Coppercube is a very practical and user friendly IDE, despite being a little dated and still using DX9 technology.

person icon
gazzauk
Registered User
Quote
2026-06-23 23:43:41

guest_Robbo wrote:
Hi 'gazzauk' - glad you have such skills - maybe we can work together in the source code ? - I can share my work to you if you like.

I agree 100% - Niko ought to release the Editor code so it can be fixed up as sometimes I feel like its fighting me and an obstacle to getting things done.


I agree too, having much more access to the inner workings of the editor would be a huge help. The editor works well and I like the simplicity of it but could do with some updates and extra features.

Sure, I'd be happy to make improvements and keep things rolling.

person icon
JIC_IN_DISGUISE
Guest
Quote
2026-06-24 07:21:04

Ahh that's not the bug, those nodes are actually the part of the editor.

Arrow nodes are custom nodes that are used for the gizmo, the X,Y and Z axes in red, green and blue color that you can use to drag, rotate and scale an object in the editor. They are not published or exported to the final scene and can only be acessed in editor.

Same goes with the camera, it's the Editor camera's. It is not just perspective camera only, if you change your camera to Top, then it will be Top camera, and same is for the other camera types, those camera are also just for the editor only and won't get exported to the final exe.

I don't think Robbo was talking about the editor. Also opensourcing editor code will make no sense or will add not that much benefit to the community. It's better to rewrite an editor shell for the Coppercube then opensourcing the current editor.

It really won't affect the community that much. Because editor only has just UI and Lightmapper for coppercube (which takes a lot of time in baking light) and some terrain editing brushes and nothing more. Rest of the features are already available to us as the part of current Coppercube source.

person icon
Guest2
Guest
Quote
2026-06-24 18:51:00

@guest_Robbo

Disclaimer: I don't have access to the "game-client" C++ code.

To rephrase your problem:
- You are working in javascript using your custom API function (implemented in a custom C++ game-client)
- You are querying an object via your custom API function and get a valid reference
- You are iterating over a group of objects via the built-in ccbGetChildSceneNode() API-function and try to find the same object by comparing the returned node references
- The object can be identified & the references can be matched up using the name-property & mesh-reference
- But the node references / node pointers themselves don't match

A pack of questions:
"the node returned back does not match [...] when placed inside a folder"

1. Is the problem isolated to nodes placed inside a "folder"-node or does it also happen with a "flat" scene hierarchy (scene contains only objects under the root scene node)?
Is the problem triggered by the presence of "folder"-nodes?

2. Does your custom API function still return the same node reference after multiple calls?

3. While it seems you have already tested for it, can you please confirm this: if you use the node reference returned by your custom API function to make changes to an object in the scene, do these changes actually apply and can the changes be detected by built-in API functions?

4. How does your C++ function interact with the javascript-side? How are the references to the "nodes" transferred over to the javascript-engine? Do you need to set up wrapper objects around C++ pointers/references?
Maybe there is a difference to how ccbGetChildSceneNode() does it?

If you are comfortable with it (and the license of the game-client code allows it), you could also post a partial listing of your C++ function & the relevant javascript code.
With this, gazzauk, JIC_IN_DISGUISE and other C++ "game-client" code users may be able to identify the cause of the issue.

person icon
gazzauk
Registered User
Quote
2026-06-24 20:48:35

JIC_IN_DISGUISE wrote:
Ahh that's not the bug, those nodes are actually the part of the editor.


Yeah, you're right, those nodes are not exported in the published exe.

My issue was with nodes having the same name and when using the function ccbGetSceneNodeFromName.
This function call returns only the first occurence of a node with that name, not matter how deep in the tree it is. Even though I had some other nodes named the same, I would of thought the editor would pop up some kind of message alerting me of a duplicate node name.

I've now realized that the scene tree is using the node ID as a unique reference to each node and the name of the node is nothing more than an attribute. This makes me wonder why there is not a function for ccbGetSceneNodeFromID.

Most of the useful ccbFunctions are not exposed to the editor so making any kind of useful plugin is quite restricted without resorting to some programming trickery. Would be useful if end-users could use functions like ccbCloneSceneNode from within the editor or with plugins.

person icon
Guest2
Guest
Quote
2026-06-26 00:23:59

After further tests with the Windows/exe build:
guest_Robbo appears to be correct

Every time you call a node reference retrieval function (like ccbGetChildSceneNode() or ccbGetSceneNodeFromName()), the standard API appears to create a brand-new js wrapper object with its own reference / pointer / memory location.

Note that the javascript engine appears to compare "objects" by reference / pointer.
The js engine seems to auto clean up the temporary js wrapper objects, so there shouldn't be any memory leaks.
This behavior appears to be consistent for all built-in node retrieval functions. Hopefully, I haven't made a mistake in my tests.

Everyone who is interested in this can check this behavior using the following minimal setup.

Scene layout:
- cubeMesh1
- startup skybox

Script setup:
On "cubeMesh1" -> Behavior -> "When a key is pressed do something"
- Key: E
- KeyEvent: key pressed down
- Action: Execute Javascript

Javascript:

var root = ccbGetRootSceneNode();

var test = ccbGetChildSceneNode(root, 0); //node = cubeMesh1
var test2 = ccbGetSceneNodeFromName("cubeMesh1"); //node = cubeMesh1

print(ccbGetSceneNodeProperty(test, "Name")); //should display "cubeMesh1"
print(ccbGetSceneNodeProperty(test2, "Name")); //should display "cubeMesh1"
print(String(test)); //should display "object CopperCubeSceneNode"
print(String(test2)); //should display "object CopperCubeSceneNode"
print(typeof(test)); //should display "object"
print(typeof(test2)); //should display "object"

//all direct node reference comparisons will return false on the Windows/exe build and return true on the WebGL build
print((test2 == test)); //false for Windows, true for WebGL
print(ccbGetChildSceneNode(root, 0) == ccbGetSceneNodeFromName("cubeMesh1")); //false for Windows, true for WebGL




In CopperLicht this works differently:
For example, in CopperLicht we have this instead:


function ccbGetChildSceneNode(node, childidx)
{
if (node == null)
return -1;

if (childidx < 0 || childidx >= node.Children.length)
return null;

return node.Children[childidx]; //NOTE THIS!!
}


This means on the WebGL build we compare direct node references.

person icon
Guest2
Guest
Quote
2026-06-26 03:53:48

Or try this one-liner:

print(ccbGetRootSceneNode() == ccbGetRootSceneNode()); //false for Windows, true for WebGL


Summary:
Direct node reference comparison / equality appears to be broken in the Windows build while it works as expected in the WebGL build.
This has no effect on the proper functioning of the node reference itself - which seems to work without issues.

Impact:
Developers cannot reliably compare node references using standard equality operators (== or ===) on Windows targets.

Recommended & practical basic workaround:
Adhere to standard CopperCube scripting community conventions:
Use unique object names & compare the identity of objects via the name-property, never via node references.
When generating runtime clones, immediately assign unique names to the newly created objects.

person icon
guest_Robbo
Guest
Quote
2026-07-08 02:46:19

Cheers 'Guest2' and 'gazzauk' for your input on this.

Using my custom API ccbGetClosestNode() using a common method in C++ to get all nodes in the scene hierarchy even within folders using this C++ source code:

irr::core::array<scene::ISceneNode*> nodes;
mgr->getSceneNodesFromType((irr::scene::ESCENE_NODE_TYPE)EFSNT_FLACE_MESH, nodes);

for (int i=0; i<(int)nodes.size(); ++i) { forloop over all nodes..}


while another method used in CC source only finds all nodes directly under Root scene node only - not inside folders:

const core::list<ISceneNode*>& children = mgr->getRootSceneNode()->getChildren();

core::list<ISceneNode*>::ConstIterator it = children.begin();
for (; it != children.end(); ++it)
{ forloop over nodes...}


So my custom API uses the better first method.
C++ source function - getChildren() is the problem - it only looks for direct children not in folders.

There actually is a commonly used internal function to run 'getSceneNodeFromId' - this actually runs the 2nd method of direct children - not in folders - ie :
const core::list<ISceneNode*>& list = start->getChildren();
(start here is the root scene node)

Its possible the commin internal and other API's need to be adjusted to include inside folders and not just direct children of the root scene node. I will investifate further...

person icon
guest_Robbo
Guest
Quote
2026-07-08 03:43:12

On second thought - having a look at basic API's:

I notice that some very common search/find functions run a forloop over a forloop until completed of any children under all nodes - so wont miss anything. It had me baffled until I worked out what it was doing as the function was forlooping over itself in endless loop until no more nodes are found and thus effectively a forloop over a forloop to cover all nodes.

ccbGetSceneNodeFromName() - checks all nodes as above
ccbGetSceneNodeFromId() - checks all nodes as above

This still doesnt answer why nodes under a folder are different nodes to the above 2 methods..

person icon
guest_Robbo
Guest
Quote
2026-07-08 03:50:42

ccbGetChildSceneNode uses this source code:

ISceneNode* parentnode = (ISceneNode*)attr->getAttributeAsUserPointer(0);

if (parentnode && isSceneNodePointerValid(scriptEngine->getSceneManager(), parentnode))
{
int count = parentnode->getChildren().getSize();
int index = attr->getAttributeAsInt(1);
core::stringc idStr = attr->getAttributeAsString(1);

if (index >= 0 && index<count)
{
list<ISceneNode*>::ConstIterator it = parentnode->getChildren().begin();
it += index;

node = *it;
}

The correct usuage of the * and & in c++ I am yet to fuly grasp so any c++ devs feel free to answer why they think the nodes are different.

person icon
gazzauk
Registered User
Quote
2026-07-08 13:19:28

guest_Robbo wrote:
ccbGetChildSceneNode uses this source code:

ISceneNode* parentnode = (ISceneNode*)attr->getAttributeAsUserPointer(0);

if (parentnode && isSceneNodePointerValid(scriptEngine->getSceneManager(), parentnode))
{
int count = parentnode->getChildren().getSize();
int index = attr->getAttributeAsInt(1);
core::stringc idStr = attr->getAttributeAsString(1);

if (index >= 0 && index<count)
{
list<ISceneNode*>::ConstIterator it = parentnode->getChildren().begin();
it += index;

node = *it;
}

The correct usuage of the * and & in c++ I am yet to fuly grasp so any c++ devs feel free to answer why they think the nodes are different.


Looks to me like that function is using the node index (node ID ???) and then looping/iterating through pointer references to each node, which seems odd to me as memory addresses are normally allocated and not fixed in code.

The node is being set by the contents of the pointer address to the list (node = *it)

In C++ adding a * in front of a pointer variable allows us to read/write to that address location in memory. The & gives us the pointer address in memory to that variable. I look at it like a simple a array where the index is the (&)address and the (*)contents

I think you really need the developers (Niko) input on this as I've only skimmed over the code and don't really fully understand the scope of that function.


Create reply:










 

  

Possible Codes


Feature Code
Link [url] www.example.com [/url]
Bold [b]bold text[/b]
Image [img]http://www.example.com/image.jpg[/img]
Quote [quote]quoted text[/quote]
Code [code]source code[/code]

Emoticons


icon_holyicon_cryicon_devilicon_lookicon_grinicon_kissicon_monkeyicon_hmpf
icon_sadicon_happyicon_smileicon_uhicon_blink   






Copyright© Ambiera e.U. all rights reserved.
Contact | Imprint | Products | Privacy Policy | Terms and Conditions |