Old man complains about progress

Hard to believe I’m sounding like such an old person about such a small engine, but…
Who is out here asking for all of these UI changes in GD 4.7/4.8?
Am I the only one who thinks some of these are a backwards step?

Esp Add ability to drag-toggle visibility in scene tree editor by mihe · Pull Request #118634 · godotengine/godot · GitHub (drag visibility)
and the constant toolbar changes (Embed the game view in the main editor window as the default by YeldhamDev · Pull Request #120736 · godotengine/godot · GitHub and Clean and simplify `Game Embed` toolbar by jaydensipe · Pull Request #118664 · godotengine/godot · GitHub)

Not sure where they’re heading with this - but changing the UI every freaking version is terrible for muscle memory, obsoletes tutorials and documentation quickly, and unless there’s some huge groundswell of demand, makes no sense.

I’m working on 4.7 currently, and I already had to waste time looking for stuff that was obvious and accessible in 4.6. It’d be nice if they stopped moving really core stuff around.

9 Likes

It did irritate me that they move the Clear Output button image in the editor in 4.7.

The stupid embedded game window thing is useless and always has been. The fact that they keep moving the disable on start button is frustrating. The fact that it defaults to on and I can’t turn it off in new projects is annoying. But it’s only a few seconds of annoyance, so I’ve never done anything about it.

So I don’t care about the second two things on the list, and clicking and dragging visibility doesn’t bother me either.

8 Likes

The part that really sort of gets my goat is that we’re still not getting easy options to auto compress pck files (which should have been built into 4.x), you still have to compile your own binary for basic pck security, and the mac export is still a mess.

You know, stuff that matters when actually shipping games instead of just screwing around with tutorials.

2 Likes

i talk from experience, so it might not work for everyone, but if you don’t like changes and don’t have to switch to newer version, stay on godot’s version you develop on normally

i’d say changing from 4.6 to 4.7 might be good for some niche case scenarios, but other than that before 5.0 it’s not worth to change version (as i’ve said earlier in MOST CASES, because you might need some new feature)

to sum it up - unless there’s big update or you need feature, don’t change engine’s version, you don’t have to

4 Likes

There is no roadmap for 5.0. It’s at least a few years out.

In my 30 years of professional experience, I have found the opposite to be true. Keeping up to date with new versions means when you do need something, you don’t have a huge update to do. Also, if something does go wrong, it is much easier to solve it in the moment, and if there is a related bug, the Godot team is focused on fixing newly found bugs ASAP. Which means the pain of dealing with it sooner is less than dealing with it later.

If you do run into a showstopper after updating that you can’t resolve, you just log a bug, and go back to your previous version and keep working.

Otherwise, you end up locked in a cycle of fear where every new version’s cool new things “just aren’t worth the risk”. You also are not longer getting performance improvements - which come fast and furious with the Godot engine.

IMO, the small amount of work needed for upgrading is worth the pain. Because there are a lot of benefits in a project this active.

11 Likes

Obviously, both are indeed solid points - there’s a lot to be said about doing a version freeze for every large project.
However, you not only miss out valid improvements, you also miss out on security fixes and end up with a much larger job at the moment when you do upgrade. This makes small updates naturally important.

IMO, the larger problem (and the reason I’m complaining) is that changing a UI regularly causes a ripple effect that increases the friction for devs and should be saved for larger upgrades (like 5.0) so that documentation and training has time to catch up.

2 Likes

embedded game window thing is useless

I am with you on that. First thing that has to get shut off in a new project is the embedded window.

The embedded game window was a popular feature request although I can’t find it right now.
iirc this was brought about during the influx of Unity refugees and I believe that is touched on in the following issue discussion.

I did find the switch to it being default and it is also popular.

@longplay_games You may already know this but the better place for input in this regard is github proposals
Theoretically the highest rated proposals are prioritized.
Follow the issues/discussions there and you are directly influencing Godot direction (theoretically).

There is also the possibility that the Godot Discord has a bigger influence than even the proposals list but I can’t say for sure since I don’t Discord.

This does not mean you can’t discuss it here also (obviously).

PS: You also have to have a little faith in the team; they seem to be keeping Godot progressing.

3 Likes

i haven’t knew there’s no plans for godot 5.0 currently, but still my point is that changing engine version as soon as they annouce small changes isn’t worth it, if you work on your project, maybe consider pros and cons and if you really need that additional performance or that new feature cuz the less frequent you update engine, the less problems you’ll have with unwanted changes and adaptation

2 Likes

Again, that’s a fear-based approach to upgrading. I’ve seen it many times. Inevitably one of two things is more likely to happen:

  1. You suddenly need something and a large jump in versions causes problems that would not have appeared if you’d made incremental changes because you’d be up on the changes as they come.
  2. You miss a security update and your game needs an immediate patch - which requires a lot of work. It also has the potential of causing problems with the community and losing trust. Once someone says your game isn’t safe, it’s all over.

Also, there are literally hundreds of updates every version. And usually there are a few dozen that are not little. Yes, you should evaluate. But you should also be using version control. Evaluating a new version is a 5 minute process and then running your game to test it. It’s not that time-consuming unless you’re doing things that actively prevent it from being an easy upgrade.

4 Likes

Wow! First I’ve heard that the embedded game window useless.
I personally really love it because of its convenience, and it will piss me off if its removed.

I guess it different strokes for different folks.

4 Likes

One monitor makes complete sense to me use embedded game window, every time turn off option for floating window was a bit like I forgot, untick a start again.
Not big deal but it’s nice feature to have, but biggest so far was vertex snapping which makes complete sense for prototyping and making exact positioning :ok_hand::trophy:

1 Like

I don’t want it removed. I just want it off by default. It prevents the game from manipulating window size, fullscreen, etc. And I have four monitors. I do not need it embedded to use it. Which, I have occasionally done.

3 Likes

I’m not sure which way I’d prefer it, but I think the “embed the game view in the main window as the default” is a backward step, as if I recall correctly it was the only option up until about 4.3?

It was not, there was no game embedding at all in early versions (i.e. 4.3 and earlier, game embedding was introduced in 4.4)

2 Likes

I wouldnt use that feature because there are times when the game has a bug or flaw that freezes everything, I simply use CTRL+ALT+DEL and close the game window, or switch focus to the debugger - and sometimes the solution is trivial.

2 Likes

*And here i am still using Godot 4.5.1

2 Likes

One of my large projects is halted at 4.5.2 because of breaking changes in 4.6, so I feel that.