Alternate Run Project/Current Scene Buttons for Running with Editor Settings

[HappyFunTimes01]

Describe the project you are working on

Old-school RPG with voxel use.

Describe the problem or limitation you are having in your project

Took longer than I'd like to admit to figure out that I needed a WE and global lighting.

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

In regards to #5800 #5801, which helped me through some confusion.

Just ran into this myself. Makes sense from both sides: no default/confusing crud but also no quick run or indication to a newbie that I need to add a WE, light, camera (of course, until I read the fine manual X-D). How about tutorial/convenience buttons to run the project/scene with the current editor lights/WE/camera? Default the buttons to visible but able to be removed from the bar if so wanted, like a browser toolbar? Added bonus of telling the user what they need to dig into in the tooltip.

(example button)

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

1. User presses button.
2. Engine creates temporary copies of WE, lights, and camera used in editor.
3. Engine links temporary copies to project/scene.
4. Project/scene runs.
5. User closes run window.
6. Engine unlinks temporary copies of WE, lights, and camera.

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

Current intended workflow for defining camera, lighting and WE works just fine.

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

Users just starting out won't know to add add-ons for it if they don't know about WE, lights, and camera in the first place.

[AThousandShips]

I'm unsure how this would work or how smoothly it would work, the running game just loads the saved scene, so we'd have to somehow inject the scene environment etc. into it when it has started

Would this be done by adding nodes to the scene? Or calling the rendering server? How would it work with remote debugging etc.?

[HappyFunTimes01]

Apologies, I wasn't entirely sure myself when suggesting the buttons. Is it possible to create a temporary copy of the entire scene and replace/create nodes as needed?

[AThousandShips]

It could be but that sounds pretty fragile and error prone

[KoBeWi]

It's possible to inject nodes into running project by using debugger (same as live editing).

[Calinou]

Took longer than I'd like to admit to figure out that I needed a WE and global lighting.

For this particular problem, I still think a warning message on startup is the most suited.

[Download]

So I'm here reading this issue because I have a related problem... I won't hijack this issue with my own problem but I just wanted to let the community know that after reading this issue and many like it, I do think that the Godot maintainers are underestimating the negative impact of the current setup on the user experience. I have been hacking around in Godot for a few weeks and I think that 90 percent of the time I had to spend on researching issues was because the runtime does not match the editor and I have no clue why not. I think it is insight that is lacking most. On my part for sue but also in the editor which does not make it clear what the differences are. We don't know WHY its different often and it is not very easy to tell.

Search online for things like 'Godot in-game no color' or "Godot everything gray' etc and spend some time reading the questions. There are a LOT of people asking very similar questions and that is a clear indication that SOMETHING is amiss. In the world of text editors we used to have this same problem. See nice fonts, spacing etc in the editor and then press print and get different results. Check out how WordPerfect used to work in the old days. People desperately wanted both views to show the same thing and they gave it a name: WYSIWIG. This stands for What You See Is What You Get. Currently in Godot it's very often What You See Is NOT What You Get.

I have no idea what the best solution is. It makes sense that the editor sometimes needs different lighting conditions than in-game (night-time scenes otherwise too dark etc). But maybe it should be turned around and the editor settings should simply always match in-game settings unless overridden. Or maybe the default new blank project should simply always get a default light/enviornment/camera.... Or maybe the differences between editor and in-game should be shown somewhere, maybe with toggles so you can quickly see what is causing the specific difference we are seeing...