TheDuckCow / godot-road-generator

A godot plugin for creating 3D highways and streets.
MIT License
316 stars 16 forks source link

Create inspector panel with RoadPoint selected #26

Closed TheDuckCow closed 1 year ago

TheDuckCow commented 1 year ago

Let's create a new panel in the inspector area of the UI so we can throw in some debug buttons as necessary. This can be used as

See this other plugin I built which shows how to create inspector areas, noting it's a bit odd how you select which region it should be placed in: https://github.com/TheDuckCow/godot-curve-edit/blob/main/addons/curve_edit/path_edit.gd#L13

In this example I'm intentionally inserting a panel right after the "transform" section, whereas we'd really want to create our own section further up most likely.

See also: https://docs.godotengine.org/en/stable/tutorials/plugins/editor/inspector_plugins.html

TheDuckCow commented 1 year ago

Hey @bdog2112 I'm assigning this one to you in the event you get time to this before our meeting on Sunday, if you don't I'll take care of it after then I expect this should take only about 2-4 hours tops. I suggest you use print_debug on the attributes of the elements being drawn in the panel to decide where to insert this panel better.

Should only appear if a RoadPoint is selected, and operate on the controls of that RoadPoint specifically.

bdog2112 commented 1 year ago

We're currently exposing various properties of the RoadPoint in the Inspector and they don't require the complexity of a custom panel. What are some use cases that necessitate this panel?

It sounds like you're asking for a blank panel, for now. Is that correct?

We should establish naming conventions that can easily be extrapolated to other classes like RoadSegment and RoadNetwork.

Should this panel exist as a separate addon? (I'm thinking, no. But, if yes, then it should probably be designed as a utility that will eventually include RoadSegment and RoadNetwork panels.)

My tentative plan is to:

Please let me know if this aligns with what you had in mind.

TheDuckCow commented 1 year ago

Good clarifying questions @bdog2112. Yup a blank panel essentially, so that - as you said - we can throw in debug functions in there as needed while we work on the controls described here. I recall you mentioning this would be convenient to have before getting started on UI components described in this PDF (I still need to create separate tasks for this).

This should be part of the same addon for sure. Indeed we will eventually have panels for LaneSegment and RoadNetwork, we can just start with RoadPoint for now.

My tentative plan is to...

Your steps sound good to me, thanks for detailing out in advance. Bonus points if you connect the placeholder button's on press signal to a function in road_point_panel.gd (which does nothing, for now. Maybe a debug print is all).

In terms of structure, I think it would be good to create a subfolder for addon ui scenes and the scripts used directly inside those scenes. Other code that is outside of this or a level higher in scope, such as related to registering the placement and loading in this UI, can be top level/the main plugin code itself.

/addons/road-generator/ui/road_point_panel.gd
/addons/road-generator/ui/road_point_panel.tscn
bdog2112 commented 1 year ago

During one of our recent conversations, I mentioned the need for a global panel to allow the developer to perform various tasks. One such task is restarting the addon. As you know, any little change to the plugin code potentially causes it to no longer respond until restarted.

It's tedious to go into the menus and toggle the addon off and on after every edit. Hence, it would tremendously speed up development if there was a quicker way to do this such as a button in the Inspector panel. "EditorInterface.set_plugin_enabled()" would allow a quick and easy toggle.

As an aside, someone created a plugin specifically for this purpose. I haven't tested it. But, it sounds potentially useful across a broad range of projects.

bdog2112 commented 1 year ago

Good news and bad news.

The Good News: The aforementioned plugin is nice and restarts plugins as advertised. The Bad News: Developers must still close and re-open the current scene in order to make everything fully operational after a minor code edit.

Observation: A button that restarts the plugin and reloads the current scene would be ideal.

Test Scenario:

Gizmo handles remain, essentially, frozen until the scene is closed and re-opened. Hence, a practical solution would be a button that, both, restarts the plugin and re-loads the current scene. It might also be of benefit to have a checkbox indicating whether to save the scene before reload. Bonus points if the button automatically switches the viewport from code editor to 3D View. :-)