Crazycarpet

+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.

PaticleEmitter2 was a typo correct? the error says ParticleEmitter2 right?

It'd be nice to leave an appropriate mark on the wall where you shoot and iron sights but ofc we could add these things..

Good to hear, can't wait.

That's handy, but its unnecessarily large and complex.my version is purely Lua and a total of about 50 lines in the main lua file, aside from the header and the enums. It also produces nicer functions instead of enet.enet_initialize it'd be proper, like: enet.initialize I'll find it on my old external harddrive later and post some snippets.

Not a problem, as for the lowercase filenames, Josh made reference to it being a problem on Unix-based systems as they have a case-sensitive filesystem, it'd be possible for it to cause problems..

Thanks for confirming.

Yeah, works for me when I disable sandboxing. Edit: Then again I have Standard Edition as-well so I don't know for sure.

I'd buy it regardless, but it'd be better to bind it using FFI: its instantaneous and would be like 0 overhead.

You could always manually track entities and assign them IDs, make your own function for creating entities that inserts them into a global entity table, and make a callback function when the map is loaded that inserts those entities into the global entity table. Someone linked me a page that had: if Map:Load(mapname,"Callback") == false then return false end "Callback" being the name of a function, you could create a function like: _G.entities = _G.entities or {} local function Callback(ent) ent.id = #_G.entities+1 table.insert(_G.entities, ent) end Note: I'm only refering to the entities table with _G in-case you already have a local 'entities' table in that file. Agreed.

Looks great! if you run into any problems with scripting feel free to post on the forums or shoot me a PM, I generally check them every day.

Yeah I know but it shouldn't just work just for map entities, I just made a function that does it all before it spawns the entity in, but it would be handy for this to be shipped with Leadwerks for all entities that are spawned, regardless of whether or not they are spawned in or spawned with the map. In my version I just made an event library and it calls the "OnEntityCreated" event everytime an entity is spawned, then you have the entity as an argument... I guess this is not needed because you can write it yourself, I just think it'd be handy; but Josh is probably focusing on much more important things..

Great work Rick, looks pretty cool.

It think it'd be useful to have a callback like App:OnEntityCreated() so players can manually track entities, assign them IDs and what-not. This would be best if it was also called on the map entities well they're being created.

This isn't a bad idea, however what if the entity was removed; would a new entity not be able to take it's old memory address? Perhaps it'd be best for Josh to add something like App:OnEntityCreated() so people can manually track Entities, of course this would have to be called for each entity created in the map as well when they are created.