GameMonkey Script

GameMonkey Script Forums
It is currently Mon Nov 20, 2017 3:29 pm

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Tue Apr 20, 2010 4:27 am 
Offline

Joined: Mon Apr 19, 2010 3:09 pm
Posts: 5
Greg wrote:
onimatrix wrote:
...Now I've made an ingame console to write and run scripts (Can anyone tell me how can I execute a script containing a function and be able to call it from an ExecuteString()?) and I'll be learning how to script properly in this weeks. ...
Welcome to the forum onimatrix :) Good to see you are having some success with GM.
To quickly answer your question, If you want to call a script function from native code, you should use the gmCall interface. Make sure binds\gmCall.cpp is part of your project and have a look at the example on the main page. Please start a new thread if you require further assistance.


And a new thread was born :P

Thank you for your welcome, Greg =)

Sorry to bother you, but I was asking about calling a script function from an ExecuteString, not from native code. I imagine it's similar to calling a script function from another script. Is this even possible?

This way, I could write a function in my console, save it to a .gm, open it and then be able to call it from the same console.


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 20, 2010 11:52 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
Calling a script or native function from ExecuteString would just look like:
Code:
machine->ExecuteString( "SomeFunction(someParam);" );
In this case, 'SomeFunction' is either a global script function from a previous execution or a native bound function.
I am not sure why you want to do this, unless you are simply saying that the user will enter such a call into a text console and that text will be executed by the virtual machine, which is fine.
Sure, save the script to file and load again, or just pass around the string and execute directly.


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 20, 2010 1:41 pm 
Offline

Joined: Fri Jan 14, 2005 2:28 am
Posts: 439
The trick is that if the user can define functions via executestring, they need to make them global

for example

Code:
machine->ExecuteString( "global SomeFunction = function(param) { print(param); }" );


instead of

Code:
machine->ExecuteString( "SomeFunction = function(param) { print(param); }" );


Default scope is local, so the 2nd example will be inaccessible due to the way strings are executed. Declaring it global keeps it around for use in a separate call to ExecuteString. The 2nd would only be accessible if you called it within the same call to executestring.


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 20, 2010 3:15 pm 
Offline

Joined: Mon Apr 19, 2010 3:09 pm
Posts: 5
:lol:

The trick worked =)
Now I can write, store and use functions from inside the game.

Thanks!


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 21, 2010 4:06 pm 
Offline

Joined: Mon Apr 19, 2010 3:09 pm
Posts: 5
Hey, maybe you'll hang me for good, but I found a way to recover and use references to individual C++ objects from scripting by IDing them with their address.

For example, I have an object of base class cDynamicObject, which has a "type" parameter that gets filled with enum values (PLANET, SHIP, NEBULAE, etc).
The manager of such objects, cMngrDynamicObject, has searching methods and can recover an object by name through hashing.

That way, I only need to bind a C function that makes the manager search for X object, return it as a DWORD (The address) and then bind accessor functions that C-cast the DWORD to a cDynamicObject, read "type" and then dynamic_cast the object to the derived class.

So... what do you think?


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 22, 2010 3:33 am 
Offline

Joined: Fri Jan 14, 2005 2:28 am
Posts: 439
It's pretty unsafe to do that with the actual address. If the object is deleted on the c++ side, the script may still hold references to it, and as soon as it tries to call something on the object the app will crash.

Better would be to use a handle, and look up your object by handle. This allows it to fail gracefully if the object no longer exists.

My favorite implementation of a handle is to mash an index in an array, with a serial number. Then to look up your object you just mask out the index in your manager class to find the index the object exists in, but you also must verify that the serial number matches the object at that index. That way when an object is deleted from the array, the serial number for that element is incremented, invalidating any remaining handles that may still exist in script.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 22, 2010 6:45 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
DrEvils described favorite method is probably the best and safest.

One thing to remember is that as long as you share a single gmObject you can nullify that object and test its validity. That is, you want all variables to point to the same object, not different objects. You achieve this by providing a accessor method which returns the one and only gmObject for your class instance. You may need to use the 'CPP owned' or gmGCRoot interfaces to retain the gmObject while it is not referenced in script, to prevent it from being garbage collected.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 22, 2010 3:52 pm 
Offline

Joined: Mon Apr 19, 2010 3:09 pm
Posts: 5
Please remember that the script doesn't do anything with the objects other than passing them to a C function.
As I validate the address there, the script just isn't able to screw things up :P

Nonetheless, I'll surely be implementing something close to DrEvil's idea in a few versions. :)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group