Rick

Yeah, that's what I was thinking, but limited to string/number that way vs tables/objects, but would probably work for a good number of situations although a little hacky.

That does work. I wonder how one could pass parameters though. There is also a CallOutputs() which is nice.

Lua can simulate classes. Look in the Scripts folder and open up AnimationManager.lua and you'll see how to simulate classes. To give the same setup but a little less detail here is a basic class file. -- if this lua file gets included multiple times this will bail out saying it's already been defined. defining twice doesn't really hurt anything but why do it right if ClassName ~= nil then return end -- define a lua table that will act as our class ClassName = {} -- define our ctor with parameters function ClassName:Create(param1, param2) -- create a local table, fill it in with variables, copy ClassName functions to it, then return it. this is our new instance of ClassName that the user will work with local obj = {} -- create variables/properties of this object instance obj.param1 = param1 obj.param2 = param2 -- copy the ClassName functions to this local object instance so it can use them local k,v for k,v in pairs(ClassName) do obj[k] = v end return obj; end -- example of a class method function ClassName:Update() -- self is the same as 'this' in other languages and refers to the instance created with the ctor. unlike other languages you MUST use self. to prefix all instance variables print(self.param1) end So in Lua functions are just variables so they can be passed around and stored just like a variable and called back at a later time. This is handy for callbacks for widget events. function MyClickHandler() end is the same as MyClickHandler = function() end So you can do something like: function btnExit_OnClick() end button = Button:Create("btnExit", "Exit", 100, 100, 200, 50) button.onClick = btnExit_OnClick You will most likely want your event handler to be a Leadwerks Script object function so you can easily access other Script level variables. In that case you have to pass the Scripts 'self' plus the Scripts function and store both in your widget. Then call them back. So would be handy to make another "class" called like EventHandler that takes both the 'self' object and a function. function EventHandler:Create(obj, func) local obj = {} obj.obj = obj obj.func = func -- copy function code here just like above return obj end function EventHandler:Raise() -- this is how you call a stored function that is part of another "class". you call the func passing in the object itself which is why we can use 'self' inside that function. lua hides the 'self' parameter when the class function is defined like 'function Script:OnClick()'. see no 'self' parameter defined but it's there because of defining the function with ':'. it's a nice lua trick self.func(self.obj) end Hope that helps

Anything you can do in C++ in terms of a GUI you can do in Lua. No "widget" will require C++ vs Lua.

Hey Imchasinyou, as cassius stated I do Lua for Leadwerks training for beginners if you are interested. Feel free to PM me if you want more info. I work with a few people currently but 1 person was completely new and he does weekly training where we are walking through making a full chess game. I started out doing most of the coding with him but would explain it as we went through it. Now he does all the coding while I aid in design and fixing bugs as we still do weekly (for the most part sometimes thigns come up) skype meetings where I just explain a design idea and aid in him coding that design.

After your map is loaded you can also loop over the entities in the world. list<Entity*>::iteration iter; for(iter = world->entities.begin(); iter != world->entities.end(); ++iter) { } This saves you from having to mess with passing a this pointer as I you can loop over this in any class. Your idea is good for other things like collisions as you have no other options but to use a callback, but with going over entities loaded from the map you have this more straight forward way.

Using all the functions Haydenmango talked about via coroutines is a good way to get cinematic control. Couroutines in Lua allow you to create scripts that execute from top to bottom while holding their state and not blocking your game loop. It's an easy way to control state in a logical way. You could write scripts that look like: MoveToPoint(player, point) PlaySound("dialog.wav") PlayEmitter() RotateCamera() A script like the above would define functions that you would create and you would yield inside each on which basically comes out of the function and allows your game loop to go and then comes back into the function where it left off to continue it's work. Only until you say the function is finished would it then move to the next function in the list. Without something like coroutines maintaining state of cinematics can become messy and hard to follow. Here's a post I wrote about this. I've tested it in Leadwerks and it works. If I had time I would love to make a library of yieldable functions to use with this, but my time is limited these days. http://www.leadwerks.com/werkspace/topic/8092-blast-from-the-past-in-game-cut-scene/page__hl__coroutines Here is an example I did with this in LE 2. You have to turn the volume way up to hear the audio that I have but you can see I play audio, move cameras around and such. http://www.leadwerks.com/werkspace/topic/340-my-scene-scripting-library/page__hl__coroutines

Unless Josh made this easier in Leadwerks, you probably can but it might be ugly. I know Josh has some Lua wrappers exposed. Below is a starting point to see how a "normal" lua function is called. Look at the Lua function here and you should see some similar ones in Leadwerks that Josh wrapped up and you might be able to work it out. If you do, make a nice easy function for the rest of us Since script functions are table functions the call will be different. You probably have to push the table onto the stack or something like that before making the call. http://www.lua.org/pil/25.2.html It would be really nice if Josh made this really easy though. Something like: pickinfo.entity->script->CallFunction("Hit");

Have you released your game with source yet for others to check out and test with you? I don't think anyone so far thinks it's a Lua problem in general, but without seeing your code it's hard to say what could be the issue. I know you are confident in your ability to debug but others are confident in theirs as well and may think you are just missing something. Without seeing the code it's hard for us to say. Or maybe you're holding out for Josh to test your code?

So before that line of code when you would stand still and do nothing the game would crash? That seems very suspicious and I would really think it's the code you have vs anything Leadwerks is doing. Are you able to comment out chunks of code that provide some feature and test that way to narrow it down? Like, maybe comment out wolves, or birds and test? Before that line was it crashing because it ran out of memory? How much memory does your system have?

Instancing is done by default. If you load the same model without any special parameters to the Load() function it'll be instanced. If you are placing trees in the editor by hand it'll be instanced.

Just a side note that I always set --entity default values to nil. You have it as a string for a default value which doesn't really matter most likely but you aren't expecting it to be a string you are expecting it to be an entity object Script.player = nil --entity "Player" After making that change you'll probably get nil value received or something like that because you probably didn't drag anything in that field from the editor? That's what Aggror is trying to get at with his post.

You could combine the 2. Prefab and code for placement. Make a prefab with a bunch of trees. Then in code loop over all these prefabs and their children (each tree) and cast a ray downward until you hit the terrain. Then adjust the tree to that point (probably a little more downward even). That way you can still manually make sure your big prefab of trees isn't on big slopes and have code adjust it. However, it'll look ugly in the editor as the trees will be hovering over the ground and only adjust at startup. You could place the code in a post processing script which would get ran in the editor, but not sure if it's that big of a deal or not.

http://stackoverflow.com/questions/19381301/how-to-expose-c-functions-to-a-lua-script If you look at the C++ Leadwerks API Josh has made some of his own functions around Lua that you can use or you can import the same Lua version and do the same thing but use Josh's Lua state.

You wouldn't have to use lua++ or luabind but you probably could if you wanted. Otherwise you could just create a normal C style function and expose it to Lua and have it do what you want.

You know, I think we may be able to expose some stuff ourselves. We should be able to wrap something up in our C++ project to be called in Lua. Now that means you would need standard and make a C++ project, but if you have standard then making a C++ project still allows you to use Lua but gives you more freedom to expose this kind of stuff yourself I believe.

You can pretty much just google for lua tutorials and go through any that come up. Also, in my sig I offer 1 on 1 Lua training for LE to help beginners get caught up to speed with Lua and Leadwerks if you are interested in a more personal way to learn.

Is _camera valid? Cameras are entities that are in the world so clearing the world should clear the camera so make sure after you clear the world and load the map that either the map has a camera in it and you get it and assign it to _camera, or recreate your _camera variable after clearing the world.

Can we see some sections of code? I'm pretty sure you should be able to call Map::Load() any number of times. If it's failing maybe what you are passing it is invalid? Are you passing it a variable? Is that variable correctly set within your states when you go back into it?

Yes, use physics once you have all the pieces put in place.

One option would be to have multiple models. 1 model of the thing complete and multiple pieces of the model put together (via a prefab). When the model gets hit by the weapon you swap out the normal model with the prefab that has all the pieces put in place and then apply come force(s) to make the explosion.

Would be cool if we could select an entity and set keys for it via the editor instead of having to assign a script to do so. Sometimes we just want to identify something and don't need to attach a full script.

CSG gets collapsed with all the other CSG and you can't pull it out if this happens. There are 2 ways to prevent this collapse from happening and allow you to access the CSG. 1) Give it a mass 2) Attach a Lua script to it. If you don't want it to have a mass just make an empty entity script and attach it to the CSG and then you should be able to access it via your code.

Follow your dream man. At this point in your life it'll be the easiest time to do so. Grats man!

If you want to do it from the editor then select the root element in the scene tab and you can set it there.