So i have read that when the Error stream spits out an Invalid configuration in means that something went wrong with the registration methods. However i think this may be just a PPC issue. As i have the code working on a windows machine, the same exact code. I am using the scriptstring add-on, and it is not failing an any of the asserts. Also I am running it in max compatibility mode, is the PPC version ready for native mode yet? Where would be the first place to look, to track down this Invalid configuration error. Thanks.

PPC is not yet ready for native mode. There is some code already, but I cannot guarantee anything as to how well it works. For now, it's best to compile the library with AS_MAX_PORTABILITY.

To figure out what went wrong you have two resources. First, I suggest you register the message callback right after creating the engine. Some of the common errors are output to the callback. Secondly, you need to verify the return code for all the calls. At least with an assert, the way that is done with RegisterScriptString(), i.e.

r = engine->RegisterObjectType(...); assert( r >= 0 );

In debug mode you'll get the exact location of the failure. After that it's just a matter of checking the return code.

If you still can't find the error after this, post your registration code, and we'll help you.

Regards,
Andreas

i stepped through the application and scriptstring is being registered in AS_MAX_PORTABILITY mode. So i know it is defined. Nothing fails until i call the Build function.

bool ScriptManager::loadScript(Ogre::String file)	{		// Scripts Functions are prepended with (filename - ext)_ function		// i.e MyUberScript.v7s = MyUberScript_spiffyFunction()		// Before we introduce the script into our main context and use it		// we need to test it to make sure it is a valid script file.  We will load it into		// a temporary module, then compile it.  If we get errors, we do not add it into our system		// and report an error.		// Create a stream to the file		DataStreamPtr stream;		String script;		try  {			stream = ResourceGroupManager::getSingletonPtr()->openResource(file);			script = stream->getAsString();		}  catch(...)  {			ScriptUtility::logErrorMessage(file + " was not found.");			return false;		}				// Add the script to the validation module		int r;		r = mScriptEngine->AddScriptSection(VALIDATION_SCRIPT_MODULE, file.c_str(), script.c_str(), script.length()); assert(r >= 0);		stream->close();		if(r < 0) return false; // error				// Compile the validation module		r = mScriptEngine->Build(VALIDATION_SCRIPT_MODULE); assert(r >= 0);		if(r < 0) return false; // error

Then it reports this error message:

0: In script section true on line 0 character 0.Invalid configuration

It appears the the asSMessageInfo is just full of null values...
And my error callback looks like this...

void ScriptManager::MessageCallback(const asSMessageInfo *msg)	{		String msgType = Ogre::StringConverter::toString(msg->type);		String msgSection = Ogre::StringConverter::toString(msg->section);		String msgRow = Ogre::StringConverter::toString(msg->row);		String msgCol = Ogre::StringConverter::toString(msg->col);				LogManager::getSingletonPtr()->logMessage("------V7 SCRIPT ERROR------");		LogManager::getSingletonPtr()->logMessage(msgType + ": In script section " + msgSection													+ " on line " + msgRow + " character " + msgCol + ".");		LogManager::getSingletonPtr()->logMessage(String(msg->message));	}

So without debugging angelcode i don't think i am doing anything wrong, as i said before windows has no issue with this code. Is there a better way to get a more detailed error message?

Thanks.

This is very strange. Could it perhaps be an uninitialized variable inside AngelScript?

You're getting this message because the asCScriptEngine::configFailed flag is true when you call Build(). Can you set a debug break to determine when this flag is set to true? That should give you the exact location where the problem is. It might also be worth it to verify that the flag is indeed initialized to false as it should when the engine is created. You can set the break point in the method asCScriptEngine::ConfigError() to check when the error occurs.

The null values are due to the fact that the error is not in the script, it is in the engine configuration. I also noted that in the message that you receive the script section is named 'true'. That shouldn't be, it should simply be an empty string. Perhaps this is due to the use of Ogre::StringConverter::toString(msg->section)? You don't use this on the message string.

Regards,
Andreas

Ok, now i just feel dumb. I had no idea that you had to register your functions as asCALL_GENERIC, when in AS_MAX_PORTABILITY. Changed all my function registration methods to asCALL_GENERIC, and it appears to be working.

So what is the difference in a GENERIC call vs one of the others. What am I limited too. I really don't want to code everything twice, once for windows and once for mac.

Thanks again,
Justin Walsh

There are no limitations with asCALL_GENERIC, everything that can be done with native calling conventions can be done with the generic calling convention. The only difference is that you're forced to write wrapper functions.

I'm glad you got it working. I was worried that it might have been a bug in AngelScript that I couldn't reproduce.

Have I asked you what project you're working on already? I like to link to projects that use AngelScript, sort of a mutual promotion. ;)

Regards,
Andreas

The project I am working on is still under wraps until the end of the year. As soon as we announce the project officially I will of course let you know, as well as link back to your site. It is a 2D style arcade shoot'em up, rendered in 3D. We are using Ogre3D for rendering, FMOD for audio, OIS for input, Bullet for 3D world collisions, and of course AngelScript for scripting :)

On a side note, on windows I am able to have my script functions as protected functions of a class, and register those functions as globals. However this method doesn't seem to be working on OS X. As a matter of fact I never expected it to work on windows and was surprised that it did when it did. The idea at first was to hide those script only functions from public access.

I am assuming this ties in to the wrapper functions statement you had made. With max portability mode can i still use member functions or do I need to make all the functions global and not a member of a class?

Best Regards

Sounds cool. I look forward to seeing the game when it's ready.

Not sure what you mean by protected functions of a class. A class method cannot be registered as a global function as AngelScript wouldn't have the object pointer. Unless of course, the method is declared as static, in which case it is really just a global function in the class namespace.

The AS_MAX_PORTABILITY mode is completely transparent for the script writers. The only change is the interface between the script engine and the application.

The application can still register a function following the generic calling convention as a class method, where the function in turn calls the class's real method. E.g:

void WrapClassMethod(asIScriptGeneric *gen){  // Retrieve the parameters  MyObject *obj = (MyObject*)gen->GetObject();  int arg = gen->GetArgDWord(0);  // Call the real method  obj->method(arg);}engine->RegisterObjectMethod("myobject", "void f(int)", asFUNCTION(WrapClassMethod), asCALL_GENERIC);

For a global script function there is no object of course, only the arguments.

Regards,
Andreas

That kind of sucks :( The beauty and power is the ability to not have to write wrapper functions in angelscript. How much more work is needed to get it working native under OS X with a PPC processor. Maybe i will start reading up and help that process along.


As to the global function comment what i meant was that this code under windows was executing...

as->RegisterGlobalFunction("void cameraRotate(int index)", asMETHOD(v7::GameManager, cameraRotate), asCALL_STDCALL);

and the function cameraRotate was a private member function of v7::gameManager.

Now i know that kind of seems off, but it was nice to have our script only functions not accessible in the engine. As we already had to wrap up some methods because when we called the function from script, back in the engine it was not getting in instance of the class, and all the class variables where not initialized in the class of the engine.

Again, I could have just been doing crazy off the wall stuff as i have never used a scripting engine in a project before. And come to think of it, It is probably best to use the generic engine because we may have a chance to port our game over to gamecube.

Thank you for your support and patience.

I know. The problem is that every compiler/platform combination has it's own calling conventions, so the only way to add the support is to have access to the compiler and platform of interest.

Since I do not have access to Mac OS X I have no hope of adding this support myself. But there are people working on it so hopefully someone will be able to send me working code soon enough. For all I know the code in as_callfunc_ppc.cpp might even be working already, but I'm not able to test it.

It is not all that difficult to add though, if you want to have a go at it. You need assembler knowledge and a good debugger that'll let you show the assembler code while debugging. Then it's just a matter of writing the code according to the Mac OS X ABI, and running the tests in test_feature until all of them work.

You'll end up writing a handful of functions in assembly, and a couple of C++ functions to prepare the input for the assembly functions. You can take a look at the already existing as_callfunc_ppc.cpp code to get a feel for the complexity of the needed changes. You shouldn't have to change any other files, except as_config.h to remove the AS_MAX_PORTABILITY flag for your compiler/platform combination.