global variables with LoadByteCode
Author
Let's say that I've saved the byte code of the program with SaveByteCode previously. Now I'm restarting the program, and I want to load the byte code with LoadByteCode. Is it true that all I need to do is call LoadByteCode instead of building the modules?
My problem really is that I'm doing exactly that, but after a call to LoadByteCode, if I call ResetModule it seems to have random values in the global variables, thus crashing when it tries to release them. So is LoadByteCode guaranteed to reset the global variables, or do I need to do something first?
Forgot to mention, I'm using version 2.4 instead of the newest one.
The LoadByteCode() should initialize the global variables, just like a Build() would. It's possible that there is a bug in this part of the code however, since I do not think that the Save/Load feature is used by too many.
Would it be possible for you to create a small test scenario that recreates the problem, so that I can verify it?
Would it be possible for you to create a small test scenario that recreates the problem, so that I can verify it?
Author
All you need to do to reproduce the bug is to add a global handle variable to a script. Kind of like this:
refclass@ g_handle;
After that it will crash at resetmodule or engine release.
refclass@ g_handle;
After that it will crash at resetmodule or engine release.
It seems that it's probably being saved correctly. The handle is saved. Unfortunatly, what it points to is not. This is no different than saving a pointer in C++.
Author
I don't know how it works internally, but to me it doesn't seem like the handle is handled correctly. If it's initially a null value, then it's saved and loaded, it seems to contain something after that, since it's trying to release it on resetmodule.
Obviously there's no need to save what the handle actually points to, but it probably should be decided whether the handle should be nulled when reloaded. :)
Obviously there's no need to save what the handle actually points to, but it probably should be decided whether the handle should be nulled when reloaded. :)
Thanks for giving me such a clear case for what the problem is. It should probably be quite easy to fix it once I get the time to test it.
The SaveByteCode() shouldn't save the value of the variables, instead it saves the bytecode that initializes them. For some reason it seems that this bytecode isn't saved correctly, or isn't executed after the bytecode is reloaded.
The SaveByteCode() shouldn't save the value of the variables, instead it saves the bytecode that initializes them. For some reason it seems that this bytecode isn't saved correctly, or isn't executed after the bytecode is reloaded.
Found the problem. The memory where the global variables are stored is not properly allocated when loading the script module.
Change line 164 in the as_restore.cpp file (function Restore()):
I'll try to release an updated version of AngelScript as soon as possible.
Regards,
Andreas
Change line 164 in the as_restore.cpp file (function Restore()):
// globalMem size READ_NUM(count); module->globalMem.SetLength(count); // globalVarPointers[] ReadGlobalVarPointers();I'll try to release an updated version of AngelScript as soon as possible.
Regards,
Andreas
Author
Great! We'll finally be able to release a public version of our game demo. We're using the byte code saving feature to hide some scripts from end users, to prevent online cheating by changing some core scripts.
Cool! Do you have a web site where we can see the game you're developing?
I'd also like to link to it from the AngelCode users list.
I'd also like to link to it from the AngelCode users list.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement