Gt-new-horizons-modpack: [RFC] NBT Dissassemble Data

[Anarack]

Almost no one uses the disassemble so this feature just creates mass amounts of bloat on items.

Recommendation
Disable for sub components, leave enabled for machines/tools.

Discuss

[bartimaeusnek]

id like to keep it enabled for wires aswell

[jiamingc0824]

I recommend just remove all the recipes from disassembler or even straight up remove the disassembler. There is no reason for its existence and we can find better alternatives for disassembling item rather than saving all the NBT data inside the items. The current lag within the pack is almost unbearable, especially the large amount of data need to be sent from the server to load the AE/ME system. This also might be related to the 10+ seconds delay when searching item in NEI.

[mitchej123]

Alk pointed out that there's a "name remover" machine that Tec added which removes some name NBT tags. The plan is to expand the usage of that machine to do the following:

1) Circuit 1 - Current Functionality
2) Circuit 2 - Remove disassembly NBT
3) Circuit 3+ Any additional tags people come up with that would be useful to remove
4) No circuit (or 24) - Remove all NBT handled by individual circuits

Any suggestions are welcome.

[bartimaeusnek]

keep in mind that such a machine might potentially create bugs. i would welcome it, if the functionallity is restricted to only base GT machines / items.

[mitchej123]

I plan on only looking for GT related NBT, so that should be fine. If there are any other good suggestions that come up, then will definitely look into the need to restrict it if it isn't a GT specific NBT tag.

[draknyte1]

Hence why you have a circuit for each tag.
Stripping NBT entirely from items may make some useless, but beyond Tinkers/GT tools, can’t think of much that will yield buggy/exploitive behaviour.

[noobyaran9]

Removing all NBT tags from components (motor, piston and you name it) and from disassembler. (There is really no point on disassembling or saving the NBT data on components.)

Let the disassembler only able to disassemble machines. Basically leaving only 1 level of NBT data on machines.

[mitchej123]

On the next update you can use the "name remover" machine to strip the disassembly NBT.

[chochem]

So @mitchej123 you expect people to put a name remover next to every machine automation in their base? plus fiddle them into ae autocrafting? you cant be serious calling that a solution. that does not sound like a good solution ;) And that is just the AE2 part of the problem. Since this old issue we had about 500 quests break over NBT and we (at least sofar) have no way to utilize NEI shift-click for recipes which I assume is also due to the NBT data.

[mitchej123]

Keep it civil or I'm going to lock this issue too @chochem

[mitchej123]

The other one was a duplicate, if this didn't solve the issue, please discuss here. Include why your view the nbt should be removed is more important than the people who want to keep it.

Also why not propose patching AE2 to ignore disassembly info, or BQ3?

[mitchej123]

had about 500 quests break over NBT

Lol so now you're grouping forestry bees and other stuff into this? Which quests specifically broke because of disassembly data. Why not propose patching bq3 to ignore the disassembly data in the comparison algorithm...

[bartimaeusnek]

@mitchej123 im actually also for removal, since its literally pointless, and it increases the risk of chunk rollbacks due to NBT overload when using a recursivly crafted machine, i.e. motor has nbt, that goes into a piston that keeps the motors NBT recursively, that goes into a Robot Arm that keeps both nbt values and so on and so on... this isnt a problem for single machines, but rather for AE2 drives that keep track of content with NBT data

[chochem]

we did go over the quests. it was quite a lot of work. And no I dont have an exact count. And yes I am well aware the key issue was a problem in the bq1 -> bq3 transistion. However the point stands, the NBT bloat costs everybody a lot of extra work without much or any benefit.

[quedral]

I dissassemble worn electric wrenches / screwdrivers...ect and get back batteries and make new tools.
I would like that functionality remain.

[GTNH-Colen]

I dissassemble worn electric wrenches / screwdrivers...ect and get back batteries and make new tools.
I would like that functionality remain.

That is not intentional behaviour though, it's an exploit

[Edit: To avoid a single discussion spanning topics, let's discuss it here!] Disassembly data really serves no legitimate purpose anymore that I can think of at least, I don't see any reason why we need to keep lugging it around with us version to version and constantly breaking things when recipes change.

[mitchej123]

@bartimaeusnek I'm relatively indifferent about it. There was a group of people who used it, and there are alternative options to fixing it. I locked the other thread because it was a duplicate and it can be discussed here if the solution didn't fully address the issue.

[lor1113]

Agree on full removal of disassembly data. Would help cut down on hard storage and memory usage, removes problems with stacking and other mod interactions. Plus, it's a nerf :P

Some deconstruct recipies might have to be hardcoded for the niche use cases in which they are commonly used, but otherwise full remove.

[Prometheus0000]

quedral, that could be considered cheating, like the disassembling turbines thing.

What if there was no data, and it simply disassembled to the lowest tier version materials? Would that be hard to do? And generally, isn't it mostly circuits that are variable?

Though tool disassembly would be out.

[kekzdealer]

Also in favor of full remove.
Limiting it to one level would be a nice start though.

Risk of chunk overload becomes especially fun if you dislocate something that contains GT items

[Regian24]

never used the disassembler, so if it's useless lag, just remove it

[Anarack]

Another option if you don't want to kill all of it is to only keep one level of data to reduce recursive storage issues, wonder if thats what if that is causing the utility world issues.

[chochem]

I am not the coder here so you guys will know better what is or is not doable, but it looks like it could be a good option to just remove the disassembly data from all the basic gregtech things but keep the disassembler as a machine around. So that if some modder, e.g., alk wants to use it then they can. The large chickens were just disabled in the pack but I wouldnt be surprised if she or someone else has another use for it.

[mitchej123]

remove the disassembly data from all the basic gregtech things but keep the disassembler as a machine around.

How would that work? Disassembler reads the disassembly NBT to disassemble it...

[GTNH-Colen]

Another option if you don't want to kill all of it is to only keep one level of data to reduce recursive storage issues, wonder if thats what if that is causing the utility world issues.

This does not address the AE issues though so would rather fully nuke this and be over it.

[chochem]

remove the disassembly data from all the basic gregtech things but keep the disassembler as a machine around.

How would that work? Disassembler reads the disassembly NBT to disassemble it...

Apparently I wasnt quite clear enough. It would then only work on a few things obviously, like large chicken eggs, etc.
It just sounded like some modders like you or alk still wanted the option, so I say sure why not. just remove it from the standard gt stuff.

[repo-alt]

Disassembler may theoretically use assembler recipe map. (posted first to duplicate thread)

[GTNH-Afx237v7]

I am also in favor of removing it if it increases performance and/or reduces risk of corruption.

[yukieiji]

How about removing the hand crafted recipes for intermediate components like motors and pistons Isn't it? (There is no NBT in the assembler's recipe. In the LV before we make first assembler, we'll need to add some additional crafting methods other than assembler...)
This indirectly makes it impossible to disassemble anything other than the machine and tools.

[GTNH-Colen]

How about removing the hand crafted recipes for intermediate components like motors and pistons Isn't it? (There is no NBT in the assembler's recipe. In the LV before we make first assembler, we'll need to add some additional crafting methods other than assembler...)
This indirectly makes it impossible to disassemble anything other than the machine and tools.

I don't see the point in overcomplicating this, just delete the disassembly data and be done with it. I've disassembled things maybe a handful of times max over 100+ days of playtime, it's a very very niche mechanic that constantly causes a bunch of players grief every update.

[Prometheus0000]

So you want to remove hand crafting... so you can add something else? Like hand crafting?

[Viktor-KN]

I'm voting for remove. Never used Disassemblers and suffered a lot from this "feature".

[johnch18]

I use it almost daily, so please no.

[KaneHart]

This older but I for one would love this crap gone... There must be better ways then storing all into NBT data...

[GTNH-Afx237v7]

Maybe put this up for vote? I briefly mentioned yesterday on Discord whether an _ignore NBT_ button in the pattern terminal was possible and/or useful.
Personally I have never used disassemblers and don't see the need for it either.

[DualBallers]

I use the disassembly regularly on e.g. lower tier machines, so please include Anarack's recommendation if it's put to a vote

Disable for sub components, leave enabled for machines/tools.

[leagris]

I dissassemble worn electric wrenches / screwdrivers...ect and get back batteries and make new tools.
I would like that functionality remain.

That is not intentional behaviour though, it's an exploit

[Edit: To avoid a single discussion spanning topics, let's discuss it here!] Disassembly data really serves no legitimate purpose anymore that I can think of at least, I don't see any reason why we need to keep lugging it around with us version to version and constantly breaking things when recipes change.

Is there a dependency on Disassembling Data for replacing electric tools tip before it reaches max durability?

Was the whole tool vanishing issue solved?

To me, GT tools are the only reason to care to provide alternatives to the Disassembling Data, such as an example:

• Once electric tool reaches its maximum durability, the tip is marked broken, tool is unusable, until you remove the broken tip and eventually recycle it in a grinder / arc furnace for raw material. and replace it.
• Or the tool losses its tip and you can place a new one over the electric handle.

[NoX-programer]

If it will be decided to cut DNBT via vote
https://discordapp.com/channels/181078474394566657/465207956745486336/764106712176394260
I suggest not to delete parts of well working code, but add a config options to disable DNBT separately for:

• Components (piston, robot arm, etc.)
• Machines (bender, multi controllers, etc)
• Tools (electric screwdriver, electric wrench, etc.)
• Others (covers, multi blocks, etc)

[dvdmandt]

If the tags are removed from components and cables, to what extent is the data even needed for machines? The only thing I can think of is circuits? Higher-tier glass?

[repo-alt]

Machines would be disassembled to components, just like now, but the components themselves will be stackable.

[dvdmandt]

I understand that, but to what extent are there variations in the machines themselves? I'd say 90+% of the NBT variations come from components, like using different types of rubber in components or something, but if we dropped that, would there still be room for enough differences to warrant having it in machines, or could we just drop down to plain recipes for disassembly of machines? It's a legit question, the only thing I can currently think of that would vary between machines of the same type if NBT data was removed from cables and components are circuits.

[repo-alt]

If there is a crafting recipe, then indeed NBT is unnecessary

[repo-alt]

Although, yes, there are circuits still. Anyway machines NBT is very minor issue I think

[Prometheus0000]