Retain exported variable values when extending the script on an existing node

[lmerriam]

Describe the project you are working on: 2D Twin Stick ARPG

Describe the problem or limitation you are having in your project: I use exported variables in the IDE extensively to make blueprint scenes that can be extended to create new content easily. For example, I have a base weapon scene which I can inherit and change a host of variables like attack_speed, damage, and knockback on to create new weapons easily without any code. This feature is a key selling point of the Godot IDE.

However, if at some point down the line I want to extend the script of a weapon with new logic (using the "extend script" option in the right click menu), it wipes all the values I've set for exported variables, and then I must manually re-enter them without any mistakes to preserve the settings I may have spent hours perfecting.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: When using the "extend script" option on a node that already exists, preserve the exported variable values that are set in the IDE and reapply them to the node after the script changes. This will make extending node logic trivial at any point and eliminate human error from the process of preserving properties that have already been set.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: I believe preserving variables when extending a script is the base use case and should be the standard function of the "extend script" action, but it could be a secondary option in the menu like "extend with properties" or similar.

If this enhancement will not be used often, can it be worked around with a few lines of script?: It can easily be worked around if the developer knows upfront that they will need to extend the scene with new logic, but often that requirement reveals itself later after many script variables have already been tweaked and perfected, at which point it is painful to change.

Is there a reason why this should be core and not an add-on in the asset library?: It's a universal QoL improvement to one of the core features of the Godot engine and IDE.

[Reneator]

Agreed!

I have the same problem, and i can regain the values by reverting certain lines via vcs. Here the question would be if maybe it would make sense to keep the values, trying to fit them to the "new" variables, and then if they dont fit, delete them.

Or maybe retain them forever, until the user clicks a button like "cleanup project" which would removed unused Assets/Resources and unconnected variable-values from scenes.

[jack-cooper]

Disclaimer that I'm primarily a front-end web dev who only just recently started dabbling in Godot for fun and I'm likely viewing things very much through the lens of what I'm familiar with, i.e. Vue and React, but:

Would it not make more sense for the instanced scene inside the parent to be the source of truth for providing its own key/value pairs for the export vars, and then these would simply be mapped onto the node's export vars by name? When I instance a scene as a child of my current scene that I'm working on, the context feels to me as though I'm working in the parent providing the data I want the child to have. The fact that edits I can make in that child, even those as seemingly inconsequential as a variable rename or an empty script extension, can delete data I've defined in the parent is a reversal of the flow I would perhaps expect.

In the given case of simply extending a script this would remove the issue entirely, as the names would of course still line up.

In the case of the issue mentioned above regarding export var renames, we can imagine a scenario in which I rename an export var from old_name to new_name. If the parent were the only place responsible for declaring the export var's values I'd now still have an old_name key with my previously set value inside. My game may (and should) now immediately error telling me Invalid set index 'old_name' on base: .. when I run it but in my eyes this is vastly preferable to simply discarding the provided data entirely, short of version control reversion or immediate manual recovery work inside .tscn files.