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.

In general, your base will have a main AE2 network doing most of the automation management; this is where you will setup your autocrafting, and most of your storage will be accessible to this AE2 network.

To set up automations for most things in the pack, your main AE2 network will have to provide resources to automations, and have some way to access what is being produced by these automations.

In terms of providing resources to external setups, these are the various options available:

• Export interfaces [recommended, almost always the best option] (see Resource Transfer section on how to move resources between machines)
• Proper looped subnet interaction [recommended] (see Subnetting section)
• Interfaces stocking slots [useful sometimes] (see Resource Transfer section on how to move resources between machines)
• Export buses [discouraged, generally laggy]

In terms of accessing the products of a given automation, these are the various options available:

• Storage bus on external storage [recommended] (see Resource Storage section for good options)
• Proper looped subnet interaction [recommended] (see Subnetting section)
• Storage bus on external Export Interface [recommended] (see Subnetting section)
• Import interface directly in main AE2 network [discouraged, makes for a base that is hard to manage]
• Import bus directly in main AE2 network [discouraged, laggy, makes for a base that is hard to manage]

In a 'perfectly optimized' world, your AE2 network would expose automation resources solely using export interfaces and proper looped subnet interactions, and it would access automation results using storage buses and proper looped subnet interactions.

In reality, there are cases where all the other available tools will be quite useful, but if you find yourself handling everything using Export Buses and Import Buses, maybe it is time to start looking into Export Interfaces and Import Interfaces.

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, never attach to your main AE2 network, 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 (see Subnetting section for ways to make this subnet interact with your main network efficiently), 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.

For 'random' items and fluids that are not automated passively, using unpartitioned cells in yout main AE2 network is more than enough.

As a rule of thumb, if you are doing big autocrafting requests, you want lots of spare cells to ensure that there will be enough space for all intermediate items, otherwise they may be deleted. This will not be relevant unless you explicitly decide to play by autocrafting as many things as possible, and for some endgame cases.

No matter the tools you use in your automation, the recommended way is to send your final products (and byproducts if any exist) into some type of storage, where a storage bus from your main AE2 network can be placed (or where you can set up a proper subnet connection).

To store items and fluids coming from passive automation, these are the available options:

• Subnet with partitioned Cells inside ME Drives, with a proper looped subnet interaction [best and recommended] (see Subnetting section)
• Subnet with partitioned Cells inside ME Drives, with an export interface, and a storage bus from main [recommended for large subnets handling over 63 items] (see Subnetting section)
• A drawer wall with a storage bus from main [medium performance, better if less than 25 drawers are involved]
• Output Buses and Hatches of Modular Machinery Multiblocks, with a storage bus from main [more performant than a drawer wall, but in many cases you may want to store more than a hatch worth of capacity]
• A dank with a storage bus from main [a bit less performant than a large drawer wall]
• Chests / crates / shulker boxes [in almost all cases please don't, but it may come in handy to buffer NBT items like Celestial Crystals depending on your automation method]

To store energy, you always want to use the largest possible storage method you can afford at your progression stage (a Draconic Energy Orb), and you want to treat it as your sole centralized battery.

All energy coming from generators should be routed inside this centralized battery.

All energy required for machines should come from this centralized battery.

To handle the input and output to and from your centralized batter, two separate Flux Networks are strongly recommended. (see Resource Transfer section for more detail on efficient machine and generator connections)

Regardless of the method you use, a general rule of thumb is that moving large batches of resources infrequently is better for TPS than moving small batches of resources frequently. This is particularly relevant for XNet, SFM, and Export/Import Interfaces.

I.E. Moving 4 stacks of coal every 4 seconds is better than moving 1 stack of coal every second.

For your passive automation contraptions (and for some autocrafting setups too), these are the available options that transfer items:

• Super Factory Manager [great performance, great speed]
• XNet [great performance, great speed]
• Modular Routers [great performance, ok speed]
• Import and Export Interface with Push and Pull Cards [great performance, great speed]
• Conduits [good performance, terrible if bundled with other conduits, ok speed]
• Actually Additions Item Lasers [good performance, good speed]
• Thermal Expansion Auto-Push and Auto-Pull [good performance, but even conduits perform better, good speed]
• Itemducts [ok performance, terrible if more than 3 machines are connected, good speed]
• EnderIO Auto-Push and Auto-Pull [ok performance, ok speed]
• Integrated Dynamics [ok performance, terrible if refresh rate is high, great speed]
• Nuclearcraft Auto-Push [bad performance, good speed]
• Tech Reborn Auto-push and Auto-Pull [bad performance, good speed]
• Buildcraft pipes [bad performance, bad speed]
• Tesslocators [terrible performance, great speed]

Regardless of the method you use, a general rule of thumb is that moving large batches of resources infrequently is better for TPS than moving small batches of resources frequently. This is particularly relevant for XNet, SFM, and Export/Import Interfaces.

I.E. Moving 4 buckets of lave every 4 seconds is better than moving 1 bucket of lava every second.

For your passive automation contraptions (and for some autocrafting setups too), these are the available options that transfer fluids:

• Super Factory Manager [great performance, great speed]
• XNet [great performance, great speed]
• Import and Export Interface with Push and Pull Cards [great performance, great speed]
• Actually Additions Fluid Lasers [good performance, great speed]
• Conduits [good performance, terrible if bundled with other conduits, ok speed]
• Thermal Expansion Auto-Push and Auto-Pull [good performance, but even conduits perform better, good speed]
• EnderIO Auto-Push and Auto-Pull [ok performance, ok speed]
• Integrated Dynamics [ok performance, terrible if refresh rate is high, great speed]
• Fluiducts [bad performance, good speed]
• Nuclearcraft Auto-Push [bad performance, good speed]
• Tech Reborn Auto-push and Auto-Pull [bad performance, good speed]
• Buildcraft pipes [bad performance, bad speed]
• Tesslocators [terrible performance, great speed]

For all energy transfer that goes through your centralized battery, two separate Flux Networks are the most effective way to handle things.

One Flux Network sends all power from the generators to the centralized battery. The other Flux Network sends all power from the centralized battery to all machines.

All of your energy generators should feed their power (directly or indirectly) to your centralized storage through Flux Plugs. In general you should limit the number of Plugs you use, so if you have multiple generators in teh same area, wire them together before connecting a Plug. Just make sure whatever intermediate cabling you use can keep up with your production.

When it comes to powering machines and logistics, you also should try to limit the number of flux points you use. A general rule of thumb would be to use a Plux Point every 50 machines. Depending on your progression stage, this may be hard, but it should be relatively easy to achieve the futher you progress.

To transfer energy between a Flux Point and your machines (or between your generators and a Flux Plug), these are the available options:

• Draconic evolution Transcreivers and Relays [great performance, very easy to use, transfer rate may be too small in some cases]
• Cryo-Stabilized Fluxducts [great performance, great transfer rate]
• Energy Conduits [good performance, terrible if bundled with other conduits, later tiers have great transfer rates]
• Xnet [good for performance, but in most cases you do not want to 'waste' a channel on energy transfer]
• Other Fluxducts [OK for performance]
• Actually Additions Lasers [OK for performance]

This section lists general practices with regards to automated processing steps, including anything that is broadly referred as a 'machine'.

These are probably the simplest machines to talk about. For many cases, recipes are exclusive to specific machines; for those, the decision has been made for you :)

For cases where a recipe has both a single-block version, and a Modular Machinery multiblock version, the modular machinery version is always more performant. In these cases, the multiblock version will also be faster (and sometimes cheaper), so once you unlock a fast multiblock, it will also improve your performance.

For cases where you can choose between multiple mods' machines for the same type of crafting mechanic, you can refer to the following:

• Nuclearcraft [great performance, great speed]
• Thermal Expansion [great performance, good speed]
• EnderIO [great performance, ok speed]
• Tech Reborn [bad performance, great speed]

This a very easy section, because most recipes involving multiblocks are exclusive to a single multiblock.

Modular Machinery Community Edition is extremely well-performant.

For autocrafting, molecular assemblers and LazyAe2 are quite well performant on their own.

To passively automate crafting recipes, or to autocraft recursive recipes, here are the options:

• AE2 Crafter on a subnet [great performance, good to great speed depending on upgrades]
• RFTools Crafter [good performance, great speed]
• Sequential Fabricator [good performance, great speed]

There are a few ways to passively automate extended crafting, listed here:

• Packaging provider level maintainer subnet [best performance, good speed, only available for late game]
• Packager/unpackager level maintainer subnet [good performance, good speed]
• Packager/unpackager combined with item stransfer [good performance, high speed if you are using a high speed option like SFM]
• Automation Interface using Import and Export interfaces [good performance, very slow]

In-world crafting refers to mechanics that involve doing things in the Minecraft world, like placing blocks, dropping items, clicking things, etc.

As a rule of thumb, you want some sort of throttling to your in-world setups, see Passive mechine Throttling section for tips on the available options.

Here are the options for automated clicking (left or right):

• Mechanical User [great performance, single block]
• Mechanical User with Ender Porcupine [great performance, multiple blocks, slow]
• Integrated Dynamics [good performance, can get bad if bad practices are used]

Here are the options for block placements:

• Mechanical User [great performance, single block]
• Mechanical User with Ender Porcupine [great performance, multiple blocks, slow]
• Actually Additions Block Placer [great performance, single block]
• Phantom Placer [good performance, single block]
• RFTools Builder with shape card [ok performance, very fast for multiple blocks]

Here are the options for fluid placements:

• Actually Additions Fluid Placer [great performance, single block]
• Mechanical User with bucket [good performance, single block, requires extra logistics]
• Mechanical User with Ender Porcupine [good performance, multiple blocks, slow, requires extra logistics]

Here are the options for breaking blocks:

• Block breaker
• RFTools Builder with quarry card [ok performance, very fast for multiple blocks]

For the sake of this section of the document, refer to these definitions. In reality, your bases will always be a mix of both, so these definitions are intenttionally 'extreme' to show the two ends of the spectrum.

• Centralized Automation: everything that you automate goes through your main AE2 network, which is used to route all automations to all other automations. Example:

1. All EMC ingots are handled by a single EMC Link with a Storage Bus;
2. The relevant ingots are pulled from the AE2 network (using conduits, xNet, etc.) into Alloy Furnaces to make alloys, which are sent to storage (drawers, danks, etc) that is accessible to the main AE2 net;
3. The relvant alloys and ingots are pulled from the AE2 network (using conduits, xNet, etc.) into Compactors to make plates, which are sent to storage (drawers, danks, etc) that is accessible to the main AE2 net;

• Decentralized Automation: only the final products of your automations go through your main AE2 network; if an item is an intermediate product, it is not sent to your main AE2 network. Example:

1. All EMC ingots are handled by a single EMC Link with a Storage Bus;
2. The relavant ingots are pulled from a second separate EMC Link (using conduits, xNet, etc.) into a first set of Alloy Furnaces to make alloys, which are sent to storage (drawers, danks, etc) that is accessible to the main AE2 net;
3. The relevant ingots are pulled from a third separate EMC Link (using conduits, xNet, etc.) into a second set of Alloy Furnaces to make alloys, which are then pulled (using conduits, xNet, etc.) into Compactors to make plates, which are sent to storage (drawers, danks, etc) that is accessible to the main AE2 net;

In the 'Centralized' example, you use one machine for each automated step, and you use lots of AE2 connections to both take items in and out of your AE2 network. In the 'Decentralized' example, you will build multiple machines to do the same thing, but you use less AE2 connections.

With regards to the TPS impact of AE2, routing the same item type to and from multiple locations is less performant as opposed to routing the same item type from a single location.

Because of this, if you find that an item you are storing into AE2 gets used in lots of different automations (E.G. Steel Plates are going into over 50 passive setups, including Steel SHeetmetal, and Reinforced Blast Bricks), it may be a good idea to build multiple decentralized supplies of said item for these automations (E.G. the Reinforced Blast Bricks automation gets its own Steel Plate maker, and so does the Steel Sheetmetal automation).

The most extreme version of this decentralization involves a base where every new item is automated starting from basic resource generation (EMC, bees, chickens, etc.). This approach has some benefits with regards to managing bottlenecks, and it can be quite useful in some cases, but doing it for everything will lead to other issues.