mojira.dev

Kevin Moser

Assigned

No issues.

Reported

No issues.

Comments

I like the idea of using a table to determine the output strength. It would fix the issue and can be applied to all containers. The problem with it is coding it for efficiency. As far as my programming skill get me, I can only come up with a block of if statements to determine the output. We'll be dealing with a continuous variable, so a pre-rendered array or table can't be used. So it will have to be checked during run time, every time there is an update. It'll add at most 16 code routines when a one-off equation will do it faster. Might cause unnecessary lag.

I've just set up MCP on my computer and I'm starting to look at the source code to see if I can gleam some ideas from there. With the 1.5.1 update coming out soon, I don't think our issue will be addressed. Maybe a mod will come out to fix this.

You're right there, error on my part. Math.ceil would be what the equation in my head was using.
So, Math.ceil[ ( Number of bottles in bottom slots /3) * ( Weight of Bottom Slots ) + ( Number of items in the top slot /64) * ( 15- Weight of Bottom Slots ) ]

My previous example had the Weight of Bottom Slots set at 7. Changed the formula a bit to allow for inequality of a brewing stand with just bottles in it and a brewing stand with just a stack of items. Weight of Bottom Slots set at 11 is the closest value to have all slots to have equal weight overall, since 15*3/4 = 11.25. If only we could submit RFEs on this site instead of just bugs. Could post something on the Suggestions Board, but I fear this topic will be drowned out by the abstract requests. An official response would be helpful to know if we're not wasting our time.

The best thing I can think of is having multiple brewing stands with a stack of a particular ingredient in each one. The user would then move the bottles from stand to stand until the potion is complete. Thus using the stands as a storage device that seconds as a brewing step. Not very practical and very intensive, but someone might like it that way.

I don't see a full revert of this fix to be the best solution as that will re-introduce 4 items in the top slot to equal full redstone output.
My best solution would be a middle ground of keeping the brewing stand as is and changing how the comparator treats it as a container. Like before, but different.

Just trying to come up with solutions that doesn't change the brewing stand that was introduced more than a year ago. Do that and there will be people coming out of the woodwork to argue for the way it used to work, just like we are doing for the comparator now. The comparator is still new enough to change how it interacts, that is where we should be focusing our attention.

I could see some instances where having a stack of items in the top slot could be used, so I doubt they will change that interaction by limiting the top slot to 1 item like the enchanting table. Would like to see some kind of change to the comparator-brewing stand interaction. Just some way of detecting an item in the top slot or not when there are 3 bottles in the brewing stand.

The work-around that I've developed for my auto-potion-maker detects when the hopper above the brewing stand is empty, then initiate a 25 second delay. Works fine, just needed more redstone circuit components than the pre-fix version.

I'm going to agree with Frank.
This fix, while it applies the correct algorithm, makes it impossible to tell when a potion has started brewing or when it has stopped.
Maybe a special method can be called when a comparator is checking a brewing stand, with it's own algorithm. Something like:
signal strength = truncate(1+ [(number of items in bottom slots/3) + (number of items in top slot/64)]*7 )

In my equation, the output will be 8 if the brewing stand has only bottles in the bottom slots, 9 when the first item is added to the top, and 15 when it is completely filled. Inversely, 8 if the brewing stand's top slot has 64 items, 9 with one bottle, 11 with two, 15 when completely filled.

This would fix the initial bug report as well as the unintended feature from the fix.