Hello, i have an idear for AE2 or AE3 can you add a Block there you can connect 2 Me systems i know with storage bus and Interface but this is only Storage and i mean that you can make many little Me systems and than connect it to one big

For what purpose? It sounds like you are asking for Sub-nets, which are usually the Interface <-> Storage Bus situation you are already aware of.

The only thing I think Sub-nets can't do that "a second full sized ME system" might would be transferring auto-crafting instructions between ME systems; at which point you really only have 1 system anyway. While being able to sub-net request based auto-crafting would be awesome, it would completely break the channel system.

I don't think anyone would build multiple main networks that are to big to be connected to one via cables. I also do not see how this could be balanced against the limited channel feature.

My problem is that so bigger the system so slower it is

That's bullshit, why should that be the case? If something makes it slower, it is the configuration of your MC instance or the power of your computer.
EDIT: Also, two networks connected via this block (if it has all the features you want) would still be one internally.

@VT-14 I know that this is not exactly what you meant with autocrafting in subnets but if you attach two multipart interfaces with the outer faces to each other and put patterns into the interface connected to the main network, the subnet can do multiple crafting steps with the use of only one pattern.

@XFactHD Sry but i have an me System in Ftb infinty evolved and the system has more than 512 changles an crafting is slower than an me system with 64 changles. Can you explain or you know a video about you second part you write

First of all, FTB Infinity is known to be really heavy on performance. Therefore it would be great if you could try to reproduce this in a NEW minecraft instance with ONLY Forge and AE2 installed.

This crafting setup is something I came with myself. The trick is that the interface connected to the main network has crafting patterns in it and puts the items specified by the pattern into the interface connected to the subnet. The items get on a storage cell in a drive or me chest and are then exported to the various machines/assemblers. After all steps are done, the end product is exported back into the main network. All export buses have to be filtered. The only limitation is that the hole chain of recipes can only have up to nine ingredients.

You can speed up auto-crafting by putting Acceleration Cards in your Molecular Assemblers, and/or run several in parallel [5 Molecular Assemblers around a full block ME Interface, and/or distributing related recipes to separate ME Interfaces].

Yes, a large system takes more computer resources to run than a small system, thus it acts slower. It is easier to see on packs that are somewhat laggy due to having a TON going, like FTB Infinity Evolved.

i half-way support the idea, but not the way it is explained
subnets are indeed the main solution described for the problem, but he is also right that you have issues with large networks, as they need a lot of maintenance and planning

one question that boggles me and i hope @yueh can shed some light on it:
why can't the StorageBus-Interface Combo extend the recipe requests to the subnets?
i mean i understand that the existing code and API only dives into the "primitive" Storage of the presented ME Interface, but with an Crafting Card inserted, couldn't there be an extension to send crafting requests into the subnetwork?

I also write this in connection with this other issue, where someone put stuff into an ME Chest connected to an ME Interface with a configured output of a certain item, but the storage bus does not recognize the ME Interface as Chest because of the special connection, instead it only shows the content of the disc but not the items in the slots of the Interface

as an alternative idea, when you have an (sub)net and drop a crafting card into the interface + preconfiguring an item, it will craft this item inside the subnet until the slot is full ... when i now connect a storage bus to the interface to make it an actual subnet, pull back all items from the slots into the network and extend the crafting recipe to the main net, so when i request something that need 200 pieces of a certain item that is configured in the interface it will not tell you there are only 64 items here, it will calculate how much items it can craft instead

i smell evil request loops in this idea but you all did great work on preventing them in the past :)

well for the first part you are right, as i stated in my own post, there is a major flaw

but for the handling AND multiprocessing you are thinking a little bit to downscaled
or i am misunderstanding you

having the crafting of subcomponents in their respective subnetworks is the same thing as when there are multiple people doing crafting steps in their own respective stand alone networks at the same time dropping the resulting items into a collective storage where the final crafting of the final products is done

and doing this for real does not result in any critical load on my server so far (7 independent AE networks crafting large queues at the same time)
so even in a single player with a massiv network of the same combined size should not cause any more additional load

the only information that has to be shared is at the beginning with the crafting structure, the evaluation of the needed items and the signal to pull the items into the crafting CPUs, whenever a subnetwork is done, it pushes the item to the requesting network (same operation as if the interface has a setup to stock items and a crafting card) and the requesting network then reroutes the item to the CPU doing the more complex stuff instead of dropping it onto a storage (same operation as if a crafting is done via "external recipe" through a furnace for example except you normally use an import bus for that)

a crafting CPU waiting for items further down the production queue can only start a new crafting process one tick after it received the items for at least a whole step

If the Storage Bus <-> ME Interface connection could transfer crafting requests, then channels lose all meaning and the ME Controller, ME P2P tunnels, Dense Cable, and maybe some other things can be completely ignored. In that case, using an ME Controller or similar would be a sign that you don't know how to use AE2/3.

You make a system that has a Storage Bus on one end and an ME Interface on the other. You have 6 channels left on this sub-net to do useful stuff, like attach terminals, drives, buses, auto-crafting, etc. You then make as many of these 6 channel sub-nets as you need, and then have the whole thing loop around to connect back to the first one, forming a ring of sub-nets. Every sub-net in this ring can already see the inventory of all of the others and provide fairly advanced item transfer capabilities and infinite storage.

What a sub-net ring can't do is a good amount of auto-crafting. That requires an ME Interface, the crafting computer part, and an terminal/crafting card to request from all on the same sub-net; which limits you to only having up to 4 crafting ME interfaces for a 'request from terminal' crafting system. If these common sub-net junctions could transfer crafting requests, then you can spread out as many interfaces and crafting computers as you want anywhere on this infinite ring of sub-nets. Using only sub-nets and basic 8-channel ME cables, you can make a fully functional and massive ME system that can store and use an infinite number of recipes.

When you take some time and think about how ae2 works, you will clearly get, why subnet crafting was not developt.
for me this subnet thing is more like a cascade and the crafting is a core thing.
so now all of you might get it why crafting is no cascade thing in ae2.
the work needed to make it possible (cascade crafting) is more than the benefit at the end and only to develop ae2 in a way which the programmer didn't see it going.

@HadesDurin i understand what you say, but this issue is made as an idea of improvement, the way i described (besides the side effects that i am not certain of) seems not too much to eat up the efforts

it would need to use existing interfaces to be reused through the interface and it could probably enhance clustering and reduce the effect of lag spikes during crafting by splitting the work in different smaller sized networks with independent resources ...
as far as i have understand some speed issues it is often the case that heavily recursive structured networks need a lot of time to update and calculate their storage, reducing this effort to smaller packages with independent crafting resources could optimize this IMHO

PS: oh god i see a terrible flaw in my idea ... 2 subnets accessing the same storage subnet telling wrong information on craftable items while requesting the same resource

you miss a few points that weight heavy.

• putting storage and crafting and what ever else into seperat subnets for each, will make it needable to get some sort of security running to not double use the same resources. security has to be established for all subnets to prevent the above case.
• having subnets makes life easier, but you need some sort of information travel from subnet a to subnet b. realising that will break the way ae2 works right now entierly. let me explain that, now you have one computer core in your ae2 network with multiple cascades for auto process stuff. you want to have multiple cores doing multiple tasks including crafting, storing and what not. that leads into server structures and managing all the stuff over multiple instances. Imagine resources subnet a, crafting subnet b, resources subnet c, d, e another crafting subnet f, g, h and so on. (belive me someone will realise things like that if they are possible)
• background prosesses, as described above you will have some really heavy stuff to handle and take care of in the background each tick on a server/client. sometimes 25ms is a long time, but doing all the above things during that time is close to imposible right now. now you think why only half a tick, well the informations need to be shared between server and all clients and that also needs time and you need some time to secure the above mentioned things so its less time than 25ms.