Hello there, We have been using Angelscript for some time now, and have recently tried upgrading to a number of the newer versions without much luck. It seems that something in the internals has changed so that the functionality that we had working previously is no longer behaving as it was. Is anyone else seeing this kind of strange behavior? We originally were using 2.4 but have needed / wanted to move to 2.8 or newer as there are a number of things in the newer versions that our users have been looking forward to (classes, etc). The main reason we moved to 2.8 was to add proper PPC support (we are using the native function interface for registering functions / objects), and have done quite a bit of work on native PPC support as well, but until we resolve these issues we can't really move forward with the newer versions. It's difficult to even explain what is happening with the code, but it seems to be directly related to variable registration. I'm wondering if it has to do with the class / object-oriented support that has been added that is possibly changing the scoping of variables within angelscript. For example, we define a variable like so (outside of a script function, but within a single script): bool myVar; then within a script function, set the variable void MyFunction() { myVar = true; } then when we check the state of that variable in another function, it is not set (value is cleared) void MyFunction2() { if (myVar) Print("variable True!"); } The way that we are managing scripts is that each individual script is a single 'scope', but this scoping seems to have changed in the new release. Anyways, I can try to provide more detailed examples, but I'm just curious if there are any long-time users of AngelScript that are seeing this kind of strangeness in 2.8 or newer?

Are you referring to global variables being shared within a module? I believe global variables, within a module, are shared across contexts using that module.

Edit: sorry, I think I misread your post in my initial comment.
Do you have any other contexts accessing this module that might be resetting the global variable to false?

Are you using native calling conventions for PPC in the latest source?

Are you using the latest source from SVN or from the website download?

PPC support is buggy, except for PPC64 support. I completely rewrote the PPC support for PPC64 (PS3), but the original PPC (32 bit) support was not touched. There may be bugs related to using global booleans with setting and checking. What if you make your global variable an int instead of a bool?

Sorry, my fault - I mentioned the PPC support simply because of some work we've done to port the engine to other platforms (360, Mac OSX), but the issues that I'm seeing are prevalent on Windows as well.

If we can figure out what is going on with the windows version, we can finish the PPC native interface code that we've done and submit it to the project. We are very close for both the 360 and Mac OSX versions of the native interface.

We've tried a number of different versions that have all done the same thing (or stranger even).

The last attempt was to update to the svn head, which ended up diverging even further from the functionality that we had previously. Our original update was to 2.80a, which is what broke things initially, but the latest svn head has reduced us to even less functionality.

We are using the native interface for everything currently (which is why we wanted to write the native interface for PPC), but I may see if we can port our angelscript wrapper to use the non-native implementation to see if we can solve some problems.

The developer that we had working on the PPC assembly port seemed to think that it was something to do with the move from stack-based variable management to the register-based system that changed how variables are passed around internally within Angelscript, but beyond that we haven't been able to track down what exactly has changed that caused these problems.

I can revert back to 2.41 and things work fine again (except for the scripts that we've written to test the new angelscript functionality).

Thanx in advance
Mike W
GDGi

One thing that we've fixed is that if the return value from a function was less than 64bits the return value in the stored in an angelscript VM register was only partially updated and the rest could contain garbage.

I'll try to see if we can come up with a small test app, that reproduced the issues - unfortunately it's a wierd situation, some scripts work, others don't - and since we have ~1000 script functions implemented in the engine, it's very time consuming to try and debug every single function to double check what's working and what isn't.

As far as I can tell, the issues are entirely related to variable passing, whether it's storing object handles or simply passing variables from the application to the scripting system.

I'll see what I can do for a test app and get back to you.