CC source code bug ? - Programming and Scripting Forum

Ambiera Forum

Discussions, Help and Support.

[ 1

] Page 2 of 2

	Ambiera Forum > CopperCube > Programming and Scripting
	CC source code bug ?

gazzauk Registered User
Quote
2026-07-08 13:57:24

https://cpp.sh/?source=include+%...


include <iostream>
include <string>

int node = 1;

int main()
{
  printf("node = %d\n", node);
  printf("address of node = %p\n", &node);
  //some pointer trickery
  *&node = 10;
  printf("node = %d\n", node);
}

Result:

node = 1
address of node = 0x640
node = 10

Guest2 Guest
Quote
2026-07-08 22:59:47

Some ideas.
Implement some reliable debug/helper script functions in C++ for use under javascript:

1) A new ccbCompareSceneNodes(nodeA, nodeB)
It would extract the raw irr::scene::ISceneNode* pointers via getAttributeAsUserPointer(0) and getAttributeAsUserPointer(1) (following the mechanism apparently used in ccbGetChildSceneNode) and compare them directly in C++, then push the result (true/false) to javascript.

2) A new ccbSceneNodePointerToString(node)
Extract the C++ SceneNode pointer via:
ISceneNode* node = (ISceneNode*)attr->getAttributeAsUserPointer(0);
(again, just following the mechanism apparently used in ccbGetChildSceneNode)
and push it as a hex-address or integer string to javascript.
This should allow you to see transparently in javascript which underlying C++ engine SceneNode pointers are actually referenced by the JS objects.

Guest2 Guest
Quote
2026-07-13 23:01:26

@guest_Robbo

Regarding your custom "ccbGetClosestNode" API function:
The use of the EFSNT_FLACE_MESH constant in mgr->getSceneNodesFromType() suggests that the function filters the output to "mesh" type nodes.

The standard API functions don't seem to limit the output to specific node types by default.
According to your description, some of the standard API functions utilize a recursive search approach using node->getChildren().

Your pre-filtered list may end up shorter than one created with the standard API methods.
Does the number of elements matter in your comparison loop?

Also, getSceneNodesFromType() appears to return a "flat" list of scene nodes.
Does the order of the list entries matter in your comparison loop?
If it matters: By the time you run the comparison, are you certain this list still matches the sequence returned by the standard API?
If your custom function sorts the nodes by distance at some point, that reordering will probably break any direct sequential index-to-index comparison.

Another thing: If your custom function is indeed searching only for nodes of type "mesh", it would be advisable to rename it to indicate this specific focus to users / script-authors.

A detail that is missing from all the presented code snippets:
how the final scene-node pointer is pushed to the javascript engine.
A simple looking "scriptEngine->setReturnValue(whatever);" probably leads into a layer of C++ method/function overloading with a slightly different handling of all the different value-types (scene-node pointers, strings, integers, floats, and whatever).

This is pure speculation, I might be wrong & additionally: this might turn out to be completely irrelevant to your specific problem.

redberylftw Registered User
Quote
2026-07-14 06:29:18

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.

I feel like it's probably because folder nodes aren't handled as parents in the same way actual parent nodes are. They probably have a different indexing method (my guess is some kind of linked list related to an index storing what physically exists in the scene) where the folder node isn't actually seen as a parent but the folder children are being seen as children of something that doesn't exist. A dummy node pointer or something. It could push everything in the index one number higher or lower depending on how the index is actually built. Idk though, I don't have the code.

Guest2 Guest
Quote
2026-07-14 20:19:50

@redberylftw
@guest_Robbo
@gazzauk

Hypothesis:
If there is a fundamental issue with folder-parsing/indexing in the C++ code,
it should also manifest in javascript under Windows.

Recursive folder exploration test via javascript

Scene setup:
- cubeMesh1
- startup skybox
- Folder1
- - cubeMesh2
- - Folder2
- - - cubeMesh3

Behaviour on cubeMesh1:
Behaviour: "When a key is pressed do something"
Key: E
KeyEvent: Key pressed down
Action: Execute Javascript

Javascript:



function explore_node(node, depth) {
var count = ccbGetSceneNodeChildCount(node);
for(var i=0; i<count; ++i)
 {
  var child = ccbGetChildSceneNode(node, i);
  print("node " + String(depth) + "," + String(i) + " -> " + ccbGetSceneNodeProperty(child, "Name") + "\n");
  explore_node(child, depth + 1);
 }
}

var root = ccbGetRootSceneNode();
explore_node(root, 0);

Results 1 on Windows & WebGL:
node 0,0 -> cubeMesh1
node 0,1 -> startup skybox
node 0,2 -> Folder1
node 1,0 -> cubeMesh2
node 1,1 -> Folder2
node 2,0 -> cubeMesh3
node 0,3 ->

The empty node without a name appears to be the default camera (seems to be added to the scene when no user created camera exists).
Adding a Camera1 to the scene will change the results as follows:

Results 2 on Windows & WebGL:
node 0,0 -> cubeMesh1
node 0,1 -> startup skybox
node 0,2 -> Folder1
node 1,0 -> cubeMesh2
node 1,1 -> Folder2
node 2,0 -> cubeMesh3
node 0,3 -> Camera1

Conclusion:
For regular users, ccbGetChildSceneNode appears to work correctly in unmodified vanilla CopperCube.
At least in this specific test scenario, there appears to be no issue with folder-nodes and they
appear to be handled like all other nodes by ccbGetChildSceneNode().

Regarding the C++ code:
Take a look at the ConstIterator-based code:


list<ISceneNode*>::ConstIterator it = parentnode->getChildren().begin();
it += index; //interesting!
node = *it;

Relevant code for ConstIterator (from Irrlicht 1.8 API doc):


00099         ConstIterator& operator +=(s32 num)
00100         {
00101             if(num > 0)
00102             {
00103                 while(num-- && this->Current != 0) ++(*this);
00104             }
00105             else
00106             {
00107                 while(num++ && this->Current != 0) --(*this);
00108             }
00109             return *this;
00110         }

Conclusion:
Seems to work as one would expect.

[ 1

] Page 2 of 2

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