xyz In the case of the "EditorInspectorPlugin" its diferent
@tool
extends EditorInspectorPlugin
const inspect0 = preload("res://inspector/inspector.tscn");
func _can_handle(object):
if object is tileDrawNode:
return true
return false
func _parse_begin(object):
inspect1 = inspect0.instantiate();everytime you press the editor screen it triggres the ready function in "inspect1"... i only found out about it now,
maybe the undoRedo history of that tscn gets reset
For some reason its reseting it... I dont have anything in the code that does that
If i use this:
@tool
extends Node2D
#class_name tileDrawX1;
func _process(_delta):
if ( Input.is_mouse_button_pressed(MOUSE_BUTTON_LEFT) && mouseJustPress == false ):
mouseJustPress = true;
if ( drawText == null ):
return;
mouseGroup.Fnum.clear();
#-----------------------------------------------------------
#-----------------undo-rendo-draw-------------------------------
undoredo.create_action("tileDraw - drawing Tiles");
undoredo.add_undo_method(self, "remove_element", layers.Lnum[ layerPOS ].duplicate(true) );
undoredo.add_do_method(self, "add_element", layers.Lnum[ layerPOS ].duplicate(true) );
undoredo.commit_action();I get 2 prints on the other side in the tscn the EditorInspectorPlugin spawns
@tool
extends EditorInspectorPlugin
const inspect0 = preload("res://inspector/inspector.tscn");
func _parse_begin(object):
inspect1 = inspect0.instantiate();this prints out 2 times everytime i mouse click on the editor, "inspector Ready"
@tool
extends Control
func _ready():
print("inspector Ready")Its the undoRedo block of code for some reason is deleting or restarting the inspector, i dont have anything else if i remove that block of code the inspctor.tscn ready function no longer prints ?
jonSS For some reason its reseting it
Who resets what? Remember that this is not a thread about your project. Have you managed to implement a simple undo system on your own in a fresh project following the model shown in my example? Do that and it'll make things a bit clearer. Don't just copypaste. Make your own variations. Add stuff to it. Do "what if" experiments with it. Tinker until you gain full understanding of how it works.
Again, the inspector has nothing to do with undo. If you're storing undoable data in an inspector then your architecture is not properly done. All undoable data needs to be on edited node's side. An inspector should only read that data and display it. Akin to classical model-view-controller design pattern.
Typically you'd implement something like update() or refresh() method in your inspector and call it every time you want to refresh what the inspector displays. In that method you'd read all the relevant data from the edited node and set the inspector's state accordingly. Everything that lives in the inspector should be totally disposable.
Also, not directly related, but all viewport input concerning the plugin (e.g. editing plugin supported nodes...) is best handled in EditorPlugin::_forward_*_gui_input(). See my example.
xyz I dont know man... You want to force your its working stuff, and its the other s guys fault, you start looking like an idiot.
I havent added anything to the inspector, about redo undo etc.. its on the plugIN node.
I havent done the redoUndo, all i know is it reset "EditorInspectorPlugin" ( func _parse_begin(object) ) and everything along with it "inspect1 " etc...
Ive made examples and tested it, and cant do anything to prevent those scripts startUp functions from running...
If there are idiots that believe in what you say, good congralutations reason is on your side... but it doesnt work... shared believed doesnt make anything work..
For the record, here's an example undo project that contains only my above code.
Lo and behold - it works! 
Who would've thunk it? 
xyz great !!! what iam supossed to do now ? create a new forum account and use the Tor Browser ?
you need to add "EditorInspectorPlugin" and see if it reset...
Also theres no reason, for to undoRedo to reset those scripts. I dont know if you added it to "EditorPlugin" or the node the plugIN handels ?
not working in here:
https://github.com/godotengine/godot/issues/97502
jonSS Your arrogant attitude doesn't warrant this but here it is anyway 
Does undo work? Of course it does. Shocking, I know. Editor inspector plugin has nothing to do with undo, did I already say that?
I suggest deleting that post on github unless you want to embarrass yourself. The only "issue" there is the lack of understanding of how this stuff is supposed to operate. I won't waste any more time trying to explain it to you just to be called an idiot in return. You don't listen. Here's the example with editor inspector plugin added on top. Learn from it. Or don't. Good luck 
️
I made a mistake the download is working, it only works when you re logged in. You keep hammering me down and i forget this things.
Ho no 
, ho my god its working !!!
apparently you example is not working either...
I thought you ve made it work, just by making the undoRedo in the "extends EditorPlugin" instead of the handle object script.
But he throws the same thing, "EditorInspectorPlugin" resets, just by to pressing any of the boxes on the editor,
You problably going to tell me iam an idiot too, and i have to add the color to the undoRedo in the "stroke_draw_list" in "EditorPlugin"... The problem is why does the undoRedo resets the "EditorInspectorPlugin"...
but fine leave it on... its working 99.9% of the cases, just move on to another thing whatever, if its not working or just working in 1 or 2 years from now whats the diference anyway... ( A thing that could be solve in 5 or 10min, its going to drag for a lot of time, because noOne its using it )
But iam the "BadGuy" right, lets all become little friends and unite agaisnt the badGuy jonSS...lol
jonSS EditorInspectorPlugin::_parse_begin() is supposed to be called every time you select a node supported by EditorInspectorPlugin::_can_handle(). Nothing gets "reset". Custom controls scene is supposed to be instantiated every time this happens. Its _ready() is supposed to be called. You're complaining about things that happen by design.
The skipped undo is due to possible bug in color picker gui modality. If you click into viewport with the color picker still open, EditorPlugin::_forward_canvas_gui_input() wont register mousedown event nor its counterpart mouseup event. This is the actual thing that may be worth reporting.
For simplicity, my example was checking only for mouseup and mousemove envents. It implies stroke state instead of tracking it via a flag set by a received mousedown. Because of that, the stroke you start when a color picker is still visible won't make it into the undo queue.
Easy fix by adding a flag into mouse input logic. It will now require an additional viewport click when trying to stroke from an open color picker. Courtesy of an apparent color picker glitch.
All this is just menial gui stuff. Nothing to do with the core undo mechanism we're trying to demonstrate here.
Now be a darling and check and report back how you feel undo performs in the project below.
xyz Its running fine now... but I dont know ?
I also think its normal for the inspector to reset when you change nodes...
Ive been messing with "func _forward_canvas_gui_input(event):" and nothing will change it back to normal... The only thing that makes it run right is if i remove the "undoRedo" code..
But never mind, i dont know why the "undoRedo" triggers that... And maybe it doesnt matter...
tileSets have been cursing this engine every since day one when it come out... problably some Dev whos in charge of tiles, did the undoRedo... best to just leave it alone... i just wanted to make my own tileMap so i could get out of dodge, i ill find another way to do the undoRedo...
jonSS Only wanted to address complaints about my example "not working". It works and it shows how undo is properly implemented. The rest of your questions have already been answered. Go re-read my posts.
Here's a hint; You do stuff with that dictionary outside of do/undo functions. Once you introduce undo functionality, all changes to that dictionary should be contained within those functions. Otherwise the thing will likely fall apart. And that's precisely what you're witnessing there.
Either that or the devs are intentionally destroying the engine, eh?
jonSS Btw the inspector refresh that is breaking your heart is triggered by notify_property_list_changed() called from undo/redo functions. This is again by design. The sole purpose of this function is precisely that - to refresh the inspector.
Also, you need to remove the inspector plugin in EditorPlugin::_exit_tree() by calling EdtorPlugin::remove_inspector_plugin(). Otherwise the custom inspector gets multiplied with every restart of the plugin.
Go do an arkanoid clone or something. Plugins are messing with your mind
