Control over autocrafting stack size (1.7.10)

[Mordenkainen]

Add the ability to set how many items should be crafted per job for autocrafting.

[SDPhantom]

I would suggest doing away with creating stacks of items at a time. Have recipes calculated to craft a single item at a time and let the crafting CPU do the work it was intended to. Sure it would be slower and take more crafting storage memory, but this was what the AE crafting system was balanced around.

If you want to entertain this idea, you can have your recipes static (ex. one iron ingot would always cost 4 tier 2 EMC crystals) and display EMC crystals the same way a Storage Drawers compacting drawer shows its contents to an AE2 storage bus. Tier 1 crystals would show equal to how much EMC is in the system while the others would have a quantity equal to the same system total EMC integer divided by their EMC value. Also make sure each time a crystal is removed, all their quantities are updated as well.

[Mordenkainen]

Actually, I would say AE was balanced around dealing with whatever the stacksize of a recipe was. (This is esp. true with processing recipes)

"Letting the CPU do the work" means that in a lot of cases, the EMC recipe is far slower than the normal. Take iron bars as an example.

As far as exposing items in that way. It has the potential to screw up the crafting simulation. If item A needs a Tier 4 crystal, and the system says it has it, and item B needs 20 Tier 3 and the system says it has it.... Then when crafting starts and the Tier 4 gets pulled out there are no longer 20 Tier 3 because of it, crafting will stall.

[SDPhantom]

If you create an AE recipe as a pattern, it processes it as a single crafting operation, whatever it usually outputs. For example, if you teach it to create a gold ingot from 4 iron and a philosopher stone, it would run that recipe 64 times to create a stack, this is what I meant by the balance of the mechanic. If you teach it to create iron bars, it'll take 6 iron to create 16, because that's what a normal crafting operation does. I'm just offering a solution closer to what the AE crafting system already does to make it feel like it's a part of the integrated system instead of trying to offload as much of the work as possible.

PS: I know processing patterns operate differently, but that's up to the player to set up the machinery to export, process, and import materials themselves. This is outside the scope of the discussion here.

[SDPhantom]

The suggestion on changing how the EMC crystals are exposed to the system was to help make the processing easier, but if you're comfortable with your current implementation, I won't push it further.

[Mordenkainen]

RE your PS:

At it's core, EqE patterns ARE processing patterns, not crafting patterns. The EMC Assembler is a processing machine that converts EMC into an item. It's not really any different than a pulverizer or a furnace other than not needing a couple of busses to interact with the network and independent power.

The purpose of this "issue" is to give the player the same control over EMC patterns that they have over other processing patterns.

As far as your recommendation on how to expose the crystals, you are quite right that it would be easier. It is in fact, the first thing I tried. Unfortunately, it's also broken in a very fundamental way. It can easily result in the AE network thinking it can make things it can not. The current implementation does have the possibility to fail in a similar way, but never "over advertises" the amount of actual EMC stored, which causes it to fail far less often.

[SDPhantom]

You're saying you want to create a way to let the user configure how many items are made in a stack, when people will expect to be able to tell AE to pull out the exact number of items they want by inputting the number to craft into the ME terminal. It's a simple solution to the problem you're overcomplicating way too much.

[SDPhantom]

Digging through the code, I found I can simulate the PR I just posted by setting emcassembler.maxStackEMC to 0.0. The point is that people expect things to work in a non-frustrating way out of the box. Even in the same playthrough, not everyone is going to have the same EMC capacity. Starting out, EMC is going to be scarce and having some items suck out all of the EMC in the system when they only want a few is going to frustrate a lot of people.

In a server situation, this is compounded by many people, all in different stages of EE/ProjectE.

I would suggest rebalancing the default for emcassembler.craftingTime following this. If you choose to apply the PR, reducing it to around 5 ticks seems reasonable to me. I didn't mess with EqEConfig.java to make these changes. I'm leaving that up to you in case there are dependencies in other files.