Opencomputers: [request] make adapters read assigned crafting requests.

[Tcll]

Since AE2 autocrafting is annoyingly painful and inefficient, but the terminal is godly for issuing requests, I wanted to use the adapter connected to an interface to deal with the request using another system...

The problem is, this setup is only good for making requests from OC, which doesn't resolve anything...

Now I can use a robot with ME, crafting, and possibly database upgrades to do all the magic with the request...
I just need to be able to read the request.

EDIT: btw, I did request a method for AE2 as well...
https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/2359#issuecomment-242727255

[Vexatos]

Doesn't Extra Cells 2 have an upgrade for this?

[Tcll]

The ME upgrade allows robots to access the ME
(I vaguely mentioned this already)

I'm trying to accept autocrafting requests with OC.

[thiakil]

What exactly are you trying to do? Most of AE crafting involves Source Material -> Dest Material

So, you can use an interface to (at worst) a chest attached to a transposer, and have your OC contraption do its 'magic'

[Tcll]

How does OC know the craft being requested, and how many to craft??
(We'll say 5k buffered)

The numbers is what I'm trying to get...
The ME upgrade can do everything else related to transferring items and fluids.

When I enter "5000" into the crafting terminal, I want OC to take that request and craft with what's to be available to craft with.

[thiakil]

Ae supplies the source items, you craft with them. That's how ae2 crafting works, even molecular assemblers.

There is no create something from nothing.

[Tcll]

You must not know a lot about AE2 then... I have my autocrafter currently set up with a bunch of rf tools crafters and the whole system is far faster than anything AE2 could give you alone, and yes, I can make an obnoxious request like 5000 T3 crafters and it'll notify me when it coughs... Otherwise it waits for the items to be available...

The whole system is obnoxiously stupid though and I want to do something more adaptive with instant item I/O (translocators are the fastest I know of, but they're not instant)...

I want to get rid of all that garbage...
If OC can read the count from a crafting request, my AE system will wait for the results...
All of the autocrafting will be handled by OC not AE2

Do note, patterns can craft anything they're set to...
If you want to supply a floppy disk in order to craft 5000 bricks, you can do that.

[thiakil]

You must not know a lot about AE2 then

What makes you think that?

I want to get rid of all that garbage...

So don't use the ae crafting terminal.

If you want to supply a floppy disk in order to craft 5000 bricks, you can do that.

You'd be limited to 64x3, but indeed you can, however you lose the ability to give an exact number to craft. Oc would have the same limitation if it were listening to crafting requests directly.

[Tcll]

How so, when you could get the number requested using a simple function??

And what made me say that is the fact that you're not thinking out of the box...
AE2 has the ability to retrieve the crafting count from it's API, it's just that OC currently makes no use of it, let alone anything related to the request other than progress (and items??).

SO that's what my request is.

EDIT: btw, no you wouldn't be limited to 3 stacks if you used the ME upgrade...
You can simply set the pattern to craft 1 and set your request for 5000
Once the request has been made, the adapter can process the request and retrieve the count and work from there

[bookerthegeek]

So basically what you are wanting is to fully bypass all of the Built In auto crafting for AE and do it in OpenComputers, thereby turning AE2 back into AE1? Something which, by the way, Yueh has denied on every request. Did I get that about right?

[Tcll]

Back into AE1?
I'm sorry but I don't see the comparison...

I mean a cluster of OC crafting robots will certainly perform a lot better and more automated than that cruddy old MAC...
I actually hated that thing...
(AE2 steps it up alot, but it still sucks and is even more resource unfriendly and even less efficient)

But yes, effectively I want to bypass AE2 autocrafting and pass it over to OC.

EDIT:
Btw, yueh denies just about everything requested to improve efficiency...
So he can live in his world while we improve ours.

[payonel]

We've already accepted this as feature-suggested. Please update this thread only if you have constructive and elaborating details. If you are not the OP and you have questions or concerns, feel free to discuss them with us in #oc on espernet, or on the forums https://oc.cil.li/

[payonel]

I think this should be reconsidered in a later release, not a patch release.

The rest here are mostly notes for myself.

<tldr>
Adapters should join me networks. those adapters with a database upgrade should provide all items in the db upgrade (as ghosted item stacks) as craftables to the me network. adapters thus can connect to me cables. oc would see a new component type, me_network. The me_network would publish crafting requests events, and an api to check crafting data.
tldr>

For OC to know about crafting requests, we need to join the AE network. This should be the job of the adapter. OC would then need a way to communicate with the AE network. It can do this today through the bus and controller components, but there would also need to be a general network component available when the adapter connects to the network through just cables. Perhaps named "me_network". Then ItemStacks can be published as craftables. The adapter would be the AE network node, and a ICraftableProvider. The me_network component to oc would produce the craft requests, and in user space we can query the me_network for pending craft requests, and any other method we need for this.

ItemStacks would have to be provided, or registered, as craftables. I think adapters with database components provide a very simple interface to this problem. The user can remove the database item and manually "ghost" in the craftables they would like the OC system to provide. Then place that db back into the adapter, which would then automatically provide them as craftables to the me network. It's convenient, easy to use, makes sense.

The me_network event for a craft request would include the db address that provided the craftable. Maybe the craft request event would be:

"me_craft_request", me_network_component_address, db_component_address, db_slot_index, count

I might make the me_network a single component, regardless of where it is connected, and regardless of how many times we connect to that same network. As an example, it would seem reasonable to thus add two components to the OC network if an adapter is only touching a single me interface, we would see a new me_interface and a single me_network component added to the oc network.

Because the adapter would need to connect to the AE network, this could possible break some current builds where oc adapters are adjacent to AE cables, but currently not connecting (too many connections). Also if we provide the me_network component as I've discussed, we'd see new oc components which in the same manner could cause the oc network to fail (too many components)

Also, there may be adapters today with db upgrades, where it is NOT the intention to provide craftables to the AE network.

Clearly, there are a few things to consider, this makes most sense for a feature for a major version change, and not the current patch

[thiakil]

I agree with most of what you said, but:

Adapters should join me networks

IMO this would be better suited (and alleviate some of the gotchas mentioned) as either a new type of adapter, or a specialised database upgrade. Such a thing would also need to determine whether to occupy an AE2 channel or not.

[payonel]

yeah, i considered that, but i don't like mod specific adapters or items

[thiakil]

hmm what about an api method that configures the DB for 'AE2 crafting mode'?

[payonel]

that's an option too. i considered it too :) haha, honestly, not trying to say i thought of everything, but it's interesting how we're thinking of the same things

I'm not against that idea, wholly, it was just an odd thing for a db to do. In fact, I had a paragraph about this idea at first, but thought it might distract from the train of thought my explanation had. But yeah, I think that is reasonable. I had also thought of just a registerCraftables(db_address[, slot]) or unregisterCraftables(db_address[, slot]) or some variations...the question is who calls this? Sure, it could be db.registerCraftables([slot]) or some such. It was just odd to have an AE-only method on one of our components. Very odd, in my opinion. I want ae methods to be on ae components :)

[thiakil]

Yeah we're just positing options that would fit within the theme & without adding mod specific items/blocks.

[thiakil]

Random idea I had, what about right clicking a Scrench on an AE cable opposite an Adapter triggering an enable-ae mode? (e.g. saved TileEntity flag)