Work on MC 1.9...
loordgek opened this issue ยท 8 comments
@davboecki @theZorro266 can we/you put the compatibility for other mods out side the main repo
and put it in LogisticsPipes-compat
for stuf that you need to implement you can use mixin https://github.com/SpongePowered/Mixin
Moving everything out of this repo into another repo and to use mixins as an interaction would only double or even triple the workload and the only real benefit would be to make porting to a new MC version a little bit faster, so I would vote no for this one.
Because our Proxys are embedded deep inside LP. So handling that with mixins and even only the part about a reperate repo would increase the workload drasticly if you want to fix something with out mod integration.
And for the time beeing if there is a mod that's not updated and we don't want to shoot into the dark with the compatibility we can simply disable the compatibility and just fall back onto the dummy proxy untill that mod updates.
I think this is why proxies exists, to separate mod integrations from the main part of LP. I also wondering why it would need more separation, even if it can mean more clean code, it would have no benefit for LP itself. I think bindings can't be too lazy, because we will fall from the rock.
@hron84 i lost you here
to separate mod integrations from the main part of LP
what??? that is not separate
this is separation
https://github.com/BuildCraft/BuildcraftCompat
and why fall from a rock?
@davboecki i was thinking of this and throw the proxy stuff out
https://github.com/BCA-Team/Buildcraft-Additions/blob/2.2.x/src/main/java/buildcraftAdditions/compat/ModuleManager.java
can try it w/ one mod (buildcraft) or am i wasting time here???
Separation can mean different things. It can mean we do not try to call stuff if the compatible mod is not present, So e.g. LP is do not crashing even if no Forestry installed or IC2 or anything other. That is why proxies exists currently. Moving proxies (because these are the things that make the compatibility with other mods) to a separate mod does not improve anything. but introduces a dependency hell. Also a lot of user reports about this or that compat mod does not work well with the core LP just because he/she forgot to update the core or the compat mod to match them. I'm pretty sure you do not want this. As I read the source of LP, integrations are separated enough to not cause issue, and this is the only thing that counts. Yeah, separated mods, separated repos can be make the code a bit more pretty, but this benefit is not worth the work you need to put into separation. Not until there is a lot of bigger tasks to be done (1.8, 1.9 compatibility for example).