The objective of this document is to provide a list of tips and tricks to help you optimize the performance of your Meatballcraft base.

None of the suggestions here should be taken as an 'automation bible' or as 'the best possible way' to do something. For most people that play Meatballcraft, the level of performance optimization explained here will not be necessary.

Most of the effects listed here become relevant only after bases become massive, with hundreds or thousands of running machines. If this description matches your base, you may want to read this.

If you are an early game player, some of the info here can still be useful, and it may save you some time to rebuild or reconfigure an automation line if/when you progress far into the pack.

Ticks per second (TPS) is the number that determines how fast your Minecraft world is running.

Most functions in the game that control what happens in your world depend on how often the game ticks.

At its normal state, Minecraft runs in 20 TPS, with 50 milliseconds per tick (MSPT).

If something in-game takes a lot of effort for the code to do, that task may take longer than 50 milliseconds. If that happens, a tick is delayed, and your game runs slower. This will lead to lag, in the form of delays when opening machines, moving items, and doing recipes.

The command /spark profiler start --timeout <seconds> will let you know the state of your TPS and MSPT. If TPS is less than 20, and if MSPT is more than 50, you are lagging.

Just a bit of lag may be ok in some situations, but it will make gameplay less fun.

When a machine (or an altar, or a multiblock) is doing something (crafting, making energy) it takes more MSPT than it would if it was just sitting there.

Because of this, a good rule of thumb is to not run machines for things you do not need.

If you have a machine running passively, it is good to make it stop after a certain amount of product has been made.

For most single-block machines, and most multiblocks, they will stop working if their outputs are full, so those are easy. Pushing into a Drawer, or using the Import Interface on a partitioned subnet are good ways to do it (more info in resource storage section). In these cases, it is a good idea to keep your buffers small; if you do not need to store a billion Stellar Alloy, do not store a billion Stellar Alloy.

In some cases, though, you may need some sort of redstone or logic system to prevent a crafting mechanic from running continuously. The Thaumatorium and the Elven Gateway are examples of setups that may need something like this.

For these systems, there are a variety of tools, listed here:

• XNet logic channels [good and recommended]
• Super Factory Manager logic [good and recommended]
• ProjectRed red alloy wire and logic gates [good and recommended]
• Level Emitters [medium, use only on subnets, still recommended]
• EnderIO redstone conduits [medium]
• Structureducts and redstone relays [medium]
• RFTools redstone blocks [medium]
• Vanilla redstone [Projected is better, but sometimes it comes in handy]

If you are requesting recipes using AE2, the machines involved will only run if AE2 sends items to them.

If you have a large nested recipe going through the same machine or the same Molecular Assembler, it will be running longer. If this happens to lots of machines, you will start lagging after requesting large recipes.

In general, the Meatballcraft gameplay loop favors passive setups over large autocrafts, but if you are running a large autocraft, it is a good idea to split recipes between multiple machines, so that each one runs for a shorter amount of time.

In many automations, it may be useful, or even encouraged, to use the Better Level Maintainer to automatically request recipe in a subnet, effectively making it act as a passive setup. This may be the case for PackagedAuto automation, and if you want to run multiple recipes on the same machine.

For these cases, it is generally preferable to request large batches of items in infrequent intervals.

I.E. Requesting 10 Fusion Coils every 1 second is worse for TPS than requesting 100 Fusion Coils every 10 seconds.

In many cases, making a truly passive setup using XNet or Super Factory Manager (more info on Resource Transfer section) will be better for TPS when compared to a Lavel Maintainer subnet, but in many cases Level Maintainers will help reduce machine count.

Neither option is objectively better in all cases, and it is good to use both, but a well-performing base has more passive setups than Level Maintainers.

If you find yourself automating everything using Level Maintainers, it will probably become too much for your game to handle, while passive setups scale a better in terms of performnce.