Good Practices With AE: Difference between revisions

From GT New Horizons
Content added Content deleted
m (Added a bullet point about storage drawers)
mNo edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Guides]][[Category:Applied Energistics 2]]



Here are some good practices to respect when building your AE network:
Here are some good practices to respect when building your AE network:
Line 5: Line 5:
* Always put the highest multiple of a recipe if you can, as it reduces queries for AE. Example: you want to automate the craft of 1 iron dust from 1 iron ingot. Automating it like that will make 64 queries if you want a stack of it. Automating 64 iron dusts from 64 iron ingots will only make 1 query if you want a stack of it.
* Always put the highest multiple of a recipe if you can, as it reduces queries for AE. Example: you want to automate the craft of 1 iron dust from 1 iron ingot. Automating it like that will make 64 queries if you want a stack of it. Automating 64 iron dusts from 64 iron ingots will only make 1 query if you want a stack of it.
* Always prefer recipes without reusable items if you can: it impacts server tps because it needs to calculate if it can reuse the items after each query. Example: you should aim for the assembler recipe of the machine casing instead of the crafting grid recipe.
* Always prefer recipes without reusable items if you can: it impacts server tps because it needs to calculate if it can reuse the items after each query. Example: you should aim for the assembler recipe of the machine casing instead of the crafting grid recipe.
* If you can, avoid using subnetworks for storage: This is a good way to trigger a lot of updates at once if you do it. (Famous example of a laggy storage subnetwork is the Super Soaryn Drive)
* Avoid using recursive subnetworks for storage: This is a good way to trigger a lot of updates at once if you do it. (Famous example of a laggy storage subnetwork is the Super Soaryn Drive.) However, storage subnetworks can improve tps by reducing the number of IO operations on the main net if used properly.
* If you want to use crafting cards in export busses or interfaces, reduce the queries as much as you can: Use the 1st point of this list and if it's still spamming the queries, consider making the needed items outside of AE and import them in AE once they are done
* If you want to use crafting cards in export busses or interfaces or in general if you want to perform some form of stock keeping, reduce the queries as much as you can: Use the 1st point of this list and if it's still spamming the queries, consider making the needed items outside of AE and import them in AE once they are done.
* Always make subnetworks when you'll do something that will cause a big I/O to your item and/or fluids. This way you contain the update to the subnetwork, and lookups for item/fluids are instant. For instance ores and intermediate items from ore treatment don't need to go in the main network, you should only send the end items to the main network.
* You should prefer using AE drives instead of the chests + storage busses combo: the hashes of the items are precalculated in the AE storage cells. It does not make any noticeable difference for items without NBT, but will make a difference for items with NBT
* You should prefer using AE drives instead of the chests + storage busses combo: the hashes of the items are precalculated in the AE storage cells. It does not make any noticeable difference for items without [[NBT]], but will make a difference for items with NBT. The only exception is storage bus on super/quantum chests, as they have a special behavior if set up like this.
* Always prefer teleporting the AE network instead of pulling long cables.
* Always prefer teleporting the AE network instead of pulling long cables.
* If you don't need interdim teleportation of your AE network, prefer using the wireless connectors, they are less laggy. (Warning: they consume more energy than the quantum ring, viable once you obtained a neutronium energy cell)
* If you don't need interdim teleportation of your AE network, prefer using the wireless connectors, they are less laggy. (Warning: they consume more energy than the quantum ring, viable once you obtained a neutronium energy cell or if you have a good power generation)
* If you need to teleport more than 32 channels to a destination, use a subnetwork with P2P, and then teleport the subnetwork
* If you need to teleport more than 32 channels to a destination, use a subnetwork with P2P, and then teleport the subnetwork
* Don't put storage buses on drawer controllers, because it'll lag the server, especially if you have big cuboid drawer storage, because the drawer controller will have to scan the cuboid drawer storage each time there is an item I/O done by AE on it.
* If you want to use ExtraCells' fluid input/output busses, don't use acceleration cards, that makes it laggy as hell.
*Defragment your storage! A very fragmented storage with thousands of item types can cause lag spikes when the ME system must find an object through all the internal storage (item export, recipe crafting simulation, etc)
* The time of your 1st opening of your AE storage is proportional to the amount of itemstacks and NBT you have inside of it. To reduce it, get rid of the item types with low amount and with heavy NBT.
*Don't chain power your networks with quartz fiber, power usage of accross all the networks will cause network updates back and forth between them. All your networks should have their own way of being powered, ideally neutronium cells if you unlocked them in your progression.
* In the 2.1.0.0 version of the pack, if you use an ore dictionary export bus and the wildcard (*) in your expression, make sure to avoid multiple oredict prefixes matching your expression, it generates a lot of lag. For example, "ore*" is matching the following list:
*Don't pattern byproducts.
** "ore*"
** "oreCrushed*"
** "oreCrushedPurified*"
** "oreCrushedCentrifuged*"
** "oreAny*"
** "oreNetherrack*"
** "oreNetherrackAny*"
** "oreEndstone*"
** "oreEndstoneAny*"
** "oreBlackGranite*"
** "oreBlackGraniteAny*"
** "oreRedGranite*"
** "oreRedGraniteAny*"
** "oreMarble*"
** "oreMarbleAny*"
** "oreBasalt*"
** "oreBasaltAny*"
* Don't put storage buses in drawer controllers, because it'll lag the server, especially if you have big cuboid drawer storage, because the drawer controller will have to scan the cuboid drawer storage each time there is an item I/O done by AE on it.

Latest revision as of 15:41, 25 March 2024


Here are some good practices to respect when building your AE network:

  • Always put the highest multiple of a recipe if you can, as it reduces queries for AE. Example: you want to automate the craft of 1 iron dust from 1 iron ingot. Automating it like that will make 64 queries if you want a stack of it. Automating 64 iron dusts from 64 iron ingots will only make 1 query if you want a stack of it.
  • Always prefer recipes without reusable items if you can: it impacts server tps because it needs to calculate if it can reuse the items after each query. Example: you should aim for the assembler recipe of the machine casing instead of the crafting grid recipe.
  • Avoid using recursive subnetworks for storage: This is a good way to trigger a lot of updates at once if you do it. (Famous example of a laggy storage subnetwork is the Super Soaryn Drive.) However, storage subnetworks can improve tps by reducing the number of IO operations on the main net if used properly.
  • If you want to use crafting cards in export busses or interfaces or in general if you want to perform some form of stock keeping, reduce the queries as much as you can: Use the 1st point of this list and if it's still spamming the queries, consider making the needed items outside of AE and import them in AE once they are done.
  • Always make subnetworks when you'll do something that will cause a big I/O to your item and/or fluids. This way you contain the update to the subnetwork, and lookups for item/fluids are instant. For instance ores and intermediate items from ore treatment don't need to go in the main network, you should only send the end items to the main network.
  • You should prefer using AE drives instead of the chests + storage busses combo: the hashes of the items are precalculated in the AE storage cells. It does not make any noticeable difference for items without NBT, but will make a difference for items with NBT. The only exception is storage bus on super/quantum chests, as they have a special behavior if set up like this.
  • Always prefer teleporting the AE network instead of pulling long cables.
  • If you don't need interdim teleportation of your AE network, prefer using the wireless connectors, they are less laggy. (Warning: they consume more energy than the quantum ring, viable once you obtained a neutronium energy cell or if you have a good power generation)
  • If you need to teleport more than 32 channels to a destination, use a subnetwork with P2P, and then teleport the subnetwork
  • Don't put storage buses on drawer controllers, because it'll lag the server, especially if you have big cuboid drawer storage, because the drawer controller will have to scan the cuboid drawer storage each time there is an item I/O done by AE on it.
  • Defragment your storage! A very fragmented storage with thousands of item types can cause lag spikes when the ME system must find an object through all the internal storage (item export, recipe crafting simulation, etc)
  • Don't chain power your networks with quartz fiber, power usage of accross all the networks will cause network updates back and forth between them. All your networks should have their own way of being powered, ideally neutronium cells if you unlocked them in your progression.
  • Don't pattern byproducts.