Signal when Inspector updates/exported property changes

[Obnivelint]

For my current Project, I am working with procedural geometry. While testing, I am generating the geometry in the editor.

The problem is that I want to experiment with different property values for the generated geometry, without resorting to the trial and error approach of manually regenerating the mesh every time I make a change.

updating every frame (or even physics frame) is out of the question, with larger meshes, that would be an enormous performance drop. appending a setter function to every exported property is another option, but they would all be the same (update the geometry), so that's a bit redundant. More importantly it removes the ability to add a custom setter to each property.

Ideally I would update the mesh only when I change one of the exported inspector properties. I propose adding a signal / notification whenever the current inspector updates.

[vnen]

The Resource class has a changed signal when any of its properties change (via Inspector or not).

[Obnivelint]

Godot 3.0 Stable

I missed that, thanks.
What about built-in types? As far as I can tell there isn't a way to convert those to a resource as they don't inherit from Object. I suspect the implementation of this would be native to the Object or the inspector/editor control, not the property itself.

The closest I've gotten was the EditorResourcePreview class. It has a signal preview_invalidated ( String path ), but I have no idea what the path would be. Also, I can't tell if the inspector is even implemented this way. Other editor windows seem to have some way of accessing them from the EditorInterface class, such as get_script_editor() and get_editor_settings, but I don't see one for the current inspector.

As a side note how did you do the grey highlighting?

[vnen]

I don't think built-in types have support for signals. I guess the Inspector could handle this in editor so plugins can make use of it.

As a workaround, you can cache the properties you need and check them every frame (or even once in every ten frames or something). If some property changed, then you re-generate the things. Should not be much of a performance drop.

As a side note how did you do the grey highlighting?

You can use Markdown here. If you surround a word in backticks it's formatted in monospaced font with gray background: `word` becomes word.

[realkotob]

I was looking into #6201 (auto-keyframes) and I imagine this issue here to be a specific blocker. Has anyone found a workaround?

It seems the most logical way to implement auto-keyframing is by using a signal callback.

Pinging @RandomShaper who might have had some luck with this basing on #12572 (comment)

[mitchcurtis]

Having a way to react to property changes (e.g. an equipped_item property that affects the player's sprite) so that we can preview stuff in the editor would be really helpful. Is there a way to do this? It seems that Node doesn't inherit from Resource, so that isn't an option unfortunately.

[wlsnxx]

The Resource class has a changed signal when any of its properties change (via Inspector or not).

Godot 3.2.stable

Don't works in Custom Resources

[Calinou]

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!

[shayneoneill]

Guys, this doesn't need changes to the language. Its already well supported for user defined signals with a bit of programming smarts.

extends WhateverBaseClass

signal my_notifier_signal

export (type signature) var property_name = <initial value> setget setter, getter

func setter(value):
    property = value
   emit_signal("my_notifier_signal",value)

func getter():
    return property

(From memory, the syntax might vary)

Then whenver your property you defined is set, your signal will be triggered (with the new value, just remove the ,value in emit_signal if you dont want that)