Bulk editor doesn't support complex data

[annenveritas]

When there are several compounds with data that's related to some same thing, to account for any changes to that thing you'd have to manually edit every single compound. So maybe it would be nice to have a special case of the bulk editor for this: a tree view window with just the equal tags from the selected compounds. Here's what it could look like:

[tryashtar]

Interesting idea!

[Max-RM]

@annenveritas
I think you can click the edit button in the snbt form, then copy the snbt into a separate text document and use the function to replace certain groups of characters, then paste the edited snbt text back into nbt studio. (I use this method when I need to replace a lot of identical data)

[annenveritas]

@Max-RM
Oh, I don't mean changing just the identical data all around the file. Consider this example:

Here, I only want to edit the property tag in B and C1 compounds of Z1\X, in B, D2 and E3 compounds of Z1\Y and in B2 compound of Z2. The same tag is present in several other compounds, and in some it has the same value - those instances I would like to avoid changing. Currently, the only way of approaching the selected tags in SNBT is converting to SNBT the node that parents all of the selected tags - that is, the very root node in the considered case. And from there, I don't see any trivial way of automatically targeting just the sections of the SNBT-text that I would like to edit. If I would be manually replacing those in text, wouldn't it be even more laborous and inconvenient than doing so in the Studio?

[Max-RM]

@Max-RM
Oh, I don't mean changing just the identical data all around the file. Consider this example:

Here, I only want to edit the property tag in B and C1 compounds of Z1*X*, in B, D2 and E3 compounds of Z1*Y* and in B2 compound of Z2. The same tag is present in several other compounds, and in some it has the same value - those instances I would like to avoid changing. Currently, the only way of approaching the selected tags in SNBT is converting to SNBT the node that parents all of the selected tags - that is, the very root node in the considered case. And from there, I don't see any trivial way of automatically targeting just the sections of the SNBT-text that I would like to edit. If I would be manually replacing those in text, wouldn't it be even more laborous and inconvenient than doing so in the Studio?

well, in this case, to avoid editing unwanted groups of characters, you need to write a separate program with a regular expression for editing text, although it will be a long time. I also sometimes need to edit some data without touching others. so I use this

import re

n = int(input())
with open('360.txt', 'r', encoding="utf-8") as infe:
s = infe.read()

res = re.sub1(r'(?<=map_uuid:)\d+(?=L}},)', lambda x: f'{int(x.group()) + n}', s)

with open('out.txt', 'w') as f:
f.write(res)

such a program written in python can edit the text by selecting only the necessary text values enclosed between "map_uuid" and " L}}", thereby not changing other values.

[Max-RM]

@Max-RM
Oh, I don't mean changing just the identical data all around the file. Consider this example:

Here, I only want to edit the property tag in B and C1 compounds of Z1*X*, in B, D2 and E3 compounds of Z1*Y* and in B2 compound of Z2. The same tag is present in several other compounds, and in some it has the same value - those instances I would like to avoid changing. Currently, the only way of approaching the selected tags in SNBT is converting to SNBT the node that parents all of the selected tags - that is, the very root node in the considered case. And from there, I don't see any trivial way of automatically targeting just the sections of the SNBT-text that I would like to edit. If I would be manually replacing those in text, wouldn't it be even more laborous and inconvenient than doing so in the Studio?

I think this will correct the situation in the future
#26

[annenveritas]

@Max-RM
The main point of my example is that sometimes the only available criterion for the selection might be the current state of the tree view (ad hoc created by manually Ctrl+clicking some tags) - and that is not encoded to the SNBT format. Currently, the only way I see, of correctly automatically targeting the corresponding sections of the SNBT in an external text editor, is by programmatically parsing the NBT Studio window to retrieve the selection (that might even require code injection) - and that is pretty hacky and far from tivial, if you ask me. And even when you have that additional selection information (or if you're using the scripting, as it is described in the #26), slightly adjusting some values (imagine changing a few words in multiline strings) would be a lot less easy to do in SNBT, where you would still every time have to come up with some additonal logic to avoid changing anything else formally similar inside the selection (if you would be doing scripted replacements).

Bulk-editing it in the tree view through the already implemented tag editor windows, as I have initially described it in this issue, seems to me much more convenient and simple.

[tryashtar]

Slightly related question, how happy are you with the process of selecting multiple tags? The only real ways to do it right now are manually, or with ctrl-f select all. Is any part of the process annoying? I thought about doing like a "select by NBT path" thing...

[annenveritas]

How happy are you with the process of selecting multiple tags? Is any part of the process annoying? I thought about doing like a "select by NBT path" thing...

Personally, I don't think I have encountered any problems with the way selecting is currently implemented. Though now that you're mentioning it, I think something like a "Go to path" with an auto-complete (and maybe a default path being the root-closest one of those currently in the view) that would move the view to the entered tag (without changing the selection - allowing the user to manually choose between just navigating around, selecting the tag or adding it to some set of previously selected ones), could be quite handy in case of large "flat" compounds/lists that have hundreds of immediate children ordered non-alphabetically.