Protection against accidental, script-triggered node deletion in tool mode (loss of work danger!)

[davthedev]

Describe the project you are working on:
A 3D rail shooter game (think like Sega's House of the Dead)

Describe the problem or limitation you are having in your project:
One of my nodes in the tree was suddenly disappearing from the editor when I opened the project. Like it remained for 2 seconds then vanished.

The node had an AnimationPlayer child in which I spent a whole afternoon editing animations. There was no problem getting the work saved. It is only when reopening the scene that the node disappeared. Then I hit Ctrl-S by reflex and all my work in the child nodes went missing, forever.

After investigation, I found the culprit was some initialization code that reparents the said node in GDScript which is intended to execute at run-time only. A simple remove_child() call on the parent.

But the scene has tool mode enabled and I found later that I forgot to put a is_editor_hint() check before executing the reparenting code.
At the moment, it was too late. My work was lost and I had to recreate all the animations.

Describe how this feature / enhancement will help you overcome this problem or limitation:

The feature would be some kind of warning or optional disabling of "dangerous" methods by default in tool mode. Or a possible failsafe scene open option that disables the tool script _ready() call, letting an opportunity to fix the bug. There are multiple ways to implement such a protection.

This would prevent such loss of work.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

The idea is actually open to discussion as there are multiple solutions to make it. Here are these:

Idea 1, Fail-safe loading option:

• User right clicks on tscn file. In the popup menu, there is a "Open scene in fail-safe mode" entry.
• User clicks on the entry.
• The scene loads, but tool script is inhibited. A warning on the editor shows "Scene is open in fail-safe mode, tool scripts may not run now". It resembles a colored bar on the top side, a bit like the popup blocker notifications in web browsers.
• Now, the user has its unaltered tree available and can fix & save its changes in the GDScript file.

Idea 2, Destructive call blocking by default:

It can be suitable as I don't know many desired uses of deleting a node from script at edit-time. An option must still be available to take the protection off for advanced users.

• In tool mode, all calls to remove_child() are no-ops.

Ideas for the expert disable option:

• Extra keyword in the GDScript file
• Project settings
• Different API methods for deleting a node at edit-time and run-time

Idea 3, Warning when node is going to be removed by script:

• User opens the scene file.
• Godot starts loading the scene in the editor
• The script has tool mode enabled, so it runs and reaches the _ready() method
• Somewhere in the script, a call to remove_child() is encountered
• Script execution pauses at that point. A warning popup is shown to the user with a message: "The tool mode script is attempting to remove the following node from the scene tree. This can cause a loss of your work. Are you sure you wish to execute this operation?"

In the dialog box, the affected node is highlighted. An excerpt of the GDScript code in context with line number where the call happens is also shown.

Describe implementation detail for your proposal (in code), if possible:

If this enhancement will not be used often, can it be worked around with a few lines of script?:

Once one realizes that the blunder happens, it is often too late. Best solution would be NOT to save the scene (it is so easy to hit Ctrl-S and not obvious to perceive the live change), close Godot and edit the .gd file using an external editor. This requires awareness of the destructive calls happening beforehand.

Is there a reason why this should be core and not an add-on in the asset library?:

It is a safeguard against loss of work. Which is priceless IMHO.

[girng]

Back in 2015 or so, I actually remember this happening once. Could never reproduce it to report it as a bug though. Has never happened since.

The node had an AnimationPlayer child in which I spent a whole afternoon editing animations. There was no problem getting the work saved. It is only when reopening the scene that the node disappeared. Then I hit Ctrl-S by reflex and all my work in the child nodes went missing, forever.

After investigation, I found the culprit was some initialization code that reparents the said node in GDScript which is intended to execute at run-time only. A simple remove_child() call on the parent.

Is there an issue about this? It sounds like it should be reported ASAP

• User right clicks on tscn file. In the popup menu, there is a "Open scene in fail-safe mode" entry.
• User clicks on the entry.

This will cause mass confusion to new users I think. I also don't want the UX to be impeded on by rare anomalies that are not widely reported.

[davthedev]

This will cause mass confusion to new users I think. I also don't want the UX to be impeded on by rare anomalies that are not widely reported.

This is a trend of nowadays, I would say "unfortunately". We see more and more power-user features being stripped from software in the sake of better UX & less clutter on screen. This is in comparison from software done 20 years ago that had options everywhere in menus & dialog boxes. Especially visible in mobile apps. Good for software aimed at casual users.

IMHO, Godot is a game authoring tool that professionals use. There should be no problem about putting as many settings as necessary, like in all professional-grade software. The extreme example is Blender. Sure, this is not a good reference for ease of use by newcomers, but it has many features that the industry needs. It is possible to hit a good balance between UX and availability of power-user features.
And a safeguard against loss of work is worth it. Sure, one does not encounter the described situation often, but when this happens, it is difficult to get out of the ditch as of today.

[kubecz3k]

I think one of the best ways to deal with this issue would be to separate the tool logic from the runtime logic. There was discussion about that in godotengine/godot#8735 (comment) and the concussions were that scenes should have a separate tool scripts which would work only in editor, and 'normal' scripts which would be loaded in runtime.