I've completely confused myself for the past 3 hours trying to figure this out. What I'm trying to do is create an object using RegisterObjectType() (which worked), but now I want a module to automatically use this object.. use as in 'be the object'. I'm sure there has to be a way to do this, but it's been confusing me for several hours that I'd figure I should just post here and see if anyone else has come up with a solution.

I'm not quite sure what you mean. Could you give an example of how you would like the scripts to work, i.e. show a piece of script that give an idea of what you're trying to do?

Do you want the properties of the object to be accessed as global variables from within the script?

Or do you simply want to access the object from the script?

Well what I want is something like a module-class.

I basically want a module to 'inherit' a class so that it could contain basic properties such as the x,y,z, texture images etc.. (so I don't have to manually define all these for every npc and can easily add more attributes without editing each script)

Unfortunately AngelScript hasn't been designed to do what you want.

Why don't you expose the application registered type to the module as an object itself? The scripts can declare their own global variables or class members if they want extra data, but when ever they need to access what the application also uses (such as entity position, texture id, etc) it would us the application registerd type.

Example:

// AngelScriptclass Npc{  void DoSomething()  {    m_extraVariable = 3.14;    m_entity.SetPos(0,0);  }  entity@ m_entity;  float m_extraVariable;}

but wouldn't that limit me to the engine? how would I go about defining extra classes if I were to wrap the script up in an npc-class.

my original thought was to just declare global-variables in each module that would be prepended to scripts, but then I wasn't sure how I'd get the proper pointers for each to use them in c++.

I don't think it would limit you anymore than any other design.

The C++ game engine has to have some minimal knowledge of the game entities, e.g. position, size, velocity, texture, etc. No script can change this, I mean the scripts can change the values of these properties, but they can't really change what they mean or which ones are needed.

You would have one script class for each scriptable entity type, e.g. ogre, troll, door, sword, etc. Then the engine would instanciate multiple objects of each class depending on the entities that are in the game world. Each script object would get it's own game entity object that tells the game engine where the object is and so on.

It is possible to have one script module for each game entity. But, if you have two entities that should have the same logic you would have to compile the same script twice in two separate modules (otherwise the global variables would be shared between them), which would give you a much higher memory consumption.

I can't really tell you how you should use the script engine. There are so many different ways of doing things. I'm just giving you ideas on how I would solve it myself.

Just got another idea. I believe I've already seen something similar described by another user of AngelScript.

Basically you would let the script writer define two things, a set of variables, and a set of funtions. The game engine would then take these two sets and join them into a script class definition that would then be compiled. Example:

// C++const string className = "Npc";const string userVariables = "float myValue; bool myFlag;";const string userFunctions = "void DoSomething() {}";// Build the script section for compilationstring script = "class " + className + "{";// Add the required variables that the game engine will usescript += "float x; float y; int textureId;";// Add the user defined variablesscript += userVariables;// Add the user defined functionsscript += userFunctions;// Finish the class declarationscript += "}";// Build the class into a moduleengine->AddScriptSection(className.c_str(), className.c_str(), script.c_str(), string.length());engine->Build(className.c_str());// Create an instance of the Npc classasIScriptStruct *npc = engine->CreateScriptObject(engine->GetTypeIdByDecl(className.c_str(), className.c_str());// Get the properties that the game engine uses. Since // the game engine defines which they are we can get them by index only.float *pX = (float*)npc->GetPropertyPointer(0);float *pY = (float*)npc->GetPropertyPointer(1);int *pTextureId = (int*)npc->GetPropertyPointer(2);

Personally I don't quite like this way of doing it, as I feel the script engine gets too heavily integrated into the game engine.

Yeah I'm not a fan of that either (seems like its bastardizing the scripting a bit).

I was thinking of having it so that it prepended some variables, and then I would receive the proper references to these variables and store it into the class for the npc.

Unsure if it is smart to have each npc it's own module though.

*Edit*
Is it possible to have a 'const' variable in a module, but have it still editable through c++? I tried using GetGlobalVarPointer (worked fine), and then altering the const but it seems not to change.

Also when using RegisterObjectProperty, I get these warnings:
warning: invalid access to non-static data member
warning: (perhaps the `offsetof' macro was used incorrectly)

[Edited by - MarkCX on June 16, 2008 1:40:51 AM]