Hi all, I've been using Angelscript in my project with great success so far, except this one weird bug.

I have bound my MeshSceneNode class to the scripting engine for scripting. It can only be created/destroyed by using the Scene interface (which appears as a singleton to the script)

// C++
assert(0 <= engine->RegisterObjectType("MeshSceneNode", sizeof(MeshSceneNode), asOBJ_REF | asOBJ_NOCOUNT));
assert(0 <= engine->RegisterObjectMethod("CScene", "MeshSceneNode@ CreateMesh(const string &in)", asMETHOD(Scene, AddMesh), asCALL_THISCALL));
assert(0 <= engine->RegisterObjectMethod("CScene", "void DestroyMesh(MeshSceneNode@)", asMETHOD(Scene, DestroyMesh), asCALL_THISCALL));

I made a Character class in script, and made an Avatar subclass to handle graphical representation of it (thus fulfilling ORP), like so

// Angelscript
class Avatar
{
    Character@ Char;
    MeshSceneNode@ armour;
    MeshSceneNode@ helmet;
 
 
    Avatar(Character@ char)
    {
        @Char = char;
        helmet = Scene.CreateMesh("helmet_steel.obj");
        armour = Scene.CreateMesh("armour_steel.obj");
    }
    ~Avatar()
    {
        Scene.DestroyMesh(helmet);
        Scene.DestroyMesh(armour);
    }
}
class Character
{
    Avatar@ avatar;
    
}

Now the problem is, when the game shuts down the player is obviously destroyed, but when Scene::DestroyMesh is called, it complains that the meshes passed in are null pointers. Why?

Sorry for coming into this late, but could this possibly be resolved (in this particular case, and maybe in others) by having the gc preferentially releasing handles that are members of objects with no destructors?

That is, in this case the gc would first release the Character::avatar handle. At this point, the Avatar would have no more references, and could be destructed safely.

Of course, this solution doesn't quite work if you have circular references between classes that each have destructors, but then that is the programmer's own fault, right?

This method of breaking circular references is used by Python and the Boehm GC, although the way each of these handle the case of circular references among objects that all have destructors is to never collect the objects . . . I think that your solution is better in this case. Or, perhaps, throw an exception and refuse to run the destructors. That sounds more complicated, though.