You are not logged in. Please login or register.
Ok, I'll get it working and submit the fix.
EDIT: was just #include <algorithm>
I guess that's probably an easy way to do it. I guess I can push the object ID (just looking where I can get that from right now) so the lua functions would be:
function fishAI(obj)
end
Last edited by Nistur (2012-08-02 09:41:34)
Hi,
yes, it would be nice to add the possibility to pass variable, right now scriptContext->callFunction cannot pass arguments.
EDIT : after verification, you can in fact pass arguments using :
scriptContext->pushInteger(objId);
scriptContext->callFunction("fishAI");
(but I never tested it)
From what I remember about lua, you just need to push values onto the state to use them as arguments. I've got this implemented now, I just have to test it later.
The development of AquaGate is now officially underway.
I don't know how much we will manage to get done in this session, but I hope to be able to have something by the end of the day.
Just so people can see, I've started up a couple of google docs. I've made them publicly viewable, so people can see what is going on, if you want write access, just send me a message and I'll add you.
Note: These are not complete. Nor are they intended to be viewed as such. They're just some structured places for notes and design to be put. Hopefully they will be bulked out and grow as the project continues
Right, I spent a while looking at the script calling stuff to try and figure out what's going on, because I couldn't quite tell why it wasn't working.
Then I went away from the computer and it became obvious.
I was wondering if we could have an incredibly minor update to MScript 
I can submit it if you want, but I want to change:
void MScript::callFunction(const char* name)
{
//...
if(lua_pcall(m_state, 0, 0, 0) !=0)
//...
}
to
void MScript::callFunction(const char* name, int numArgs = 0)
{
//...
if(lua_pcall(m_state, numArgs, 0, 0) !=0)
//...
}
So yeah, it was calling the function... but the lua state didn't realise there were any arguments to get from the stack...
Hi ! Ho, yes, sorry !
Sure, you can commit it thank you 
I'm also working on improving the script before making the builds,
I added some stuff that I will commit after you :
- get objects from other scene in lua : using getScene(sceneName)
- clone objects : getClone(object)
-- default is current scene
toto = getObject("toto")
box = getObject("box")
boxClone = getClone(box)
scene2 = getScene("scene2")
totoScene2 = getObject(scene2, "toto")
gravityCurrentScene = getGravity()
gravityScene2 = getGravity(scene2)Previous code is compatible, but internally getObject now uses a pointer and not an id (to deal with the different scene)
So, after I commit, you will need to send the object pointer to your function instead of the id : lua_pushinteger(L, (lua_Integer)object);
- also added a function to send a ray test : rayHit(pos1, pos2, object)
- and a function to quit from script : quit()
That's up
That reminds me. Want me to do the loading callback stuff? The way I was going to do it was... either a function pointer or a callback interface, then within M_fread and M_fwrite, run the callback based on the amount read/written (so the faster it loads, the more animation frames or whatever...)
Yes, it's interesting, I never did animated loading screen, only static image.
Just, doing it every M_fread will maybe slow down too much (lots of calls) as we need to draw and update the framebuffer, also, the external libraries don't use M_fread. There is also the problem of knowing the total size if it is a percentage bar.
What takes time to load are meshs, textures and sounds.
We could be delaying the loading of all this data at the end of the level loading to have the total number of stuff to load
(the MDataRef for textures, meshs and sounds) and call MDataRef update to actually load the data while counting ?
The way I've seen it done in the past is to get a callback every (say) 100 bytes that are read. As you have things like the mesh loader which does a lot of stuff that isn't just reading, you get a reasonable feedback of how much is happening by how quick things are animating. I don't think there's a major issue with 3rd party libraries, because I think most of them are tied into the MFile wrapper. Having had a look, libsndfile uses MFile directly, so M_fread wouldn't necessarily make sense, maybe moving it into MFile might...
You're right, this wouldn't work for a loading bar. I can't think of a nice way at this point of making a loading bar work though. Potentially you could have a count of the objects in the scene, calculate a percentage for each of them, then say 50% of the object is mesh loading, 50% is texture loading. As it loads the objects into the scene, it sends a callback for every 1% or something.
We can keep that for later, at least it's possible to do static loading screen which is not too bad.
By the way, it is possible to divide the loading of a level / scenes by selecting "Data Dynamic" instead of "Data Static" in the scene properties (where you can change the gravity). I also prepared a progressive loading depending of the visible objects but didn't finish it.
Ok, we'll just leave it for now. It seems like it's more complicated than I was expecting. Never mind
Thanks for the information
Hi,
I added a simple function in script to enable a scene layer to be draw on top of a camera
(each camera can have a different layer)
Example, to draw the scene2 on top of "Camera" :
Scene2 = getScene("Scene-2")
Camera = getObject("Camera")
enableCameraLayer(Camera, Scene2)
--disableCameraLayer(Camera) -- to disable itnice!
... I really think we should start adding documentation to the wiki. I'm going to see if I can get access from my Kindle, in which case I might have 2 weeks when I'm on "holiday" in Bulgaria with very little to do soon
yes, I'm also thinking of the documentation a lot, I didn't find the time yet...
I'm trying to finish improving the script functions and I'm making the build, I'd like to do it tonight because next week I'm going to work for a studio in Marseille.
Do you see something missing in the script ? I was thinking of adding something to say to a camera to render in a texture, but it's maybe not so urgent. Maybe a function to get the mouse position in the 3d world (to use it as a rayHit), access to bones and basic vector functions...
I haven't seen much missing in the script. To be honest, I think the only way that anyone can find these is to just use the system in anger and come up with things.
BitPuffin has been looking at the scripting a good deal more than me recently, so he might be able to tell you some more.
The build would be great. Obviously no rush, as I know what it's like to be busy (I still can barely do any personal dev work apart from during my commute. Even today, I'm at work... meh!)
With regards to the documentation, I think that is really a community effort. No one person, even yourself, who wrote the system, can know all the perculiarities with everything. I'm not sure how to best promote the wiki and get people to contribute. If the community was a little larger, I'd suggest maybe something like a points system where new pages got X points and then edits that get voted as being good get Y points... When I get some time (with or without points) I will do what I can to fill in the wiki.
I added a system to enable a camera to render to a texture easily,
in c++ :
camera->setRenderColorTexture(colorTexture);
camera->setRenderDepthTexture(depthTexture);in lua :
enableRenderToTexture(Camera, "maps/texture.png", 256, 256) -- texture.png will be replaced by the camera rendering 256x256
--disableRenderToTexture(Camera)I think I'll stop there and make the builds, it should be a good start version for this project,
and we'll add things when you find features are missing.
Nice! So the post processing can be sorted from lua?
Looking forward to the builds
I'm having trouble with the Windows version of the game.dll right now, for some reason it doesn't seem to want to load properly, I'm not sure why 
EDIT: scratch that. Windows is working now
Last edited by Nistur (2012-08-05 17:09:25)
Yes, for example you can load a quad mesh with a blank texture and a post-process shader, set an ortho camera in front of it - it will be the "view" camera. Then from script you can tell that the "game" camera is rendering into the blank texture.
It can also be used to do a live screen camera (for a sport game etc)
For the windows version, check that MCore.lib, MCore.dll and MEngine.lib, MEngine.dll are up to date and that the dll are the same used by the editor and game.dll.
Yeah, I've been trying for a couple of days to get it running. Usually it loaded, but my behaviour names were garbage (which caused segfaults when trying to select/load them) even though, under Linux, it worked perfectly. I just tried another compile now and it just worked. No code changes. Nothing. Weird. My guess is that Visual Studio was playing silly and decided not to recompile some objects for some reason before, then realised just now that something had, in fact, changed...
The live screen thing is awesome! I have no idea what I can use it for... but I want to!
Simple boat just modeled. It will be a little more rounded. I don't know who to send or where to upload. So, I uploaded here.
Regards.
That looks great!
Is it possible for you to come on IRC at some point today? I can sort out access to dropbox, and can set you up with access to the project at github. (don't expect me online in the next ~hour, I'm on a train)
If you can't come online, just fire me off an email and we can set it all up over that
Previous code is compatible, but internally getObject now uses a pointer and not an id (to deal with the different scene)
So, after I commit, you will need to send the object pointer to your function instead of the id : lua_pushinteger(L, (lua_Integer)object);
lua_Integer isn't exposed, and when trying to compile on a mac, it seems to default to 64 bit, it refuses to compile this:
script->pushInteger((int)obj);
Cast from pointer to smaller type 'int' loses information
Yes you are right, we could add a "script->pushPointer" or change "script->pushInteger" to take long instead of int
Does long change in length based on architecture? I think that pushPointer is probably a better solution as it's more obvious what it takes
void MScript::pushPointer(void* value){
lua_pushinteger(m_state, (lua_Integer)value);
}
the size of void* definitely changes based on architecture, and it reads quite nicely. I'll make the change and submit during my lunch break (in 30 mins)
yes pushPointer is better and clearer
can you also commit a "void * getPointer(unsigned int arg)" ? for the reverse use.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.