Add a way to disable all plugins when opening a project (safe mode)

me2beats commented 3 years ago

Describe the project you are working on

plugins

Describe the problem or limitation you are having in your project

Then creating plugins sometimes I have a plugin that crashes the editor on startup, so I need to disable it, and the only way I can do this is to open the project.godot and manually remove plugin from there. This is not convinient.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It would be useful to be able to open a project in "safe mode" - with all plugins disabled. When I open it, I could find the problem, and then enable the plugin again.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

In Project Manager, we could have an option to open any project in "safe mode", when clicking on it the project opens with all plugins disabled.

Also --safe-mode command line argument could be useful.

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

If you have the problem above, you need to manually disable plugins in project.godot which is no so handy.

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

I don't think this can be solved properly using plugins because it's plugin related.

me2beats commented 1 year ago

All tool scripts should be disabled too. I've just opened Cyclops editor in godot 4.1 and I've got thousands of errors from _process(). They spammed so often that I had to kill godot editor.

dsnopek commented 1 year ago

Thanks, I think this is a great idea!

I've had similar issues when porting projects from Godot 3 to Godot 4 - after conversion, they'll sometimes be so broken in the editor, that the editor crashes or is unusable (requiring fixing up with external tools).

akien-mga commented 1 year ago

I think this is very needed indeed. It's not that uncommon to have complex projects crash on start due to an accumulation of errors which can be caused by plugins, extensions or tool scripts.

Following some discussion with maintainers I would suggest that safe mode disables:

Editor plugins
GDExtensions
Tool scripts
Scene restoring

I would also suggest considering the following to disable:

Resource preview generation (it's long been the cause of many crashes)
Multithreaded import (helps avoid race conditions, so we could force single threaded import)
Or disable import altogether possibly, if we provide a way to trigger it manually once the editor could be opened

Safe mode should be exposed as a command line option, and indeed adding it in the project manager as a mode to open projects would make sense.

For engine contributors, there could be a way to customize what the safe mode will actually disable, which could help tracking some issues that happen in normal mode and not in safe mode, so we can narrow down which component is problematic. But that shouldn't be a prerequisite for a first implementation.

Additionally, the editor could have a system to track if it last failed opening a project, and propose opening it in safe mode automatically. This could be done e.g. by saving some state to editor metadata in res://.godot/editor/. But a first implementation of safe mode doesn't necessarily need to include this, a way to trigger it manually would already be a great improvement, and let us test it to ensure it's actually useful and not triggering more issues due to the stuff that gets disabled.

An important aspect would be how to handle potential data corruption that could come from a too aggressive safe mode which disables things that are needed for a project to persist its state. E.g. for GDExtension we now have a system for placeholder nodes and resources which should help ensure that node/resource data isn't lost, but that would require more testing to make sure it's safe.

One possibility could be for the safe mode to make backups of each file it's modifying in the project, so that they can be restored if using safe mode someone led to loss of information.

QbieShay commented 1 year ago

Small nitpick: I think "safe mode" would be near-impossible for users to google successfully. --disable-plugins should be already self explanatory and easier to run a search on.

EDIT: follow up Akien's comment, we can have multiple flags instead perhaps? And sfae mode does --disable-plugin, --disable-import etc.

akien-mga commented 1 year ago

I don't understand the concern about search engines. If you google "godot safe mode" currently, it actually points you to this very proposal. It's a well established term in software, so if you're not able to open a project, it's more likely that you'll look for a safe mode than for a way to disable plugins - for the latter, you need to be experienced enough to know that plugins might be the problem. And as I listed above, there's a lot more things which can be the cause of issues opening a project, so a catch-all safe mode that disables anything non-critical and risky makes more sense IMO.

Finally, if it's exposed in the project manager, I don't think users would even need to google it at all? But if they do, they should land on our documentation page that describe what the safe mode does and how to use it.

QbieShay commented 1 year ago

Well the support people in discord would most likely first ask them to open Godot from terminal - then they'd see the issue comes from a plugin, so at that point I'd search "how to disable all plugins godot" and this doesn't include "safe mode" in any way. I have worked as a software engineer and wouldn't think of googling for safe mode :P

Zireael07 commented 1 year ago

"Safe mode" is a pretty universal term in game engines and creative software. Once people know safe mode exists in Godot too, they'll just google safe mode godot.

The only thing I'm on the fence about is this disabling tool scripts, this might be a good thing to leave to command-line indeed as many projects will be outright broken w/o tool scripts

YuriSizov commented 1 year ago

The only thing I'm on the fence about is this disabling tool scripts, this might be a good thing to leave to command-line indeed as many projects will be outright broken w/o tool scripts

We already disable plugins and don't restore scenes. So tool scripts wouldn't immediately be useful. This is a mode to try and recover a project that cannot be edited as is, and tool scripts can easily kill the editor for you (I've done this numerous times with infinite loops). You can then debug what is going on without worrying it will affect your environment.

Zireael07 commented 1 year ago

Ah, good point. I forgot how easy it is to accidentally infinite loop in an editor script

rsubtil commented 6 months ago

I'm interested in having a look at this. I'd like to also add our own scenario which led me to search for such a feature. We are using C#, and we had a misbehaving tool script that caused a crash when opening a project. While similar from what was discussed, the problem was even more annoying because simply commenting such files outside of the editor doesn't fix it because we need to trigger a rebuild of the project. And because we cannot open Godot, we had to figure out how to fix this externally, thus having to find how to manually recompile it (dotnet build).

I agree with the ideas discussed already: a way to manually trigger this mode both from the CLI interface (--safe-mode), and from the project manager, and also an automatic trigger that can detect such issues and thus prompt the user to open the project in safe mode. Then, the safe mode would disable the usual trouble makers that have been mentioned, and be limited to mostly editing functionality of scenes/scripts.

If it sounds good to all, I can start an initial implementation with a manual trigger for now, and see how it goes :slightly_smiling_face:

Calinou commented 6 months ago

I agree with the ideas discussed already: a way to manually trigger this mode both from the CLI interface (--safe-mode), and from the project manager, and also an automatic trigger that can detect such issues and thus prompt the user to open the project in safe mode.

The usual approaches to handle crash detection are:

Write a file in the user data folder (not .godot/[^1]) when opening a project, remove the file when the editor exits normally. Don't remove the file in the crash handler. If the file already exists on startup, prompt for safe mode then remove the file.
Write a file in the user data folder in the crash handler. If the file already exists on startup, prompt for safe mode then remove the file.

[^1]: The file shouldn't be written to .godot/, otherwise you risk having it included in ZIP files that are passed around (e.g. as MRPs on GitHub).

rsubtil commented 6 months ago

@Calinou do we want this mode to extend to general/runtime crashes too? I've been assuming this is intended for the crash on startup scenario which prevent projects from being opened at all.

The reason I ask this is because I'm imagining the safe mode would be quite restrictive on runtime functionality, particularly that it would prevent running/launching the project. I've assumed its purpose is more of a rescue tool rather than a debugging environment for any runtime crashes.

Calinou commented 6 months ago

do we want this mode to extend to general/runtime crashes too? I've been assuming this is intended for the crash on startup scenario which prevent projects from being opened at all.

I think this should be an editor-only solution, and it shouldn't prevent you from running the project (most editor crashes are due to editor plugins or tool scripts). Runtime crashes should be handled by something like https://github.com/godotengine/godot/pull/61906 instead.

rsubtil commented 6 months ago

I think this should be an editor-only solution, and it shouldn't prevent you from running the project (most editor crashes are due to editor plugins or tool scripts). Runtime crashes should be handled by something like https://github.com/godotengine/godot/pull/61906 instead.

Ah, sorry, my choice of words wasn't the best here :sweat_smile:

By "general/runtime crashes" I was referring to only crashes that occur during development and on the editor, not on the released project.

rsubtil commented 6 months ago

Before starting with functionality, I was curious to have a look at UX already. Since it's a subjective topic, I'd like to share already how I envisioned it to get some early feedback and iterate over it while functionality is implemented.

I really like how the movie maker mode was implemented on the UI: it functions as a toggle that "wraps" the whole launch bar to clearly indicate a mode switch which is affecting how the project is being handled:

Since the safe mode will disable features which can put the project in an invalid/incomplete state (such as addons which provide custom types get disabled), it made sense to me to prevent the project from being run completely. But, instead of disabling the launch bar, I've experimented with the similar concept of wrapping the launch bar to clearly denote a change in how the project is being handled, only in this case I've modified the bar to completely remove any launching functionality, and added a button to reload the project once the user is done:

Having this prominent yellow "Safe Mode" banner also comes with the advantage of being very noticeable immediately when the project is opened, thus clearly indicating to the user the project is not in a normal state:

Dark Theme	Light Theme

Lastly, and in order to give a chance to describe what this mode does exactly, I've also added a popup that appears when the project is launched and when the Safe Mode banner is clicked. It also features the yellow border to further emphasize the current mode.	Dark Theme	Light Theme

Calinou commented 6 months ago

Looks good to me!

godotengine / godot-proposals