[Suggestion] Make machines save state when harvested

[MauveCloud]

Originally suggested by leagris in #1544

Then in a blink of questionable motivation, he added the overly complicated plunger to purge input tank whereas wrenching out the machine is always a simpler and less costly option. Because he expected to make the tilemachine NBT data to be persisted on harvest but failed the code. So machine inventory is not saved to the item in harvest and the plunger is made useless.

Looking at the changelog, https://mechaenetia.com/changelog/#Changelog I think you are slightly mistaken about the motivation:

5.02h ... Added Plunger, which can be used to clear a clogged GT Item Pipe System just by rightclicking any Pipe inside the System.

5.02j Added two new abilities to the Plunger: 1. Cleaning Fluid in Tanks and Pipes and 2. Cleaning Essentia Containers and Tubes from Essentia.

Admittedly, the item pipe system can alternately be cleared by connecting a chest. I'm not sure about essentia containers and tubes.

As far as making the tilemachine NBT data persisted on harvest, the framework is already there: https://github.com/Blood-Asp/GT5-Unofficial/blob/77a3c956e510b7c8ef4654054bcb16a0fccb86f7/src/main/java/gregtech/api/metatileentity/BaseMetaTileEntity.java#L1249 It's just that most GT tile entities don't do anything yet with that "setItemNBT" method. A lot can be copied from the "saveNBTData" method, but there are a few details that probably shouldn't be saved when harvested:

1. Facings - the player might be planning to move the machine, and the new location might be the opposite orientation of the old one.
2. Progress - if the player insists on breaking the machine while it is running, it might be intentional to interrupt the operation.
3. Item inventory - is it really worth saving this, rather than letting the items drop if the player neglects to deal with them beforehand?

[leagris]

Item inventory - is it really worth saving this, rather than letting the items drop if the player neglects to deal with them beforehand?

Yes it be nice to keep molds, shapes, integrated circuits.

Notes about persisting machine covers and orientation:

Currently, machine front is determined when placing. This is absolutely ok to stay as-is. But output side is always default rear, except for single-block generators who ave their output side at front. Covers are persisted but their data is stored as absolute world side. I mean it would be much more practicable to have covers persisted relative to the front side, so as when placing a previously harvested machines, left, right, rear, front covers are still left, right, rear front relative to player, regardless of the new machine placement. This would also fix the issue of covers dropping to the ground when the new front side world orientation occupy the world side of a previous cover which is not allowed on the front side.

[MauveCloud]

Yes it be nice to keep molds, shapes, integrated circuits.

Okay, good point. Just be aware you'd lose them if you toss the machine in an arc furnace or macerator without removing those items first, or if you for some reason decide to take a pickaxe to the machine instead of a wrench.

Covers are persisted but their data is stored as absolute world side. I mean it would be much more practicable to have covers persisted relative to the front side, so as when placing a previously harvested machines, left, right, rear, front covers are still left, right, rear front relative to player, regardless of the new machine placement. This would also fix the issue of covers dropping to the ground when the new front side world orientation occupy the world side of a previous cover which is not allowed on the front side.

This could be tricky to implement, especially considering that covers on pipes and cables (which have no obvious "front") are handled by the same code, but I'll look into it. Also, related to the above, saving item inventory would also affect item pipes (at least by default, I might be able to add special conditions for that), so breaking a clogged item pipe would no longer work to drop the contents.

[leagris]

Battery slot is a good place to persist.

Makes me think that if machine had dedicated configuration slot for circuits, molds, shapes, blades... you'd only persist this one and the battery slot.

A good GUI place for a configuration slot would be atop of the progress indicator.

A configuration slot would exclusively accept configuration items, with input slot blacklisting configuration items to maintain backward compatibility with existing automation setups; where the configuration item is piped-in and out alongside input items.

[MauveCloud]

There is already code for saving and loading the entire machine inventory (presumably triggered when the chunk unloads/loads), I'd just have to copy that part to the function called when the machine is harvested, and remove the code that drops the contents on the ground. Persisting specific inventory slots and not others would actually be more difficult.

As far as piping the configuration item both in and out of a dedicated slot, how would it stay in there long enough for the recipe to work? The recipes could be changed to "consume" the configuration item and put it an output slot when finished, but then it would be a pain to have to move it back to the input slot when not using some form of automation.

Wait, here's an idea I just came up with: what if piping in a configuration item pushed any existing one into the output (if there's room)? Sort of outside the scope of the current suggestion, but wouldn't really need a new dedicated slot.

[leagris]

You would not be able to remove the configuration item.

[MauveCloud]

Thinking about this "dedicated slot for configuration items" idea more, it might be more hassle to implement than it's worth:

1. How do you detect if an item is a "configuration item"? There are items that we can "by convention" consider as such, namely programmed circuits, lenses, molds, extruder shapes, and slicer blades, but afaik there's currently nothing in the code that strictly limits it to those - the recipe handler treats anything specified in the recipe with a quantity of zero like a configuration item, whether it's one of those, a block of dirt, a cucumber, or a quantumprocessor mainframe. Also, I don't think there's anything preventing the addition of a recipe (via GTTweaker, presumably) that includes two or more such items (e.g. a mold and a programmed circuit in addition to some other items in an assembler).
2. Some machines have no standard recipes involving configuration items, some have recipes both with and without configuration items, and some have only recipes with configuration items. The last category might suggest reducing the number of normal input slots, but in some cases that would be down to zero (e.g. distillery, fluid solidifier), which would look strange.
3. The extra slot would require some special code to handle already-placed machines updating to the new version that includes it.