Migrate to Godot 4 with v1.0

[TheDuckCow]

Edit: updated Jan 27, 2024

Check out the godot4 branch for experimental support. See latest comments below for more details/status.

---

The initial alpha launch of this addon is targeting Godot 3.5 support. Most of the early development was before Godot 4 was stable enough, so it was the right decision at the time. The reality at this stage is that we will want to move to godot 4 for anyone to seriously consider adoption of this plugin.

Unfortunately, godot 4's syntax is very much so not backwards compatible. There's a lot of good things that come with it, and they are all worth it, but it means that there's too much overhead in supporting a 3.5x and 4.0x version of this addon.

Therefore the strategy is to launch v1.0 with Godot 4 only. Anyone who wants to use this repository for 3.5x will have to use one of the pre 1.0 releases. We do not expect to make additional patches to any 3.5x builds once we've moved on to godot 4, so please bear that in mind.

[bdog2112]

Based on preliminary testing (and Juan Linietsky's own admission that the current release is not feature complete), I don't think Godot 4 is quite ready for production use on the Road Generator. That could change at any time. But, currently, the showstopper is lack of full support for gizmo plugins.

Handles are a key feature of gizmo plugins and Godot 4.0.2 doesn't currently seem to display them. This was determined by using a simple test project from v3.5.2.

Inside the project, there is a scene that contains a root node and two custom "MySpatial" objects. When a MySpatial is selected, three gizmo handles are displayed as shown in the screenshot, below.

Converting the project to Godot 4.0.2 started out fairly straight-forward. When opened, there was a prompt to run the conversion process.

Upon completion, it only showed a blank black screen on my computer, which is what all Godot 4 conversions did unless they were switched to "compatibility mode". However, that had to be done manually by editing the project.godot file after conversion was complete. (Proper syntax was determined by creating a blank new project and comparing project.godot files.)

Once compatibility mode was properly delineated in the project file, it opened just fine. Then, it was necessary to resolve issues stemming from Godot's latest revisions to built-in functions. That was straight forward and easy enough.

At that point, the project should have displayed gizmo handles when a custom Spatial was selected. But, it didn't.

Although, not represented, here, I did various additional tests by overriding the current equivalent of "EditorSpatialGizmo" (not to be confused with "EditorSpatialGizmoPlugin") and that didn't work, either. This left the impression that gizmo handles don't currently work.

Maybe there was a workaround. But, I'd already invested too much effort into something that should've worked right off the bat and my gut said that the prospects weren't good, right now.

Here are copies of the Godot v3.5.2 and v4.0.2 projects in case anyone wants to try their own conversion and/or look for a fix/workaround in the v4.0.2 project.
Gizmo Test 06 - Godot.zip

It would be interesting to hear if gizmo handles are displayed when the v4.0.2 project is not running in compatibility mode.

[TheDuckCow]

Thanks for putting together the sample project. Couple notes on your test project for godot 4:

• I will at least agree that the tutorial here continues to not be a great reference point; the as is provide example does not yield anything that draws in godot 4 for sure.
• To match the gd4 docs and tutorial, you need to rename draw to _draw, and set_handle to _set_handle.
• In addition to that, _set_handle then complains that the signatures don't match the parent class. We evidently need to add the secondary but can set it to false (it's a control to allow for multiple overlapping handles while setting click priority)
• Bigger takewaway: Try out the test project here - I did not look closer, but I do get the handle to at least draw in that case (although the bug they mention appears to remain relevant). Might be interesting to see what is set up differently about these two projects, and why they are able to get the actual handle to draw.
  • That being said, the actual bug that linked issue references is still true: I get stutter, which would make the handles not very usable

In the end, I tend to agree that if handles aren't working, we're not in a position to migrate right now. But we should see about pushing for this, and if there's any other issues beyond the one referenced in the linked bug, then we should submit a new bug.

[bdog2112]

I took a brief return look at this. It was interesting that "redraw" and "set_handle" didn't trigger any errors. At any rate, it was trivial to add the underscore, which did cause an initial error. But, in a different conversion effort, I found it was best to simply go into Godot's help and copy the subroutine signatures verbatim. So, I copy/pasted them and that fixed the errors right up.

Unfortunately, the handles still didn't show in my test project. But, I tested the "bug report" project and it did display a handle. So, at least on some level, handles DO work.

It's still early days for Godot 4.0 and I'm sure things will get better. There's already a release candidate for 4.0.3 and 4.1 is in alpha.

[TheDuckCow]

With the launch of godot 4.2, we had our first external contributor (thanks @nonunknown777!) help us get a little closer. I'll be doing some additional work to get it to an at least passably useable state, even if not all features like gizmos are working, since we had trouble with that in the past.

[nonunknown777]

keep in mind, that is totally possible to create your own gizmo system, and I think its even better because then it will be version agnostic!

[TheDuckCow]

Though it's taken some time, I am excited to share we have some initial experimental support for Godot 4.

https://github.com/TheDuckCow/godot-road-generator/tree/godot4 (EXPERIMENTAL)

The current godot4 branch has essentially all the working functionality of the current godot 3.5 branch, with some behavioral caveats:

• Enum name dropdowns aren't user friendly names (easy enough to fix, just need to get back to this)
• Fix rotation on RoadLanes (believed to be a 3.5x problem in some scenarios too)
• Make selection via left click in 3D view work even if an existing node is not selected (currently, can only select if another node is already selected, regardless of being a plugin node. Rather odd)
• There are a number of error printouts due to some rogue get_node on an empty path. With godot would give us culprit line numbers :/
• Minor but weird: Pressing f doesn't work when you use the select next/prior road point, as though there's a new concept for 'active' selection.
• Connections between two containers (as opposed to between two RoadPoints) doesn't always work reliably, and undo works especially bad here.
• No migration of unit tests yet. We won't do that until we have shut the doors on the 3x branch.

Otherwise, everything listed should be working. Again, this is experimental and thanks may change which could break projects that start to use this. Ye be been wanred.

[TheDuckCow]

Also worth mentioned that a manual version of git patching is effectively what this branch implements:
#143

I was making changes in parallel to both branches as I resolved all functionality, so we can continue making the necessary dev updates in 3.5 world and then relatively quickly get back to a functional 4x build from the latest version the next time we do this (hopefully the last!)

[TheDuckCow]

It's worth updating that the current state of the godot4 branch is in pretty good shape, albeit not perfect still. It was used to create this gamejam entry. Will see about marking this as a pre-release, but since we haven't fully migrated unit tests, cannot recommend it for production usage at this stage.

Some known oddities:

• Sometimes lane arrays get linked together between road points
• Must have a node selected before you are able to utilize click to select a roadpoint
• Sometimes need to manually refresh to draw roads in the editor when switching scenes (I have not seen this to be a problem on game export).

It is nice to know it appears to work nicely even in web exports, even without any of the optimization of pre-exporting mesh resources!

[TheDuckCow]

Hey all I just wanted to chime in with some news updates: We had to get through an important playtest milestone with the Wheel Steal project, with that out of the way now, we're full steam ahead to wrap up (basic!) intersection support in v0.5.0 and then move on to formally release the plugin for 1.0 with godot 4. The godot4 branch continues to be available in the meantime!

Updated planned dates available in the milestones view: https://github.com/TheDuckCow/godot-road-generator/milestones

[TheDuckCow]

v0.5.0 of the plugin just released for godot 3.5, I will now start the process of replicating the changes forward into Godot 4.x

[TheDuckCow]

That process has already made great progress - while the PR branch over here is arguably already useable, I do have some additional improvements I'd like to make before merging in.