Rick

It's a little confusing to follow, but my suggestions would be: 1) loadMenu() isn't loading anything. It's drawing your menu. Naming it as such will make it's purpose more obvious (drawMenu()) 2) You have multiple context:Sync()'s going on. There shouldn't be a need for that. Just leave the updating of the time/world and syncing where it originally is in the default App.lua. 3) You might want to look at state's. Most games have higher level states like (Splash Screen, Main Menu, Gameplay, etc). It can help to break your game into these states where each state has it's own Init(), Update(), & Draw() functions. You would do this to separate their duties. Then in your App:Loop() you would determine which state you are currently in and call it's Update() and Draw(). A simple example of this could be: App.lua ====== function App:Start() ... -- start out in the main menu state self.currentState = "main.menu" end function App:MenuUpdate() -- this is where you look for key presses and mouse clicks specific to the main menu end function App:MenuDraw() -- this is where we draw anything related to the menu end function App:update() --Update the app timing Time:Update() --Update the world self.world:Update() -- determine what state we are in if self.currentState == "main.menu" then self:MenuUpdate() elseif self.currentState == "somethingelse" then end end function App:draw() --Render the world self.world:Render() --Render statistics self.context:SetBlendMode(Blend.Alpha) if DEBUG then self.context:SetColor(1,0,0,1) self.context:DrawText("Debug Mode",2,2) self.context:SetColor(1,1,1,1) self.context:DrawStats(2,22) self.context:SetBlendMode(Blend.Solid) else --Toggle statistics on and off if (self.window:KeyHit(Key.F11)) then self.showstats = not self.showstats end if self.showstats then self.context:SetColor(1,1,1,1) self.context:DrawText("FPS: "..Math:Round(Time:UPS()),2,2) end end if self.currentState == "main.menu" then self:MenuDraw() elseif self.currentState == "somethingelse" then --Refresh the screen self.context:Sync(true) end function App:changeMap() [size=4] --Handle map change if changemapname~=nil then --Clear all entities self.world:Clear() --Load the next map Time:Pause() if Map:Load("Maps/"..changemapname..".map")==false then return false end Time:Resume() changemapname = nil end [/size] end function App:Loop() [size=4]-- If window has been closed or App.game = true then end the program[/size] if self.window:Closed() then return false end -- break this out into it's own function so it's not cluttering up our main loop self:changeMap() self:update() self:draw() [size=4]end[/size]

I see no lua file.

It kind of does honestly. If skill sets aren't lined up correctly the team has a high chance to fall apart. I'm guessing he's more talking about "elite" members bashing the "noob" members for the quality of their work, which sometimes happens when people join up. We need a match.com for matching up the right programmers with the right artists lol. I'm thankful I found one and we work great together . However, it took about 10 years to find a good match.

Looking at materials alone might not work for terrain. Seems terrain just has the textures not the material and not sure if we can get what texture is showing through at a given location to decide on the sound. Using an atlas shader, which we do, also wouldn't work as you wouldn't know which subtexture you are on. Trigger zones might be a better option but more work. Footsteps aren't generally gameplay breaking.

This sounds like it could be a fairly simple "library" to make. I'll need this for our game so perhaps I'll look into this and release something. It's pretty much mostly setup. Configure a table that says this entity type on this material makes this sound. Then it would just have some Update() function that you call that does the raycast. [EDIT] I think I'm going to put this on my sprint because it's interesting and I want to work on it

As usually happens on forums responses flow over from other posts. Nothing in this specific thread warrants the response, but I think it's the combination of other threads started by OP. Ask YouGroove about the responses you get when you make multiple threads that complain about this or that in the engine. He would be the extreme example in this case, but surprisingly he's turned his tune around lately

There is no such thing as "self" inside a normal function. The "self" variable is only available in "classes". If you've ever used C++ "self" is basically equal to "this" or in VB to "Me". If you want access to the context variable you can either use App.context (IF you are using a Lua only app) or Context:GetCurrent() as in local context = Context:GetCurrent() and now you can use context in your function. This is probably the best option. "self" can be confusing if you don't know object oriented programming. It's actually a hidden variable that Lua gives you inside table functions when you use the syntax sugar of calling the function.

To be fair official support is only C/C++/Lua in LE 2.

Yep you can do that. Look at one of the AI scripts to see how it includes the animation script. The animation script is more of a class but this shows how you can include lua files. Just note that those lua functions are global and so if you don't keep track of your function names and you have a lot of files around you may end up overwriting one of your function definitions and Lua won't be kind enough to tell you that

@Ameshi That scene is great, but getting your characters to move around in it is way easier in LE 3 than it was in LE 2 since you had to build your own system in LE 2 to do that. Now, some experienced people might say that's better as you have more control, but your average "I have a dream game I want to build but don't know much about game dev" person just wasn't able to get characters moving around their scene like they can in LE 3. And since LE doesn't take royalties all customers are pretty much created equal and the experienced guys aren't favored all that much over the guy with no experience. LE 3 was more about getting a lot of inexperienced people able to get some type of gameplay going and I think it's done it's job. We can only hope that over time some of those neat features in LE 2 come back.

C++ will always be the fastest but often you don't need the fastest in some of the gameplay things you do. Lua is more flexible though. It's the never ending battle between speed and flexibility!

dexsoft is the best place for animated models and I've never had any issues with them.

I agree. This allows for spritesheets instead of separate images for 2D animations

It's been some time (many updates) since I've been in our C++ solution for our game. When I opened it just now I'm getting errors saying it cannot find Leadwerks.h. Does anyone know if anything changed within the last recent updates for C++ projects that we need to do?

That's what I thought at first but he's passing self.entity inside an entity script (because of Script:Start() shown) which means even if it was it has a script attached to it which would prevent the collapse. I'm not 100% sure if the Lua entity can be translated to an Entity in C++. You might want to try just passing it's string name and then in C++ find it via it's name for testing purposes. Of course this means each name has to be unique (which I'm a proponent for personally anyway).

UpdateWorld() is called as fast as the PC runs where UpdatePhysics() is called at a constant rate (promises to run x times per second) from what I remember. Which I think would mean if you have a slow PC then UpdatePhysics() might be called multiple times per cycle to catch up.

Soldiers I believe he mentioned he would like to look at.

I'm working on a project with TJ and I notice if I just open a model and look at it and do no changes at all the .meta file for that model seems to get changed (git is picking it up as a change). Is this really needed? It can cause conflicts that aren't valid. 1) What is getting changed in the .meta file when you just open the file? 2) Is whatever change really needed? For people using source control this can cause problems/extra steps.

I don't think this works the same in C++. I've never used the script field in C++ so can't tell you how working with that is. In Lua you'd check if functions or variables (basically the same thing anyway) exist before trying to use them and if they don't you can print a warning to tell the person they messed up.

I think he meant: He's probably expecting more business speak . "I don't think a tagging system is the way to go for Leadwerks" Nobody likes hearing their idea is a very bad one

Bumping this as I still offer 1 on 1 Lua training for LE. See original post for more details. Feel free to send me a PM with any questions you have.

When you call the function you pass your object to it. You are defining an object with Nivel n inside the parameter. I've never done that before and guessing it's not liking that. Try: Nivel n; prota->moverDerecha(n);

So when I step through I have some strange behavior. If I have something like below: function ScanDirRecursive(dir) local files = ScanDir(dir) local i for i = 1, table.getn(files) do local ext = FileSystem:ExtractExt(files[i]) if files[i] == "" then -- this is a directory local fs = ScanDirRecursive(files[i]) -- copy all files we just found in fs to the final files table local j for j = 1, table.getn(fs) do table.insert(files, fs[j]) end elseif files[i] == "mdl" then -- this is a model file so we want to add it to our list table.insert(files, files[i]) end end return files end I put a break point on the line that has FileSystem:ExtractExt(files). If I press F9 (step into) the cursor goes back up to the line above (the if statement). Basically it looks like it ran everything below and hit the breakpoint I have back on the if statement. Now an F9 obviously can't go into FileSystem:ExtractExt() but then it should be acting like a Step Over command instead of a Resume command. This is how Visual Studio does it and I assume all debuggers.

Give this a shot self.light = Pointlight:Create() self.light:SetPosition(self.entity:GetPosition()) self.light:Move(0, -1, 0) -- may have to play with the -1 value self.light:SetRange(5) I can't recall if lights start pointing downward but if not you'd have to rotate it too. Unless you plan on moving the box during runtime you don't need to make it the parent. Just curious though, why do this in code? Why not just make a point light in the editor and line it up in the editor and make it a child of the box? Then you can make a prefab of it.

What are you expecting? "I wanted to draw a light from my object which is a box" isn't detailed enough. Are you expecting the light to shine down from the box bottom of the box? Up from the box? What is your final result you are aiming for.