Sign in to follow this  

Invalid configuration (PPC)

This topic is 4052 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4052 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this