Any documentation?
Croutonix opened this issue · 24 comments
I can't find any documentation on some of the pipes, how to make them work. what they do?
- Gravity Feed Pipe
- Obsidian Fluid Pipe (pump?)
- Closed Transport Pipe
- Addition Transport Pipe
- Priority Insertion Pipe
- Jeweled Pipe (tag/meta?)
Next question: what's the difference between PipeBehavior.writePayload() and PipeBehavior.writeToNbt()? Do I have to implement both on my pipe behaviors?
writeToNbt is used for saving and loading between server instances. You probably need to override this for every custom pipe behaviour that stores extra data.
writePayload is called for server -> client sync. If you have any data the the client needs to know about then you'll probably need to override this. (The side parameter is currently useless, as at the moment only the server sends messages to clients. However in the future networking might be expanded enough to allow for client -> server messages, in which case adding an if side == SERVER check will be a good idea. Its only required that they properly mirror each other though, so if you add the check to write you'll need to add the check to read as well)
@AlexIIL Quick question: I'm bugfixing the 1.8 version of additionalpipes, and I ran into an issue. Does Utils.createLaser() work anymore? It seems to not do anything in 7.2.8, and I notice that nothing inside BuildCraft uses it. Is there any other way to create lasers that does not require calling a renderer myself?
I don't think so? However I haven't touched 7.2.x code in a loooong time so I don't really know.
Dang. Thanks for responding though!
Next question, now that I started my 1.11 update, what happened to IIconProvider on pipes? How do I associate a pipe with its texture?
Also, does Utils.createLaser() work in the current version? Or is there now a proper substitute?
And am I correct in assuming that Flows are the successor of Pipe Transports?
You pass the texture locations when you register a pipe, in an array. You then return the index in that array in the pipe behaviour object. Buildcraft itself handles sprite allocation and stitching past that.
I'll have to look into how lasers work a bit later, for now I know that TileLaser and RenderLaser use them directly.
Yes, Flows are the successor to transports.
Last question: why do pipe item events now contain multiple items in one event? Are you not supposed to just for-loop over all the ItemEntrys?
All events fired after "split" contain all the outputs that were split off by the split event. It's mean to give full context about the items in question, although most of the time you'll just loop over all the entries.
Pipe data is sent when the client first connects or requests a particular chunk, via writePayload (writeToNbt is never used for networking). In addition calling "pipe.getHolder().scheduleNetworkUpdate(PipeMessageReceiver.BEHAVIOUR);" will send the payload from the server to the client.
I'd recommend syncing teleport values separately from the client to the server, although if it's small enough you could get away with sending to every client if you wanted to.
Just FYI it might be quicker to talk via our discord or PM on our discord here. Oh, and if you find something that doesn't work or you'd like to be added please say as I'll try to add it (the entire point of the API is for addons anyway 😄)
Obviously I won't be around very much during Christmas, but I'll try to respond when I get the chance.
Does this mean that pipe data on the server is automatically synced between clients and the server now?
For example, Additional Pipes has a teleport pipe GUI that sets the pipe channel and other options. In the 1.8 version, when the GUI opens, it sends a packet to the server to request the pipe's values, then displays those values in the GUI, and sends them back to the server when the GUI closes.
In BC 7.99, can I just assume that the server pipe's values will get synced to the client?
Also, if data about teleport pipes is only ever used on the server, do I even need to bother implementing the payload functions, since I already use packet-based synchronization?
Oh wait, I reread your post, and I think I get it a bit better. Is this correct: when a client first connects to the server, the pipe behavior is serialized as NBT and sent to the client. Then, any further updates to state after the world loads are sent using payloads.
This leads to the question: what conditions would cause payloads to be sent?
Just to be on the safe side, did you just join discord and PM me? I probably won't be able to get things sorted out properly until tomorrow though (for me it's 4 AM right now)
Actually, I'm reopening this because I need to migrate the documentation somewhere else. I don't care if the forums are resurrected again, that's the second time in 2 years that they've gone down.
Wait, WHAATTT? I've been away for a while, but I'm back now, and it seems that the buildcraft forums have been shuttered. The documentation lived on the forum thread, which can still be viewed thanks to the Internet Archive:
https://web.archive.org/web/20160202133259/http://mod-buildcraft.com:80/forums/showthread.php?tid=1467
Do you have any idea why this happened? Did someone break into the forums again?
It was mostly due to me not being able to getting it to work, and then I just assumed that it could be completely replaced with reddit + discord. As that assumption is wrong I'll look back into bringing back all the lost information. (Although I do recommend using github wiki or adding to the bc guide for newer versions, and hopefully I'll have a way of exporting guide entries into a webpage so that you don't have to keep two different places up to date.)
Its because the forums were not very active at all. The site was transferred over to @AlexIIL at the time so im guessing it wasn't worth the hosting fees for the inactive forums. Also the docs could be moved to the ingame BC guide when you move to 1.11.2+ :)
Documentation is now up on the CurseForge page: https://minecraft.curseforge.com/projects/additional-pipes-for-buildcraft