Crazycarpet

Why do new variables need to be at the top? For organization sake I guess. But I mean as long as the variable exists in whatever scope you're trying to reference to it from you should be able to define variables anywhere... Maybe I'm misunderstanding the suggestion but often times in Lua I don't want my variable declared at the top, lots of the times I want it to be 'local' to a smaller scope, so I define in further down and sometimes even in it's own block using 'do' like: do local whatever = 4 print(tostring(whatever)) --Would print '4'. end print(tostring(whatever)) --Would print 'nil'. I do think in some cases it'd be handy, but overall I feel like it'd create clutter, and I feel like there's better things Josh could dedicate time to. Definitely misunderstood the suggestion. Noticed literally after posting, lol. For a moment I never realized you were talking about the 'Script.' variables that you can see in the editor, this would actually be fairly useful but as Rick said not too many scripts are going to be that large.

Looks good! glad you got it working. However, you don't need the "fpsplayer" argument in your Script:GetPlayer() function calls. Change: self:GetPlayer("fpsplayer") to: self:GetPlayer() Because Script:GetPlayer() doesn't take any arguments, which also means it wouldn't work for a multiplayer game not that it'd matter for you. "fpsplayer" was there because the other 'FindEntity' function searched for entities by name, where as GetPlayer() loops over all the entities in the world and returns the first one who's key value "type" is equal to "player". Good to know, wonder why is was saying 'SetSkybox' was nil in the example file if it's exposed though.

No problem! It comes with time, glad I could help. It really does come with time, and even if you're great at Lua switching between engines can be tough because everyone has things set up differently, for example in Leadwerks you have the global lua state - and every object with a script attached has it's own Lua state. So you have to be careful. My solution isn't the prettiest and could be made nicer but tracking player entities and entities via tables, it'd be faster to retrieve the player object to. The only reason I prefer my solution over the 'world' method (besides the fact it's undocumented and I never knew it existed.) is because in something like the multiplayer game I'm making, it's nice to have per-player control over these things. If you ever need any help with Lua just shoot me a PM. I've been writing it for a long long time so I definitely don't mind helping with it. Thanks! I never knew there were world skybox commands, but honestly I personally prefer the camera skybox methods because it allows you to have like per-player control of it in for example the project I'm making where it's a multiplayer game (Not that I plan on making players ever have different skyboxes, but it gives me the option to). You just have to have a few systems that keep track of entiteis, and player entites etc to make retrieval of the player object easier. Not to mention the 'World::SetSkybox()' methods aren't exposed to Lua. As for the 'world' implemntation, there's nothing wrong with what he did. If you look in "Main.lua" he defines 'world' globally using: world = World:Create() Since it's created in "Main.lua" which is executed on the 'Interpreter::L' Lua state, this will be safe, and will exist in the script file. I know this because I checked, I wondered the exact same thing as you. thanks for the reply though! especially for the info about 'World:SetSkybox' not to familiar with Leadwerks as is because I've only been working with it for a very short time.

You get the error message ":attempt to call method 'SetSkybox' (a nil value)" because 'the 'world' object you reference to doesn't have a SetSkybox method. 'SetSkybox' belongs to the 'Camera' class, so what you'll have to do is make a simple Lua function to find your player entity, for example using one of Rick's old snippets: function Script:FindEntity(name) --Or you could make this a global function, in Main.lua or any file included on the global lua state. for x=0, world:CountEntities()-1 do if world:GetEntity(x):GetKeyValue("name", "") == name then return world:GetEntity(x) end end end Then we use that function to find the player's object, and set the players cameras skybox.: function Script:Show() self.skybox = Texture:Load("Materials/Sky/SunSet.tex") --Should be no need to create this on 'Show', why couldn't you create it on 'Start', then just not release it on 'Hide'? local player = self:FindEntity("fpsplayer") --"fpsplayer" in this case would have to be the name of the player in the editor. if player ~= nil then player.script.camera:SetSkybox(self.skybox) end directionallight = DirectionalLight:Create() directionallight:SetRotation(-18.83,-54.375,-118.364) directionallight:SetColor(1.68,0.67,0) world:SetAmbientLight(0.02,0.02,0.02) return true end I feel like you'd be better off loading the skybox textures, and setting them in the player itself maybe... Edit: Alternatively you could do something like: function Script:GetPlayer() for i = 0, world:CountEntities()-1 do if world:GetEntity(i):GetKeyValue("type", "") == "player" then return world:GetEntity(i) end end end

Because lots of people, like me use this to store the Entity* and Object* in maps/vectors. Wouldn't that make this not possible?

Don't know about that. I'd rather see Josh focus on the engine then the DLC. We can make our own model packs, or buy them elsewhere if we don't like the ones on the workshop. We can't change Leadwerks itself.

Great tutorial, helped a lot. Thanks.

What's the global 'entity' table here for? it doesn't look like you use it. But on to your original question, I don't see a problem in the code you've posted. Are you sure this trigger/button that runs 'Show()' it isn't being accidentally activated after you hide the entity? You could try adding a simple 'System:Print' line to the 'Show()' function to see if it's getting executed when you don't want it to. (Which I'd assume it is.) What exactly are you doing to execute the 'Show()' function?

Weird, VSync isn't so great I guess... was just testing on a blank project and my FPS (80) doesn't ever drop due to things like NPCs, however once I turn VSync on, and the NPCs show up my FPS instantly dropped to around 25. Nevermind, was due to some GPU settings. Fixed.

Definitely should, I've been having problems with VSync even in newly generated projects. I feel like this may be the cause of a lot of the framerate issues people experience in Leadwerks.

I think it's just people testing their application in Debug mode and/or VSync on. Because I was really worried about performance in LE as well, I actually quit using it for a while. When running my application in debug mode w/ vsync on, maps with water would instantly drop FPS to 29-30, with AI 20-25, and I have a pretty good gaming computer so I jumped to the conclusion that Leadwerks had performance issues. But then when I finally tested my application in release build with vsync off the FPS of a simple scene was like 1000, and still in the high hundreds when the map would have water and AI. However I noticed that even in release mode when I have vsync on water and AI drop my FPS back down to around 40. So maybe it's a problem with VSync and Leadwerks?

All great suggestions, hope they get added.

Did you edit your "Additional Include Directories"? Right click your project, go to "Properties" --> C/C++ --> Additional Include Directories. And make sure "$(LeadwerksHeaderPath)" is one of them. If that's not there you'll definitely be missing some others and you'll have to pull them from a fresh project. Also check "Additional Library Directories" and make sure the ones containing "$(LeadwerksLibPath)" are there. (Although I don't think this one would affect it.)

I mean its not hard to delete them yourself... but it would be handy to have this done automatically I guess. Plus I'm sure this would be very easy to do.

+1 for sure.

I think it's related to water, any of my maps that have water the FPS drops from 60 to 29-30 constant.

Exactly what Shadmar said, the behavior you described generally only happens when you've forgot to generate a navmesh. In the editor go to: Tools -> "Build Nav Mesh" Once you've generated a navmesh the NPCs should behave appropriately.

I don't really know exactly what you wanna do, sorry half asleep.. Two things: -Keep in mind the particle takes a moment to reach an opaque alpha, it'd be hard to see it in this time if it's spawning in the wrong place. -If you want to use the water effect you should at the bare minimum be creating the water material that's created in the documentation. Shoot me a PM explaining what you want your weapon to do and I'll write and comment it for you. I'd recommend increasing the duration immensely than setting it to a per-defined location on the map, perhaps where you spawn.

I'm just working on networking, a UI library, and all the main things for my game right now: once I get to weapons and stuff I'd gladly post some tutorials.

Sorry for the late reply, but I'd assume 'enemy' doesn't exist in the 'entity.script' table, I haven't tried but although not the cleanest thin to do you could make it into: if (self.entity.location < bulletrange) then if entity.script.enemy~=nil and entity.script.enemy==true then entity.script:Hurt(self.bulletdamage) else System:Print("nope") end end I don't really know when 'enemy' gets defined, so may as-well check to ensure it exists. But why build a Melee weapon object when Leadwerks comes with one?

Edit: Hmm, I dropped it into a new project and it does crash, and yeah, it makes sense. I'll try to figure out what I did in my main project to fix it, I totally forgot - this would definitely cause a stack overflow. Edit2: I got home, and you're right Rick: in order to do it I had to use my 'events' library and call an event in the Script which handled everything elsewhere. Edited first post accordingly. Another thing I noticed is I made "ChangeMap" a global, it has to be part of "App" to use "self.world".

They're out.

Use the Interpreter. Interpreter::NewTable(); Interpreter::SetGlobal(); Interpreter::GetGlobal(); Interpreter::GetTable(); Interpreter::IsTable(); Interpreter::IsFunction(); Interpreter::IsBool(); Interpreter::ToBool(); example from Josh's App.cpp: int stacksize = Interpreter::GetStackSize(); //Get the global error handler function int errorfunctionindex = 0; #ifdef DEBUG Interpreter::GetGlobal("LuaErrorHandler"); errorfunctionindex = Interpreter::GetStackSize(); #endif //Create new table and assign it to the global variable "App" Interpreter::NewTable(); Interpreter::SetGlobal("App"); //Invoke the start script if (!Interpreter::ExecuteFile("Scripts/App.lua")) { System::Print("Error: Failed to execute script \"Scripts/App.lua\"."); return false; } //Call the App:Start() function Interpreter::GetGlobal("App"); if (Interpreter::IsTable()) { Interpreter::PushString("Start"); Interpreter::GetTable(); if (Interpreter::IsFunction()) { Interpreter::PushValue(-2);//Push the app table onto the stack as "self" #ifdef DEBUG errorfunctionindex = -(Interpreter::GetStackSize()-errorfunctionindex+1); #endif if (!Interpreter::Invoke(1,1,errorfunctionindex)) return false; if (Interpreter::IsBool()) { if (!Interpreter::ToBool()) return false; } else { return false; } } } //Restore the stack size Interpreter::SetStackSize(stacksize); As for the map changing, why not use a C++ Derivative of Josh's Lua version? world->Clear(); Time::Pause(); Map::Load("Maps/" + map + ".map"); Time::Resume(); Edit: You'd need to do quite a bit more to take map changing off the Loop so I'd recommend just copying the style of the normal Lua project, It'd be easiest to use a Lua project's App.cpp, App.h and main.cpp files.

I think you missed /lots/ of the link, lol.

If you want you could use LuaJit's FFI api in combination with Lua C API to multithread Lua using Mutex. You shouldn't need much C code, only abit to start the threads and their main functionallity. I've never tried it but a friend of mine on steam linked me this: https://github.com/ColonelThirtyTwo/LuaJIT-Threads I currently use one I made that uses coroutines, but its extremely slow and soon I'll be writing a real multithreading library.