Hi to devs,
I decided to add a new conduit to the mod, but, being a novice in modding, i don't quite know what are the required steps.
Here's reddit post showing what i already did

I would like to ask you for help (as described in post).
Thanks in advance.

Related to #3872. Any update on that RS API?

Yes, RS API is available...in 1.11

@FancyBanana If you're interested in a way to implement the RS conduit, I had a commit almost fully ready for that feature: Volune/EnderIO@a614724

It's somehow based on the RS API, but the integration in RS 1.10 was discussed and declined there: refinedmods/refinedstorage#703

I have no idea if I'll have time to follow that feature, so feel free to reuse my work when EnderIO hits 1.11.

oh, you already have to code running on the capability api. nice!

I missed the 'denied' discussion as well... The last I remember seeing was a note saying to PR something like this in. As a result, I also have a functional branch adding RS conduit support here: SelfEatingWatermelon/EnderIO/tree/add-refinedstorage-conduits.

My branch is based on the latest 1.10 branch of EnderIO (3.1.173) and the latest 1.10 version of RS (1.2.23). Feel free to use any of mine as well. It doesn't require any refactoring of RS and uses their latest 1.2.23 API directly from their Maven. I've seen the API overhaul that's going on in the RS 1.11 branch, and I can understand if they intend to backport it to 1.10 that this work would be pointless. From what you said their 1.10 branch is in bugfix-only mode though, so given that scenario I'm wondering what the problem would be of having the 1.10 version of RS integrate with the 1.10 version of EIO. (beyond of course that upgrading any world to 1.11 versions would cause major problems) The only risk I see is if they backport to 1.10, which could be mitigated by locking down support to an exact RS version.

As an aside, I'm afraid 1.10 is shaping up as the new 1.7.10... When I'm putting together packs, there's just so much that is unavailable in 1.11. Waiting for 1.11 is a nice thought, but I will really miss these conduits in 1.10 which is what the majority of mainstreamers use right now if they're not still on 1.7.10.

Thanks for all the work @HenryLoenwind! EnderIO is my go-to mod for every pack I make. I hope nothing above came off as snarky, it was not meant to be. It's clear that integrations are a big balancing act and EnderIO is no small piece of code to coordinate.

@HenryLoenwind, as a follow-up I just had a conversation with Raoul from RS. He confirmed that the 1.10 API in RS 1.2.23 should be stable and won't be backported from the 1.11-based 1.4.x branch. He mentioned that part of the potential problem was a naming conflict with INetworkNode and AbstractConduit (the getNetwork method) but as you can see in my branch when implemented like the OC/AE2 conduits are by having IConduitBundle extend INetworkNode there is no conflict.

I may be completely wrong here, but unless you are moving to a system where a single branch/jar supports both 1.10 and 1.11, there shouldn't be any problem with adding the 1.10 RS conduits to the 1.10 EnderIO 3.1 branch and keeping all the 1.11 stuff for the future.

Again, I'm happy to do what I can to help move this forward, and can submit a PR unless this is just a completely dead issue. I'd just hate to see 1.10 miss out on some sweet integration.

I'd actually prefer it if you could make them an addon mod. Then I don't have to worry about maintaining it. With my latest changes to the conduits it should be possible to do them that way, e.i. you don't need to edit any existing files. Feel free to contact me on irc if you need assistance or run into unsolvable problems.

If you need a template for an addon mod, have a look at the 1.10.2 version of me Travel Huts mod. It already has nearly all parts you need (config system, dependency on Ender IO, ...). You'd only need to add the runtime dependency in the @mod annotation. Licence is CC0, so you can copy freely.

I will take a look at that right now... I didn't think I'd be able to add a conduit type via an add-on, but if I can I most certainly will. Thanks for the idea!

Actually, now that you mention it, have you guys ever thought about separating out the conduit stuff into it's own standalone mod?

@HenryLoenwind I've been trying to implement a new conduit type via an add-on mod, but if it is possible, I don't believe it will be easy. In addition to having to replicate a large portion of the render pipeline to support local textures, there is no good way of extending BlockConduitBundle to support an extended TileConduitBundle where the functionality for the new conduit type is kept. The resulting mod would also be so tightly tied to EIO that there would be near constant breakage.

Any other ideas?

oh right, this is one of the APIs that uses interfaces on the TileEntity. Didn't think about that. So putting this one in an addon is out of the question. Oops.

But as you had a good look, I'd love your feedback; e.g. what's the issue with the textures?

The problem with the textures is that resource locations are set at various places in the render chain to EnderIO.DOMAIN so you'd have to basically cherry pick and extend a bunch of those classes to point the resource locations to the add-on pack. In the end, you wind up re-creating a big chunk of the render code and any underlying change potentially breaks the add-on.

As for the rest of it, I tried extending TileConduitBundle/BlockConduitBundle but the constructor for the BlockConduitBundle forces the tile entity type to TileConduitBundle and since the name/teClass in BlockEIO are final there's no changing them after the constructor is run and no constructor in BlockConduitBundle that lets you call super() with arguments.

I know it would be a pretty big undertaking, but I think the best thing for extensibility in the long run would be to move as much to Core as possible, then split conduits off from machines and have them as a separate mod, like CoFH did with dynamics vs expansion. You could have separate testing/development efforts going on simultaneously, it would be easier to add custom conduits and quite frankly the conduit code is likely to change at a much slower pace than the rest of the mod. I think that and/or providing an API for adding conduits (would be easier with capabilities) would be the way to go.

For what it's worth though, the PR for this is relatively small and fairly clean. It may look like alot of lines, but when I imported the EnderIO reformatting xml into Eclipse I accidentally turned it on automatic for a file or two :( I can clean it up some more if there is a chance could get merged.