Complete Godot 3D: Code Your Own 3D Games In Godot 4!
Godot Version
v4.6.2.stable.official [71f334935]
Question
For context: Only been using Godot a couple days, following gamedev.tv lesson (instructor using v4.1.1)
Also, I’m only using the UI (no code) for creating/instantiating, etc.
I’ve created a simple scene with multiple mesh blocks. There is one ‘main’ block called ‘floor’ and the rest are children. The ‘floor’ block is transformed by -4y with other children all around.
I selected the ‘floor’ group and saved ‘branch as scene’.
I immediately noticed that the ‘floor’ group with children became only the ‘floor’ - all children nodes folded up into the ‘floor’ parent. I can no longer access/edit the children. I assume this is because the system now considers my parent/children an instance of the ‘branch’ I just saved.
Most importantly, when I used ‘instantiate child scene’ in a different scene, and loaded the ‘floor’, it imported in the original location instead of the transformed (-4y) location that the branch was saved.
However, in the tutorial, the instance imported in the transformed position (which is what I wanted).
So I have several questions:
Why is the saved instance imported at the origin, instead of the transformed position (like in the tutorial) ? Perhaps it’s more accurate to say that it was saved at the origin and not the transformed location?
Why did this happen differently in the tutorial (Godot v4.1.1) ?
Yup, this certainly works, although I don’t actually recommend using Save Branch As Scene if you can avoid it. Usually it’s fine, but I’ve noticed that on rare occasions, it might cause a desync between the new scene and the instance you saved it from (therefore I personally don’t do it this way anymore). Not a big deal, as the solution is simply to delete the old instance and replace it, but it’s a bit of an annoyance to do that.
Yes, exactly. Save Branch As Scene does exactly that, and then converts the branch of loose nodes into an instance of the scene it just created. An instantiated scene (an instance) displays only its root node by default. Since the children would have their default (or at least unedited) values, hiding the children reduces the depth of the SceneTree for a cleaner appearance. If you need to make per-instance edits of the children, you can right-click the instance and tick Editable Children. This will cause them to expand into the SceneTree, and their names will be in yellow to indicate that they are children in an instance.
Somewhere in the chain of Node3Ds and descendants (ie all the red nodes - everything that inherits from Node3D), there would be a Transform with Position values that don’t match up between the lecture and your project. An offset. Which node is that offset in? I tried this same instantiation just now and it worked as intended, so it’s most likely just that one of your Transforms doesn’t have the values you expect. These offsets can be deceptively tricky to find.
In either case, be careful about introducing such offsets into non-level scenes when you don’t mean to. It isn’t an error and it’s fine to do, but it will make the scene behave like it’s attached to an invisible selfie stick if this isn’t your intention (because the scene origin doesn’t match up with the visible Mesh or object). Barbarian Blaster raised a number of issues related to this. Just a heads-up really =)
Once we have the answer to the previous question, it’ll answer this one too, since my quick test didn’t reproduce the issue.
Regarding Save Branch As Scene - what would you use instead?
Also, regarding the normalized ‘floor’ - I went into the saved floor scene and saw that the transform was 0x 0y 0z, so I added a -4y transform and saved it.
I then checked each of the 4 ‘levels’ that instanced the floor scene.
My expectation is that each instance should now be lower in y by -4 (a total of -8)
In levels 1 and 3 the floor position is unchanged (top of the floor at 0y) with -4y transform, as though it did not update.
However, levels 2 and 4 show -8 transform, with the top of the floor at -4y: updated.
What I find most strange is that only 2 of the 4 levels changed when I updated the floor scene.
Ah, simply create a blank scene first, rather than starting your work directly in the level scene and saving the branch halfway through its development.
What you’re describing sounds like the instances in levels 1 and 3 may have the aforementioned problem. While you could manually adjust the Transforms of those instances, I would just delete these instances and instantiate them again to be certain. In this case, it won’t make a difference which action you choose to take because these are just static background objects, but if we were dealing with something more active and with customizable behaviour, like an Enemy or a moving obstacle, you’d want to make sure each instance is syncing properly with any changes made to the scene it’s instantiated from. Otherwise, you might be left with problems that don’t respond to your scene/code changes and you’ll be wondering why “the fix that should be working” isn’t, when it’s really just a desync problem. That’s how I stumbled upon this in the first place. May my headache make your life easier! =)
The other possibility is that these instances are affected by an offset from a parent’s Transform. That’s unlikely to be the problem, given how simple these levels are, but it’s worth confirming.
Regarding to collapsing of Branched Scenes and other issues:
I’m working on Barbarian Blaster: Introducing Timers and have found yet another UI change (there are A LOT between v4.1 and v4.6 - these tutorials need updating).
This one seems very helpful except now it is gone from v4.6x
In this particular chapter, projectiles are created in code, then removed using queue_free().
In the tutorial, we’re shown that we can see the code-instantiated objects appear in the Scene list (TurretManager node at 10:25 in the tutorial), then disappear when queue_free() is called. I see this as very helpful, but in v4.6 this is not possible. The instantiated Nodes (projectiles) are never shown in the Scene list when added and therefore never disappear when queue_free() is called because TurretManager cannot be expanded.
Am i doing something wrong, or is this useful capability gone?
Not to worry though, as it’s only a very small oversight. You’re working on 3.17 - Introducing Timers, and at 10:23, Bram specifies that he is looking at the Remote SceneTree, which is effectively a “live” view of the running game’s SceneTree (if you select a node, you can even see live properties in the Inspector. This is great when debugging things like missing spawns).
If you can’t expand the TurretManager after placing a Turret, you are definitely still looking at the Local SceneTree, which is the blueprint that the game started from (equivalent to what you see in the Editor when the game isn’t running).
The Remote tab is only visible when the game is running, but getting to it is as simple as clicking the Remote tab at any time after the game has started:
