This decrease the amount of processing each time

I'm submitting a...

• Bug report.
• Feature request.

Bug report

What is the current behavior?
\SpaceInfiniteGeneration\03-LayeredGeneration\LayeredWorld.gd
If you fly far away enough from a planet for it to queue_free() then fly back towards it to reload it, the code will begin to spawn hundreds of instances of that planet over time. This behavior also causes unreliability when planets are loaded. Sometimes they fail to appear at all if attempted to reload them.

What is the expected behavior?
Planets load/unload reliably, and without creating additional nodes every frame.

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.

1. Run LayeredWorld.tscn
2. Travel away from any planet on-screen until it unloads
3. Travel back towards that planet until it should reload
4. Observe the remote tree as it is populated with planets over time

Demos for the cellular automata chapter

A new chapter in the procedural generation course will have four accompanying demo scenes teaching the basics of cellular automata. Each demo focuses on a new feature to eventually create a pleasing randomized dungeon the user can move around in with doodads such as doors and chests.

Demo 1 - Creating Simple Foliage

This introduces the idea of cellular automata using a modified version of Conway's Game of Life to generate patches of foliage. The idea is to show how users could quickly generate randomized content for their game.

Demo 2 - Basic Dungeon Generation

Here we create an empty dungeon with sliders to control the generation's look and feel. Moving the sliders instantly updates the dungeon.

Demo 3 - Increasing the Dungeon's Appeal

This demo shows how to make the dungeon look good using a tilemap and tile variations.

Demo 4 - The Final Dungeon

In the final demo, we show how to handle gameplay using what we learnt. We place an entrance, exit, doors and chests to create simple, playable level.

I'm submitting a...

• Bug report.
• Feature request.

Feature request

I'll call this a feature request, as I haven't read all the code and don't feel comfortable submitting a PR at this time. Excellent examples! This has helped me get up to speed on GDscript as well as Godot. First off, thank you!

I got hung up on learning how the WorldGenerator works given a bit of perceived inconsistency in variable names (because frankly, a lot of the variable names are quite descriptive and I understood most of them right away). This specific section of code confused me in context:

## Total number of sectors to generate around the player.
onready var _total_sector_count := sector_size * sector_size

Given sector_size = 1000 (in world coordinate units) and the sector axis count is more like 10 (overridden to 16 in the example, in units of sectors), the "sector count" computes to 10_000. The count of sectors, however, is 100 (or 256 in the actual scene with export/tool overrides).

Then later, in the physics process, it is used to find which sector the player is in:

var sector_location := _current_sector * sector_size
if _player.global_position.distance_squared_to(sector_location) > _total_sector_count:

In this case (I'm not sure if there are others), the _total_sector_count is being used more like a pre-computed size for the Sector length to use with _distance_squared_to. The unit of the "total sector count" is actually in world coordinates, not sector counts. I expected it to be the square of _sector_axis_count based on its name.

Tell us which solutions you've explored, the solution you would pick, and why you think it would be the best for everyone.

It may be appropriate to rename the variable _total_sector_count to _sector_size_squared with an adjusted comment for what it represents. This comment "Total number of sectors to generate around the player" appears to be wholly independent of the variable's value at this time.

I have probably over-explained myself, but I hope this finds you well :)

I'm submitting a...

• Bug report.
• Feature request.

Bug report

There is no such class and file

All four demos, stored in directories numbered from 1 to 4, use the scenes and the ProceduralWorld.gd file you can find in the Shared directory.
The ProceduralWorld class is a virtual base class that all world generators extend. It defines a _generate_sector() function that we use to generate areas of the world around the player.

https://github.com/GDQuest/godot-procedural-generation/blob/master/godot/SpaceInfiniteGeneration/README.md#how-it-works

There's some bugs when runing this on godot 4.3. For example, randomwalker can't be run.

I'm submitting a...

• [X ] Bug report.
• Feature request.

Bug report

What is the current behavior?

from the docs at: https://github.com/GDQuest/godot-procedural-generation#how-to-use

How to use
Clone the repository. Each demo is in a separate directory.

Cloning works, opening project file works.

There are 5 demos (one with 3 sub-demos, aka 'cellular automota' or CA for abbrev).

Of the 5 demos:

• 3 of 5 have both main scene and code (CA, ModularWeapons and SpaceInfinite)
• 2 of 5 have only assets but no code nor scene file (WorldMap and RandomWalker), and thus can't be run at all
• of the 3/5 demos with scene and code (or 6/8 if you count 3 sub-demos inside CA) only 1 scene does anything like what the docs say they should (CA.dungeongenerator, the other two CA modules show a UI control but don't respond to pressing it).
• The other non-CA modules display an asset on screne, but have no controls and don't appear to do anything.

What is the expected behavior?

For a demo project, would generally expect to be able to download and run it to see behavior described in docs.

Tell us the steps to reproduce the bug, and if possible share a minimal demo of the problem.

1. clone the project as described on project README file (and repeated above in this issue)
2. open project file in godot
3. locate the folder for demo you wish to run (eg Modular Weapons)
4. locate scene file 'tscn' in this folder, right click this file and choose 'set to main scene'
5. start demo clicking godot's 'play' button
6. expect: see behavior described in docs instead: we see static assets that don't respond (w/exception of CA.Dungeons, which works as described)

Feature request

n/a

Other

Other information

• tested using godot-3.3.3.stable.mono.official [b973f997f]

I'm submitting a...

• Bug report.
• Feature request.

@NathanLovato This post is in response to the certain silly and worthless guys at GDquest, and some of its slave worthless members (including razvan)
Shame on them, cheap slaves. Shame on them cheap loser slaves for promoting dumpsters in socities called "universities" [dumpsterversities]. Shame on razvan for boasting about his stupidity. How extremely dumb and childish you are for promoting those ultra racist clowns. GDquest and godot and open-source have no potential and are a complete failure. Death to "univeristies". Death to every low life lower clown who uses those stupid and childish and pathetic "prefixes" when mentioning first name. Death to open source. Death to GDQuest. Death to godot. Hope them clown devs have a tragic life and painful death.

And another thing.... Stop making lies about real Engineering. Engineering has nothing to do with sitting behind a keyboard and writing code or games. Engineering is a real subject. Engineering means designing and building real mechanical systems, like vehicular engines and turbojets. Sound and software devs are the biggest liars. Game/software devs have absolutely nothing to do with engineering, they are just being stupid wannabe liars. They will never be engineers, not even close. In fact, they don't even know what it takes to be an engineer. None of you are engineers, and you'll never even be close. So stop being disrespectful to real engineers (mechanical engineering is real engineering, and nothing else)
Mechanical Engineering is the ONLY ENGINEERING. Period.