All Activity

Yes, this is much better.

There doesn't appear to be one simple state that tells you what the recast navigation agent is doing. I'm sure the info is in there somewhere, but it will take more time to figure out exactly how it works and what information is available.

Simple I do that: local now = self.world:GetTime() local timebetweenshoots = 500 if now - self.lastfiretime > timebetweenshoots then ... self.lastfiretime = self.world:GetTime() end

Let me see if I even have any functionality like that in Recast...

I think if you add such an event, it will be perfect

It's possible to share the solution?

Not currently. I usually just do a distance check between their position and the destination, and if it's less than a certain amount, I consider them to have reached their destination.

Yeah, you are constantly creating timers, and you are waiting for an event inside the update loop! You probably want to do this: function MyScript:Update() if player:GetPosition().y < -5 and self.enabled == true then self.enabled = false if self.gTimerReborn == nil then self.gTimerReborn = CreateTimer(2000) self:ListenEvent(EVENT_TIMERTICK, self.gTimerReborn) end --self:Kill(player) --self:Start() end end function MyScript:ProcessEvent(event) if event.id == EVENT_TIMERTICK and event.source == self.gTimerReborn then player:SetPosition(initialLocation) self.gTimerReborn:Stop() self.gTimerReborn = nil end end

Is there an event that fires when a mob reaches a designated point on a NavMesh?

Solved

The WaitEvent event slows down the game significantly. I added this code to Update function: if player:GetPosition().y < -5 and self.enabled == true then self.enabled = false gTimerReborn = CreateTimer(2000) --self:Kill(player) --self:Start() end event = WaitEvent() if event.source == gTimerReborn and event.id == EVENT_TIMERTICK then player:SetPosition(initialLocation) gTimerReborn:Stop() end And my game started to slow down a lot.

Its not my script. Josh had it included in the original demo for Ultra Engine.

Sure. I'm kinda taking a page out of Dwarf Fortress's book and making a game where you generate the world first and then the characters you create live in that world. World gen is handled by layering a bunch of different fields on each other, each representing different. First is a land/water field where anything below a certain value is water. Then we layer on a height field, influence it by a separate ridge field to not only give us mountains, but to also have them appear in ranges. From there, a hydrology pass is made to determine rivers and lakes, along with other stuff. All of this is derived by the seed, with the world gen saving only the macro-world data, such as the biome, if there's any water, the min and max height for that cell, if there are any resources. etc. Various properties about the macro-cell are derived based on how that data mixes, such as deserts appearing not because a height map said so, but because the water value was low, and it was close to the equator. Rendering the world is purely deterministic at that point, since the macro world data encompasses cells that are 32x32km each. So when it gets to rendering the area where the player is at, it samples the height data from the derived functions and generates the terrain from that. I found an Leadwerks blog post talking about handling large terrain areas with what is effectively a sliding window, referencing new height values and rebuilding the terrain. This ended up being a much more performant route than trying to generate new terrain chunks. It was much more reliable too, since now I didn't have to worry about seams or stitching, since it was always sampling the same window. This part of the terrain gen is where the suggestions are coming from, I was able to knock out almost all of the performance issues, except for the last bit. Doing some diagnostics, showed that the per-vertex write to the terrain object was about 100ms. When I tried to do it in a worker-thread and write it to a back-terrain object using a time budget method, I was actually able to have the terrain generate with no noticeable hitching, the resulting terrain ended up having stripes from having the terrain built in sections. The striping went away when I did the rebuild all in a single tick. Below are screenshots from a MacroWorldVisualizer tool I wrote so I could spot check the world gen to make sure everything was working properly. Note that the world is a cylinder, so it wraps left/right, but is clamped up/down.

Thanks for the suggestions. Would love to see how you are using the terrain. It sounds like you are doing some very interesting stuff.

I've been working with the Terrain object in C++ in my game using procgen, and while troubleshooting bugs and performance issues, found a few instances where more control over the terrain itself would be immensely helpful. 1. Bulk-update the height data for a terrain If we could have a way to bulk-update the height data for a terrain object, it can greatly help performance. To give an example of how this can help, I'm currently calling SetHeight per vertex (~66k calls for a 257×257 terrain), which is causing about a 100ms hitch when the terrain loads in. If we could get access to an in-memory path like SetHeightmap(shared_ptr<Pixmap>) or LoadHeightmap(shared_ptr<Stream>), it would let us do a bulk upload without writing an .r16 file to disk first. 2. A way to defer rebuilding terrain When we update heights incrementally across multiple frames (time-budgeted), we see visible striping artifacts during the transition. If we apply the same update in one batch, the artifacts don’t occur. Something like SuspendTerrainRebuild() / ResumeTerrainRebuild() would let us apply many height changes while rebuild is suspended with a single rebuild step, avoiding partial intermediate states that cause visual artifacts. Alternatively, exposing a public “finalize dirty region” API like FinalizeHeightChanges(rect) / RebuildNormals(rect) (or similar) would let us control exactly when derived data is rebuilt. 3. Async rebuild support Even if terrain updates must remain on the main thread, an engine-supported async path could help a lot: accept a bulk height update, rebuild internal patch meshes / derived textures asynchronously , then publish (swap) render resources at a safe frame boundary. That would avoid long main-thread stalls and avoid intermediate partially-updated render states.

Y no puedes cambiar el color en un cuadro combinado de las letras del artículo, siempre permanecen blancas.

Thanks for ThirdPersonControls.lua script.

Grand Abbitt is one of my favorite Blender instructors on GameDev.tv. He's created many excellent courses from zero to hero.

I just increased the delay between shots

Simple I just need to call the Move method.

Hey Everyone, I've created a couple of brand new music tracks for your projects....they're 100% free to use with attribution, just like my thousands of other music tracks and sounds: "ENGINEERING STARS" - (Looping) Listen here: https://soundimage.org/wp-content/uploads/2026/01/Engineering-Stars.ogg "PLANETARIUM" - (Looping) Listen here: https://soundimage.org/wp-content/uploads/2026/01/Planetarium.ogg Both tracks can be downloaded from my Sci-Fi 14 page: https://soundimage.org/sci-fi-14/ MUSIC PACKS Please don't forget to check out my genre music packs as well as my Game Music Mega Pack. They're huge time-savers: https://soundimage.org/ogg-game-music-mega-pack/ https://soundimage.org/ogg-music-packs-2/ NEED SOME CUSTOM MUSIC FOR YOUR PROJECT? I create custom music for content creators all the time...mostly indie video game developers. Information is here: https://soundimage.org/custom-work/ Please share! :-)

I can't answer this without seeing your project.

if I link Monster.lua to an object, this object turns its face to a target only but doesn't move. why?

Closing due to lack of response...