The Editor plugin API in Godot was mostly done with wishful thinking, and as a way to have a stable and clean API to editor functions (which may vary over time internally, or are not clean enough).
However, I'm positive that a lot of functionality for what you can do in the editor is missing from this API, thus inaccessible for plugins.
This issue is for you to write what kind of functions, objects, functionalities, etc. are missing for you, or you would like to be able to access so we add them in the next Godot version.
Feedback very welcome!
Here is a list of features/fixes.
+1 on the mouse offset bug. Currently using a messy hack to get it to work.
Also, the ability to show/hide the gizmos in 2D/3D when editing custom nodes. Functionally it doesn't matter since input can be captured, but it would be a nice visual improvement.
get_base_control().get_theme().get_icon
but I'm not sure where to get the name and type arguments.set_child_rect()
, not exposed). Currently I'm copying the margins from AcceptDialog::get_label()
- Draw custom stuff in the scene view from the EditorPlugin so we can draw gizmos for our own Node.
@EdwardAngeles
That's what my comment above is about. You need access to CanvasItemEditor and SpatialEditor viewports/canvases in order to draw on them.
Is there a way of sharing data between plugins? I think it should be possible but some sort of standardized interface would be appreciated.
See #5786
There should be a way for plugins to add a control to the main editing tab (2D, 3D, Script, etc) in a similar manner like AssetLib does. Useful for plugins requiring lots of real estate (say such as a plugin to manage a game project's git from within the editor). Right now there's no way to actually get an editor control into that region. This is also the region of choice for controls that provide custom editors.
edit()
relevance? I feel like edit
is not really needed in the API, or maybe it needs better behaviour/counterparts. I began using the edit()
callback as a way to know when an object I care about is selected, however it is not called when the object is deselected, and in the end I completely based my plugin on the Selection object as I get more info and events, at the cost of a few boilerplate code.forward_spatial_input_event
. The 2D event has no camera argument.)Easier access to the cameras (I only know how to get the 3D one, which is an argument of forward_spatial_input_event. The 2D event has no camera argument.)
@Zylann
There is no Camera in 2D -- there is just canvas transform AFAIK
@bojidar-bg well, that's what I meant.
edit()
relevance. I even think we don't really need make_visible callback too. EditorSelection has everything we need. And those callbacks act weirdly. If I select a node, I got two edit() callbacks (with same node) and three make_visible callbacks. At least this should be fixed.Could someone verify my two problems please? I hope I'm not doing something wrong.
Edit: Ok, I have another:
edit(object)
and handles(object)
callback, if I select more than one node. How to use it? It's not documented. I guess that it's object which holds references to properties from selected nodes. Am I expected to use it? It's not even exposed in GDScript so I can't test it with extend keyword. Why can't we get an array of selected nodes like in EditorSelection.get_selected_nodes()? It leads me to my final proposal. It's just my idea how it could work:No handles(object)
callback. Let me decide if I wan't to edit selected object. I will get it from EditorSelection signal. Then, I don't need edit(object)
and make_visible(visible)
. I can decide when to show/hide GUI from EditorSelection signal too. Forward_spatial_input_event()
should work like _process
callback. Let me activate this callback by function like set_forward_spatial_input_event()
. Current implementation is restricting. For example, I get the array of selected nodes and user can change which node he want to edit. But I can set Forward_spatial_input_event()
on and off only between handles()
callbacks.
@ndee85
Fix this mouse offset bug #1885
fixed
Make selected nodes from EditorPlugin.get_selection().add_node(node) also be set in the properties panel or expose a function that can do it
added an inspect_object() function to EditorPlugin so it's up to you to do it now
store editorplugin data in with the addon which is loaded when opening the editor
I think you have get_state() / set_state() to store state in a scene-specific way, is this not enough?
function to create thumbnails for scenes
Added access to EditorResourcePreview and EditorResourcePreviewGenerator, so you can now request and generate previews for all data types, including your custom ones.
draw custom stuff from the EditorPlugin
Added proper API for forward_canvas_input_event, forward_draw_over_canvas and update_canvas to EditorPlugin, this should allow you to draw any kind of gizmo for your edited objects.
enable automatic soft reload for tool scripts
This is already supported, isn't it?
@neikeq not kind of sure if I want to expose those, since they may change and are not super clean. What kind of functionality would you like to use from them?
@eska014 Added binding to set_child_rect(), will remove this function in 3.0 and make this control behave more container-like (so anything is expanded inside automatically)
@gau-veldt Just return true when asked: has_main_screen() in EditorPlugin and it's added as a main plugin after 2D, 3D, Script, etc.
I only wanted them for drawing. Does forward_draw_over_canvas
work with the SpatialEditor too?
@neikeq for Spatial editor you can use a node anywhere for drawing, or you have the Gizmo API.
@EdwardAngeles this should be already covered
@Zylann , @GlaDOSik : edit() is meaningful because most Godot editor works on the premise that editors pop up when needed. When selecting and deselecting, you don't necesarily get an edit() call.
The rest sounds like a bug :P
@GlaDOSik selection issues should be solved. MultiNodeEdit I suppose you are free from ignoring it. Not sure if it has any use for you, as you can already get the selection.
@Zylann I noted for Godot 3.0 to make plugins unregister the custom types and controls they created automatically. Will not do it now because a lot of existing stuff will break.
@reduz already tried that func has_main_screen(): return true
All you get is an tab in that menu (NB: that does not go away when the plugin unloads) whose selection activates a blank Control. The plugin is not given a node representing that Control to actually be able to place a scene as a child to actually be able to use it. The editor probably needs another method, something along the lines of get_main_screen_child() that the editor calls after adding the plugin entry to the menu so the plugin may return the instance to a scene to be used in that space (which Editor would then set as child for the tab as long as plugin is loaded).
@reduz
@GlaDOSik selection issues should be solved. MultiNodeEdit I suppose you are free from ignoring it. Not sure if it has any use for you, as you can already get the selection.
Well, I want to know if user selected multiple nodes. In this case, there is a problem with callback order. If I select a node, I'm getting handles(object)
callback first and after that signal selection_changed()
. That means I can't decide how to handle current selection. My brightest idea was to yield in handles and wait for signal selection_changed()
. It kinda worked but throwed a lot of errors.
So I think the order should be changed. I need selection_changed()
first and then callback handles.
Okay so I was thinking of this idea when diving into the plugins tutorial. The documentation is well-written btw!
Suggestion:
Example:
For example, I'm writing a script that will export my levels into json format to be used on my server. Instead of having the node highlighted, then clicking on the button, we can just right and click our custom menu item to be executed. However, this is just icing on the cake and honestly not sure what everyone thinks, but I think it'll be a cool feature down the road
I noted for Godot 3.0 to make plugins unregister the custom types and controls they created automatically. Will not do it now because a lot of existing stuff will break.
@reduz How stable is the plugin API now? This is something that still needs to be done in 3.0 AFAIK (using alpha1, not recent builds).
Hi @reduz I still see the issue with get_selected_nodes as described by @GlaDOSik in https://github.com/godotengine/godot/issues/6254#issuecomment-243595724 (v2.1.4)
I only get either child nodes or the parent. But if both parent and child is selected only the parent is returned.
Can you point me at the commit that is supposed to fix this or is this something fixed in 3.0?
Thanks!
EDIT
I assume that is the reason:
https://github.com/godotengine/godot/blob/master/editor/editor_data.cpp#L895
From the look of it the assumption is that selected root nodes imply their children are selected.
I don't know where this behaviour is needed but in my case I need all the selected nodes, including children.
Can we fix this or add an alternative interface that returns all the selected nodes?
Ok I think "get_transformable_selected_nodes" in master is what I was expected.
Do you think this can be backported to 2.1.x?
I would like to see MultiNodeEdit exposed to GDScript so that at the very least you can iterate over the collection yourself.
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Most helpful comment