[Experimental] Factory dropper behaviour
rai-en opened this issue ยท 8 comments
Hi again. I am thrilled with the potential of the factory dropper, however, some behaviours do not feel right.
When placed facing a cardinal direction the dropper's aiming behaves as you would expect. When placed facing up or down it does not. Moving the targeting marker to the right or left drops the item towards the east or west respectively. The expected behaviour would be that moving the marker up would drop towards the north and moving down would drop south but instead the functionality is reversed.
A redstone pulse is able to be applied to the dropper but levers and buttons are unable to be placed directly on the machine. Additionally the dropper does not stop auto ejecting if it is provided a redstone signal.
Finally, I don't understand how this works, but if your eject group size causes a stack to contain less than the number that is supposed to be dropped then the dropper will just stay on that stack and not cycle through the rest of the inventory. For example if your drop cluster size is 3 and you have 4 stacks each containing 16 items the dropper will eject 15 items from the first stack and ignore the remaining valid stacks. This behaviour changes if the stack size of your filter is larger than 1 but less than a certain number. Although then you're stuck with stacks containing a single item that won't be dropped even though the total number of items in the container is valid.
Ok, pushed the second dev loop on curse (1.0.7b1). Fixed the button placement there, added axis markers in GUI and front. Also "dropped" one req above, that should make the logic more simple: A filter now also matches when it's not explicitly in one stack. The items can be anywhere in the dropper inventory. It takes the matching items always from the last to the first slot (because the dropper is filled front to back, so that also frees slots early).
Hi, thanks for beta testing that! Yes, the device is definitely not in release state yet.
-
The direction is a good point. I used "x+" here as a first shot, unsure if a reference marking or introducing additional placement parameters (means saving the complete coordinate system transformation) made sense. My guess is now that would not help in the end. Much more important is that the user can see the orientation on the outside of the dropper and can match that to the GUI. So the change for the next beta will be that x/y axis is marked with red/green in the GUI and around the shutter door.
-
Thanks for the lever/button hint, did not mark all sides "solid" yet.
-
According to the dropper logic: That's "in tweaking". The most important stuff is implemented. Means in this step I wanted to see how if the basic features can be somehow made accessible in the GUI, without using text (international), or fields where you have to enter numbers, and how the dropper can show you that it is ready to drop something based on internal trigger conditions (without that you have to open the GUI, just looking at the block: that is the shutter door now).
The basic reqs and behavior that I had in mind:
- Low CPU consumption when idle
- By default the easiest/most obvious behavior. Means you place it, change nothing and insert stuff to drop. Then is must be a normal redstone-triggered dropper with zero-force.
- Changing drop angle, force, stack size, and cooldown should be easy enough and repeatable, so that people can quickly see and find out how it works (not over-document, just giving the possibility to play with it).
- The internal triggering/matching and the logic selection is the "Engineer level 3" advanced usage: This should help to solve more specific needs, e.g. for conveyor contraptions. Without going through all use cases now, the basic plan is:
- Must be able to trigger internally without a redstone signal.
- When triggered internally or externally (AND logic with EXTI) it must drop from all matching stacks simultaneously (no other slots), stack sizes as defined in the filter slots.
- When triggered externally while no internal condition matches, it must drop round-robin (next slot that has at least the stack size that is configured with the slider).
- External triggers that come in during cooldown must be latched and directly executed after the cooldown has finished. Otherwise there will be complains that it does not react to redstone signals.
I think I will leave the single-stack-compare, not filter-stack-to-complete-inventory, because that allows pre-setting the slots and thus deciding what hoppers or drop-conveyors can insert into the dropper.
So, ya, there's a bunch to tune and fix before that thing can be released.
Alright. I've been toying around with the new dropper and for the most part the red and green indicators do make it easier to discern where an up or down facing dropper will throw. Perhaps the lines are out of place and could be replaced with something that feels more organic to the theme? As a a quick example I threw this together and swapped the y-axis visualizer to the top because that also seemed more natural.
Yeah. I think you've done well in conveying how it works without showing any words or inputting numbers. Graphically the hardest thing to figure out was that the arrow for the drop speed is an arrow, but in conjunction with the snail it's more clear.
So as it turns out, if you have an external trigger (redstone clock, Botania's hourglass, etc) and apply an activated lever to the dropper then that will stop the machine from auto-ejecting. This behaviour was already present in previous versions and so only the internal trigger doesn't respond to a signal.
Hey ho, wow you checked quite a bit, also with the textures! I double checked again, topic top-down:
-
I had in the beginning similar markers on the edges (small arrow head like), but decided in the end against it, because it made the already full packed UI look too busy to my eyes. Also the outside should not have markers that catch the eye at first. The lines came because they can be faint axes overlays. People who see a coordinate system in it can quickly match that to the outside. People who see the lines have an indication where bottom/left is. I might make the outside lines maybe a bit more dimmed. They are only needed when the drop angle setting is needed - that is probably not that often. In the end I think the auto trigger will be more useful in most cases (e.g. for dropping 9 redstone/lapis/etc on a conveyor in front of the Metal Press with packing form), or dropping stuff into an Assembler.
-
Arrow in the UI for fast drop ... I was (still am) out if ideas how to indicate "high frequency" or so with 4x6 px. Also tried a bullet, lightning/spark, etc - it didn't look. Any further ideas very welcome ;-).
-
Redstone trigger: Should be ok. The trigger condition is "unpowered"->"powered". So if a lever is switched on it permanently powers the dropper. An additional button that is pressed does not change this state. It's a quite common convention to simply check for power from any side (also the vanilla dropper does this).
Thanks again for that testing effort, it's really appreciated.
We're getting close to have that thing "releasable".
Looking at it again today I agree the outer markers are rather bold. I tried bringing them more in line with the colour levels you initially had but the red still looked too eye-catching. After a little more adjustment I feel the levels are appropriate.
I then moved to see what could represent speed in place of an arrow. The 6x4 parameter is difficult to work with but I decided to stay within the animal theme and chose a dog.
The speed icons needed to be moved down 1px as otherwise the dog's head would be covered by the top slider. Perhaps with careful editing the dog icon could be made to show that it is running, but I didn't want to spend too much time on an unconfirmed change.
Alright then. To me it seemed maybe inconsistent in how the internal/external worked though the reasoning you have seems sound.
You're welcome. The mod is really coming into its own so I'm looking forward to what will come next.