A range upgrade would be bad for performance, though I may be overstating the impact of a big drawer network. I've already given consideration to such an extension block -- essentially a network bridge connecting two controller networks together. At that point it starts sounding like AE2. I need to chew on the idea some more before I'm willing to commit to it.
Considering that certain mods are dragging their proverbial feet in moving to 1.8; that might give you more notoriety, if that is anything you desire.
What I'd like to know is if I use a chest on a hopper with pipes leading to one controller; by your description only drawers that have been preloaded will accept items, is it possible to gather the items that don't transfer into that controller and send them towards another controller that does, or through a series of controllers until the inventory is depleted. Finally a chest at the end of the chain to gather what doesn't get placed.
Is that possible or am I missing the point of the interface sides?
i've been using jabba now for quite a while and when you said the controls were reversed from jabba you lost me but as i read the next sentence you got me straight back in with the config option, well played. i'll give this wee beauty a whirl now
What I'd like to know is if I use a chest on a hopper with pipes leading to one controller; by your description only drawers that have been preloaded will accept items,
There's a slight distinction here. When you right-click on the front of the controller with an item in hand to insert it, only preloaded drawers will accept the item. If a drawer isn't allocated, you can't right-click the item in. This also applies when you double-right-click to dump your entire inventory into the controller - which I think is a good thing.
However, inserting items via hoppers will insert into empty drawers too. It will prefer to insert into preloaded drawers if possible.
There's a slight distinction here. When you right-click on the front of the controller with an item in hand to insert it, only preloaded drawers will accept the item. If a drawer isn't allocated, you can't right-click the item in. This also applies when you double-right-click to dump your entire inventory into the controller - which I think is a good thing.
However, inserting items via hoppers will insert into empty drawers too. It will prefer to insert into preloaded drawers if possible.
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.
Drawers aren't a pipe system though. They're like a really big chest, that your pipes see via the controller block. What happens when you pipe into a full chest? Same issue. Not sure what the state of item transport is like in 1.8 right now, but it's a reasonably solved problem in 1.7.
Maybe I will add more network blocks to do more advanced things, but my focus is bringing 1.8 to completion first.
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.
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.
There's a slight distinction here. When you right-click on the front of the controller with an item in hand to insert it, only preloaded drawers will accept the item. If a drawer isn't allocated, you can't right-click the item in. This also applies when you double-right-click to dump your entire inventory into the controller - which I think is a good thing.
However, inserting items via hoppers will insert into empty drawers too. It will prefer to insert into preloaded drawers if possible.
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.
Drawers aren't a pipe system though. They're like a really big chest, that your pipes see via the controller block. What happens when you pipe into a full chest? Same issue. Not sure what the state of item transport is like in 1.8 right now, but it's a reasonably solved problem in 1.7.
Maybe I will add more network blocks to do more advanced things, but my focus is bringing 1.8 to completion first.
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.
...oh. In that case I'm curious what kind of pipes Kreezxil is using!
Ok, I figured out.
Btw, I have at least 3 mods that allow items to be moved, NeoTech, TechStack's Heavy Machinery and Hopper Ducts.
In this version I'm using Hopper Ducts.
So, I have a chest on a hopper pointed at a controller, the controller feeds two drawers. The last drawer is on a hopper connected to hopper ducts that pipe items to another controller (2nd screen shot) that feeds its drawer network. Also, this means that you don't have to make a network extender because you've essentially allowed it with hopper interactivity. The other caveat is that the hopper only drains the one drawer unlike if the hopper were placed under the controller.
One more 1.8 alpha. Assuming no major problems, the next version will be the first stable version of 1.8. The only thing missing will be a rendered overlay for the storage upgrades (the ugly iron/gold/etc trim around the edge). Supporting that "well" is going to require a bit more work than I'm ready for right now, so I'll punt and make that a 2.1.0 thing. Solving it properly will also give resource pack creators more leeway in creating something that's actually pretty.
Changelog:
- Fixed status upgrade rendering for all supported blocks.
- Fixed storage upgrades not applying.
- Fixed drawers dropping the wrong status or storage upgrade if one was applied.
Ok, something I might have missed or you didn't tell us. When the Drawer Controller puts items into the connected drawers, what is the method it uses to fill them?
I understand that it first find homes that have like items in them and fills them, but when it comes to empty drawers where does it start looking?
From my point of view it almost looks random, as the items flow in they don't appear to enter in logically.
I think tho that I just understand the logic and that is what I want to know, how does it determine which empty drawer gets loaded?
However, can I make some suggestions that maybe you might make.
Allow the storage drawer network to allow regular chests to be included and said regular chest all act as overflow, only receiving items if said items can't be stored elsewhere in the drawer network.
and/or
provide a face on the controller or the controller slave that allows for output of items as overflow under the same conditions.
div class="quote-body">
Ok, something I might have missed or you didn't tell us. When the Drawer Controller puts items into the connected drawers, what is the method it uses to fill them?
I understand that it first find homes that have like items in them and fills them, but when it comes to empty drawers where does it start looking?
From my point of view it almost looks random, as the items flow in they don't appear to enter in logically.
I think tho that I just understand the logic and that is what I want to know, how does it determine which empty drawer gets loaded?
The drawers are discovered by a DFS-Dijkstra implementation, with some preferred ordering among the X/Y/Z axes. As I've thought more about it, a BFS search would work better and naturally order the discovered drawers from near to far. By further making the search non-recursive, I would be more open to the idea of range upgrades.
owever, can I make some suggestions that maybe you might make.
Allow the storage drawer network to allow regular chests to be included and said regular chest all act as overflow, only receiving items if said items can't be stored elsewhere in the drawer network.
This is the kind of stuff Refined Relocation does, but Refined Relocation has a concept of priority and lots of other control bits. It's just not ported to 1.8 at this time.
Any inventory could be made part of a drawer network, including chests by writing an adapter to the IDrawerGroup interface. But there's no concept of priority.
provide a face on the controller or the controller slave that allows for output of items as overflow under the same conditions.
The main thing I don't like about this is that a set of drawers is no longer an inventory endpoint. It will greedily take all items, in essence becoming a kind of pipe network of its own. It raises some thorny issues like "what do I do if there's several valid output blocks".
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.
With the revised network search algorithm, the 25x25 theoretical octahedron has been lifted to a guaranteed 25x25 cube. It doesn't matter how convoluted you snake your path of drawers and trim, so long as it's all contained within that volume.
Empty drawers will be populated starting nearest the controller and radiating outward according to the shortest length connecting path.
Hello everyone. I'm half of Paws Gaming. We wanted to do a mod spotlight, so we went scrolling through our long list of mods and came to Storage Drawers. We made a nice thorough spotlight. We tried to show everything this mod has to offer, as well as showing it's compatibility with our other mods. Just wanted to share that video with you. Enjoy!
Currently MIRED in GUI code. Doesn't help that I haven't had a solid few hours to just sit down and work on it.
The new GUI is looking nice. Any plans for it to appear in the 1.7.10 version, or just moving forward on the 1.8 version?
As far as the what to do with overloaded drawers and allowing upgrades to be removed: I say put the onus on the user there and lock the upgrade from being removed if the new maximum would be lower than the current inventory.
Alternately, you could be forgiving and let them remove it and keep the current inventory, but not allow anything new to be added as long as it remains capped out... but this can lead to a bit of abuse with players passing the upgrades around like a key.
The other other options are to delete the excess inventory, or dump the excess on the floor. Both of those are messy options from a player perspective, albeit it the easiest ones to code
Storage Upgrades do not render any overlay on drawers. You'll have to just remember you applied them. For now.
No integration with other mods. Most mods 1.7.10 integrated with have not been ported. WAILA support may come in the near future, when I can get it working in dev and it's not so buggy.
Block labels render dark on some drawer faces. I'm still evaluating how this can be solved.
Drawer models are simpler and flatter. I intend on offering an alternate resource pack to let you pick the style you like.
Storage Drawers for 1.8 is dependent on the Chameleon library.
Considering that certain mods are dragging their proverbial feet in moving to 1.8; that might give you more notoriety, if that is anything you desire.
What I'd like to know is if I use a chest on a hopper with pipes leading to one controller; by your description only drawers that have been preloaded will accept items, is it possible to gather the items that don't transfer into that controller and send them towards another controller that does, or through a series of controllers until the inventory is depleted. Finally a chest at the end of the chain to gather what doesn't get placed.
Is that possible or am I missing the point of the interface sides?
i've been using jabba now for quite a while and when you said the controls were reversed from jabba you lost me but as i read the next sentence you got me straight back in with the config option, well played. i'll give this wee beauty a whirl now
There's a slight distinction here. When you right-click on the front of the controller with an item in hand to insert it, only preloaded drawers will accept the item. If a drawer isn't allocated, you can't right-click the item in. This also applies when you double-right-click to dump your entire inventory into the controller - which I think is a good thing.
However, inserting items via hoppers will insert into empty drawers too. It will prefer to insert into preloaded drawers if possible.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
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.
Drawers aren't a pipe system though. They're like a really big chest, that your pipes see via the controller block. What happens when you pipe into a full chest? Same issue. Not sure what the state of item transport is like in 1.8 right now, but it's a reasonably solved problem in 1.7.
Maybe I will add more network blocks to do more advanced things, but my focus is bringing 1.8 to completion first.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
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.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
He's playing 1.8
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
...oh. In that case I'm curious what kind of pipes Kreezxil is using!
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
Ok, I figured out.
Btw, I have at least 3 mods that allow items to be moved, NeoTech, TechStack's Heavy Machinery and Hopper Ducts.
In this version I'm using Hopper Ducts.
So, I have a chest on a hopper pointed at a controller, the controller feeds two drawers. The last drawer is on a hopper connected to hopper ducts that pipe items to another controller (2nd screen shot) that feeds its drawer network. Also, this means that you don't have to make a network extender because you've essentially allowed it with hopper interactivity. The other caveat is that the hopper only drains the one drawer unlike if the hopper were placed under the controller.
One more 1.8 alpha. Assuming no major problems, the next version will be the first stable version of 1.8. The only thing missing will be a rendered overlay for the storage upgrades (the ugly iron/gold/etc trim around the edge). Supporting that "well" is going to require a bit more work than I'm ready for right now, so I'll punt and make that a 2.1.0 thing. Solving it properly will also give resource pack creators more leeway in creating something that's actually pretty.
Changelog:
- Fixed status upgrade rendering for all supported blocks.
- Fixed storage upgrades not applying.
- Fixed drawers dropping the wrong status or storage upgrade if one was applied.
Download: http://minecraft.curseforge.com/mc-mods/223852-storage-drawers/files/2237786
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Ok, something I might have missed or you didn't tell us. When the Drawer Controller puts items into the connected drawers, what is the method it uses to fill them?
I understand that it first find homes that have like items in them and fills them, but when it comes to empty drawers where does it start looking?
From my point of view it almost looks random, as the items flow in they don't appear to enter in logically.
I think tho that I just understand the logic and that is what I want to know, how does it determine which empty drawer gets loaded?
However, can I make some suggestions that maybe you might make.
Allow the storage drawer network to allow regular chests to be included and said regular chest all act as overflow, only receiving items if said items can't be stored elsewhere in the drawer network.
and/or
provide a face on the controller or the controller slave that allows for output of items as overflow under the same conditions.
Any inventory could be made part of a drawer network, including chests by writing an adapter to the IDrawerGroup interface. But there's no concept of priority.
The main thing I don't like about this is that a set of drawers is no longer an inventory endpoint. It will greedily take all items, in essence becoming a kind of pipe network of its own. It raises some thorny issues like "what do I do if there's several valid output blocks".
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
that bfs method sounds useful
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.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
With the revised network search algorithm, the 25x25 theoretical octahedron has been lifted to a guaranteed 25x25 cube. It doesn't matter how convoluted you snake your path of drawers and trim, so long as it's all contained within that volume.
Empty drawers will be populated starting nearest the controller and radiating outward according to the shortest length connecting path.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Version 1.4.6:
MineTweaker API:
Changes are not ported to 1.8 yet.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Hello everyone. I'm half of Paws Gaming. We wanted to do a mod spotlight, so we went scrolling through our long list of mods and came to Storage Drawers. We made a nice thorough spotlight. We tried to show everything this mod has to offer, as well as showing it's compatibility with our other mods. Just wanted to share that video with you. Enjoy!
P.S. Thumbnail doesn't always like to appear.
The new GUI is looking nice. Any plans for it to appear in the 1.7.10 version, or just moving forward on the 1.8 version?
As far as the what to do with overloaded drawers and allowing upgrades to be removed: I say put the onus on the user there and lock the upgrade from being removed if the new maximum would be lower than the current inventory.
Alternately, you could be forgiving and let them remove it and keep the current inventory, but not allow anything new to be added as long as it remains capped out... but this can lead to a bit of abuse with players passing the upgrades around like a key.
The other other options are to delete the excess inventory, or dump the excess on the floor. Both of those are messy options from a player perspective, albeit it the easiest ones to code
I'm very excited for any sort of "storage network" to hit 1.8. Can't wait for stable!
The 1.8 version is now out of alpha.
Known issues and differences from 1.7.10:
Storage Drawers for 1.8 is dependent on the Chameleon library.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate