immibis

Necrobump. I'm around again! Current thoughts: Having multiple tiers of pipes is probably a bad thing, since it adds complexity. Compare to BuildCraft where there is mostly only one tier of pipe, and so the things you place are like pipes with modules pre-applied. It reduces inventory clutter compared to having to carry around pipes + modules separately. Should pipe intersections send items in random directions? I don't know. Currently items try to continue in a straight line. Liquid pipes should be connectable to machines. I don't remember whether liquid pipes are in any released version. The details might be tricky to figure out since SAM liquid pipes work differently from every other type of liquid pipe - they are based around velocity, rather than volume. Autocrafting tables should pull from adjacent chests, like in BuildCraft. This shouldn't be a problem to add. Pipe items shouldn't be entities, because nothing should be entities, because entities are based around Mojang code which isn't as reusable as it seems, and pipe items are too dissimiliar to anything Mojang's tried to do. This is an internal thing. How can I make this useful? There's not very much you can do with pipes by themselves, so they are not fun by themselves. BuildCraft had mining wells and quarries for a long time, so that you could use the mod, by itself, to automatically get ingots for you. It also had pumps and oil for not quite as long, which didn't really let you do anything you couldn't do before - the introduction of engines was basically a nerf to most things - but added more stuff to play with before you could set up your automatic ingot system. Forestry (the really old version, in Beta 1.8) added a lot of stuff that was tricky to automate. Once you did it, though, free wood forever! This was good - it was a significant challenge (that therefore took a lot of time and was fun to solve), with a useful end result. Even better, you could stop at any point and have a farm that required a varying amount of manual intervention. And successive parts got harder and harder to automate, so it took a long time to get a fully automated system (at which point you run out of stuff to do with Forestry, which is a bad thing). Forestry is not special in this - there always have been and always will be mods with the same property. Around Beta 1.7-1.8, there was also Equivalent Exchange (other imbalances notwithstanding), IndustrialCraft 1 and 2. Currently there's MineChem, Factorization, Mekanism, AE2, Liquid XP, MFR, and so on, to varying extents. None of those seem to be as large as old Forestry by themselves. Mekanism and AE2 have their own transport methods. From the above list, MineChem probably has the most automation challenge potential, but it has major balance issues when used with most other tech mods. There should not be power transfer as long as this mod doesn't have any use for power. Decelerators creating power is a gimmick.

It wouldn't be weird because it's outdated technology, it would be weird because you'd have to use two sides for power. You could have a hydraulic turbine connected to two hydraulic pipes and an axle, then connect the axle to the macerator - then the macerator wouldn't have to have two sides for power...

The OP has been updated to link to the newest version of the mod. Added module recipes. There are no obvious recipes to use for these, so I made them similar to the BC pipe recipes, but with stone instead of glass: Vacuum module: Extractor module: Directional module: Item filter module: Tag filter module: Colour filter module - any vanilla dye works: Tagging module - any vanilla dyes work: FORTH module: Insertion module: Redstone control module: Redstone detector module: Acceleration module: Deceleration module: Note: FORTH modules and insertion modules are likely to be removed at some point. There will be a replacement for FORTH modules; insertion modules can already be constructed (less compactly) out of pipes. Deceleration pipes are redundant - items cannot be accelerated through cobble pipes, so a single piece of cobble pipe acts as a decelarator. If I decide to not make them produce power, they will be removed later. By the way, SAM stands for "Simple Automations Mod". Yes, "automations" with an "s".

Saying "it works with pipes other than iron" (from a BC perspective) is equivalent to saying "it works with modules other than redstone control modules"... and neither is a particularly useful thing to say.

Well yes, but only because the fact that a pipe is made of iron means something completely different.

With an iron pipe you need something like this: R -+- W R = redstone signal W = wooden pipe (input) - = any pipe (output) + = iron pipe With a redstone control module you need something like this: R X+- | R = redstone signal X = pipe with redstone control module + = pipe | = pipe (output) - = pipe (input)

It should be about the same size...

In Buildcraft you can do something similar using an iron pipe. I should reiterate that I don't think this is a good power transfer system. But if someone wants to do it (maybe they don't have space for a cable) then they can. You could fabricate lava, fill it into buckets and send the buckets down a pipe into a combustion engine, if you wanted, but nobody does that.

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.

Added Tag Filter Module and Colour Filter Module - now you don't need to use FORTH pipes to read tags. Also removed console spam. 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. 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. 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. That's a very unique idea, XD. Something like RP2 accelerators, where decelerators also produce power proportional to the item speed? 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. Like RotaryCraft? Basically what TheBytemaster said? (Yes, I'm aware your post was first. I'm replying in reverse order, just because) 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? 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)

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)

If FORTH turns out to be important, then that's a good idea. 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! 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. 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. 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*

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.

Is there an interface tile entities or blocks can implement to know when they're being moved?

Get Java 7.