Crazycarpet

Great start mate.

Good point, overlooked the fact that one we remove the animation, the vector shifts all elements above it down an index at this point in the script. I prefer the first method because otherwise they'll all delete at once after and that'd be a slight performance drop... not to mention we'll save a tiny bit of memory by keeping Animation it's own class, and keeps the vectors copies when shifting smaller. Also figured out jittering thanks to Josh, fixing now... will re-upload. Edit: *Big thanks to Josh for helping me figure out how to fix jittering, and the last of the issues in the AnimationManager* Anyways, I cleaned up the code, used forward declaration, removed redundant checks, and this version should work out of box: .cpp file: http://pastebin.com/PCfEBzW0 .h file: http://pastebin.com/fHRhPrvp (My projects currently unusable til I generate a few toLua++ bindings and I can't test on it so if for some odd reason the above doesn't work, I fixed the links in my first post to contain a working version but if you use this version you'll have to make a few changes for it to work in your project, just minor things... SAFE_DELETE(*it) would become delete *it. (You should know when it's safe to delete something reepblue!! Puppeteer class won't exist for you, etc.)

Sleep's overrated anyways. Also I updated the pastebins and changed the example so 'animationmanager' isn't allocated to the heap, but to the stack as a member of AnimationManager instead of as a pointer to the object just so no-one thinks we were doing it the right way in the example by creating the 'animationmanager' using the 'new' keyword. But yeah, now it's proper in the pastebins and it's all good. Edit (bcus 2 ppl asked why it's better to make it a member over a pointer to the object): -Since I made it so 'animationmanager' is a member of the PuppeteerAnimating class it's now both allocated on the stack (faster because it already knows where to insert the memory, instead of finding a place to put it where it'll fit) and it's an automatic variable which means we don't need to destroy it in the destructor, because it'll be destroyed automatically when it goes out of scope. (In this case when the parent, PuppeteerAnimating object is destroyed.) -Because it's no longer a pointer, and now an actual member you have to access it using 'animationmanager.' instead of 'animationmanager->'. -Stack allocation is much faster than heap allocation ('new' keyword, malloc, etc) because it's just moving the stack pointer, it already knows where to put the object in memory. Where as allocating memory on the heap it has to find a big enough block, split up the memory, keep information about where it's located, etc. Not only is it much faster, but it also has to do with the lifespan of the object, this goes back to the fact that it's now an 'automatic variable' because it's a member. Memory that's allocated to the stack is destructed in the reverse order it was allocated in (so it's lifespan is the same as the scope it's declared in, then it's automatically destroyed.) Memory that's been allocated to the heap (or free-store) has a lifespan you control, which should generally either be shorter or longer than the lifespan of the scope it's allocated in. (If it's the same, odds are you could be allocating to the stack instead and getting those performance gains and slightly lower memory usage! [no pointer]. Although when you NEED dynamic allocation you need it.. just if you don't, don't use it. [like when you don't know the size of an array you have to initialize beforehand.]) (^ in a nut shell, so please don't kill me about heap/free-store terminology, etc. It's just a quick explanation for anyone who was wondering why I changed it.)

Thanks, good to know.

Sorry for the bump, but you shouldn't be doing it like that... You add it as an argument when you're calling Leadwerks::Package::Load(); You shouldn't edit Leadwerk's included header files and all you're doing is setting your password as a default parameter when you don't specify one when calling it. .But yeah I don't think editing these header files has any effect... I tried it once when I was bored (or maybe you have to rebuild your project instead of just build?). But either way it shouldn't be done.

Wow Josh UI's looking great, thanks for keeping us updated. Are there callbacks yet? >

I have a feeling your code's getting to 'break' in your loop because the 'if' condition isn't met... I don't really have a demo so I can't test anything. So it seems 'Animation* completedanimation = *it;' is the last thing called, but I bet it's doing that, then breaking because 'n>= maxanim'. Edit: Also 'n' is always 0 in your code, isn't it? I did a quick skim through so maybe I missed something... You should be setting 'n' to the index of the current animation you're on in your loop. n = it - animations.begin(); or change to a range based loop when you need the index and are traversing a std::vector (lists aren't contiguous so you can't.): for (int n = 0; n < animations.size(); ++n) { } Then you'd have to set 'completedanimation' using animations[n]; Because in Lua 'for n,completedanimation in ipairs(self.animations)' makes 'n' the index of the current table member and 'completedanimation' the value itself. (Although I'm pretty sure you know this and just forgot to set 'n' ) If it works any chance you could post the working one? I know it's a quick change but I need to do this soon myself and if you've already done it it'd be cool. Edit #2: You forgot to make a few different variables equal the current index in the vector you're traversing. Like 'i' in Update(); Also 'maxanim' could be wrong because animations table in Lua would start at index 1 where as in C++ it'd start at index 0. 'animations' should be a member or everything will share one queue. Edit 3: Here's a fixed animation manager, thanks reepblue for the project so I could test and fix: .cpp file: http://pastebin.com/PCfEBzW0 .h file: http://pastebin.com/fHRhPrvp Also Josh have a look at animationmanager.lua. Where you have the loop with 'n' as the key and a separate 'index' variable, I think you mean to just be using 'n' in table.remove() and remove the 'index' variable all together. If two animations finish in the same frame, the wrong animation could be removed from the stack, no? NOTE: endHook calls your callback (can't be a member function) and passes the Leadwerks::Entity* the AnimManager belongs to as the first argument, and a 'const std::string&' which is the sequence name as the second argument. Example usage is in the cpp file. Here's a std::list version of the .cpp file that's unbenchmarked. http://pastebin.com/AQh4w74M ^ The list version could very well be slower (and most likely is), because although faster on removing elements from the middle (avoids copies) traversal, etc, is all slower. It's almost always slower to use std::list in my experience unless you're removing big objects that aren't at the back of your vector. (Big, slow, expensive copies.) *OUTDATED* NOTE NOTE: The animations seem to be a little jittery, will fix tomorrow.

You may as well go up to like 50-100 because it's not going to slow things down... it'll print as many as it should then 'break' out of the loop.

You can just loop to as many levels as you want and 'break' when the object returned from debug.getinfo(level) is nil.

Great idea.

There's no way to make it so we can specify the range of scale we want?

https://en.wikipedia.org/wiki/Normal_mapping http://www.leadwerks.com/werkspace/topic/9225-best-free-tool-to-generate-normal-maps/

Just make the outer bound huge and paint it all in a matter of seconds.

Josh should really update the demo, LE has come a long way since 2014.

Looks great so far, can't wait to switch over to the new Leadwerks Ui... finally I'll be able to give my client application a nice developer console. Using pdcurses for the server. :/

I think having a whole wack of cameras would be the ugly way of doing it. xD Rick's suggestion is great, I'd do that... it doesn't have to be ugly if you organize it properly... you could just have a Lua table that stores your cameras, then a function like App:SetActiveCamera().... that's basically what I do in my game, except in C++.

Looks nice!

Good, would be useless. although VS2015 support would be nice.

Callbacks please.

Definitely do kind of like this way. It's very simple and straight forward, looks organized too. We could just create a listener or something in C++ and attach a Lua script to it to "spawn" the GUI from C++ code right?

It's pretty easy to make a few C++ classes over ENet that allow you to write data , then expose them with the LuaJit FFI api, or even toLua++ if you wanted. I did this with ENet and used FFI to allow for creation of these classes in Lua without the additional overhead, I don't really want to give my code otu til I get it a little further a long at least, but if anyone wants I could give a quick tutorial or description of how I made my system. Minus all the back end systems, to use my Message/Reader system it writes like this: Lua: --Server netmsg.Register("MsgOne") --If you forgot this part it would still work, but it'd give you a warning telling you it's faster to register this, because then the client downloads it on initial connection instead of while he's playing. (Except when sending messages from the client to the server 'message name' MUST be registered by the server.) concommand.Register("testmsg", function() --concommand system unrelated to example. netmsg.Start("MsgOne") netmsg.WriteInt16(12345) netmsg.WriteFloat(34.4536) netmsg.WriteString("Whatever") netmsg.WriteVec3(Vec3(12.3, 45.6, 78.9)) netmsg.Broadcast() end) --Client netmsg.Listen("MsgOne", function() local int16 = netmsg.Readint16() local fl = netmsg.ReadFloat() local str = netmsg.ReadString() local vec = netmsg.ReadVec3() System:Print("Message received!") end) C++: //Server Netwerks::Message::Register("MsgOne"); //Inside some sort of initialization function. static void TestMsgCMD(int argc, char* args[]) { //Unrelated, part of con command system. Netwerks::Message message("MsgOne"); message.WriteInt16(12345); message.WriteFloat(34.4536); message.WriteString("Whatever"); message.WriteVec3(new Vec3(12.3, 45.6, 78.9)); } //Client static void RecvTestMsg(Netwerks::Reader* reader) { int16_t int16 = reader->ReadInt16(); float fl = reader->ReadFloat(); char str[MAX_MSG_STRING_LENGTH]; reader->ReadString(str, sizeof(str)); Leadwerks::Vec3* vec3 = reader->ReadVec3(); Leadwerks::System::Print("Message received!"); } Netwerks::Handler::Register("MsgOne", &RecvTestMsg); //Also in some sort of initialization method. But for entity variables I made a separate system (that uses this one) to keep certain variables synced. When I get a little further into my project I'll most likely release a template or something, but for now best I can offer is helping anyone make a similar system. But yeah if you don't want to do this extra work I'd use RakNet, like Rick said you can only send strings through ENet with Lua unless you do something like this.

Omg this REALLY REALLY needs to happen, real headache after you hollow or carve and you have like 50 CSG brushes.

Amazing update, brought Leadwerks to a whole new level.

Although it would be nice to have some sort of "plugin" feature for the editor I don't think it'll happen. I'm fairly certain it's been suggested a few times.

I have a GeForce GTX 970 and I get the same problem, however only in the editor. I haven't been able to figure out what causes it so I haven't bothered posting as I figured it'd be useless to complain about something Josh can't reproduce. But since it seems other people have similar issues I figured I'd mention it. I seem to randomly get these exception access violations when doing anything in the editor, some common things I've noticed are: Loading a project (Most often), Creating a new project (Very rare), and often when selecting things [maybe only certain things?] from the "Create" drop down menu (Fairly rare). Edit: That being said, since opting into the beta this hasn't happened once. Although I can't confidentially say it's fixed as it was always a rare issue that'd happen once or twice a day on average and I haven't been using the editor extensively since updating, more been working on the code in MSV. Also after posting I noticed this thread got a little off topic. xD OP's problem is his video card is incompatible.