In any Minecraft item transport method, you have to have one of the following three features:
1. Instant transportation
2. Infinite backstuffing
3. Items spilling on the ground
It's just occurred to me that golems do not quite fit this model - they can get stuck holding an item, but that isn't really backstuffing and it isn't infinite. I guess they aren't really an item transport method, they just have some limited item transport features.
It's just occurred to me that golems do not quite fit this model - they can get stuck holding an item, but that isn't really backstuffing and it isn't infinite. I guess they aren't really an item transport method, they just have some limited item transport features.
Golems pretty much follow the same approach as XU pipes. The node "holds" the item and attempts to pathfind a destination. If it can't find one, then it get's stuck, just like Golems.
In any Minecraft item transport method, you have to have one of the following three features:
1. Instant transportation
2. Infinite backstuffing
3. Items spilling on the ground
Take your pick! You can have both 2 and 3, if you want. I guess "items traversing back and forth infinitely" is another option, but I'd say that's a sub-type of backstuffing. Also, items being destroyed when there are too many in the pipe is another option, but I don't think that it's a sufficiently popular one to be worth listing.
CMIIW, I'd be interested to hear of a method that avoids all three of these features.
There is also limited backstuffing where no more items enter the pipe while the previous item is still traversing (extra utils nodes and golems), though that can be considered a general case of instant transport.
There is also limited backstuffing where no more items enter the pipe while the previous item is still traversing (extra utils nodes and golems), though that can be considered a general case of instant transport.
XU is instant transportation, so it has feature 1, and as a bonus it implements limited backstuffing. That's a bit of an odd decision, to implement a flaw that is entirely unnecessary. I guess it's ok, working around the flaws in a system can be fun.
XU is instant transportation, so it has feature 1, and as a bonus it implements limited backstuffing. That's a bit of an odd decision, to implement a flaw that is entirely unnecessary. I guess it's ok, working around the flaws in a system can be fun.
Here's how I would do it, inspired by the concept of transactions in programming.
I would implement teleporting with placeholders. Pipe A is sending from inventory X to inventory Y which is attached to pipe B. Pipe A tells Pipe B to reserve a spot in inventory Y by creating a placeholder item (This item is not able to be removed by the player or another mod. How to code this aspect alone is the most difficult part I can think of as a non-modder) Once pipe B tells Pipe A that the placeholder is in place, pipe A would teleport the item from inventory A to pipe B, but the animation would show as if it were traversing the pipe network at the pipe's rated speed, increasing or decreasing as in buildcraft's pipe transitions from cobble to gold, etc. However, Once the requisite number of seconds have passed that the item should have gotten there visually, pipe B removes the placeholder item and inserts the in-transit item into inventory Y (This stops those with a lot of tick rate lag from other sources from having their entire system take longer and longer to occur, and it also reduces the reliance on FPS from the user's perspective. But it does mean that items may "skip" the last several pipes at times).The transaction is now complete.
A slightly more complicated method would implement placeholders in both inventories, so that if for some reason the placeholder is removed from inventory Y then the item returns to inventory A and the transaction fails. No backstuffing, instant teleportation is only in code, but the user sees the "minecrafty" animation of movement from one location to the next. It removes the EnderIO effect (which I personally don't mind at all, I'm just brainstorming here)
My theory on FTB Monster lag in my group's server is that certain pipes must contact each other and tell the next pipe how much it's getting, etc. I like being able to see items move, but I think the placeholder effect, with a in-code teleportation and only visual movement would solve many of the issues. I know that MC is a CPU game, and I think teleportation is a way to ease the CPU and utilize only the GPU to render an item in transit. And I think placeholders allow for the elimination of backstuffing, which can cause some level of lag, and still have the animation of the items through the pipe for the aesthetics and minecraft feel of a mod.
This is of course just thoughts of a guy who's never written an MC mod and has barely messed with configs. So take it as you will. But I know that animations can be extended well beyond a single block radius, so it's my thought that a render that overlays several pipes and animates a travelling item or a few thousand should be easier on CPU than actually animating it from one pipe to the next and having to place calls to each next pipe's methods that tell it to receive and send the item.
Here's how I would do it, inspired by the concept of transactions in programming.
I would implement teleporting with placeholders. Pipe A is sending from inventory X to inventory Y which is attached to pipe B. Pipe A tells Pipe B to reserve a spot in inventory Y by creating a placeholder item (This item is not able to be removed by the player or another mod. How to code this aspect alone is the most difficult part I can think of as a non-modder) Once pipe B tells Pipe A that the placeholder is in place, pipe A would teleport the item from inventory A to pipe B, but the animation would show as if it were traversing the pipe network at the pipe's rated speed, increasing or decreasing as in buildcraft's pipe transitions from cobble to gold, etc. However, Once the requisite number of seconds have passed that the item should have gotten there visually, pipe B removes the placeholder item and inserts the in-transit item into inventory Y (This stops those with a lot of tick rate lag from other sources from having their entire system take longer and longer to occur, and it also reduces the reliance on FPS from the user's perspective. But it does mean that items may "skip" the last several pipes at times).The transaction is now complete.
A slightly more complicated method would implement placeholders in both inventories, so that if for some reason the placeholder is removed from inventory Y then the item returns to inventory A and the transaction fails. No backstuffing, instant teleportation is only in code, but the user sees the "minecrafty" animation of movement from one location to the next. It removes the EnderIO effect (which I personally don't mind at all, I'm just brainstorming here)
My theory on FTB Monster lag in my group's server is that certain pipes must contact each other and tell the next pipe how much it's getting, etc. I like being able to see items move, but I think the placeholder effect, with a in-code teleportation and only visual movement would solve many of the issues. I know that MC is a CPU game, and I think teleportation is a way to ease the CPU and utilize only the GPU to render an item in transit. And I think placeholders allow for the elimination of backstuffing, which can cause some level of lag, and still have the animation of the items through the pipe for the aesthetics and minecraft feel of a mod.
This is of course just thoughts of a guy who's never written an MC mod and has barely messed with configs. So take it as you will. But I know that animations can be extended well beyond a single block radius, so it's my thought that a render that overlays several pipes and animates a travelling item or a few thousand should be easier on CPU than actually animating it from one pipe to the next and having to place calls to each next pipe's methods that tell it to receive and send the item.
Sounds like XU transfer pipes, but with actual animations. The transfer nodes extract items out of whatever inventory they're attached to and store them in the node's buffer, then every second (or some fraction of a second if there's speed upgrades) check any adjacent blocks to see if they're either inventories or transfer pipes. If it finds an inventory that will accept the buffered items, it will dump the whole stack there at once and start over. If there's no acceptable inventory, but there is a pipe, the node will store the location of that pipe, relative to the node. Then the next second, the node repeats the process starting at that pipe. If there's an adjacent inventory, the items get dumped there; if not, it looks for a pipe other than the one it just came from and stores its location.
The end result is that the node scans the length of a line of transfer pipes adjacent to it, dumping items into the first available inventory. If it hits a branch in the pipe, it chooses a direction at random.
Your suggestion sounds similar, but with a few differences:
1. The transfer node is replaced with a pipe configured to extract items.
2. The input pipe extracts and buffers all the items it's going to at once, rather than one at a time as it scans.
3. The input pipe actually renders the items in its buffer "in transit", creating an illusion that they're traveling through the pipes.
4. The input pipe maybe has several separate buffers so it can transport several stacks in parallel?
5. If the input pipe doesn't find anywhere to put the item... ?
Not exactly sure what you 're trying to do with your "placeholder"... trying to answer difference #5?
Interesting idea, and it is, in theory at least, a genuine alternative to my "must have" list. I suspect that the "reserved space" item that can't be removed might not be possible in Minecraft, but I may be wrong. It's also fraught with other problems, such as, what if the pipe breaks before the item gets to the destination? What if something breaks ALL the pipes simultaneously, how do you ensure that the transaction is either committed or rolled back?
Sounds entirely unlike them to me. XU has an input buffer that extracts from the source regardless of whether there is a valid destination. Bacon's idea does not have an input buffer and does not extract if there is no valid destination, and reserves the destination when there is one.
Here's how I would do it, inspired by the concept of transactions in programming.
I would implement teleporting with placeholders. Pipe A is sending from inventory X to inventory Y which is attached to pipe B. Pipe A tells Pipe B to reserve a spot in inventory Y by creating a placeholder item (This item is not able to be removed by the player or another mod. How to code this aspect alone is the most difficult part I can think of as a non-modder) Once pipe B tells Pipe A that the placeholder is in place, pipe A would teleport the item from inventory A to pipe B, but the animation would show as if it were traversing the pipe network at the pipe's rated speed, increasing or decreasing as in buildcraft's pipe transitions from cobble to gold, etc. However, Once the requisite number of seconds have passed that the item should have gotten there visually, pipe B removes the placeholder item and inserts the in-transit item into inventory Y (This stops those with a lot of tick rate lag from other sources from having their entire system take longer and longer to occur, and it also reduces the reliance on FPS from the user's perspective. But it does mean that items may "skip" the last several pipes at times).The transaction is now complete.
A slightly more complicated method would implement placeholders in both inventories, so that if for some reason the placeholder is removed from inventory Y then the item returns to inventory A and the transaction fails. No backstuffing, instant teleportation is only in code, but the user sees the "minecrafty" animation of movement from one location to the next. It removes the EnderIO effect (which I personally don't mind at all, I'm just brainstorming here)
My theory on FTB Monster lag in my group's server is that certain pipes must contact each other and tell the next pipe how much it's getting, etc. I like being able to see items move, but I think the placeholder effect, with a in-code teleportation and only visual movement would solve many of the issues. I know that MC is a CPU game, and I think teleportation is a way to ease the CPU and utilize only the GPU to render an item in transit. And I think placeholders allow for the elimination of backstuffing, which can cause some level of lag, and still have the animation of the items through the pipe for the aesthetics and minecraft feel of a mod.
This is of course just thoughts of a guy who's never written an MC mod and has barely messed with configs. So take it as you will. But I know that animations can be extended well beyond a single block radius, so it's my thought that a render that overlays several pipes and animates a travelling item or a few thousand should be easier on CPU than actually animating it from one pipe to the next and having to place calls to each next pipe's methods that tell it to receive and send the item.
the place holder bit is kinda impossible, ItemStacks (the individual items) are dumb. dumb in the sense that they don't know where they are or what the inventory it is in is doing to it. So the item cannot prevent itself being removed.
All "item in inventory" effects like countdowns and flight are done using player or TE ticks and checking the inventory for the item each tick/every few ticks.
Ok. so since my idea spawned a few comments, I'll play along and pretend I'm not just making this up as I go along (I totally am). =-P
There are a few things that are considered no-nos in modded Minecraft these days. And most of them can be identified as anything that would make a quarry cause a lot of lag. Spilling plus quarry (or automated cobble gen, etc.) = tons of lag. Infinite backstuffing (whether it be of items, RF, liquids, etc.) will cause lag (and be abused most likely as free storage. I remember a "tip" once on how to setup a cobble pip loop to store an infinite amount of anything. Not a good idea).
So, the placeholder item... I agree it would be hard to code, if not impossible (I think I said that in my original comment). Maybe like @ratchet freak saidother mods do, have it check every 5-10 ticks to see if it's in the inventory assigned to it by the pipe that created it, and if not, to tell the pipe to fail the transaction and then the placeholder deletes itself. If you wanted to make it hard on yourself(as the mod coder) you could add support for each of the mainline item transport mods as well as vanilla hoppers to blacklist it from item movement automatically, but that'd be a heck of a job to keep that support going. It would be easier just to put the onus on the player to blacklist it themselves for other systems, and only blacklist it automatically in your own mod. Most systems use one primary transport system anyway. But then that requires more resources for between mods and can be hard, depending on the mod being used to extract (a blacklist slot for an ME2 import bus is pretty valuable early on) and really hard with vanilla hoppers.
The other option is to say meaningful animations be da**ed, and just show a representative animation. Say that the pipes are moving a stack of cobble one at a time. Instead of animating 64 individual cobble pieces, and moving them from one pipe to another, just teleport the stack and play an animation of a string of cobble, too close together to see how many, moving between locations. If the pipes aren't too slow (and do we really want pipes as slow as Buildcraft 2 Cobble pipes?), the movement should be fast enough to not be noticeable, and even if seen, should be indistinct.
Yet another idea...
This option is inspired by Stargate:Atlantis' intergalactic stargate system with the Midway Station. For those how don't know the show, this is gonna sound weird, but each stargate in that show was in effect a node (or a pipe). each could connect to others, but only within a certain distance. To bridge two galaxies that are way too far apart to travel normally, they created a sequence of gates that would each dial the next in line and forward the traveller. This is how a pipe system typically works to my understanding, but with the max distance being 1 block away.
So how about we say that a pipe can teleport to any inventory that's less than 10-15 pipes away. But if it's more than that, it needs to find a junction pipe. You could make these junctions automatic for ease of use, or you could make them a separate item. So if I'm placing blocks to move items from point a to point b 500 blocks away. Every tenth pipe I place sees that there is no junction in range, so it either fails to connect and makes the player place a junction (complicated mode) or it automatically becomes a junction itself (easy mode).
Animations are played between junctions, but items are teleported. It reduces the number of calls to the pipes tenfold from the one pipe to another method, as well as breaking up the size of the animation into smaller pieces (only junctions would create animations, but they would make it appear as if the items were going through the in between pieces.
And finally, since I'm brainstorming here, you could also get rid of the in between pipes all together, and just place the junctions, which each have a configurable amount of storage (backstuffing), teleport items and liquids between them, and attach to any inventories. You could still play animations, just like botania mana bursts do. The problem there comes with linking them, which could be done with a shift-wrench click or a color system (Ender-storage spinoff, anyone?). You could even make it so that you have to use a splitter upgrade to have more than one destination, and then depending on the type of splitter used will determine the type of pathfinding that occurs (Like a diamond pipe, iron pipe, round robin, random, etc).
Anyways, I think this is crazy off-topic regarding Thermal Dynamics, since I doubt any of it is considered even remotely plausible for them (maybe with the exception of the junction idea with animations played over pipes between them, which would reduce lag with fewer between block calls, allow for limited backstuffing(each junction has a small inventory), work like teleportation, look minecrafty, only spill when junctions are broken, etc.)
If anyone wants me to post a thread of my own on the brainstorming I've done here, message me and let me know. I just created this profile because I forgot the password for the one under my real name, but it is my minecraft name so it fits. =-)
Ok, now I think I understand what the placeholders were all about. They're how you prevent problems from arising when an inventory fills while there's an item in transit. I still think this idea is more like XU transfer nodes than anything else out there that I know of.
So every 5-10 ticks, the input pipe scans the network (instantaneously) for somewhere to put an item. If it finds such a location, it tells the output pipe to put a Useless Item of some sort (which you call a placeholder) in the receiving inventory to take up space, while the input pipe extracts the item, buffers it somewhere, plays an animation of moving the item along the pipes, and when the animation is complete (or rather, when the proper amount of time has passed serverside), it destroys the Useless Placeholder and replaces it with the buffered items.
Should work fine with chests, but I do see a problem: Barrels. Since they only hold one type of item, you won't be able to jam a placeholder in there while the actual item is "in transit".
I know that Immibis wrote a mod a while back (forget what it was called... the one that interfaced with RedPower 2 and included a retriever-regulator block) that included a sort of placeholder item used to jam the filter on RedPower retrievers to make them not retrieve/accept any more items than necessary. I don't think he had any way to keep players from pulling the item out of the retriever, but it certainly deleted itself it it was somehow dropped on the ground and some player decided to pick it up.
Also, you Stargate-inspired thing could be interesting. Makes me think of logistics pipes... without the pipes.
In those cases (Barrels and partial stacks) I would probably instantly teleport the item, and then play the animation. I don't know, that's a good problem for it.
Or, I would use particle effects to substitute for the item prior to teleportation and not even try to pretend that it's the item itself that is travelling.
Take the example of how a player throws an ender pearl. They throw the item, it travels, and once it arrives, the player teleports. You could do the same thing with the animations. Maybe a 2d graphic with the item's icon in the middle (like the flat space mirror prisons from Superman) flows along the pipe graphically, and once it arrives, if there's room, the item instantly teleports. If there's no room, the icon travels back near-instantly (a graphical representation of the transaction failing) and the item never moves.
Come to think of it, I think my two favorite ideas are the pipe system with teleporting junctions that have to be within X number of pipes from each other, and the botania like design where pipes connect to each other through the air and items, fluids, or power travel on particles.
Maybe this is a good time to say that I'd like credit if this inspires anyone to make such a system. =-P Or maybe I'll just find a way to start it myself. Like I said, I've never made a MC mod, but I have watched most of Pahimar's Let's Mod Reboot series. I bet with some time and research I could get a functional enough demo to recruit some more experienced programmers.
Take the example of how a player throws an ender pearl. They throw the item, it travels, and once it arrives, the player teleports. You could do the same thing with the animations. Maybe a 2d graphic with the item's icon in the middle (like the flat space mirror prisons from Superman) flows along the pipe graphically, and once it arrives, if there's room, the item instantly teleports. If there's no room, the icon travels back near-instantly (a graphical representation of the transaction failing) and the item never moves.
Now that's sounding even more like XU. If you put a glowstone dust in one of the upgrade slots in a transfer node, it'll spawn some particles whenever it scans a pipe, so you can see what it's doing. This suggestion sounds like that, but with an animated item entity instead of a string of poofs of particles.
Maybe the transfer node buffer could be done away with, and instead, the input pipe could just scan the network looking for inventories that can accept one of the items in the inventory it's pulling from. This could be paired with any kind of animation, and once the input pipe finds a suitable destination, it just starts teleporting items. Hmm... Sounds like a reversed version of XU retrieval nodes. These are an upgrade to the transfer nodes that scan the pipe network looking for items, and start teleporting items found to the attached chest- they don't really need to use a buffer at all.
Come to think of it, I think my two favorite ideas are the pipe system with teleporting junctions that have to be within X number of pipes from each other, and the botania like design where pipes connect to each other through the air and items, fluids, or power travel on particles.
Maybe this is a good time to say that I'd like credit if this inspires anyone to make such a system. =-P Or maybe I'll just find a way to start it myself. Like I said, I've never made a MC mod, but I have watched most of Pahimar's Let's Mod Reboot series. I bet with some time and research I could get a functional enough demo to recruit some more experienced programmers.
The only thing I dislike about mods only being allowed to be tested by mod devs is that they think they are clever enough to fix bugs in it. Everyone knows that casual players are more clever than the devs in terms of finding exploits and bugs. Starbound, even though it is a different game, it has a mode where you can play with whatever the devs had added and fixed in a day allowing players, at their own risk, to find bugs and exploits so that the devs can fix them. I wouldn't mind seeing the FTB mod devs to try something similar to this where they can update the mods whenever they see fit to do so, not every single day because I'm sure they all have IRL jobs.
The only thing I dislike about mods only being allowed to be tested by mod devs is that they think they are clever enough to fix bugs in it. Everyone knows that casual players are more clever than the devs in terms of finding exploits and bugs. Starbound, even though it is a different game, it has a mode where you can play with whatever the devs had added and fixed in a day allowing players, at their own risk, to find bugs and exploits so that the devs can fix them. I wouldn't mind seeing the FTB mod devs to try something similar to this where they can update the mods whenever they see fit to do so, not every single day because I'm sure they all have IRL jobs.
The only thing I dislike about mods only being allowed to be tested by mod devs is that they think they are clever enough to fix bugs in it. Everyone knows that casual players are more clever than the devs in terms of finding exploits and bugs
As a general rule of thumb, you want to eliminate as many bugs as humanly possible during dev/closed testing- its easier to get the relevant information from someone who knows what they are doing, rather than the 'OMG it broke- FIX IT!!!' which comes with casual players who probably installed it wrong with a tonne of other crap or broke it with Minetweaker et al. Signal to noise ratio my friend.
Casual players only become useful for the hard to find bugs; where there sheer number of players will inevitably root it out through pure dumb luck. If that actual report makes it back through the slog of installation errors and StupidIDException is another matter altogether.
