RFC: ME Input bus

[repo-alt]

Your GTNH Discord Username

repolainen#0483

Your Pack Version

GTNH-1.7.10-2.1.2.4-25-pre

Your Proposal

I hear many requests from the top tier players to introduce "ME Input bus", that would get recipe ingredients right from ME system reducing the lag caused by very large input buses. I will describe the feature as I understand it and maybe implement it if time permits and if there will not be some major objections.

1. ME Input bus has an GUI akin to the usual ME interface, with patterns put into it.
2. In may be tiered, in the sense that e.g. ZPM bus has 9 input slots, UV has 18, etc. (should be only one allowed in that case)
3. Or it may have fixed amount of slots, and multiple buses are allowed (each needing a channel)
4. From the AE2 point of view such a bus acts as a crafting provider (interface), so that you request stuff from it
5. When the stuff is requested ME input bus wakes the multiblock, and it does its thing, pushing the results in the network
6. ME Input bus does not even need to pull the ingredients out of the network, it just uses the ingrediens reserved by the Crafting CPU cluster at the order time.
7. Implementing such behaviour may require significant changes in multiblocks, because they all implement checkRecipe in somewhat different ways, so for I'll probably add support to the PA (a bit hard to make that code any worse), and maybe @mitchej123 will consider this use case when implementing new multiblock system.

Your Goal

.

Your Vision

.

Final Checklist

• [X] I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying I like this feature please reconsider adding it will prompt us to investigate and reopen it once we confirm your report.
• [X] I believe there is nothing similar in the pack already, or the existing solution isn't good enough.
• [X] I understand this change request may not attract enough attention and thus not be implemented.
• [X] I understand this change request may be rejected due to other community members thinking it's inappropriate.
• [X] I believe this feature would make the pack better.

[boubou19]

i would say that we should prefer 2 over 3 because less ticking entities the better, it could also be easier to implement, and most importantly, we force players to improve their infra if they want something more powerful, which is interesting.

[Glease]

How is ticking tiles related to 2 vs 3? 🤔

[repo-alt]

The bus is not ticking, why should it. It is like an interface w/o top slots

[boubou19]

then if there is no technical difficulties implementation wise, that's even better. But i still think it's more interesting to make players upgrade their infra than spam ME input buses until the minimum casing amount is reached.

[GTNHAfx237v7]

One of the early ideas of the ME Input bus was that it would provide the items in AE to a multiblock but without the user actually starting a craft. This of course would only make sense if you want the specific item(s) to be process at all times, predominantly ore processing. This was to avoid having to pullyour items out of AE via interfaces and conveyors, as this input bus will do both.

[repo-alt]

This is a different issue, that may be solved by a faster export bus. (Kind of acceleration card that makes the export bus try to export every tick (expensive, yes, but still less expensive than a conveyor doing the same))

[chochem]

You should really talk to @Elisis . There already is ongoing work on a ME input bus based on export instead of interface.

[chochem]

on the ticket itself: I totally understand this comes from technical limitation and probably amount of effort but I am not a big fan of having this for the PA only. That really throws another imbalance in the game to push this multi further which I dont support. PA spam should not be our game design goal imo.

[repo-alt]

You should really talk to @Elisis . There already is ongoing work on a ME input bus based on export instead of interface.

This is RFC, I described the solution as I see it. If someone would implement something making that solution unnecessary, that would be really great.

[repo-alt]

of having this for the PA only.

I don't see a simple way to add support for all multiblock at once. If there is one, this is the place to discuss

[Eranicus]

Maybe start with one of the most important ingame multiblocks, assembler ?

Ofc., if it is even possible to make support for it ...

[repo-alt]

Maybe start with some actual GT5 multiblock?

[boubou19]

PA support would be a good choice as the code is already hacky so a bit more hack isn't going to hurt.

[repo-alt]

Before starting anything I would like to hear from @Elisis what is he actually working on

[Elisis]

This is probably a better solution as I really was only thinking of a larger ME export bus basically

[greesyB]

2. In may be tiered, in the sense that e.g. ZPM bus has 9 input slots, UV has 18, etc. (should be only one allowed in that case)

I would suggest slot scaling be increased. In an extreme example, maxing out a radon MCR takes 257 stacks of items in a single run. Even a more reasonable example like multilayer fiber-reinforced boards would take 72 stacks of items for one MCR run.

It would also be very nice if some stocking mode could be included so passive processes do not need a crafting CPU.

[repo-alt]

This is probably a better solution as I really was only thinking of a larger ME export bus basically

It is not better, it solves a different problem. Anyway, thanks for clearing that, @chochem confused me a bit.

[repo-alt]

2. In may be tiered, in the sense that e.g. ZPM bus has 9 input slots, UV has 18, etc. (should be only one allowed in that case)

I would suggest slot scaling be increased. In an extreme example, maxing out a radon MCR takes 257 stacks of items in a single run. Even a more reasonable example like multilayer fiber-reinforced boards would take 72 stacks of items for one MCR run.

These are not slots for items, these are slots for patterns. (Also item stack size is irrelevan in ME context)

It would also be very nice if some stocking mode could be included so passive processes do not need a crafting CPU.

It should be a different bus, and yes it makes sense. I thought to solve that problem with a faster export bus, but having a kind of input bus with a filter, (from the user point of view - storing all the filtered items in the network ), would probably lag less, although a bit harder to implement. (E.g. it would require GT multiblocks to expect huge item stack sizes)

In general, ME interface is very overloaded, and in 1.18 it was split in 2 blocks: an interface and a pattern provider. The latter doing the crafting. Personally I'd split it even further making interface to give access to one network from another and making item (fluid/gas/any channel) provider a different block/part. Anyway, unfortunately this change cannot be backported, because it would break every single world.

[joshaup1999]

I mean, whats one more thing to break everyones world kek

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 3 days