Rick

Like Ma said you can think of it as moving the camera to a spot and taking a picture (this new buffer) from that location then moving the camera back to your player for the normal game to play. Now you have this image/buffer that you can draw anywhere on the screen or as a texture on a model. This moving the camera to a spot, taking a picture from that spot, and moving back to the player happens every frame for video or once for a static image.

An oldie but a goodie! http://www.leadwerks.com/werkspace/topic/11252-prefab-children-not-getting-scriptstart-called/page__hl__prefab+children Don't recall if I ever sent him an example but he did close it. Prefabs in general need more love. There are other quirks with them that seem to pop up for the artists on our team. Faith in them is low and that's not a good thing.

EAX is a C++ library? Where do I get this library? Not really seeing anything definitive on google.

Does anyone know if there is a way to get muffling on a listener? Sometimes I want all sounds to seem muffled at various intensities bit don't see anything on the listener in the docs that would do this.

Is gridPfb null? Check it once before populating.

It would just have to be simulated manually. I would argue with finer control than a physics system and forces you would make much more awesome jumping and tricks.

Does it even pay to use physics? Just align the board to the terrain and move it without physics engine. Messing around with forces would probably result in clumsy controls for the player. In snowboarding games you don't normally fall when doing straight down, it's usually when doing tricks and not landing them right, which probably would suck and be less epic with real physics systems.

Ah ok that makes sense then.

You do? Why is it when I have mutilple ai go to the player they all lump up and slide all over each other? They seems more like they are all trying to move to the same spot and they are colliding with the character controller and because it round they slide off each other.

I think it gives us more control and options specific to our games. We can check for our own BB collision once every 200ms and adjust accordingly. We can have flocking logic to make sure they don't collide with each other but are all following one general path. This is generally what's games do anyway. They don't allow character controllers to collide and slide over each other like what happens in LE when 2 or more collide. That's not a case in my view to not give us the path data. There is a common theme of some ppl asking for access to data the engine already has. These topics are for the ones who push the limits. It's data that already exists. I'm curious on the constant push back on said requests for data? You provide the data and one system that works with data. If that system doesn't meet the needs the user is responsible to make it work. This way you have something for the beginner and something for the advanced. Win win. Steering is the term for what I'm talking about and I think can be combined with the path and dynamic obstacles in realtime at an interval that works best for the game. https://gamedevelopment.tutsplus.com/tutorials/understanding-steering-behaviors-collision-avoidance--gamedev-7777 Open source liberal for steering. http://opensteer.sourceforge.net This article is amazing! http://www.valvesoftware.com/publications/2009/ai_systems_of_l4d_mike_booth.pdf

"For example, there's basically no physics in that game and you will never see an enemy kick over a box like ours do." You're not making a game so that's a strange comment to make. Most games don't require physics on AI characters so the fact that characters in LE can kick over a box doesn't really add much value. The ability to choose would be better. That would start with access to the recast path, specifically from Lua would really help.

That's c++ and didn't catch anything that it's exposed to Lua, unless I'm mistaken.

You said above 45 fps with 25 zombies is reasonable. I'd argue agasint thst given he gets 120 fps until they start chasing him. I've noticed this slow down when being chased in the past as well. The question is what's causing 120 to drop to 45. I suspect it's the physics. I'll run a small test with just tweening, or Move() even, the models towards the players this evening to see if that helps narrow it down. Jen mentioned before SetPosition was slow so maybe that causes something behind the scenes? L4D can have 200+ zombies on screen at once. That should be the bar I would think. Sure poly count will come into play there but something else is also going on.

Are we able to get the path that recast finds? What does it return inside LE? A list of points? Can we get access to this, and from Lua? A lot of things that need to find a path don't need physics and physics is slowing games down because we don't have any alternative movement options when using the navmesh system, that I know of. If we could get access to the path data from that system we can make our own alternatives movements that doesn't waste time checking that we aren't falling when we know the path we got has us on solid ground. This would help increase the number of entities we can have pathing around as most characters moving don't really require physics.

So a big portion of that is physics then and not the models. I can test when I'm home in 9 hours, but that tells me it's more physics and that's nothing to do with Lua but Newton. @Josh is Newton running on a separate thread? If not I would think we'd get a big boost from that. Or perhaps we can control physics update interval? Do zombies chasing on relatively flat ground (game specific) require the update rate physics currently runs at? I'm interested in this because we are working on a game where this matters as well. The interesting thing to ask is does something chasing you really even need physics? If we are able to get the path points that raycast is using then we can use our own move code and bypass physics completely. The physics is what's killing this.

I assume that is because of the physics and not the models. What if you don't make the model a character controller and just a static model sitting there? If you get higher fps then it's the physics which really wouldn't have anything to do with Lua. If it is the physics couldnt couldn't that be threaded to improve performance? I'd also be curious as to what happens if you remove the UpdateWorld function from their script. That would be more of a Lua thing. We noticed when a lot of objects have the UpdateWorld function it slows things down. There can be alternative ways to achieve behavior without the UpdateWord function in each script. It's not enough to have an empty UpdateWorld, it can't exist so that c++ doesn't call it because the function calling overhead is what slows things down when you have a lot of entities that have an UpdateWorld function and if you're doing a good amount of things in there it hurts even more. You want to bail out of UpdateWorld quickly if you can.

@Brutile NOOOOOOOOOOOOOOOOO! Aggror you have to figure out how to show the ghost path the first place on each track as we are racing. Would love that playing at the same time I'm racing to see how well I'm doing. The first Mario cart had that and it would be sweet! Push josh to get generic web api calling into le so this can happen! Or you could just add it yourself and take the game out of the game launcher as it's limiting the potential for gameplay features.

Bugs: The first time you start a track the camera rotation isn't always right. After playing level 60, I think, and hitting Main Menu the game crashed.

Level 1 ball how the hell did you get 13 seconds! At least I'm in 2nd place now! [edit2] Nevermind I see the shortcut now! I got 14 seconds. I'm coming for your title! [edit2] NOOOOOOO. I had it in 12 but overshot the goal! [edit3] And you're looking at the new champion of the world!!!!!!!!! 12.610 [edit4] Got ya in level 3 ball too (barely)! That was was fun! It would be nice to see scores before I try a level.

I do. There are some annoyances using LE with it but I just deal with I guess.

If the point of wanting this is to Id later in code for a check like in his example then what josh said should work. If the point is to be able to make one change to point to what a name is pointing to instead of finding and changing each loading of said code then what he's asking for makes sense. Does that come up often is the question. Often enough to warrant the code to set this up in the editor. Seems lower on the priority of things.

That would seem like ClientToScreen changed between the version then.

Ok I'll just making sure I understood what was happening. This is server side stuff for your game right? I thought you went away from c++ for the server app?

Ok so you will put the data for quest in the database but instead of reading the database at runtime you're doing these other steps to get the data out at design time and it all gets loaded up on startup? Couldn't you just load all the quests on server startup from a query to the db to get it all in memory right away vs doing these extra steps each time you update a quest in the db?

Curious to what you see the benefits of this over using sqlite with it's C++ library to manage the data in a "database"?