nick.ace

If I'm not mistaken, with the C++ version of Leadwerks, you can access recast functions directly and do threading, so you can recompute a small region of the navmesh instead of the whole thing. Personally, I would like to see these functions exposed to Lua. When I bought the engine, I had thought that dynamic pathfinding was a part of it due to a few dev videos that showed it, but I guess that was an earlier version like Olby said.

Einlander and randomkeyhits: Is it possible to do this with the navmesh and pathfinding system built into Leadwerks though? I mean, you would essentially be having to program A* or something just for selecting the waypoints. That being said, that's probably the way to go for a tile-based game like Guppy described.

Normally, an emitter plays continuously (think of the firepit in the Workshop). This means that the particles flow out indefinitely. A one-shot emitter is when a set number of particles flow out and they don't get recreated or replaced. This would be for something like a collision against a dirt road where the dust doesn't keep coming up from the ground until it is hit again. You can control this with SetLoopMode(): http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/emitter/emittersetloopmode-r93 The one thing I don't understand is that I can change this mode after the one-shot collision finishes. Is this because the Lua garbage collector hasn't cleared that spot in memory yet?

Lol, your not a trouble! This is what forums are for! Alright, here's a tutorial I created, anyone let me know what other information you want. I can't upload my whole code files because there are a lot of interdependencies that make the files not work in most situations. http://www.leadwerks.com/werkspace/page/tutorials/_/script/waypoints-and-reactionary-ai-r120

I actually have done this in my game. The way I did this was that I parented pivots to the entity that I attached the script to. Then, I renamed those pivots to something like Pivot0, Pivot1, Pivot2, etc. In my code, I got the global position of all of those points, and then I stored their position values in a Lua table. Finally, I iterated through the points (so I would make the character head towards one Pivot0, and then once he came in a certain radius of Pivot0, he goes to Pivot1, and this continues). I would post my code, but it's a rather large and complex file, so I think it would confuse you more than it would help.

Do you mean that you want collisions enabled or the navmesh to be regenerated? If you want the door to have collisions, you need to pick a physics shape under the physics tab for the entity. If you want the navmesh to regenerate, you can do that in code (but it's slow for real-time performance): http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/world/worldbuildnavmesh-r789

I started playing with some of the vehicle physics, but the vehicle seems to glitch out a lot and I think I'm doing something wrong maybe. Is there a way to see where the tires are located (like a command similar to SetDebugPhysicsMode)?

Yep, just right-click and select the decrease grid size option.

If you don't plan on using them anymore, then you should release it. Otherwise, it's still a valid entity. I tested this by created an emitter and allowing it to switch between loop and non-loop mode. After it stopped emitting, I could restart it, so it's still in memory. That being said, I doubt you will encounter noticable performance issues, it's more of a good practice thing.

I always liked being able to slow time and such, especially in the Fallout games. That seems like a good idea for adding to your FPS/RPG game! I'm interested in seeing how you implement it!

That bear is creepy! :0 I love the lighting and the texture detail! I would not want to sleep in that bed!

It looks like the walls have no thickness, am I correct? Generally, those types of seams are a result of walls that are too thin. Unfortunately, the only real way to fix this problem is to make the walls thicker.

Hehe, and I worked on 2 of those games. Question for Josh: Would it be possible to get some of the recast stuff exposed in the future for Lua? It could provide support for RTS games and other building games with the Indie Edition, although this probably should be placed in the suggestions forum. I understand if it's low on the priority list though.

I think it also has a node system if I'm not mistaken. Idk how it works, but I think it's supposed to support shader creation without the need for coding? Or, at the very least, it allows you to easily combine shader effects. Anyway, it seems overpriced for what it offers because there are shader programs for free like it (without the node system of course, which is sort of the selling point of this software). But I might try it out once it goes on a bigger sale.

Oh ok, I guess I misinterpreted it haha. So, a 1k map would probably take a few (2-3) minutes to run across (not sprinting) provided nothing is blocking your path. Of course, you can put some of the background buildings outside of the map if you need to (you can change the world size in the editor without starting over I think). I think the bigger issue is having a 2k or more terrain, as that takes up computational power for rendering, lod (the terrain has a dynamic lod thing going on), and physics. So, you could theoretically create a 2k world with a 1k terrain. I think that's what I do, just so I can go slightly off the map for stuff like that.

From a technical standpoint, Oblivion is quite different than what you are planning to do. I might be wrong with the technical details, but Oblivion streams in what it needs (thus it can have a lot more unique models over a wider distance). The drawback to this is that you can occasionally get lag or glitches if not implemented well, and loading screens are generally needed for indoor environments. Also, Oblivion does not feature huge cities (except for those that require a loading screen). Most of Oblivion's landscape is covered with vegetation or water. One thing I've found is that more so than limiting the number of unique models, try to limit the number of unique textures. The reason being is that texture memory can skyrocket if each building has a unique texture. Although, limiting both is good. I'm working with a similar level design as you, so if you have any questions feel free to ask. My game features a 1k x 1k city with mostly buildings that can be entered and many unique models and textures. I've filled up about half of the map with roads/buildings, but it took me dozens of hours, so unless you procedurally create the city or have many level designers, it's probably a good idea to choose a smaller map size. Edit: Also, the huge open-world games typically have heavily customized engines that support this style of game, something you are unlikely to be able to accomplish with any standard engine (at least to the scale of games like Skyrim).

For breaking down a wall, the easiest way to go about doing this is to make a wall out of broken pieces (each with unique physics shapes) and preferably add a force to at least one of the shapes. Your would replace a solid wall with the broken pieces once the zombie action occurs. I'm still not sure what your design is, so I can't really give much more advice on it. You should provide more details as to what you mean by autorespawning, because there are a bunch of ways to handle it, and it depends on the design of your game.

Oh I see! Thanks! This solves a ton of issues going forward.

That looks like it would work well. Thanks Rick! I'll test it out later when I get time. Is the Interpreter class somewhere in the documentation? Oh I hadn't thought about that. Where are these C++ source files located?

I know you can use Lua in a C++ project, but I want to do something very similar to what Guppy is doing, where App.lua is being wrapped into C++ code. Basically, then you can program App.lua in Lua (so its quick for testing in the editor) but then you can add extra functionality with C++ libraries. Josh once told me it was possible and quite simple to do this, but I haven't had the time or need to try it out just yet.

One up on this as well. I want to know if this is possible, because I love Lua, but I also want to possibly access C++ libraries and commands in the future.

Here's my list: The community (I must say that the contributions of many of the members is something I am very thankful for, and will be something I don't think I can ever repay) Lua support (I never really thought Lua was going to be as useful as it is, but a lot of it has to do with how easy it is to apply scripts to stuff in this engine, including the Leadwerks API (the API is very clean and easy-to-use)) The editor Steam Workshop No royalties Graphics potential (although the current shaders available and the lighting are already outstanding) Physics is seamlessly integrated Being able to speak directly with the developer (Josh ) There's other things about the engine I like as well, but these features are what I view as unique to Leadwerks and what I like most about Leadwerks.

Thanks for correcting me, Rick. I forgot about that! Yes, Rick's answer is a much better answer. For performance reasons it helps a lot. Also, for workflow reasons, it's arguably better to use many models because you can update individual models without breaking the whole map. Additionally, physics can get buggy with complicated shapes that need accurate collisions.

Generally, many different assets. One big model is usually problematic because UV's can get stretched, map sections can't be hidden, and physics of props can't be used. Also, one big model won't allow you to apply different material properties. For texturing, CSG will take care of your texturing concerns for you for the most part, but if you texture a custom model you make, then you'll need to UV map it.

I didn't even know that a radius pick was a thing! I should probably be looking at the documentation a little more, as I always am surprised by cool features I haven't seen or thought of before that are already in the engine. I think I might go Rick's route though since it should also increase speed a little and should give me more control over how the object is picked.