Option to set a node as editor only

[Oranjoose]

Godot 3.0, build 10-27-2017

There should be an option to let a node remain visible in editor, but be invisible in game. Clicking the eye icon in the Scene panel just sets true and false on the node's Visible property, making it invisible in the editor as well.

It would be nice if this feature could be toggled per node, rather than a View menu setting which makes all invisible nodes visible or not in the editor. Maybe a Visible In Editor checkbox in the Inspector dock (next to the Visible property checkbox) that doesn't represent a property in the code?

[Zylann]

Like the "editor only" flag available on lights?
Because there is no point in hiding a node ingame if it's just for editor anyways, A good solution for this use case would be to have the scene loader ignore it when loading the game (through meta properties), and strip it on export.

In the meantime... you could write a script doing that, but a built-in feature would be cleaner.

[kubecz3k]

Just do in ready something like
if(Engine.is_editor_hint()): node.hide; #or node.queue_free()

[Zireael07]

Scene loader ignoring when loading/exporting would be a great idea. I often have "editor only" stuff such as debugging lines using ImmediateGeometry.

[Oranjoose]

@Zylann I feel that people are misunderstanding what I'm requesting. Editor-only nodes are def useful, such as with level design sketches as overlays for laying out a level in editor.

But I also believe that it is useful to have a visible in game flag, for objects you only want only visible in editor but still exist in the game. For example, you could have a bunch of different types of invsible trigger zones or invisible walls color-coded for different events and purposes.

I suppose you could put an editor only flag on just the graphical element, maintaining the functionality of the collisionshape.

[Calinou]

I think this would be pretty useful to have. In fact, I'd also like to see a "Game Only" option (which would hide the node in the editor, but not in the running game).

This way, you won't need to script the node hiding.

[NathanWarden]

If I'm understanding you correctly, you mean essentially having "proxy" objects to help with scene setup, but then these proxy objects would simply not be loaded in the release build of your game/application?

[Oranjoose]

@Calinou Yes, I agree that would be useful as well. A lot of set decoration in levels get in the way of editing the level, and it would be annoying to have to group them all together and hide them temporarily just to have to unhide them every time you wanted to test the game.

[kubecz3k]

Hmm sounds a little like 'load scene as placeholder' option
edit: oh I have probably misunderstood

[puppetmaster-]

I use group to handle visibility:

for _debugNode in get_tree().get_nodes_in_group("debug"):
	_debugNode.hide()

for _decorationNode in get_tree().get_nodes_in_group("decoration"):
	if get_tree().is_editor_hint():
		_decorationNode.hide()
	else:
		_decorationNode.show()

[hubbyist]

I had a similar need #9029 some time ago. May be these two can be merged in a single solution by the way. WDYT?

[kubecz3k]

I think it should be implemented by allowing to set 'load as placeholder' flag for every node, not only subscene ones. When any subscene has load_as_placeholder flag set, it will not load in runtime, and instead blank empty node is used, but there still is possibility to instance it with replace_with_instance function.

That way it would be useful not only for 'editor only' gizmos but also in scenarios like game settings, where I for example would like to choose if node should be loaded based on [condition] / [graphic_settings] (like for example GiProbe or ReflectionProbes which take while to load or even unload, so it's not really practical to freed them after loading).

[willnationsdev]

@kubecz3k That would be a nice feature in and of itself, but it seems to me like this is more about a request to provide an option for maintaining the node either in games-only, editor-only, or both (some sort of dropdown in the Inspector or a 3-way toggling switch next to the node in the Scene dock?). Using the placeholder feature for this would restrict it to only implementing the editor-only feature.

[kubecz3k]

@willnationsdev I'm probably missing something, can you give some use case where 'load as placeholder' will not solve the problem?

[willnationsdev]

@kubecz3k Nevermind, I think I just misunderstood what you meant. That should work for all variations. And it might not be too hard to implement either...with some slight modifications to the Editor and the InstancePlaceholder class. Maybe refactor the basic functionality into a base NodePlaceholder class and have it derive from that?

[kubecz3k]

What I meant was basically that we can use the fact that placeholder nodes are available in the editor (don't think any modifications in the editor are even necessary), but they are not loaded in runtime by default.
Not sure what would be the best way to implement "placeholder" mode for all nodes. (not only subscenes)

[vnen]

There are two issues with placeholder:

1. It must be loaded via code.
2. It's a node, so it's occupying a place in memory and in the tree.

Also, I don't think it allows to make a game-only node.

[kubecz3k]

@vnen about second point, as long as you don't instance it will take neglectable amount of memory. And yes it would not be possible to create game-only nodes this way, but can't find use case for that one (keep in mind that if node is not working in tool mode it's logic won't be performed in Editor). (update: I mean, from my point of view, currently if something is not a tool that means it's game only)

[willnationsdev]

Are tool scripts not compiled into the release of a game though? Or does a tool script still show up in the node hierarchy upon exporting to a platform (I thought they still did)?

[volzhs]

tool makes script can be executed in editor also.
it's not tool only.

[vnen]

Well, if game-only nodes aren't needed then my first point is moot, because you won't load the placeholder in game.

[Calinou]

Closing in favor of godotengine/godot-proposals#370, as feature proposals are now tracked on the Godot proposals repository.

[Zireael07]

I think we have a similar proposal already on godot-proposals?

[Calinou]

@Zireael07 Indeed, I edited my message accordingly.

[berarma]

It doesn't seem like the proposal and the followup to that proposal are really the same as this issue. And I think it would be very useful to have as a base feature.

Do you know of some other proposal? I couldn't find any.

[Calinou]

It doesn't seem like the proposal and the followup to that proposal are really the same as this issue. And I think it would be very useful to have as a base feature.

Do you know of some other proposal? I couldn't find any.

I just opened a proposal: godotengine/godot-proposals#3433