[Suggestion] Machine Configuration Copy/Paste Item

[Caedis]

Is your feature request related to a problem? Please describe. Getting into the end game of Omnifactory requires the use of many solidifiers with a creative fluid tank and setting them each up manually can be very repetitive

Describe the solution you'd like Crouch+UseItem = Copy machine config (output side and fluid/item output toggle)
UseItem = Paste machine config from copied machine
Optional: Have config copy item in off hand to auto paste the config to the machine when placed.

Additional context Think something like the Conduit Probe from Ender IO or Red Print from Thermal Foundation

[LAGIdiot]

This sounds like interesting idea and I am in favor of it.

I think we should discuss this before we get to implementation as this may not be easy as it sounds.

Also we could use this tool for copying configurations to covers too. But for that we would need more then one mod on it.

[galyfray]

I think the step to make this possible is to define what is a configuration and what is not a config the second step would to create a class (or a family of class) which will handle those configuration inside it something which would work a bit like an NBT tag compound

[warjort]

A generic implementation of this would need to get the NBT for the tile.

But that tag contains more than just the configuration. It contains the state of the machine (including inventories, energy, recipe progress etc.) and also its attached covers.

So that does not seem doable in general.

An alternate approach would be to have a capability, something like:

public interface IConfigurable {
    // Used to match the tile entity id so configruations are not applied to the wrong machines
    ResourceLocation getId();
    // Gets the configuration subset of the tile NBT
    NBTCompoundTag getConfiguration();
    // Applies the configuration subset
    void applyConfiguration(NBTCompoundTag configuration);
}

It needs to be NBT because that is the only way to store additional information within the item stack of the new tool.

Once the basic plumbing has been added to MetaTileEntity, AbstractRecipeLogic and other places that have standard configuration (or pass through to something that does), then machines can "opt in" to the process. e.g. SimpleMachine would be an easy candidate

For covers presumably a separate "screwdriver" version would be used? This would just extend the main tool with logic to redirect its operation to the cover like the screwdriver does. Or maybe it can be a different mode of the same tool?

But covers have the additional complication that some of the config is stored within optional items added to the cover, e.g. filters. They would need additional logic to detect this and indicate the problem to the user (chat message?).

Finally, the mechanism would need to implementated in such a way that the applyConfiguration() is robust to additional/changed configuration added in new versions. The tool could be storing configurations from an older version.

[warjort]

An alternate approach would be to have a capability

The other advantage of using a capability is that other things beside the tool can do this processing. e.g. You can imagine ComputerCraft automatically switching configurations based on programmable conditions

The downside is that the configuration NBT potentially becomes an api. Unless we say it is only supported as an opaque object.

[galyfray]

A generic implementation of this would need to get the NBT for the tile.

I don't think I just talked about an holder for the data a tag compound or anything like this

It needs to be NBT because that is the only way to store additional information within the item stack of the new tool.

yes we can't choose any holder for data that answer quickly to my second point

the way you proposed seems good for me.

Finally, the mechanism would need to implementated in such a way that the applyConfiguration() is robust to additional/changed configuration added in new versions. The tool could be storing configurations from an older version.

I think a good way of being sure that applyConfiguration() will be robust could be to extract code from readFromNBT and put it inside applyConfiguration and doing the same with getConfiguration and writeToNBT this way we would ensure that any changes to the configuration storage will have to be correctly done to handle older version or glitch/crash would appear really quickly when loading older saves.

But covers have the additional complication that some of the config is stored within optional items added to the cover, e.g. filters. They would need additional logic to detect this and indicate the problem to the user (chat message?).

I think a specific method should handle checking that the config can be applied and should return a string if the string is empty there is no problem if not then it's an error that needs to be printed in the chat.

The downside is that the configuration NBT potentially becomes an api. Unless we say it is only supported as an opaque object.

I don't really see how this could be a down side ?

[warjort]

If you don't like this open ended version of the capability an alternative would be:

public interface IConfigurable {
    // Save the configuration subset of the tile NBT in the item
    void saveConfiguration(ItemStack stack);
    // Applies the configuration subset from the item
    void applyConfiguration(ItemStack stack);
}

Where we are more responsible for the IItemBehaviour of saving and retrieving the NBT in the item. This way also means that other mods configuration tools could potentially be retrofitted with the capability when they support such things.

[royalmustard]

But covers have the additional complication that some of the config is stored within optional items added to the cover, e.g. filters. They would need additional logic to detect this and indicate the problem to the user (chat message?).

One of my main issues with filters is that they dont keep their configuration, so I would rather have it copying the filter configuration as well. But I dont know if that is technically possible right now.

[warjort]

But I dont know if that is technically possible right now.

Its possible, the issue is what happens if you copy a cover's configuration that has a filter to one without a filter. There should probably be some warning in the chat window telling you that you goofed. :-)

[eutro]

With that much effort you could also just have it appropriately consume a filter from your inventory.

[warjort]

With that much effort you could also just have it appropriately consume a filter from your inventory.

You want something that plays the game for you? Like those magic sticks that construct multiblocks. :-)

[eutro]

You want something that plays the game for you? Like those magic sticks that construct multiblocks. :-)

I actually enjoy incredibly repetitive tasks such as dragging filters into machine covers and configuring them, it's really engaging gameplay and it's what I'm here for as a GTCE player.

Isn't that the whole point of this issue?

[warjort]

I actually enjoy incredibly repetitive tasks such as dragging filters into machine covers and configuring them

Me too, especially when you forgot to toggle the output side to accept inputs before making it inaccesible with cables, pipes and other machines.

But the logical extension of your request is that the tool could;

• place the machine
• add the covers (with any filters)
• configure the whole thing

provided you had all the items in your inventory.

And then somebody is going to ask for it to do multiblocks.

[eutro]

Sorry, I didn't realise the slopes were this slippery around these parts.

Of course, a logical extension of a machine configuration copying item is, indeed, one that copies a whole factory, but there's no need to go all the way there.

The question of balance is an important one, but having it automatically transfer a filter would not break the game, while it may be appreciated for quality of life.

[ALongStringOfNumbers]

Me too, especially when you forgot to toggle the output side to accept inputs before making it inaccesible with cables, pipes and other machines.

This can be set via the machine grid

[ALongStringOfNumbers]

I am of the opinion that this tool should have several different modes, each copying several different things.

Mode 1: Machine Configuration In this mode, the tool would copy the configuration of the machine, that being if fluid/item output are enabled, the facing the the fluid/item output, the selected overclocking level, and if input is enabled from the output side. These settings would be transferred from the initially selected machine into the target machine. The information would be acquired and transferred in a way similar to the Ender IO conduit probe: Shift + RClick to copy the configuration, RClick to paste the configuration to other machines.

Mode 2: Cover Configuration In this mode, the settings of the covers would be copied. Those settings being:

• If the cover is in import or export mode
• Any special movement modes, such as on the Robot Arm or upcoming Fluid Regulator
• Selected movement amounts
• The Manual I/O information on the bottom
• Filters and their configurations

Due to the differences in some of these elements between covers, the tool should not attempt to apply setting from mismatching covers, eg: Settings copied from a Robot Arm should not attempt to be applied to a Conveyor. There should be a failure message in chat if this happens.

In addition, this mode should make use of the machine grid, as covers can be placed using the machine grid, so it would be annoying to have to physically access the face that the cover is on to copy/paste the settings.

As for Filters, we could split the tool into different tiers, with the higher tier being able to add a filter to the cover, and configure it, if you have a filter in your inventory, and the lower tier simply pasting the contents of the cover, but you have to add the filter manually. For this lower tier of the tool, if it has copied the configuration of a filter with a cover, it should simply skip pasting the filter configuration if a filter is not present.

---

But the logical extension of your request is that the tool could; place the machine add the covers (with any filters) configure the whole thing

This is not logical, as we do not want to add something like this in GTCE. However, if someone wants to make an addon mod that adds a tool that can do this, then they could feel free to try, because not everyone is required to use the addon mod with GTCE.

Adding something that automatically places entire setups already does someone exist, with the mod Effortless Building, players can place many multiblock structures at a time.

The scope of this issue is solely on copying the configuration of covers and machines, not automatically placing machines pre-configured and with covers that are also pre-configured. This is something that most mods do not even offer, and I feel like placing entire machines configured, with covers, also configured, is something that does not need to be included in GTCE.