SAM (unfinished)

[immibis]

Download

This is a mod I made in 1.2.5, because "why not clone Buildcraft?". Then I stopped working on it in 1.2.5. Just now I updated it to 1.6.4, and decided I should finish it, but I can't think of anything to add for it to be finished! That's why I'm posting it here - to get ideas.

Current features:

• Pipes! There are four tiers of pipe materials. Cobblestone < wood < iron < gold. Each tier has a different colour and speed that items move at.
  
• Pipes more than one tier apart do not connect (eg: cobblestone+wood connect, cobblestone+iron do not).
  
• Pipe modules. Right click a pipe with a module to add it. Module is indicated by a coloured line on the pipe.
  
• Vacuum modules - like BC obsidian pipes.
  
• Extractor pipes - like BC wooden pipes, but do not require any signals or engines. Extraction speed is determined by pipe tier. Right-click with a SAM wrench to set direction.
  
• Directional pipes - like BC iron pipes. Right-click with a SAM wrench to set direction.
  
• Item filter pipes - like BC diamond pipes. Right-click with a SAM wrench to set filters.
  
• FORTH pipes - run Forth programs (DEPRECATED; there will be another programmable block later)
  
• Tagging pipes - add or remove string tags, set colour tags. Tagging explained below.
  
• Tag filter pipes - filter by string tags.
  
• Colour filter pipes - filter by colour tag.
  
• Insertion pipes - like Additional Pipes or Additional Buildcraft Objects or Thermal Expansion insertion pipes. Right-click with a SAM wrench to set preferred direction. (DEPRECATED)
  
• Redstone control pipes - when powered, items will prefer to go a different way. (There is no automatic routing; the pipe directly before the redstone control pipe should be an intersection)
  
• Redstone detector pipes - emits a redstone pulse each time an item passes through.
  
• Acceleration pipes - gives items a speed boost.
  
• Deceleration pipes - remove speed boost from items.
  
• Automatic crafting tables, with 100% less nerfs!
  

Unfinished things:

Module icons are very, very plain, and some modules have the same colour as other modules.

Unfinished texture for Automatic Crafting Tables.

Automatic Crafting Tables should pull from adjacent chests.

Many features that should be added but haven't been thought of yet.

Tagging: Every item travelling through a pipe has a colour tag (or not), and zero or more string tags. Colour tags are like RP2. String tags are more versatile - instead of 16 predefined choices, you can use any string, and an item can have more than one string tag. Colour filter pipes filter by colour, and tag filter pipes filter by string tags.

FORTH pipes. YOU DO NOT NEED TO KNOW THIS TO USE THE MOD even though it takes up over half of this post.

If you knew RP-Forth, great! Otherwise ask someone (including me) if you're unsure of the syntax. Example program after the word list.

List of basic FORTH words:

• WORDS - prints all words to the output area (not very useful)
  
• PAGE - clear output area
  
• . - print a number to the output area
  
• RETURN
  
• CR
  
• DUP, DROP, SWAP, OVER, ROT, -ROT, NIP, TUCK, ?DUP, 2DUP, 2DROP, 2SWAP, 2OVER - stack manipulation words as usu
  
• DO ... LOOP, DO ... +LOOP, UNLOOP, I, J
  
• BEGIN ... UNTIL
  
• BEGIN ... WHILE ... REPEAT
  
• BEGIN ... AGAIN -- infinite loop
  
• ... IF ... THEN
  
• ... IF ... ELSE ... THEN
  
• Comparison operators: 0= 0<> 0< 0> <> < > <= >= =
  
• Arithmetic: + - * / MOD 1+ 1- NEGATE
  
• MAX, MIN
  
• Bitwise: AND, OR, XOR, INVERT
  
• TRUE, FALSE
  
• 2*, 2/
  
• line comments: ...
  
• inline comments: ( ... )
  
• VARIABLE name
  
• Memory access: @ !
  
• size ARRAY name
  

List of pipe-specific FORTH words, with stack comments:

• side ( -- last-item-input-side )
  
• emit ( output-side -- )
  
• tag? word ( -- has-tag? ) (checks for a string tag)
  
• tag+ word ( -- ) (adds a string tag, if not already present)
  
• tag- word ( -- ) (removes a string tag, if present)
  
• coltag@ ( -- colour-tag ) (reads colour tag)
  
• coltag! ( colour-tag -- ) (sets colour tag)
  
• item? ( -- item? ) (returns TRUE if the pipe is currently processing an item)
  
• white orange magenta lightblue yellow lime pink grey gray lightgrey lightgray cyan purple blue brown green red black ( -- colour ) (constants for colour values)
  
• nocolour ( -- colour ) (constant colour value representing "no colour", use "nocolour coltag!" to remove colour tag)
  

If you have defined a word "item", it will be called each time an item passes through the pipe.

Example FORTH pipe program:

: item

    blue coltag@ = IF

        red emit

    ELSE

        blue coltag!

        green emit

    THEN

;

With this program, any item tagged blue will go out the red side, and any other item will be tagged blue and go out the green side.

[TheBytemaster]

Ooh! Shiny! This looks like it has a great deal of potential! I think I'll be following this closely.

I like buildcraft, but it feels kind of bloated/old to me.

I like AE, but it feels kind of cheaty/OP to me. I like my items to have a physical location, not be stored in some ethereal magic techno-ether somewhere.

I have wanted to figure out logistic pipes, but the learning curve, (or at least, apparent learning curve), turned me off. (Or maybe I was just lazy at the time.)

This feels like it could be something quite interesting, perhaps a smattering of all of these flavors, but more refined and focused, as well as a taste of the redpower tubes I loved so much. Do you already have an idea of what direction you're going to take this in?

One of the few ideas I have for the moment would be to perhaps implement some kind of FORTH dictionary/starting guide via either book or terminal into the game, for those of us who never bothered to learn it before. With a few extra/more complex script examples, like a basic string sorting program or something.

The other idea I have for now would be some sort of auto-mining mechanism that isn't quite as cheaty/ham-handed/simple as BC's almighty quarry.

Maybe some sort of multi-block mining mech/crane type thing you have to design and build/program yourself? That could be an interesting way to improve on buildcraft. I've never quite come across a mod that did in-place auto-mining in a very interesting way. More power compatibility for it, (BC, EU, TE, etc,), would be nice too.

Question, do you have plans to re-implement/re-use any of the buildcraft power functions? Or is this more of a tubes-only thing?

[dwwojcik]

The other idea I have for now would be some sort of auto-mining mechanism that isn't quite as cheaty/ham-handed/simple as BC's almighty quarry.

I had an idea for that. You have to craft and build 2 parallel rails, and once they have been built in a permitted configuration and they are powered the arm will spawn and move back and forth.

Like this:

I think that would be neat, and more hands on certainly more plausible than the quarry.

[TheBytemaster]

I had an idea for that. You have to craft and build 2 parallel rails, and once they have been built in a permitted configuration and they are powered the arm will spawn and move back and forth.

Like this:

(snip)

I think that would be neat, and more hands on certainly more plausible than the quarry.

See, that's kind of along what I had in mind. Building a big multi-block quarry with rails, motors, and such would be a ton of fun if done right, in my opinion. And far more balanced/interesting than the any-size-is-free BC quarries.

Programming it or some kind of industrial control machine for it would be fun too, and it would encourage learning a bit of programming in a more focused/incentive-led way than the blank slate that is computercraft. An extension to FORTH could be used, maybe?

Some kind of industrial control block for the various motors/pneumatics and such? Maybe it would have an API for both Computercraft and forth?

Pneumatics as computer/industrial control block controlled pistons with up-gradable lengths/properties? That could be a fun way to manage the movement of the quarry.

Ooh, pneumatic pistons with embedded pipes in their arms. Maybe even with inventory manager things on the end.

Imagine it, a frame with pistons in the edges, all working together to push a downward facing piston with an embedded tube in it around, which then pushes down a drill. All managed via computer. Glorious.

I don't really know about feasibility or the scale of this project at this point, just throwing out random ideas/wouldn't-it-be-amazing-if for now.

[dwwojcik]

Here we go: the Block Manipulation Gantry. Yeah, yeah, right?

It can both break and place blocks, but you'd have to program it. Maybe it could ship with a quarry program built in for those not proficient in forth, but if properly programed it could have the potential to do much more complicated tasks, like maybe a huge industrial farm. (break wheat, plant seed, next). It could also function as the builder clone, if you wanted to add one.

[XxBrookeHasSwaggXx]

I can help

[immibis]

One of the few ideas I have for the moment would be to perhaps implement some kind of FORTH dictionary/starting guide via either book or terminal into the game, for those of us who never bothered to learn it before. With a few extra/more complex script examples, like a basic string sorting program or something.

If FORTH turns out to be important, then that's a good idea.

The other idea I have for now would be some sort of auto-mining mechanism that isn't quite as cheaty/ham-handed/simple as BC's almighty quarry.

I didn't think quarries were OP before the speed buff. I can't tell if that's because they actually

weren't, or because of some aspect of the way I played. Maybe it's because you had to wait for the quarry to mine out all the upper layers before reaching anything interesting - I had a max-size quarry in my 1.0.0 SSP world that never hit bedrock before I got bored with the world!

Maybe some sort of multi-block mining mech/crane type thing you have to design and build/program yourself? That could be an interesting way to improve on buildcraft. I've never quite come across a mod that did in-place auto-mining in a very interesting way.

Not even RP2? Although, even building an RP2 autominer was exciting the first few times and boring after that. I'm not sure if that's possible to avoid.

Question, do you have plans to re-implement/re-use any of the buildcraft power functions? Or is this more of a tubes-only thing?

I'm sure there will be a power system at some point. I preferred old IC2 power over BC, though - it has more depth.

On the other hand, I made an unreleased mod of Buildcraft that has a similar kind of depth in a different way [eg: you could build power storage yourself using loops, switch pipes/iron pipes, diamond pipes, and gate logic]

I definitely do not want to make a power system like Redstone Flux or new Buildcraft, though - where you connect everything together, and that's it, and there's nothing more you can do (except add more storage). Even old Buildcraft beats that (until it became incredibly easy to explode pipes), because there was no storage.

Here we go: the Block Manipulation Gantry. Yeah, yeah, right?

It can both break and place blocks, but you'd have to program it. Maybe it could ship with a quarry program built in for those not proficient in forth, but if properly programed it could have the potential to do much more complicated tasks, like maybe a huge industrial farm. (break wheat, plant seed, next). It could also function as the builder clone, if you wanted to add one.

That would be cool. Like a BC quarry, but you have to program the arm? (And perhaps the frame has to entirely surround the area)

The controller would still be a magic block like the quarry.

PS. Does anyone else have a problem where items won't ever move downwards at an intersection? It could be a Java bug, since it disappears if I put a breakpoint anywhere in the relevant code, *even if the breakpoint is never hit*

[TheBytemaster]

That would be cool. Like a BC quarry, but you have to program the arm? (And perhaps the frame has to entirely surround the area)

That's kind of what I meant by "stationary" mining mech. RiM and Redpower frames aren't what I meant, but I suppose they sort of apply apply. You could have an extendable crane "arm" that zips around on a multiblock rail system, reaching down to do stuff.

But giving it more flexibility would be really cool, and give it a much more unique role. You could even use it like a 3D printer.

If that is done though, I'd like to put in a vote for a system like the IC2 miner, where the pipes to reach down weren't free, you had to craft them.

Interesting idea; how about different progressive types of heads for the crane thing instead of one omni-head? You could have multiple arms zipping around on shared tracks or something. Or maybe modules for heads. I dunno.

[dwwojcik]

That would be cool. Like a BC quarry, but you have to program the arm? (And perhaps the frame has to entirely surround the area)

The controller would still be a magic block like the quarry.

Exactly. The controller should be a magic block, because the idea is that it's a computer. The arm would be programmable. Also, I think the ability to place blocks would take the gantry from a more complicated quarry to a truly flexible and powerful tool.

Also, I think a preloaded quarry and builder programs (at least primitive ones) would make it much more accessible.

Interesting idea; how about different progressive types of heads for the crane thing instead of one omni-head? You could have multiple arms zipping around on shared tracks or something. Or maybe modules for heads. I dunno.

Multiple heads sounds reasonable, although I would suggest only a few general-purpose types. Modules sounds much better than more than one arm, remember immibis has to code this stuff and we have to program it! How would collisions be handled?

[TheBytemaster]

Exactly. The controller should be a magic block, because the idea is that it's a computer. The arm would be programmable. Also, I think the ability to place blocks would take the gantry from a more complicated quarry to a truly flexible and powerful tool.

Also, I think a preloaded quarry and builder programs (at least primitive ones) would make it much more accessible.

Multiple heads sounds reasonable, although I would suggest only a few general-purpose types. Modules sounds much better than more than one arm, remember immibis has to will probably be the one to, (if he wants to), code this stuff because he is awesome and we have to program it! How would collisions be handled?

They just...collide and declare that movement invalid or something? Maybe some sort of junction track ? I don't know. That was just a brainstorm idea anyways, it would certainly look cool to have multiple arms zipping around in a factory.

[dwwojcik]

I was just thinking about how glitchy big entities can get, I'm not sure how well the collisions would work. I agree, it could be awesome.

[TheBytemaster]

I'm not sure about this, but I would imagine that each arm would have a "base" that it retracts into. I'd imagine them to be a block in size. (Maybe it has a small invintory too? Along with upgrade slots?)

The bases would be the only thing allowed to move; the arms would have to retract into their bases before moving. Poof, no weird collisions with terrain, and no huge moving entities to worry about.

Now, while I'm here, maybe I can ask a technical question.

What is a tile entity exactly? And how does it differ from a regular entity/a block? I keep hearing people refer to them but I don't really understand what they are.

[planetguy]

A tile entity is additional data that Minecraft stores with certain blocks. Blocks have 4 bits of metadata (enough for 16 different values, such as wool colours) but that isn't enough information to store, for example, the contents of a chest or furnace, so that is stored in tile entities.

[TheBytemaster]

A tile entity is additional data that Minecraft stores with certain blocks. Blocks have 4 bits of metadata (enough for 16 different values, such as wool colours) but that isn't enough information to store, for example, the contents of a chest or furnace, so that is stored in tile entities.

Ah, I see. Thanks!

If I get the time today, I'll mock up some of the ideas in here to see how they look.

[immibis]

Programmable quarries are cool, but I was hoping someone had ideas for the item pipes.

Also, added liquid pipes! These are based around pressure and velocity, instead of being like BC/RP2/TE/every other pipe. Which is pretty cool.

Note - pipes always render as full, even though they only buffer a few ticks of fluid.

As a temporary way to make them somewhat useful, they will extract and insert from blocks that use Forge's fluid system.

To set a pipe to extract from adjacent blocks, shift-right-click on the top with a wrench. Other pipes will insert into blocks. They will not visually connected.

Btw, unused pipes show a reed texture instead of a liquid, that's obviously temporary too (like everything in this mod).

Screenshot: (diamond thing is a Tubestuff liquid duplicator; lava things are Tubestuff liquid disposers)

[planetguy]

So you want ideas for pipes...

Energy in the form of items' inertia? Item accelerators and turbines? Smooth (read: expensive) items and pipes lose less energy? Item cannons?

Maybe you can transmit energy as hydraulic pressure? You could have a hand pump and pumps that use mods' energy systems? Intakes that get a small amount of pressure from being below lots of still water? Hydraulic turbines? Multiblock hydraulic pistons that move tile entities? Or crush blocks into other blocks, like cobble->stone, netherrack -> nether brick, etc? If you break a tube under pressure the pressurized liquid hurts you? (Seriously, there's a Darwin Award like this somewhere.)

[Neowulf]

I'd say break the FORTH pipe into an Automation Pipe and a Forth Processing Unit block.

That way the automation pipe can be setup as a computercraft and/or opencomputers peripheral and controlled by those, or by the built in forth processor block.

Pipe ideas:

Liquid Packetizer module- Allows a liquid pipe or liquid storage block to connect to an item pipe network, turning a bucket worth of liquid into an item. Liquid item will only consider liquid packetizer modules in output mode as valid destinations and will not enter normal item storage. This would allow sending items and liquids to a destination block with a single pipe connecting to it (example water and coal to a steam dynamo from TE) or multiple different liquids without clogging the system (example water and fuel to a BC combustion engine).

Entity compressor/decompressor block- Do you think you could swing shifting the players viewpoint (like Morph does to a small creature), disabling their clipping (so they don't suffocate), and locking their movement to that of an item traveling through the pipes?

Yeah it's a bit wacky, but pipe roller coaster transport through a base would be awesome.

[TheBytemaster]

So you want ideas for pipes...

Energy in the form of items' inertia? Item accelerators and turbines? Smooth (read: expensive) items and pipes lose less energy? Item cannons?

I second this idea. I've always found the most effective/fun concepts and mod things are ones you can see; the ones that take place in the "physical" minecraft world, not in an inventory somewhere. Sending power around via item inertia would be awesome. I suddenly have the desire to power things with fast-moving streams of cobblestone.

But see, cobble or dirt would be cheap, sure, but it would also cause a lot of friction. Stone would be slightly better, but not much. The more items you use, the more friction they cause, a-la IC2 packet size/transmission rates.

Specialized kinetic energy holding items could be made. Heavier/smoother/more expensive things work better.

Maybe some kind of lube is needed?

Maybe some things can't handle huge amounts of kinetic energy, and it has to be siphoned off by a long line of blocks that each slow an item down a bit. Or maybe they can't go around corners above a certain velocity without exploding/emitting a fast-moving ballistic projectile.

Entity compressor/decompressor block- Do you think you could swing shifting the players viewpoint (like Morph does to a small creature), disabling their clipping (so they don't suffocate), and locking their movement to that of an item traveling through the pipes?

Yeah it's a bit wacky, but pipe roller coaster transport through a base would be awesome.

Oh. Yes please. The applications are endless for that. What if we accelerated a player, (at full size), to high speeds and used the decelerator to slow them down without killing them? Could that be used to transmit power?

What if all of the energy was simply mechanical? Storage could be in flywheels, various tiers could hold more/go faster without having problems? What about giant multi-block flywheels for powering railgun-teir acceleration?

So many crazy ideas...

[immibis]

Added Tag Filter Module and Colour Filter Module - now you don't need to use FORTH pipes to read tags. Also removed console spam.

I'd say break the FORTH pipe into an Automation Pipe and a Forth Processing Unit block.

That way the automation pipe can be setup as a computercraft and/or opencomputers peripheral and controlled by those, or by the built in forth processor block.

Agreed - but maybe the Automation Pipe could be split further. Perhaps there could be a thing you clip onto the outside of a pipe to make it not accept items when given a redstone signal.

Pipe ideas:

Liquid Packetizer module- Allows a liquid pipe or liquid storage block to connect to an item pipe network, turning a bucket worth of liquid into an item. Liquid item will only consider liquid packetizer modules in output mode as valid destinations and will not enter normal item storage. This would allow sending items and liquids to a destination block with a single pipe connecting to it (example water and coal to a steam dynamo from TE) or multiple different liquids without clogging the system (example water and fuel to a BC combustion engine).

I don't like this. You can already use buckets to multiplex liquids. You can't input buckets to liquid storage blocks unless the block is already designed for that, of course. If you want to not run liquid pipes, you'll need an unbucketing station near the machines.

If you want to run multiple liquids into the same machine, use multiple liquid pipes! I don't want to make things compact just for the sake of making them compact.

Entity compressor/decompressor block- Do you think you could swing shifting the players viewpoint (like Morph does to a small creature), disabling their clipping (so they don't suffocate), and locking their movement to that of an item traveling through the pipes?

Yeah it's a bit wacky, but pipe roller coaster transport through a base would be awesome.

Funny you should mention that. I found this in the code earlier:

package mods.immibis.sam;



public enum Transport {

    ITEM, LIQUID, POWER, MOBS, PLAYERS

}

It's obsolete unnecessary code, so I will remove it eventually. Nothing other than ITEM and LIQUID was ever used.

It would indeed be cool to send yourself around with pipes.

I second this idea. I've always found the most effective/fun concepts and mod things are ones you can see; the ones that take place in the "physical" minecraft world, not in an inventory somewhere. Sending power around via item inertia would be awesome. I suddenly have the desire to power things with fast-moving streams of cobblestone.

But see, cobble or dirt would be cheap, sure, but it would also cause a lot of friction. Stone would be slightly better, but not much. The more items you use, the more friction they cause, a-la IC2 packet size/transmission rates.

Specialized kinetic energy holding items could be made. Heavier/smoother/more expensive things work better.

That's a very unique idea, XD. Something like RP2 accelerators, where decelerators also produce power proportional to the item speed?

Maybe some kind of lube is needed?

I've read that RotaryCraft now requires a constant supply of lube for some types of engines. If anyone's used RotaryCraft, how annoying is this?

Perhaps you need to use a separate machine to lubricate items, and speed boosts last even longer for lubricated items than unlubricated ones. Or perhaps it's the same machine - accelerators can optionally take lubricant, which makes them give more speed. Or perhaps the lubricant is required.

Gold pipes are already very fast (~8 blocks/second, which is 4x iron) That could be reduced, or it could be kept the same and accelerated items go even faster. Having items travel extremely quickly over long distances would mean that optimizing chunk loading will be a future priority.

What if all of the energy was simply mechanical? Storage could be in flywheels, various tiers could hold more/go faster without having problems? What about giant multi-block flywheels for powering railgun-teir acceleration?

Like RotaryCraft?

So many crazy ideas...

Energy in the form of items' inertia? Item accelerators and turbines?

Basically what TheBytemaster said? (Yes, I'm aware your post was first. I'm replying in reverse order, just because)

Item cannons?

If item cannons just shoot items at high velocity, then with item accelerators, you could already make simple item cannons. To make it more useful, you'd need a way to aim pipes at a 45-degree angle, or a controllable angle. Then they would be useful for transporting items long distances. Should item cannons do anything else?

Maybe you can transmit energy as hydraulic pressure? You could have a hand pump and pumps that use mods' energy systems? Intakes that get a small amount of pressure from being below lots of still water? Hydraulic turbines? Multiblock hydraulic pistons that move tile entities? Or crush blocks into other blocks, like cobble->stone, netherrack -> nether brick, etc? If you break a tube under pressure the pressurized liquid hurts you? (Seriously, there's a Darwin Award like this somewhere.)

Another alternate power system idea. I don't like the idea of giving liquids two very different purposes, so hydraulic power pipes couldn't be connected to liquid transport pipes, except through machines.

Hydraulic pressure makes a lot of sense for enhanced pistons that need power. Much more sense than electricity, anyway. Plus, you could connect many pistons to one hydraulic pipe, and then extend them all at once by activating a valve (and then retract them with another valve).

It would seem weird to have a crafting room with a macerator running on hydraulic power. It also doesn't seem like a good idea for long-distance transmission. Perhaps it should be confined to pistons and other similar things (like moving programmable block gantries! Or maybe that would make them too hard to set up)

[planetguy]

I had imagined item cannons as being useful as weapons, as in fired TNT explodes when it arrives, metal blocks smash through blocks, any item damages what it hits, etc. Alternatively, only items have special effects (substituting gunpowder and ingots for TNT and metal blocks) and blocks are placed where they land. Or maybe there's a transport cannon separate from tactical cannons?

You do have a point that hydraulics isn't right for everything, though. Maybe use it for moving blocks or quarry parts only and use the inertia grid for everything else?

If you're going to do the item inertia power system, it might be best to have better pipes only reduce friction, and not add velocity.

[immibis]

The mod is not updated, this is stuff I am working on. Yes, textures are horrible (although maybe fitting the simplistic style of this mod).

Redstone control modules - when powered, items will prefer to avoid them:

These are just pipe modules that render differently, not new blocks, so they connect normally:

Acceleration and deceleration modules. Power not implemented. The base speed of items still depends on the pipe material, but they can go faster after they go through an accelerator:

Gold pipe speed is reduced to compensate - to 3 blocks/second, from 8. Boosted items in gold pipe go up to 10 blocks/s.

Speed of accelerated items - maybe too high?

Cobblestone pipe - items cannot be accelerated.

Wooden pipe - items go up to 3 blocks/s (instead of 1), lasts for 25 blocks.

Iron pipe - items go up to 6 blocks/s (instead of 2), lasts for 80 blocks.

Gold pipe - items go up to 10 blocks/s (instead of 3), lasts for 175 blocks.

Also:

Fixed "pick block" for non-cobblestone item pipes.

Fixed pipes z-fighting in your hand in third-person.

[TheBytemaster]

Redstone control modules - when powered, items will prefer to avoid them:

Oh heck yes. I've felt the need for that exact thing many times. Thank you.

Acceleration and deceleration modules. Power not implemented. The base speed of items still depends on the pipe material, but they can go faster after they go through an accelerator:

Gold pipe speed is reduced to compensate - to 3 blocks/second, from 8. Boosted items in gold pipe go up to 10 blocks/s.

Speed of accelerated items - maybe too high?

Cobblestone pipe - items cannot be accelerated.

Wooden pipe - items go up to 3 blocks/s (instead of 1), lasts for 25 blocks.

Iron pipe - items go up to 6 blocks/s (instead of 2), lasts for 80 blocks.

Gold pipe - items go up to 10 blocks/s (instead of 3), lasts for 175 blocks.

Those speeds sound about right to me. I just now realized how cool it is that you have unified item and power transport lines.

NOTE: (I'd never heard of rotarycraft before you mentioned it yesterday. But it looks kind of cool, I'll have to play with it and see what I think about the lube thing you mentioned.)

And a somewhat selfish small request; I'm sure someone, somewhere has made this, but I've never seen it, and can't find it. Could you include a block with a texture on the top that acts as a simple NSEW compass?

As in, the texture points/renders to the in-world NSEW? I've always wanted something like this, just to orient myself without having to rely on a minimap, but the closest thing I could find was atomicstryker's compass mod, which isn't really what I was looking for.

[Lethosos]

May I point out that all textures on the top of all blocks follow the same cardinal drawing direction? I suggest grabbing some random resource pack, and mutilate one texture (say the iron block,) so that the top edge is some bright color. Then load MC and that resource pack, go Creative, and place iron blocks.

[Dentcat]

I think that the pipe travelling system, if you decide it's a good idea, should be like that pod shuttle in that film, alas, I forget the name.

I mean, you lay down in a pod, and it goes through a pipe that fits the pod. Got to have windows, though. I think it should be more expensive than rail, (I'm thinking obsidian, iron, glass and cables, and need external power) but able to travel through 1 block spaces, as you would if you were laid down in a pod, and also vertically, because you are in a pod, you are not going to fall out. A lot less silly than shrinkification to fit inside pipe, and possibly/probably already done in the real world. I can imagine great, fully functional transport networks and elevator systems. Just a suggestion on how silliness can be prevented with the proposed idea, and still be awesome.

I like the progress on the mod, and I approve of your work, as Buildcraft doesn't work with my custom modpack, so I am glad you are making this. I wish I could help, but I know very little about coding outside ComputerCraft's LUA, and even then I can hardly move a turtle. Anyway, I really do like this.

[TheBytemaster]

May I point out that all textures on the top of all blocks follow the same cardinal drawing direction?

That's what I meant, and while I know that I could do what you suggested, it would be nice to have something slightly more legit. Plus I believe it would make a nice little trinket addition for those who never thought of that. Up to immibis, (Immibis? immibis? am I supposed to capitalize that or not?), on what he wants to do, I suppose.

Travling people-pods.

That sounds interesting. And it also sounds like a place where pneumatics/hydraulics would be very well suited to use.