Started by
gabisa00
on
Topic category: Feature requests and ideas for MCreator
I believe having a tool for editing multiple selected elements could significantly contribute when projects require drastic changes.
Topic category: Feature requests and ideas for MCreator
I believe having a tool for editing multiple selected elements could significantly contribute when projects require drastic changes.
Even a multi-open function would be nice, though, more so for when specific changes are needed with multiple elements rather than the general changes this idea would probably be restricted to.
Regardless, multi-edit tool definitely great idea
How do you envision such editor to work?
Say you open 20 elements at once, how should the UI show all of the elements at once in a sensible manner?
I assume those 20 elements have some differences, so one UI for all of them could not work
I'd assume it might work somewhat like unity's multi-select, where it would only show features present in all the selected elements. Granted, unity operates different to MCreator, but for most elements, if all the selected elements are the same, they have identical options.
My views on how multi-edit can be implemented can probably be summed by a tree:
uniform: the option shows
no drag n' drop: open UI of element -(per option)<
1 (all same): multi-edit -< not uniform: the option is "Varies" or blank
multi-select -< has drag n' drop: something (maybe D n' D area that's pasted to selected)
2: multi-open (just open all separately)
Hope the tree is readable and helps
the tree got messed up, so I'll use my words.
when the user has multiple elements selected, they have the option to multi-open (open all separately) or multi-edit (only if all same element for simplicity).
If the user chooses multi-edit, open a UI for the element (harder for the block editors, so something different for those) and then, for each option, if the option is the same for all selected: paste that option, if it varies: set the option to "*Varies*" or something to that effect.
Then when something is edited in the multi-edit UI, paste it to all the applicable selected elements.
Hmm, merging all UIs into one intersection UIs would be a super complex system to implement
not even necessarily merging UIs, but the data in the UIs, hence why maybe only add the multi-edit option (at least, initially) to selections of the same elements.
I get it, but there need to be a way to show value editors in the UI. Thus merging UIs in a way to show all values that share same value in a UI that merged all editors into shared editor. This is a very complex thing to do
I'm not entirely sure what you mean by value editors, but I don't think you'd need to merge UIs, just the UIs values.
I have no doubt it would be a major pain to merge the values in different types of elements (such trying to merge values in a block element with values in an item element), hence why I think that would need a different method than I'm proposing.
With the same types of elements though, I wouldn't think it would be too hard to pull a UI of the shared UI (such as when trying to multi-edit a block element and different block element, it would just pull up the block element UI), and then when a value is changed in the UI, attempt to set the same slot in all the other selected elements to the new value in the UI.
for example, say you're multi-editing two different block elements, so the multi-edit UI will show the block element UI, and you change the opacity in the multi-edit, the opacity in the two blocks elements will be set to the opacity in multi-edit.
please let me know I'm just talking in a circle, not addressing key concerns, or just generally yapping.
I will try to explain with images to make it easier to convey what I have in mind. It's just my opinion, and of course, feel free to criticize.
First, a new multi-editing tool, and I’ll clarify upfront that it would only be for blocks of identical elements, meaning only entities, items, etc., without modifying procedures.
Second, we select the type of element we want to modify.
Third, we select all the elements we want to perform the multi-editing on.
Fourth, here you can modify only specific parts of an element or make changes that will apply to all the previously selected elements. This allows you to edit multiple characteristics of multiple elements simultaneously.
I believe this wouldn’t be an extremely difficult functionality to implement and, in the end, it would help me and many other creators.
I have a couple more questions.
What value should the editor show when All is selected and multiple elements have different values?
What should happen if one sets new value, but original values of "all" elements are not equal?
What if certain element has field disabled because it should not be altered, but some other has it enabled (e.g. different block bases) and one sets value to all of them? This would inevitably break the block where the value should not change.
That's a fantastic idea! 🛠️ Having a tool to edit multiple selected elements would be a huge breakthrough, especially for projects that require significant and quick changes. Imagine the efficiency gains and the reduction in rework it could provide! I'm very interested in exploring how this feature could be implemented. If you already have something in mind or need help structuring it, I'm all in to collaborate! 🚀
The intention is always to simplify, so I’ll provide some suggestions.
What value should the editor show when All is selected and multiple elements have different values?
Suggestions:
Leave it blank if the values are different.
Keep the value if they are all the same.
Create an indicator to notify whether the values are identical or different.
What should happen if one sets new value, but original values of "all" elements are not equal?
The "All" option is specifically for edits where you want to assign the same value to multiple elements.
What if certain element has field disabled because it should not be altered, but some other has it enabled (e.g. different block bases) and one sets value to all of them? This would inevitably break the block where the value should not change.
In this case, I believe the best approach would be to check if the field is enabled before making the change. If the actual intention is to modify that field, the user will have the option to enable the field for multiple elements or a single one, as they have already selected what they want to modify beforehand.