Crazycarpet

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.

AMD's auto-detect never seems to work for me, glad you got it to work; I'd still recommend finding the driver yourself, till I did I had problems with a small selection of games.

Did you ensure it was higher on the list than Leadwerks like Guppy said? This should be the only reason for this.

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.

I have a version that binds ENET using LuaJit's FFI api, I''m sure it'd work on Leadwerks Indie ediotion, although I'm not sharing it; however, I could help you create your own it's very simple and quick..

I'm a bit confused, so how is the grenade supposed to work? You press the shoot key, your character does a throw animation and then it creates an entity for the grenade that's been thrown that eventually explodes or..? Great to see people helping out within the community, looking forward to seeing some of your work.

Yeah, I was quite happy to see it there haha, hope it helps! Good luck!

Agreed but doing it through C++ would produce more overhead, however I do agree with you about toLua, I'm not a big fan of it, also I haven't used it much; I would much prefer the implementation of LuaJit's FFI api into Leadwerks, I think this is something that should be strongly considered in the future. Edit: Nevermind, it looks like FFI is in Leadwerks. Perfect I'd strongly recommend using FFI.

Not a problem, good luck with your future projects!

Same place as the C++ project's source files. Leadwerks/Projects/<Your Project>/Source/

Just copy the code from the C++ source files of a Lua project and replace the C++ source files in your C++ project with the ones from the Lua project, then use the normal App.lua file from a Lua project and edit it as you please, this would make it behave the same way as a Lua project but you'd still be able to code C++ in your project. This is what I did, I find it works the best.

Oh, well that'd work just fine but since LE3 uses LuaJit I'd strongly recommend using toLua. toLua is much faster and weighs in at like 1/10th the overhead.

I'd assume Rick used toLua++ to expose the C++ functions of Raknet to Lua, you can learn about toLua++ here: How to use toLua With a basic understanding of toLua this shouldn't take any amount of time to do. Good luck!