Ok. You're almost there. :)

The problem is in the C++ function EntityGetData(). Since the application will keep a reference, and pass a reference to the script engine, you'll have to change your function to call AddRef() on the object before returning from the function. This was why the object got deleted, AngelScript called DecRef() on the reference it had.

long EntityGetData (long id, Entity_Data **entity){  *entity = Vars[id];  Vars[id]->AddRef(); // Count the reference passed to the script engine  return (1);}

AngelScript works best with objects that are properly registered with the AddRef and Release behaviours. This allows for proper memory management, giving a secure environment.

After seeing a little more of your implementation, you could probably get away with registering dummy functions for AddRef and Release that don't do anything. That would allow you to pass the Entity_Data around by handle, but without the need for changing the actual C++ structure to count references. The drawback of that would be that if you're not careful, the scripts might have stored a pointer to the object somewhere that it will use later on, even though the application has deleted the original object. Though, now that you have implemented the reference counter I don't see the reason to remove it again. :)

They are not the same, just as & and * are not the same in C++, even though they are very similar.

@ passes the object by pointer to the function, increasing the reference counter first. The pointer may be NULL, just as for C++ pointers.

∈ also passes a pointer to the value, although to guarantee correctness, the pointer is actually to a copy of the original value. Any changes to the value in the function, is not reflected on the original value.

&out passes a pointer to an object, meant for output values. After the function returns the value is copied to the original value.

&inout passes a pointer to the true object. But to guarantee safety this is only supported for objects that support object handles.

Parameter references for primitive types and object types that do not support object handles are only allowed as either ∈, or &out. Both are compatible with C++'s normal parameter references, except in the case where the function wants an input value, and alters it.

If you really need AngelScript to handle parameter references like C++ do, then you may compile the library with the flag AS_ALLOW_UNSAFE_REFERENCES. When that is done, all types may be passed by reference by declaring the parameter with & (without any extra keyword). However, just as the flag might suggest, this may not always be secure, just as it is not always secure in C++.

If you get that, one of the registration functions failed. Verify the return value to see what it is.

You can also set the message stream before calling any of the registration functions, in which case the engine will write out the errors.

I recommend that you validate the return value with an assert after each call. This will catch the errors in debug mode and doesn't impact the neither code readability, nor performance in release mode.

Example:

r = RegisterGlobalFunction(...); assert( r >= 0 );

That is the error code for asINVALID_ARG (see angelscript.h). One of the arguments to the register function is not allowed.

You need to show me the line that you're calling for me to tell you what's wrong.