All Activity

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.

-- Configurar colores para el combo box (tema NASA) _cbResolution:SetColor(0.1, 0.1, 0.1, 1, WIDGETCOLOR_BACKGROUND) _cbResolution:SetColor(1, 0.5, 0.25, 1, WIDGETCOLOR_FOREGROUND) _cbResolution:SetColor(0.3, 0.3, 0.3, 1, WIDGETCOLOR_BORDER) _cbResolution:SetColor(1, 0.5, 0.25, 0.3, WIDGETCOLOR_SELECTION) _cbResolution:SetColor(1, 0.6, 0.3, 1, WIDGETCOLOR_SELECTEDTEXT) --_cbResolution:SetColor(0.2, 0.2, 0.2, 1, WIDGETCOLOR_RAISED) -->>>> Crash App _cbResolution:SetColor(0.15, 0.15, 0.15, 1, WIDGETCOLOR_SUNKEN) And you cannot change the color in a combo box for the item letters, they always remain white.

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...

5.0.2 Beta Full update for bug fixes, see details here: https://www.leadwerks.com/community/forum/120-bug-reports/?filter=solved_topics

I'm almost approaching the end, polishing errors, something there, something there, we're almost there.

In our game, there was a problem where a call to window->FlushKeys() was resetting the key down state, making the invetory screen flash on and off.

You don't want your characters to act as a navigation obstacle. That will make their volume get removed from the navigation mesh, and may be the cause of your problem. Navigtion agents will avoid each other using the built-in crowd system.

I played with Nav Mesh parameters and sometimes got: self.agent:Navigate(p1) == true but a zombie didn't move This is parameters values from The First-Person Shooter example.

I deleted NavMesh then create it again and all surfaces in my level are colored in blue. But Agen:Navigate returns false. Another point. At the beginning of the game, the characters are slightly elevated above the ground, so when the game starts, they fall to the ground. But after the NavMesh is created, the zombie falls to the ground very slowly. Early I used to think this was because "Nav Obstacle = true"; turns out not. The surface needs to have its "Nav Obstacle = true" parameter set to make it blue.

This is very strange. Perhaps objects representing the ground should have some special properties or object types? In the example The Ferst-Person Shooter, all floor objects have the following properties: Static = True; Nav Obstacle = true; But if I assign “Nav Obstacle = true;” to my NPCs, they slowly fall through the ground. Maybe there are some special parameters to Nav Mesh? My character and an enemy are very closed. Nav mesh is stretched across the entire game world, as in the example The First-Person Shooter. When I rebuild the navigation (Shift + N) in the editor the surfaces of game objects are not colored blue as in the example The First-Person Shooter.

My thanks to everyone who helped. Everything is fine now, the erroneous charge was cleaned out and I have the engine. I haven't had a lot of time to do anything but some planning and trying to get versed on using Lua. My eyesight is terrible and it takes a while for me to get focused.

Updating graphics drivers will likely solve this problem. Closing this due to lack of response. If you have still have problems feel free to let me know.