Crazycarpet

No problem, although I still can't reproduce the gliding! Nice game, looks good glad to see an increased amount of C++ use in the LE community. Also you sir, need a banner!

Well forst on line 3 is self not nil? But your errors talking about line 9 where you accidentally used curly brackets. newObject:SetPosition(self.entity:GetPosition())

I don't know, just a guess... but maybe you can't pass light user data as an argument since it technically has no type? try doing a tolua.cast on the entitiy. myclass::some_function(tolua.cast(self.entity, "Entity")) But again, just my best guess off the top of my head, assuming 'self.entity' exists. That would also explain why void* pointer version works, because you're passing a type-less argument.

Great suggestion, really hope it gets added in the near future. Edit: Didn't realise the pick-mode option was in the material settings.

Isn't this just the angle of your directional light?

This is exactly what it looks like, my project external dependency for Entity.h has UnlockMatrix argument as a bool still, yet it compiles but crashes when trying t use Context::GetHeight for anything... How do i fix this?

I was just finding ways to optimize my project on a blank one while I'm waiting for the Context fixes.. and I noticed something, by disabling some settings on bones you can get pretty decent FPS gains... any reasons why I shouldn't run any of the methods selected in the screenshots here? http://postimg.org/gallery/3c0l909gw/ (Average FPS outputted to console in screen-shots, showing which ones have bone setting changes and which ones don't in the screenshots.) They still seem to draw their shadows and handle collision properly, just get a nice FPS boost... This is a freshly created project with nothing other then an average FPS counter and the code to change bone settings in the map callback. Also, does anyone have any ideas as to how I can make this automatically happen to bones whenever they're created by the engine?

Makes sense.

In my C++ project the following crashing on the 'GetTextWidth' line, during the following code in my App.lua after updating my project: //Create a context. context = Context::Create(window); System::Print("TESTING"); //Makes it here, then crashes. //context->SetFont(Font::Load("Fonts/Arial.ttf", 36)); //When uncommented, makes it here, then crashes. System::Print("Size: " + to_string(context->GetFont()->GetTextWidth("gfdgdgfdgfd"))); System::Print("Made it here!"); System::SetProperty(PROPERTY_MOUSESENSITIVITY, mousesensitivity); I'm wondering if anyone else is having issues with GetTextWidth (In C++ only, works in Lua for me...) or if this is just a me thing. I added that test code because BEFORE I added it GetTextWidth was crashing elsewhere in my project. I find it very weird that this only crashes the app when called in C++.

Yeah that does look great, hope that comes in an update soon.

I don't know if it's something on my end, but I updated Leadwerks and rebuilt my projects now they both say the following error when trying to launch: "The procedure entry point StreamInternal_CreateInterface could not be located in the dynamic link library". I don't know if this is a bug or what... but any help would be appreciated. It had no problems til I rebuilt it under the new update on the beta branch.

Give me a few minutes, I'll post some screenshots its a fresh project. Edit: here's the map file since you wanted that instead. https://www.upload.ee/files/6069655/start.map.html Edit#2 since you think I'm lying to you about FPS numbers -.- : -1 Crawler http://i67.tinypic.com/6ibb6h.jpg 742 FPS -2 Crawlers http://i67.tinypic.com/174fty.jpg 580FPS -3 Crawlers http://i65.tinypic.com/2n8v3u0.jpg 369FPS -4 Crawlers http://i63.tinypic.com/8wk47p.jpg 350FPS -5 Crawlers http://i64.tinypic.com/33cyah2.jpg 270FPS. -6 Crawlers http://i67.tinypic.com/2432gdg.jpg 216 FPS -7 Crawlers http://i63.tinypic.com/2mgtwrq.jpg 162 FPS So as you can see, I'm not lying to you about the numbers, don't know why you'd think I'd make up FPS numbers... -.- I'm not complaining about the performance it's fine, I'm wondering why it starts out with such immense drops.

Thank you! Animations were the only thing in LE eating my FPS... can't wait to see if there's a noticeable FPS boost. Edit: Gained a solid 20 FPS on a scene w/ about 10 crawlers. Couldn't be happier, gained tons of FPS in my actual test scene. 0.o Although (of course) animated NPCs are still the most expensive thing in my project, drop about 25-60 FPS per crawler. Is that normal? FPS: -7 crawlers, 180 FPS. -5 crawlers, 300 FPS. -2 Crawlers 750 FPS. Tested on a new project w/ a 1024x1024 terrain, and a hollowed box containing the crawlers and the player inside.

Are you not able to check if they collide with the door? then stop them. I'd recommend keeping the 'pick' too... there's probably a quite simple way to make the pick alone detect the door every time, but I just woke up and I'm too lazy to think about the simple math involved... maybe later.

Fixed a simple bug that was caused by a Lua work-around not needed in the C++ verison (--n;), can you re-upload if its not linked to the pastebin directly.?

That's the work around I ended up doing... I just feel like it'd be nice to have these hooks regardless.

So if you want to know your first and last block, and make sure ones at one end, and the others at the other end. Do something where you'd randomize the X and Z positions of each block (left/right, up/down) BUT for the Y axis, calculate the next block's position based on the (blockCount * distancePerBlock) then you'll know it keeps moving in one direction. (You can even add slight random offsets to the Y position after you do the (blockCount * distancePerBlock) calculation to determine the next blocks y-axis position.) Otherwise you're just looking for the block in the furthest direction each way.. there's no guarentee blocks won't spawn in each other and that you'll be-able to get across them. Edit: I forward in LE the Y axis is up/down and Z is forward/back for some odd reason. (Turns out I just live under a shell and this is pretty common in games.) Untested and not-very thought through but heres an example showing what I'd do: http://pastebin.com/7eScHecb In the future you may even want to make the offset's scale based on the 'box' size and what not just so you can have a really dynamic, easily customization obstacle generator.

Great job guys, looks awesome. Shadmar that water looks... wow.

Looks pretty slick.

I know this'd probably be a pain to implement but I feel like it'd be a really great hook to have... The problem I'm facing now is I'm trying to attach a "PhysicsMaterial" to every Leadwerks::Material that's created, and right now I just use PhysicsMaterial everywhere instead of Material and the methods in PhysicsMaterial create the Material... but this is kind of a head ache, and not so Lua friendly.. I was wondering if it would be possible to get an Object::CreateHook because it's make life easier in so many situations, and it'd be a great counterpart to Object::DeleteHook... It'd be nice because then I could just create my PhysicsMaterial on this CreateHook for the material and that'd be that, instead of this big, headache of a class that makes creating materials in Lua a headache til I expose PhysicsMaterial through toLua++... I just feel like in general it'd be a great hook to have in so many systems... especially because in things like Materials, many entities may share one Material so I can't create my "PhysicsMaterial" when the entity is created. It'd be nice to hear back on this from you Josh because if you're planning on adding it I definitely want to put my project on hold as this would make life so much easier in the future. Edit: -Another problem w/ the way I'm doing it now is I have to do a sloppy hack spawning a huge box to change what type of material every LE entity and collapsed brush that's created in the editor uses... -I also don't know how you'd implement CreateHook since like.. it'd have to be global and not object specific (because we obviously can't object->AddHook() when there's no object) but something like this would be so handy... I guess the hook system couldn't do it but if you could think of another way to implement this it'd be so amazing. A callback like this is literally make-or-break (work-arounds working pretty well) for people who want to make robust C++ games, because otherwise we have to have tons of hacks every time we have a situation like this where we want to extend the behave of an LE object type. I'll try to post an example of a situation where this'd help later... basically the problem right now is we need to implement seemingly unnecessary hacks (that could be avoided with a callback) every time we want to extend the behavior of LE object types, and in turn this really limits the type of projects that can be made in LE But again, I do realize this'd be a pain to implement in a neat, working manner because we run into all kinds of issues like what type of object is it, etc.. maybe LE would benefit from some form of global-hook system? Physics Material Files for info on how we're extending "Material": http://pastebin.com/HZBfZGi6 http://pastebin.com/twVLUPWG Again! I know this would be a pain, but it'd make LE Objects so much easier to extend, right now its SUCH a headache. I really feel like LE is too focused on Lua, to the point where it's next-to-impossible to make a pure C++ project that is unique, and robust... this simple solution would make all our C++ problems go away! we even have our C++ entities working w/ the flowgraph editor (thx reepblue)! This is the last problem (to my knowledge) we need to conquer. Edit2: Why can't we just have some global hooks thru System::AddHook for creation of LE objects?

I noticed when implementing a system today that even on some surfaces GetMaterial() returns null.... So I guess some surfaces simply don't have materials on them, just check and make sure 'Surface::GetMaterial() != NULL'. I noticed this in a similar situation, when I was relying on the fact that Surface::GetMaterial() never returned null, when in fact it does in many cases so I had some crashing til I did a check to make sure the returned value isn't NULL, now I'm getting the expected behavior.

Is a torus not a doughnut shape? Pretty sure it is.

I noticed this too, but in general I'm just getting poor performance on the beta branch no matter what scene I'm in, no matter how complex or simple... if there's shadows I'm getting bad performance..

Sorry not going to be by a computer for a few days and i dont have Animationmanager.lua handy so ill show you the arguments for the c++ animation manager. void SetAnimationSequence(const std::string& pSequence, const float pSpeed = 1.0f, const int pBlendTime = 500, const bool pMode = false, func_ptr pEndHook = nullptr); (Ignore endhook because that arguments different here, but up to there its the same on the Lua version (except every numeric type in Lua is a double.).) Try: Self.animMan:SetAnimationSequence("attack", 0.4, 500, 1) So that'd be speed of 0.4 blendtime of 500 and a mode (repeat or not?) of 1 (Don't repeat). Right now your blend time of 0.5 seems really, really low... And im not sure if 'mode' defaults to one or zero. Edit: Just checked before leaving for the weekend... in the Lua AnimationManager 'mode' defaults to 0 which is repeat mode.... The line I pasted above should w/o a doubt work. Although are you sure self.model is the entity you're meaning to attach this to? and not 'self.entity'? I'm just saying this because it looks like you're meaning to attach your script to an entity in the editor, which would then make the visible object you see in the editor 'self.entity'.

So I'm suggesting this because reepblue and myself have systems that both use large, physics-less,, invisible entities as triggers and it works great... minus one thing, when building GI thinks look really messed up. We were hoping in the near future we could get something like a flag for materials to prevent this issue, and other issues alike when building GI.