Witchlord, I had read a note on the Angelscript site that pointers may be making a return. In my situation, its purely an interface issue as I wouldn't need Angelscript itself to actually allocate or free pointers. For instance the interface of my native code follows a scheme like the following where CreateSphere and CreateCube actually take care of allocating a new Entity instance and RemoveEntity actually takes care of deallocating it. Entity* Scene::CreateSphere(); Entity* Scene::CreateCube(); bool Scene::RemoveEntity( Entity* ); Once an entity is created, you can invoke its methods in the native code via the -> operator. For example: 'entity->BindTexture( Texture* )' Since Angelscript obviously has no conception of the -> operator, I have to make a simple translation layer for any class like my entity class. A translation for entity bind texture might be: bool Entity_BindTexture( Entity* e, Texture* t){ return e->BindTexture(t); } This would have an Angelscript prototype of: Entity_BindTexture( PtrEntity, PtrTexture ) where PtrEntity and PtrTexture are just int enumerations pretending to be pointers in a language that doesn't do pointers (essentially acting as integer handles). This works fine and the translation layer is a lot simpler than it might be in other scripting languages. However, if you had support for the -> operator in Angelscript, I would not need a translation layer at all between my native code and my Angelscript code. I hope what I am describing makes sense.

I want to add support for pointers in AngelScript again (as an optional feature, of course) but it may take a while yet. There are so many other things I want to add too.