gdnative VS Godot

> Same for Godot.

While likely true that it's "Unlikely to ever be as supported" as the 4 officially supported languages[0] ("GDScript, C#, and, via its GDExtension technology, C and C++."), Godot's GDExtension technology is specifically intended for use in adding support for other languages.

The most relevant tracking issue for Rust is presumably:

* <https://github.com/godot-rust/gdnative/issues/824>

Which links to:

* <https://github.com/godot-rust/gdextension>

[0] https://docs.godotengine.org/en/4.0/getting_started/step_by_...

...Godot v3.x has Rust support via godot-rust and Godot v4.0 is released as of this month?

I was curious, and looked it up. Nothing built in, but there's an interesting project that works with godot: https://godot-rust.github.io/

Curious why you think Rust would not work with a node-system like in Godot since there are already Rust-bindings for Godot. And while I can think of several reasons for not using Rust (I don't use it myself) I never thought the lack of inheritance would be an issue at all.

Also if you want to use this as an opportunity to learn Rust, take a look at godot-rust.

GDExtension is a platform, much like GDNative. It provides tools, but additional language bindings will still come from the community. For Godot Rust you can track the progress here: https://github.com/godot-rust/godot-rust/issues/824

For what its worth, you can write your scripting for godot in Rust with godot-rust. It's not perfect cause its fitting Rust into the Godot model, but it'll also give you a "best of both worlds" type of situation if you want to get up and running quick but also do the game logic in Rust.

There's godot-rust for writing Rust components for the Godot engine.

If you desire to use Godot, as having the editor and support, while wanting to use Rust for the logic, might wanna look into Godot Rust.

Current version of godot-rust uses type-state to declare Ref references "safe to use" once the user has asserted their safety, and to switch between shared/unique/thread-local ownership.

The other primary tool to think about today is Godot (https://godotengine.org/). I feel like Godot is to the main game engines (Unreal and Unity) very similar to Blender's relationship to the major 3D modeling tools (Maya, Max, etc.) Godot is improving at a dramatic rate, and it's a wonderful tool for creating 3D games from assets you create in Blender. It's lightweight but incredibly powerful, is reasonably easy to learn, and exports to a lot of great formats including web.

If you feel there is something missing in the documentation, you can open an issue on the docs repo, or if it's about the class reference, the main repo. Even if your issue doesn't match the template exactly, it's ok as long as it describes the problem properly.

I recommend a hierarchy of terrains and avoid "dirt-on-grass"/"grass-on-dirt" scenarios to prevent the algorithm from choosing a transition tile from the wrong tile set. The issue is better described here: https://github.com/godotengine/godot/issues/70218

It's only a matter of time before we can find this on SideQuest -- Bastiaan's work on a VR editor

Clone Godot repository then switch to your current using version if needed.

No, not yet. A solution has been proposed in https://github.com/godotengine/godot/issues/70691, but it has yet to be tested and implemented.

See also this PR https://github.com/godotengine/godot/pull/56420

Here'sHere's the commit for adding it to GD4 - more pics, but do I know how to use this? Not so well. Will commence digging in. (Funny comment here: "FastNoise exposes a ton of detailed handles which makes it very complex and daunting for end-users")