🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Globals & recompile
Author
Hey again
Just curious... I've got a couple of global variables in my scripts (declared in a script). The thing is, I've made my scripting system so that I can reload scripts on the fly, which works fine in most ways. Problem is that the globals won't get stored across recompilations. Anyone got any ideas on how to solve this?
EDIT: With GetGlobalVar* I guess I can find all the globals, but I can't see an easy way to get their size & data so I could store/restore them. Any ideas on that?
[Edited by - Dentoid on April 27, 2005 4:08:08 PM]
You could get the declaration of the global var, and from that determine it's size and type. This would let you store the variables and then restore them afterwards. It is a bit of work though.
If you can think of a way how AngelScript could be improved in this regard, I'm all ears.
If you can think of a way how AngelScript could be improved in this regard, I'm all ears.
Author
Well, I just noticed the "GetGlobalVarPointer" method that provides a way to access the data. But, as you said, to figure out the size of it you'd need to parse the declaration. Doesn't AS already have size information internally? Or at least the means to figure it out somehow? If so, a GetGlobalVarSize or something would be enough to be able to store and restore the data.
The size of the type should be quite easy to figure out, using as you said a method GetGlobalVarSize(). But it will not be enough. What if the variable is an object, or a handle to an object?
I'm thinking about making all global variables be stored in a special container, whose pointer can be accessed by the application. The container would then have methods for serializing the type it holds.
Still need to think more on this though. All ideas are welcome.
I'm thinking about making all global variables be stored in a special container, whose pointer can be accessed by the application. The container would then have methods for serializing the type it holds.
Still need to think more on this though. All ideas are welcome.
Author
I don't know how handles work really, but if they work similar to pointers they should work fine after the recompile too, provided the app hasn't deallocated the object or anything like that. But yeah, I can see if there are problems one way or another.
For handles, the application will have to call AddRef() on the pointer, otherwise the object will be destroyed when the library cleans up the global variables.
For objects that don't support handles, a copy must be made, using the assignment operator, otherwise the members might hold invalid pointers after the script has been rebuilt.
For objects that don't support handles, a copy must be made, using the assignment operator, otherwise the members might hold invalid pointers after the script has been rebuilt.
Author
True, I didn't think of the fact that stuff really needs to be cleaned up (in case they're not present in the new compile, for example).
Oh well, I have got workarounds that work okay for now, so it's no big deal. (The reference problem stated in another thread is a way bigger problem. *hint hint* :)
/Anders Stenberg
Oh well, I have got workarounds that work okay for now, so it's no big deal. (The reference problem stated in another thread is a way bigger problem. *hint hint* :)
/Anders Stenberg
I may be able to include the automatic reference counting mentioned in the other thread for WIP 3, I'm looking into the exact changes needed at this very moment.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
