multitheftauto / mtasa-resources

This project maintains a list of up-to-date resources that come with Multi Theft Auto.
https://multitheftauto.com
MIT License
153 stars 156 forks source link

editor: Inconsistency in destroying elements #301

Closed Yamsha75 closed 1 year ago

Yamsha75 commented 3 years ago

Which resource(s) have this problem? editor_main

Describe the bug When destroying an element using editor_gui (for example with DELETE button), first "onElementDestroy" event is triggered, and then the actual action is made, which is in fact just moving the element from working dimension (200) to destroyed elements dimension (201), as seen here: https://github.com/multitheftauto/mtasa-resources/blob/master/%5Beditor%5D/editor_main/server/createdestroy.lua#L99-L102 https://github.com/multitheftauto/mtasa-resources/blob/master/%5Beditor%5D/editor_main/server/undoredo_action.lua#L210

After this action, when doing an UNDO and then a REDO, the order is different: first the element's dimension is changed and then the event is triggered, as seen here: https://github.com/multitheftauto/mtasa-resources/blob/master/%5Beditor%5D/editor_main/server/undoredo_action.lua#L258-L260

To Reproduce

  1. Run this code in runcode:
    srun function f(e) outputChatBox(e.dimension) end addEventHandler("onElementDestroy", root, function() f(source) setTimer(f, 50, 1, source) end)
  2. Create an element in editor
  3. Delete this element - observe "200" and "201" in chat - this shows that at onElementDestroy the event was still in working dimension and then moved to destroyed elements dimension
  4. UNDO
  5. REDO - observe "201" twice in chat - this time at onElementDestroy event the element was already in destroyed elements dimension

Expected behavior This behaviour should be more consistent, as the only way to check if an editor element is destroyed or not is checking if its dimension is 200 or 201.

Screenshots

Version Multi Theft Auto v1.5.8-release-20802

Additional context

Haxardous commented 1 year ago

fixed by #401