2: Great, I'll work on a system for wrapping all my executes into my error reporting. Man even run time error reporting, Angelscript is great!
3: Yes its really an instance of ObjectRef, I thought making it an instance would make things a little cleaner.. One less thing to allocate and keep track of. The problem was returning handle of the ObjectRef in opAssign causing it to deincrement and release itself. mLight never tries to release its mOwner because it knows its local and just needs to be cleaned up as local. You do bring up a valid point about dangling pointers however. I might look into changing that for that reason.
4: I can call my C++ code via angelscript via C++ by passing registered objects instead of Angelscript objects? I have no idea why I would want to do that, but that seems cool. Very unified. Wait... That means I can transparently use registered C++ classes or user designed Angelscript classes on a class by class basis?... Awesome!
5: sorry called it the wrong thing. Meant assignment operator.
6: Ahhh ok. I copied the opAssign prototype from the string registration function, but that is a value type so I guess it was a bad prototype to copy. I have read the entire Angelscript documentation and thank you for taking the time to write it all. Its just the difference between handles, references, value types and the exact details on ref counting is taking a little time to sink in.
Some details of the documentation are kind of hidden on only one page and that makes it a little harder to use as a quick reference. While I understand you don't want to be redundant in your documentation, Maybe some more hyperlinking between related pages would help? "See also:" section maybe?
Is there any difference in returning a handle instead of a reference other then angelscript will decrement a handles ref count when it expires? I assume if one takes a handle of the returned ref, its ref count will be incremented?
Are references there mainly to support C++'s typical 'ignorance' of ref counting?