LP pipes are not properly connecting with teleport pipes
doushio9967 opened this issue · 41 comments
See attached screenshot.
Items will bounce out of the phased item pipe in the front instead of teleporting over.
So while it looks like they are connected, the phased pipe isn't finding any further pipe to send the items to, I guess. If I replace the basic LP pipe that is just after the phased pipe in the back with a stone pipe items will properly teleport over and then get routed when that stone pipe hands it over to the LP network.
Some basic regression testing show that LP pipes directly after phased item pipes worked in b193, but broke in b195 (or b194, but I couldn't test that one of course).
BC 4.2.2, Additional Pipes 2.6.0 (tcooc's)
Ummm..... Anyone? I'm kind of stuck here, and yes I did try with the latest Jenkins build of LP.
OK, I made some progress, I figured out that my SpecialPipedConnection was set up totally wrong and was incorrectly filtering in isType(). I fixed that as best I could, and now items are being thrown on the ground instead of sent through the teleport pipes after the delay. So... I guess that's progress?
Alright, I've added a basic API which will allow you to interact with the teleport manager. You can download it from the releases page. It's fairly well commented, but here's how it works:
If TeleportManagerBase.INSTANCE is non-null, then Additional Pipes is installed. It is set in init to an instance of the TeleportManager. In order to get the teleport pipes receiving from a specific pipe, call
TeleportManagerBase.INSTANCE.getConnectedPipes(pipe, false, true);Let me know if you need anything else, and I really hope that we can fix this, and get our users to stop complaining about it!
" I really hope that we can fix this, and get out users to stop complaining about it!"
First part will be easy. However, the other part... I think it would be the hardest job. 😄
I will get on this when I am over my exams next week. Sorry for the huge delay @multiplemonomials and thanks for making the API :)
When the fix implemented will I need to connect the Teleport Pipe directly to a Logistics Pipe?
My system was built back when Logistics Pipes would only connect if they where indirectly connected to Phased Transport Pipes. (On both ends I have a Basic Logistics Pipe connected to a Sandstone Transport Pipe connected to a Teleport Pipe.)
Thank you @multiplemonomials & @theZorro266, I'm happy to see that there is some progress is being made on this issue.
Oh, I just realized, there's an issue with the current plan: In your earlier post, you said that there must be one logistics pipe attached to two teleport pipes. However, if a logistics pipe is connected to two teleport pipes and another teleport pipe is chunkloaded or placed, your mod would have no way of knowing about it. Maybe I'd need to implement some kind of "frequency locking" system to prevent this.
Multiplemonomials, I think you misunderstood when he said "one logistics pipe attached to two teleport pipes". I've written this post many times, trying to say it in a way that is hard to misinterpret, but still be 'readable', and it has been difficult, but here's what I came up with:
He means that you have to have (in both locations you are teleporting to and from), a single route which an object can pass, between the TP pipe and the LP pipe. No other junctions. The LP pipes do not HAVE to be attached directly to the TP pipes, but you cannot put another pipe going somewhere else on the pipes directly connecting the two.
Also, I'll have to find your blog, there still an issue with the current TP pipes, which causes them to loose packets. I have a firm handle on what the issue is, and can describe it to you in the right place.
Oh, yeah I did misunderstand. In this case, maybe the best idea is to create a new kind of Teleport Pipe (the Logistics Teleport Pipe?) which only connects to Logistics Pipes. It would be kind of weird for Item Teleport Pipes to suddenly change their behavior when a logistics pipe is connected.
Also, I don't have a blog, but I would really appreciate help with the disappearing-items issue, since I'm kind of stuck on it. You can respond on the issue for it or the Additional Pipes forum thread.
If its to create a new kind of teleport pipe, wouldn't it make more sense to have it directly in LP itself?
Well... there was some talk above about implementing this as part of LP itself? =P
Yeah, I kind of see what you mean. If I'm going to add it as a new type of pipe anyway, it doesn't really have much to do with my "current" teleport pipes and can't use much of my teleport pipe infrastructure, so why have it in my mod instead of LP? Good question, actually.
Now that I think about it, it probably does make more sense to have it inside LP. It seems a little strange to require LP users to install Additional Pipes just for the teleport functionality.
Logistics Pipes developers, what do you think? I'm still OK to add the functionality to my mod, but this way (you adding a "teleport upgrade" independent of Additional Pipes) might make more sense.
@multiplemonomials I do not understand one thing: we talking about supporting Teleport Pipes from LP side, or we talking about making an LP pipe/upgrade that can immediately deliver an item (read: it can teleport an item)? I think in the first case it is an inter-mod compatibility thing and it does not matter which side can implement it. However, the second case can cause balancing issues in LP as well as some unexpected routing problems.
I think installing Additional Pipes to get a teleporting ability is not a bad thing since this is how LP currently supports "teleporting' too: you can work with Ender Storage chests to teleport back and forth items instantly atm or using Thermal Dynamics warp pipes too. I think this behaviour should not be changed.
I also think from user's side Additional Pipes can do this job quite well and I would be happy to use it to teleporting stuffs.
For last words: you will always have a users who want to use your mod with LP. Why not support it anyway, regardless what LP devs decide?
@hron84 if I understood @multiplemonomials comments up to now:
- Current implementation will of "Teleport Pipes" do not work well with LogisticsPipes
- It would probably be better to create a totally new Teleport Pipe for Logistics [which should provide better support/stability]
- If you code the pipe for scratch it would probably make more sense to do the code inside the LogisticsPipes mod instead
- @multiplemonomials said "I'm still OK to add the functionality to my mod"
4.5. I think he wants some input before starting to put time and effort to resolve this issue
Also LogisticsPipes and AdditionalPipes work perfectly fine together except for the edge-case of the Teleport Pipe [which has bit me hard]. While it would be nice to see the Teleport Pipes start working or it be replaced with something else, if it were to take a complete rewrite it may make sense to do the code in LogisticsPipes itself.
@QORTEC thanks for clarifying this, my English is sometimes not enough to got all points.
However, I still not agree it should be in LP. This mod is currently have a many other ways to teleport items back and forth, but I think it would be very hard not only to implement this teleporting pipe to LP (think about RF/EU power supplier stuffs) but also balancing it. Maybe - just maybe - I can imagine this thing as a ISC upgrade as this strips down only for items, but... I really have doubts about this would be a good idea.
Also I wanted to add: @davboecki said "We already have so many mod interactions that it is starting to get difficult to keep track of all of them." Issue: #748
If LP users want this feature and the best solution is to be to create a new LP specific pipe, I would think it would be easer on everyone to keep LP specific code in LP.
But I would like to hear from the LP devs what their thoughts on this issue are.
If the devs are open to the idea of adding some form of teleportation into the mod then the discussion would likely change to possible implementations and balancing.
QORTEC, your interpretation is correct. I've thought about it some more, and decided that since my mod is called Additional Pipes, an addon to another mod, instead of Buildcraft, is in scope. Also, I think I'll be able to re-use more of my existing code than I thought I could.
I feel like this thread is starting to turn into a Firefox bug report (lots of people arguing, while nothing gets fixed), so unless the LP developers have any objections I'm going to continue as planned and make the Logistics Teleport Pipe.
I started typing a comment yesterday, but I was not happy with my English at that time.. ^^
I would not like to duplicate a feature another mod already has. If possible, we should just implement a mod interaction, because it is not even that hard in this case (definitely not on the difficulty level as taking the full AE integration on our side as in linked issue above).
If the mod integration should be in AP instead of LP, that is fine: There will be a new interesting interface for that anyway, see #765
OK, I'm trying to get the Logistics Pipes API set up in Eclipse, but it's telling me to put LogisticsPipes_dummy.jar into my mods folder. Where can I get this file? Or am I just totally missing something?
yeah, https://github.com/RS485/LogisticsPipes/blob/dev/BUILDING.md is a good guide, but I need to add that step there.
OK, I'm starting to get things going using a snippet of code someone else wrote which hacks LP compatibility into Additional Pipes (for 1.6).
try {
Class<?> SimpleServiceLocator = Class.forName("logisticspipes.proxy.SimpleServiceLocator");
logger.fine("Logistics Pipes is detected");
Object specialconnection = SimpleServiceLocator.getField("specialpipeconnection").get(null);
Method registerHandler = specialconnection.getClass().getMethod("registerHandler", ISpecialPipedConnection.class);
registerHandler.invoke(specialconnection, new ISpecialPipedConnection() {
@Override
public boolean init() {
return true;
}
@Override
public boolean isType(TileGenericPipe tile) {
return tile.pipe instanceof ITeleportLogicProvider;
}
@Override
public List<TileGenericPipe> getConnections(TileGenericPipe tile) {
return Lists.transform(((ITeleportLogicProvider) tile.pipe).getLogic().getConnectedPipeLogics(true), new Function<PipeLogicTeleport, TileGenericPipe>() {
@Override
public TileGenericPipe apply(PipeLogicTeleport input) {
return input.pipe.container;
}
});
}
});
logger.fine("Logistics Pipes is compatible now!");
} catch (ClassNotFoundException e) {
} catch (ReflectiveOperationException e) {
logger.warning("This Logistics Pipes is not supported");
e.printStackTrace();
}Is this something I shouldn't be touching? I feel like if it were, IPipeInformationProvider would be declared in the API.
Of course, I'm also making it so that Logistics Teleport Pipes only connect under the proper conditions.
@davboecki that looks good, doesn't it?
OK, I'm making progress, but I'm having an odd issue. LP routes items through teleport pipes correctly, but as soon as the come out on the other side, they get "stuck" in the Logistics Pipe.
After a few minutes, they continue to their correct destination. Any idea what's causing this?
Also, I keep seeing this stacktrace when I load the world:
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: java.lang.NullPointerException
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at logisticspipes.pipes.basic.LogisticsTileGenericPipe.overridePipeConnection(LogisticsTileGenericPipe.java:1064)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipe.canPipeConnect_internal(TileGenericPipe.java:743)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipeCompat.canPipeConnect_internal(TileGenericPipeCompat.java:134)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipe.canPipeConnect(TileGenericPipe.java:795)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipe.computeConnection(TileGenericPipe.java:835)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipe.computeConnections(TileGenericPipe.java:820)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipe.initialize(TileGenericPipe.java:572)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.transport.TileGenericPipe.afterStateUpdated(TileGenericPipe.java:1016)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.core.lib.network.PacketTileState.applyStates(PacketTileState.java:63)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.core.lib.network.PacketHandler.channelRead0(PacketHandler.java:96)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.core.network.PacketHandlerCore.channelRead0(PacketHandlerCore.java:22)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at buildcraft.core.network.PacketHandlerCore.channelRead0(PacketHandlerCore.java:19)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:98)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:169)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at cpw.mods.fml.common.network.internal.FMLProxyPacket.processPacket(FMLProxyPacket.java:86)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.network.NetworkManager.processReceivedPackets(NetworkManager.java:241)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.Minecraft.runTick(Minecraft.java:2141)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:1028)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.Minecraft.run(Minecraft.java:951)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.client.main.Main.main(Main.java:164)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at java.lang.reflect.Method.invoke(Method.java:606)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
[13:26:54] [Client thread/INFO] [STDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
Is this my fault, Buildcraft's, or yours? I ran the debugger, and this.pipe is null in the top frame.
I'm sorry in machine translation.
I found a similar problem.
It is a case of an image.
When an item passes through the logistics pipe, items are packaged in a box.
When passing through the pipe of another logistics network in the state,
It gets the "stuck".
A question: what happens, if you make the second network one pipe larger and move the chest to the new pipe, and not mark default same pipe that connecting to the LP power block? Also try out with vanilla chests pls.
The same thing happens, items get stuck in the Logistics Pipe connecting to the Teleport Pipe.
To give an update for Additional Pipes: There are two versions out there right now.
BC 6.0: https://github.com/davboecki/AdditionalPipesBC
And BC 6.1: https://github.com/multiplemonomials/AdditionalPipesBC
Right now there is no plan to fully support Additional Pipes again, until it is being maintained properly and with some kind of API that would make the integration easier. However there were speakings about implementing something like a teleport pipe into LP. But we are not sure about that yet.
I'd be willing to help you make this work, as the one who did the AP 1.7 port.
@multiplemonomials that would be great.
You might know it already, but there are some prerequisites.
The network does not connect, if there is not only one LP pipe on exactly two connected teleport pipes (to prevent misrouting, etc.).
- There must be some way to get the location and tile entities (and amount) of connected teleport pipes
- It would be nice to have a check, if the opposite teleport pipe is chunkloaded
Other than that we need to have some kind of interface for exactly those methods. And the interface is on the tile entity class of the teleport pipe, obviously.
Any other input from @davboecki ?
While I don't know a whole ton about the Buildcraft API, given the current code implementing those two functions should be simple enough. Do you want me to just add the functions to the teleport pipe tile entities and you would call them via reflection, or do I have to make an API?
There must be some way to get the location and tile entities (and amount) of connected teleport pipes
For this, you can call bulldcraft.additionalpipes.pipes.TeleportManager.instance.getConnectedPipes(((TileGenericPipe)pipeTileEntity).pipe)
It returns a List. To get the tile entity of a PipeTeleport, access its member TIleGenericPipe "container".
It would be nice to have a check, if the opposite teleport pipe is chunkloaded
I think that the above method will only return pipes that are currently loaded.
I'll be honest, I have know idea how to make an API. I suppose you can invoke the function via reflection, or you could point me towards a source of info.