Just making a note of this interaction. It's really minor, you can overcome it with a warp itemduct.
I have a chest that receives a non-stacking item (a Witch's Hand from Witchery). I have a TE plain itemduct leading from the chest to a void drawer locked to that item, and a servo on the chest. When the servo extracts the item, it waits for the item to traverse the entire length of the itemduct and vanish into the void drawer before extracting the next item of that type. If the non-stacking items are coming in fast enough, and/or the itemduct is long enough, the non-stacking items can be arriving faster than the system can void them.
Using warp itemducts instead of normal ones solves this quirk completely because the items will then have no travel time.
But what you CAN do is tape the drawers shut with masking tape! Kinda ghetto but it would work.
So how about you add a masking tape item that "encases" the drawers upon right clicking, and you can pick up and move the encased drawer wherever you want. The tape would dissolve when you set it down because it's cheap. lol
And this reminds me of Mekanism's Cardboard Box. It can be used to pack up any block including its TileEntity, but it has some weirdness: You can put an Aura Node in a box and it will have its aspects rerolled when you unbox it. Also, the empty box has the same block ID as a box with an item in it, so when you're boxing up a whole lot of blocks, and the stack of boxes in your hotbar runs out, Inventory Tweaks will fill the slot with filled boxes instead of empty boxes. Also, the boxes are reusable so there's all kinds of confusion when ITweaks keeps putting empty boxes in your hotbar when you want full ones and vice versa.
A single-use item that's just for packing up a drawer sounds like a great idea and wouldn't have any of those problems.
Reminds me of Thermal Expansion's Strongboxes. They keep their inventory when broken, regardless of tool, though you can break them instantly using shift+right-click with a wrench. The inventory tooltip even shows the contents of the strongbox.
I used to use them as ghetto backpacks. Ahh, those were the days...
I did research a bit the other day, but opinions on that feature sure are varied. Personal experience with any drawbacks?
I have used it for years with no obvious drawbacks. Since my selection box is a textured box rather than a wireframe, I had z-fighting problems early on and never encountered them again after using glPolygonOffset. I also use it to stop z-fighting when I have to render the preview of an imported object (otherwise the imported blocks will fight with the blocks already in the world). In fact, I have a list of constants for ordering the different things that get rendered so they all overlap correctly without any fighting.
If there's a drawback, it's that the GL doesn't give you a way to do a "relative" offset. If you have nested elements that need to be offset from one another, you'll need to track the current offset level in the elements themselves. But frankly that didn't even occur to me until recently when I started doing multiple imports and saw them fighting with each other.
Another potential drawback is that it interacts with the precision of the screen-space Z-buffer, incrementing it by the minimum possible difference between two float values. For objects close to the screen, this is a small value, but as you get further away that difference increases, but this isn't even noticeable in practice - I didn't start to see it until rendering things over 5000 blocks away. And even then, at those distances you are guaranteed to see z-fighting if you're trying to do the offset in world space.
Did you know you can use glPolygonOffset to render labels and decals on top of other surfaces and completely avoid z-fighting? It's true! Polygon offset uses the screen-space Z values to offset pixels, which guarantees they will always come in front - unlike world-space values which suffer precision loss during the conversion to screen-space, leading to unsightly z-fighting at a distance.
Enable GL_POLYGON_OFFSET_FILL, then call glPolygonOffset(-1, -1) before drawing your decal. Negative values are offset toward the viewer. No more adding 0.01 to your Z coordinates!
glPolygonOffset is provided by OpenGL 1.1 and should be available on all systems.
I've had ideas to make conversion an optional upgrade in a future release.
I like that idea. Better to be explicit than implicit. If you're not aware that conversion is going on, it looks like your items are just disappearing when you click them into the controller.
I found the configuration option for turning off conversion, but I just thought I'd mention this:
The oredict conversion will turn Thaumcraft gold coins into gold nuggets. However, gold coins can be melted down for 1 Lucrum essentia; gold nuggets only yield 1 Metallum. Thus, a gold coin can be used to transmute 2 iron nuggets into gold nuggets while the gold nuggets themselves cannot. I had to take care not to put my gold coins into storage or they would end up as gold nuggets in the compacting drawer. Thinking on it again, I should have tried storing gold coins instead and converting the nuggets into coins, which would allow me to transmute ALL of my iron into gold without having to use other sources of Lucrum.
I believe the search order for empty drawers is related to the way it finds all of the drawers in a connected bank. It's fairly unpredictable as it depends on the orientation of the drawer bank relative to the world axis as well as the position of the controller within the bank.
A few pages back, somebody requested a drawer that acts like a regular chest. I think that's a nice idea and might be relevant to your suggestion.
how about overflow in the pipe system. Near as I can tell if the item won't go anywhere the pipe will simply stop working. If the controller or slave had a side that ejected such items that would be great.
Might not help you much, but I know EnderIO's item conduits have a "priority" setting. You can set the conduit on the controller or slave to have a higher priority than the conduit on your overflow container, and it will always try the controller or slave first before trying the other container.
0
Oh, I forgot to note that the drawer is already full of witch hands. Until it is full, the hands come in at full speed.
0
Just making a note of this interaction. It's really minor, you can overcome it with a warp itemduct.
I have a chest that receives a non-stacking item (a Witch's Hand from Witchery). I have a TE plain itemduct leading from the chest to a void drawer locked to that item, and a servo on the chest. When the servo extracts the item, it waits for the item to traverse the entire length of the itemduct and vanish into the void drawer before extracting the next item of that type. If the non-stacking items are coming in fast enough, and/or the itemduct is long enough, the non-stacking items can be arriving faster than the system can void them.
Using warp itemducts instead of normal ones solves this quirk completely because the items will then have no travel time.
1
Just sent in a patch adding the Treated Wood drawers. Immersive Engineering fans rejoice!
0
Hold that thought - I think I can do this.
Well, maybe.
0
I humbly request a drawer texture and crafting recipe for Immersive Engineering's Treated Wood planks. Here's a preview:
Bottom row is the default planks, the other two are "chiseled" variants you can craft in hand.
0
Very nice!
0
And this reminds me of Mekanism's Cardboard Box. It can be used to pack up any block including its TileEntity, but it has some weirdness: You can put an Aura Node in a box and it will have its aspects rerolled when you unbox it. Also, the empty box has the same block ID as a box with an item in it, so when you're boxing up a whole lot of blocks, and the stack of boxes in your hotbar runs out, Inventory Tweaks will fill the slot with filled boxes instead of empty boxes. Also, the boxes are reusable so there's all kinds of confusion when ITweaks keeps putting empty boxes in your hotbar when you want full ones and vice versa.
A single-use item that's just for packing up a drawer sounds like a great idea and wouldn't have any of those problems.
0
Reminds me of Thermal Expansion's Strongboxes. They keep their inventory when broken, regardless of tool, though you can break them instantly using shift+right-click with a wrench. The inventory tooltip even shows the contents of the strongbox.
I used to use them as ghetto backpacks. Ahh, those were the days...
0
I have used it for years with no obvious drawbacks. Since my selection box is a textured box rather than a wireframe, I had z-fighting problems early on and never encountered them again after using glPolygonOffset. I also use it to stop z-fighting when I have to render the preview of an imported object (otherwise the imported blocks will fight with the blocks already in the world). In fact, I have a list of constants for ordering the different things that get rendered so they all overlap correctly without any fighting.
If there's a drawback, it's that the GL doesn't give you a way to do a "relative" offset. If you have nested elements that need to be offset from one another, you'll need to track the current offset level in the elements themselves. But frankly that didn't even occur to me until recently when I started doing multiple imports and saw them fighting with each other.
Another potential drawback is that it interacts with the precision of the screen-space Z-buffer, incrementing it by the minimum possible difference between two float values. For objects close to the screen, this is a small value, but as you get further away that difference increases, but this isn't even noticeable in practice - I didn't start to see it until rendering things over 5000 blocks away. And even then, at those distances you are guaranteed to see z-fighting if you're trying to do the offset in world space.
0
Did you know you can use glPolygonOffset to render labels and decals on top of other surfaces and completely avoid z-fighting? It's true! Polygon offset uses the screen-space Z values to offset pixels, which guarantees they will always come in front - unlike world-space values which suffer precision loss during the conversion to screen-space, leading to unsightly z-fighting at a distance.
Enable GL_POLYGON_OFFSET_FILL, then call glPolygonOffset(-1, -1) before drawing your decal. Negative values are offset toward the viewer. No more adding 0.01 to your Z coordinates!
glPolygonOffset is provided by OpenGL 1.1 and should be available on all systems.
0
I like that idea. Better to be explicit than implicit. If you're not aware that conversion is going on, it looks like your items are just disappearing when you click them into the controller.
0
I found the configuration option for turning off conversion, but I just thought I'd mention this:
The oredict conversion will turn Thaumcraft gold coins into gold nuggets. However, gold coins can be melted down for 1 Lucrum essentia; gold nuggets only yield 1 Metallum. Thus, a gold coin can be used to transmute 2 iron nuggets into gold nuggets while the gold nuggets themselves cannot. I had to take care not to put my gold coins into storage or they would end up as gold nuggets in the compacting drawer. Thinking on it again, I should have tried storing gold coins instead and converting the nuggets into coins, which would allow me to transmute ALL of my iron into gold without having to use other sources of Lucrum.
0
I believe the search order for empty drawers is related to the way it finds all of the drawers in a connected bank. It's fairly unpredictable as it depends on the orientation of the drawer bank relative to the world axis as well as the position of the controller within the bank.
A few pages back, somebody requested a drawer that acts like a regular chest. I think that's a nice idea and might be relevant to your suggestion.
edit: The Boss beat me to it.
0
...oh.
In that case I'm curious what kind of pipes Kreezxil is using!
0
Might not help you much, but I know EnderIO's item conduits have a "priority" setting. You can set the conduit on the controller or slave to have a higher priority than the conduit on your overflow container, and it will always try the controller or slave first before trying the other container.