Jump to content
  • Advertisement
Sign in to follow this  
EddHead

import facility doubts

This topic is 5053 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

Advertisement
Can you show me with an example of how you want it to work? I think I don't quite understand what you're trying to tell me.

The import statement will only work with the complete function declaration, as the compiler needs this information to know how the function is called.

If you don't want to have to remember all the function declarations with their parameters and return types, how are you supposed to know how to call the functions?

You never have to remember the section names, they are only used for compiler messages. If you don't want to have to remember module names, then compile all script sections into one module with no name.

The error locations will be correct as long as you don't alter the script file before adding them to the module with AddScriptSection(). Each file should be added with a separate call to AddScriptSection() where the section name is the filename.

Share this post


Link to post
Share on other sites
yep, i have been using it this way,

AddFSMState( fsm1, ANGRY, "angryfunc" );

what i do is use GetFunctionIDByName to get the context for the function angryfunc and call this function from the FSM handler code, very convinient(which was what made me so obsessed with this library). i normally dont send more than 1 parameter, maybe like a single integer paramater. this helps em alot in dynamic behavior changing. i could explain better i guess...but my english sucks.

Share this post


Link to post
Share on other sites
Sounds like a good way of handling it.

If you wish to use modules, then you could either add the name of the module as a parameter to the AddFSMState() function. Or you could pass the function ID instead of the function name:

AddFSMState(fsm1, ANGRY, engine->GetFunctionIDByDecl("module", "void angryfunc()"));

Share this post


Link to post
Share on other sites
Yes, but like i said the module names are cumbersome, i would like to add module names only if i am handling it internally, since scripts are mostly used by Modders, i would like to give as minimal control to them as possible.

i would like to bypass the usage of a Module name.

Share this post


Link to post
Share on other sites
Who is doing the calls to AddFSMState? Isn't that the your application when it loads the scripts for the AI entities?

Why would the script writers need to know the module names? Why do you need to use the import statement?

True namespaces would perhaps have been easier to use, but I haven't implemented them yet.

Share this post


Link to post
Share on other sites
Most of the Modders i am talking about will be more advanced than the usual modder, i require them to have some coding knowledge anyway, but AddFSMState is an example. these are called in the script defs for FSM creation. (yes i want to be able Mod to that level).

Share this post


Link to post
Share on other sites
Most of the time you don't need to specify the module name, because the application can obtain the module name from the context when an application function is called:


void func()
{
asIScriptContext *ctx = asGetActiveContext();
uint funcID = ctx->GetCurrentFunction();
string modulename = ctx->GetEngine()->GetModuleNameFromIndex(funcID >> 16);

... Do something where the module name is needed
}


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!