Rick

Would that execute it right in the editor? Is that a value we can get from a property so it can be executed at a specific time?

Would be nice to have both options. That wouldn't hurt anything would it? Also some way to loop through all entities would be nice. Let's say I want to create an entity that acts on all other entities. I would have to drag all entities to my entity to create a target. That would be a pain. I just think these things provide more flexibility. How many targets can you have?

Here is something that might be of interest and should allow for some more dynamic behavior controlled from the editor. You can call functions by just knowing the string name of it. function HelloWorld(name) print("Hello "..name) end _G["HelloWorld"]("Rick") With this you can have a model class that has 2 properties. One for a lua file and one for a function name. In the Spawn() you can run a dofile() on the lua file to load it, and inside the update you can read the function name and call it from the string name. This would allow 1 model class to have different behaviors based on what you setup via the editor. So let's say I'm making an rpg game. I have a rat model that I really like and would like to use a few times. Let's say I want a "Small Rat" that has basic attacks. Then later in my game I want to use the same rat model but want it to have more functionality and call it "Big Rat". With this I can have 2 separate lua files that control the behavior of the rat and in the editor assign what lua file gets played with each instance. Very cool. This will also be useful for volume triggers because you can use the same trigger model but have it run different things, because the trigger model is generic and what happens in each trigger would be unique.

I think adding lua is a big step in the right direction, but with the implementation of class models being on their own island of scope is kind of a pain to work with. I just can't see it being feasible to make any sort of complex game using the editor/engine with just sending messages to class models. I think at least we need a way to access any entity loaded anywhere. That should be able to be done with a simple GetEntity(name) where name is the name property setting. Targets are good but the are limiting and cumbersome. If I want to push a button to open a door, they are fine. But if I want some sort of scripted sequence of events to happen they are cumbersome. Think of interactions like in Half-Life, a game I know you like. When you walk into a room with a scientist and he starts talking to you. Then he walks over to a table and presses a button to open a door for you. How would you code that with LE currently in lua? It would be a major pain if possible at all with the editor/engine provided. This is the problem I'm trying to solve. The above could be as easy as: function MyScript() DoSound("talk.wav") -- this would wait until the wav file is complete to continue but doesn't block the game DoMove(GetEntity("scientist1"), GetEntity("pivot1")) -- this would wait to continue until the model scientist1 gets to pivot1 DoAnimation(GetEntity("scientist1"), "press_button") -- this would wait to continue until press_button animation is complete DoMove(GetEntity("door1"), GetEntity("pivot2)) -- returns after the door1 is at pivot2 end This is all very possible in the editor/engine executable right now IF there is a way go get any entity loaded by name AND someway create global lua tables that all class model lua scripts can read/write to. Imagine the speed of editing/testing such interactive situations. Because it would be so fast and easy to create and test these things we could see amazingly interactive environments.

I think a GetEntity(name) function would be very helpful. With each model class script kind of being on an island (since they all use their own lua states) a way to get any loaded entity from anywhere could be beneficial. This should be possible if GetEntity(name) is a C function that is exposed to lua from the executable. In the executable every entity is available so it should be that hard to give all scripts access to any entity. The name parameter would be a key setting called "Name". So if I add a model to my scene and set the name property to "Rick" I should be able to access that entity in a different model class lua file by calling: GetEntity("Rick") I know Targets() can be used for this, but setting all sorts of targets for all different kinds of interactions gets cumbersome and error prone. Would be better to just be able to call 1 function to get the entity. I would think this would be an easy feature to add and give a ton of help to us.

Your example and my example do the same thing but they do them very differently. That difference is the key because when the examples get more complex my example will work. Think of stepping out of the function completely only to return at another time. -- This is the coroutine way function MyScript() DoWait(5000) i = 5 DoWait(10000) i = 10 end -- This is the way you are talkinga bout function YourScript() SendMessage(x, y, z) i = 5 SendMessage(x, y, z) i = 10 end Let's imagine stepping through these functions. In YourScript() we would step right through it. First SendMessage(), then i = 5, then SendMessage() again. Stepping through YourScript() would take about a second and it would be finished. Stepping through my script would take 15 seconds minimum. Because when we hit the DoWait() function it actually leaves MyScript() and comes back into it 5 seconds later. So if we stepped through it when we ran the DoWait() function it would actually go back to whatever called MyScript() and continue on with the engine loop. This is where the global tables come in. DoWait() added an entry to this global table that says MyScript() is to run again in 5 seconds. Then that global table is iterated over inside the Update() of the coroutine model class to see if 5 seconds has past. Once it has, we call the function again, but because it was setup as a coroutine it will start up where it left off. So if we were stepping through the function it would come to the i = 5. So you see in my example i will = 5 for 10 seconds, but in your example i will = 5 for about a millisecond because it'll just continue on to SendMessage() which just continues. So you can think of DoWait() as blocking to the function it's in, but not to what called it.

I think you are going to find that the messaging system doesn't handle every situation. Sometimes entity communication with each other needs to be more advanced than just sending messages to each other.

You are missing the point. The point wasn't to end the game. That was just an example. The point was to provide the functionality of DoWait() to the engine. And DoWait() is just the start. DoSound(), DoMove() will all act similar but their conditions to start the function back up will be when the sound is finished playing, and when the entity has reached a destiation. So a message delay isn't enough in these situations.

Well honestly I'm ok with lua, but lua with LE is a little different. With each entity being it's own lua state, it complicates sharing data between entities. There are some design things that are different and don't have anything to do with just knowing lua but instead how Josh exposed LE to lua and how he's using it.

I think it's probably to early for something like this for most of us. We are still learning the power and limitations of lua with LE.

Sure. This all revolves around my coroutine entity that I'm creating. So the thought process goes like this: 1. Create an entity that is like a light in that in the editor it has properties and has an Update() method that gets called each cycle but this entity isn't shown. It has no visual to it. It's just logical. 2. Ideally this entity would create some global tables. These tables are iterated through in it's Update() method. So far so good. 3. There is another .lua file that people include in their scripts. This file defines functions like RunScript(func) & DoWait(cr, interval). The DoWait() method adds entries to the global tables that the coroutine entity created when it was placed into the scene. So this is where the table would need to be global. Imagine you create a volume trigger. In the Collision() function you want to run a sequence of events. To make it simple let's say when the player collides with this trigger you want to wait 5 seconds and then end the game. In this volume trigger script you would include (dofile) this coroutine.lua file. This would give you access to the DoWait() function. To simplify in the volume trigger script you write a function that is your sequence of events. Then in the Collision() method you call RunScript() (also available because of coroutine.lua including) passing in your function to run. Inside RunScript() is where you first call DoWait(5000), then set some flag to kill the program. Here is some pseudo code of what I'm trying to get done: coroutine_coroutine.lua --- This is the entity you add in sandbox function Spawn() tblWait = {} -- Creates a global table end function Update() -- loop through tblWait looking to see if entries have their time up so we can resume the function for k, v in pairs(tblWait) do end end cr.lua -- gives access to some functions function DoWait(cr, interval) -- Create a timer of sorts that last for interval time and add it to tblWait global table coroutine.yield() -- this actually yields the function they are in. Looping through the tblWait let's us know when a time is up to resume end function RunScript(func) cr = coroutine.create(func) coroutine.resume(cr, cr) -- starts the function they passed in passing to it the coroutine created for it end trigger_volume.lua -- example of how a trigger volume would work function Spawn() end function Collisions(...) RunScript(MyScript) -- starts the script sequence end function MyScript(cr) DoWait(5000) endGame = true end

OK, that really hurts the logical entities idea. Calling the community: How can we share variables between all entity scripts? Put on your thinking hats because you'll most likely run into a situation where you'll need this when making a game. I have a hard time believing a full game can be created without it.

Are you including dofile('\Scripts\base.lua') to your script at the top? I think it's required for the key constants. Try KeyHit() also. Just to make sure. Also put an AppLog() inside your if statement and check your engine log to make sure it's getting inside there.

There is a way to load a dll from lua. I've done it before. Check out this thread. http://forum.leadwerks.com/viewtopic.php?f=45&t=5956

So I assume giving all these scripts the same lua state isn't going to ever happen for the editor? Just wondering where this stands so I can try to figure out the best way to handle this. The best way that I see is to use the same state for all of these, but that would be up to you for the editor.

How is SetGlobalNumber() working currently? I would imagine you would have to loop through all the lua states you have and set a variable for each one and give it the value.

My guess would be that the propeller code is adding torque to the plane as well. This is my confusion around what is stored in entitytable and how to find the entity you want when looping over it. From my understanding entitytable holds all entities loaded. So this would mean your plane and propellers are in this table. If that's the case it would be adding torque to both, which is what you are seeing. Other possible things: You have 2 model variables. The param coming in is named model also, so there might be confusion there. Is the parameter to UpdatePhysics() the model or the world? I know Update() passes in the world but one of the scripts I saw named it model, which Josh said was a bad variable name because it should have been world.

Can you show the complete lua code.

Couldn't you make a boolean flag in the spawn and set it to false. Then in your Update() check if the flag is false and if so run an init function and then set it to true. It'll make this check each call to Update() but that wouldn't cause any significant performance hit. The though being that when Update() is called everything should be loaded by that point.

Would that return the actual entity/model or just the name of it? If it returns the entity/model then it's possible that it hasn't been spawned yet. This is something I notice we have to be careful about in the Spawn() function. We really can't be guaranteed any other entities are loaded at that point. It would be nice if our entities had a method that is called once after everything has been loaded. Because we may wish to store references to other entities in an entity. Currently to do that we'd have to create some sort of loaded flag and check it/set it in the entities Update() method.

AppLog() worked like a charm.

Is there something like this for lua tables also? If not, then could there be because this seems like kind of a big limitation. For my coroutine system it needs to have global tables. I want this to be a "model" that users can just drag into their Sandbox scene and use instead of code files that they have to put into their custom main loop lua file. The "model" lua script would house the tables and the Update() method to run checks on entries in these tables. Another script would provide the methods to use like: DoWait() DoWait() would need access to these global tables to add entries.

Is this what's happening the in editor? I assume only one lua_State* is being used to call all these scripts?

I include base.lua which includes engine_const.lua which defines KEY_ESCAPE. I also tried the actual number instead of KEY_ESCAPE but that didn't work. I'd love to see if my Update() method is actually getting called. What would you recommend I do to see this. Normally I would use lua's print() but that doesn't seem to do anything. [EDIT] OK, using AppLog() I see it's getting inside the KeyHit(). So it must be setting runGame to false, but that's not being seen in the main game loop inside fpscontroller.lua.

How can I print to engine.log from lua from the editor?