Zi

I agree with that.

Yeah I don't think it's not reasonable. It's just annoying if you literally never want it.

Everything about a scene's editing-related state (environment, grid, FOV, etc) isn't saved unless I save the scene. That's always been the case for me. Do you observe differently?

They come back if you don't save the scene after viewing it. They come back if you clear your project cache.
It's not a bug - it's just incredibly annoying if you never want it, but it's there by default as a constant chore. It feels like every time I open a scene, I'm hiding its origin.

1) Most scenes with a meaningful origin already have something at the origin.
2) There's already a grid with thicker lines at the origin.
3) You can already press O to focus the origin.
4) I hate things returning after I disable them and I'm petty.

A side-by-side screenshot showing a 3D scene with a lawn chair. The left side shows it with the scene origin visible, the right side shows it removed.

If you're like me and you can't stand the huge origin lines in Godot that always shout for attention and return after being disabled, I made an addon that obliterates them. 💥🤷 Grab it here under "Never Show Origin": codeberg.org/MajorMcDoom/...
#GodotEngine #gamedev #indiedev

I don't know how Kotlin specifically works, but in many languages the concept of an "enumerable" or "iterator" doesn't necessarily mean allocating it. The elements can be fetched as-needed, on step.

I eventually saw traditional for loops as filling out a "Build-a-Loop" form.
1. What do you what to do at the beginning?
2. When do you want to stop?
3. What do you want to do every iteration?

Once I saw it in that light, I couldn't unsee the redundancy. It's arguably more convenient syntax? 🤷

Oh yeah totally agree. Whenever I have an index like that, I find that for loops are sufficient. I use while loops when there is some less-regular logic of how things might count down.

Took me getting used to at first, coming from C++/Java/C#, but nowadays I actually see "traditional" for loops as being very clunky, and as essentially while loops with body code smooshed into the first line.

In contrast, the more "modern" for loops now feel more clean and usable. :)

This is how many languages are, like Python, or GDScript. The Kotlin documentation makes it sound scarier than it is. They should just immediately tell you that you can do:
for (i in 1 .. n) { }
Or you can do:
repeat(n) { }

Hey! I think using code completion allows you to see the color by looking up the name already. The use case I imagine for the cheatsheet is the other way around - looking up the name based on desired color. So I think grouping roughly by hue would be ideal!

I used an annoying but not QUITE as annoying sound effect. 😅

This was an important inspiration.

YURI

I made scooch tech. 🐧🪑➡️
#GodotEngine #gamedev #indiedev

VR Forever | 2026 Submission Form // Hosted by Creature + Future Friends // Contrary to what you heard, VR is actually NOT dead. VR Forever is coming back after a successful first edition last year and this time we are open for submi...

Contrary to what you heard, VR is actually NOT dead. VR Forever is coming back after a successful first edition and submissions are open now:

forms.gle/fvU8BhqVPYfo...

Submission Deadline: March 31st

#VRForever is hosted by @creaturedotpage.bsky.social and @futurefriendsgames.com #VR #gamdev

Make orthogonal viewport camera not neutralize its viewing distance · Issue #12388 · godotengine/godot-proposals Describe the project you are working on Any 3D game Describe the problem or limitation you are having in your project Orthogonal 3D viewport cameras are locked to being hundreds of units away from ...

I have a proposal open here: github.com/godotengine/...

This one has been driving me crazy for years. github.com/godotengine/...

That's the top top top issue for me.

Found the problem. The chair responds to *locomotion*, and applies a full constraint. But, turning code executes right after that. So it does exactly ONE FRAME of turn (exactly 9 degrees) before the chair does another full constraint next frame. The result is a 18 degree shimmy.

I keep forgetting I implemented facial expression tech. 😏

Had to do it. 🐧🫨

This was my first thought. 🤣

I have no problem including it, but still gotta look into it in case it's symptomatic of a deeper issue. 😅

Every once in a while my game does a thing that I have no idea how it's doing. Seated characters are supposed to be locked in place with no locomotion implemented. Yet somehow the seated player is... doing a shimmy??? Gonna look into it, but it's pretty funny.
#GodotEngine #gamedev #indiedev

Codeberg is currently down, but when it comes back up, you can pull the updates here:
codeberg.org/MajorMcDoom/...

Fixed TWO long-standing bugs in my Lines & Trails 3D addon!Trails sometimes made weird jaggies, and also used to linger around waaaaay past their time limit. All fixed now. Thanks @qbieshay.bsky.social for pointing me in the right direction. 🙏
#GodotEngine #gamedev #indiedev

One for tween, one for the ease() function, and one for color constants, please. :) Thank you! 🙏

Also even though Blender has vertex snapping, it doesn't combine instant vertex creation, vertex snapping, and convex hulling all in one action. So this addon is still way more streamlined for my needs. Overall way faster for iterating.

The asset import workflow doesn't work for me, personally. I try to avoid using it if I can. Material/mesh references break often on import, meshes always need specific import properties to be set, and also the whole "automatically put physics under visuals" is completely backwards for my needs.

Stoooooop!