Feature request: Scene patching

[20kdc]

Hello! Sorry if this is a bother, I don't... generally do feature requests, but as you'll see my attempt to make something PRable is a bit lacking. (I did try, though.)

Adding new content or changing existing content in the world in Cassette Beasts is extremely awkward presently.

The 'mod concept' that caused this request involved nudging an existing NPC out of the way of a door and installing a new entrance. While I know how to do this, it was on behalf of someone very new to Godot, and jumping into GDScript for relatively simple changes added a lot of complexity.

With this in mind, I'm suggesting a scene patching system based on chaining inherited scenes.
I have a prototype of what I'm thinking of at https://github.com/20kdc/CassetteBeasts-modutils/tree/scene-patching-test .

However, there are a few practical issues that make it hard to PR:

• Keeping all scenes that need modifying loaded at all times is probably not a good idea.
• My current API isn't really fleshed out.
• The patch order resolution hasn't been properly tested. It's been tested enough to confirm that the idea of "rebasing" a patch onto another patch works, but I'm not sure if there are any big scary things to worry about.
• Sometimes Godot will attempt to include nodes that shouldn't really be being changed.

It might be an idea to instead go with a workflow where a scene patch has a root of a custom node type, which manipulates the scene after construction (so it can use the existing hooks). (The issues with using class_name only matter for references from GDScript. Resources always use the file paths.)

This custom node type could use a tool script to spawn the original scene as a positioning aid, along with using, a 'virtual node tree' to hold new content and to accept trivial repositions (if the virtual node and target are, say, Spatial)

The problem with this is that unlike the inherited scene approach, it's the sort of thing where I'd really want confirmation from upstream as to how exactly to go about the fine details before something happens that can't be undone without breaking API compatibility down the road.

[Yukitty]

Ah. Hm. For efficient scene patching that uses GDScript to manipulate objects inherited from the vanilla scene, eg. moving NPCs around, I would use ModUtils' connect_chunk_setup callback to run a script that makes changes directly or loads and inserts additional nodes as needed (eg. to change script events by loading an entirely separate scene containing only the nodes to be added)-- In other words, no reason to inherit from the original scene, or make a custom scene root to hold the original scene with a different scripted structure, etc.

Using Editor scripts to build an easy WYSIWYG interface to visually represent the changes you want to make and then saving the details of "what was changed and how" as a Resource that the runtime script can look through to replicate those changes every time the scene loads seems like the best way to go.

[20kdc]

Given the complexity, amount of properties that can be changed, and the problems with rewriting the Godot editor inspector, I was considering scene inheritance as the WYSIWYG interface. I suppose it's a possibility to derive some kind of 'working form' from the PackedScene dictionary for application at runtime, though.