Bug - Fixed maximizer will (try to) acquire, not pull items when you have >= 16 in storage.

I

IronTetsubo

Member
At least, that's my theory. Here's the situation. I was running into an issue where maximizing mainstat (as zombie) with "pullable/buyable" selected in ronin happened to pick up a "mesh hat" as the right item for me - but, instead of listing it as "pull & equip...", it listed it as "acquire & equip...", and then trying to actually execute that maximizer line would fail (as I'm in ronin still, so acquiring of course won't work).

So, that's the actual bug - now, here's my logic/conclusions, some or all of which may be faulty. :)

After poking around further (and some false starts), it turns out that I happen to have 16 mesh caps in storage. The maximizer uses bitflags as a part of the item count to pass around how to treat items, specifically 4-bit ranges... and my theory (hence the bug report above) is because it's using 4 bit fields and I happened to have 16 items, I've "overflowed" the proper range for pullable and ended up in the buyable range. Attached is a patch which fixes this, by "clamping" the count - it forces the count to 1 for the flag, regardless of your actual count. I think this is okay, as for all equipment you're just pulling 1 anyways, and for potions and the like you generally don't want to pull more as well. And I don't think potions and the like are even checked as a pullable thing? not sure about that, though. I'm not really sure if this is the right fix (or we should clamp to no more than 15, so as to not overflow the bitfield but still preserve some level of the count?), but it's at least a starting point for the discussion. the other route to go, which of course is an extremely painful/unlikely one, is to throw out the bitfields entirely which would of course bypass this issue.

One other minor point/bug - in theory this is an issue for the other flags out there, but I just looked at pullable. View attachment fix_maximizer_pull_flag.patch
 
C

Catch-22

Active member
I have no idea if any of what you said is true nor do I have the time to check, but I couldn't resist the opportunity for some bit shifting voodoo.

Throwing out the bit fields is probably a good idea though. Based on what you're describing, it seems odd to be using them in this case.

Untested :)
 

Attachments

  • MaximizerFrame.java.patch
    656 bytes · Views: 28
Last edited:
C

Catch-22

Active member
Whether or not my earlier patch works, I don't know, but the "correct" fix is probably this one.
 

Attachments

  • MaximizerFrame.java.patch
    658 bytes · Views: 21
Last edited:
Theraze

Theraze

Active member
I think this is not a bug... acquire uses whatever automatic item acquisition you have set. If you haven't set it to allocate some number of automatic pulls, the maximize acquire won't auto-pull either.
 
C

Catch-22

Active member
I think IronTetsubo is right in classifying this as a bug.

The count variable in MaximizerFrame is really multiple numbers (such as nibbles and bits) stored in a single 32-bit integer, and it's being bit masked to determine the value of those different numbers.

The "pullable" nibble is stored in bits 25-28 (4 bits). When you try to shift the integer 16 (0b10000) into this offset, it won't fit, because 16 takes up 5 bits. In a few areas of the MaximizerFrame the nibbles are being capped at 15 (0x0F) to prevent these values from overflowing, but not in the "pullable" shift, which is where the bug lies.

We're not programming embedded systems here though, so I don't really know why all the information is being crammed into one 32 bit integer.
 
Last edited:
I

IronTetsubo

Member
Theraze said:
I think this is not a bug... acquire uses whatever automatic item acquisition you have set. If you haven't set it to allocate some number of automatic pulls, the maximize acquire won't auto-pull either.
Click to expand...

Er, no - the maximizer will pull regardless of your budget, as long as you have pulls available - and when I have pulls available (and can equip other parts of the outfit with no problem), trying to "acquire" the mesh cap failed (because it was trying to go to the mall while in ronin). Now, your point is interesting, and one I didn't test - I wonder if it would have worked if I had budgeted pulls, and acquire then had the option of pulling it from storage.
 
nworbetan

nworbetan

Member
I don't understand how the bit shifting and masking works on a detailed enough level to know if the unexpected behavior I'm seeing could be caused by the shifting/masking code. So this could easily belong in a new thread, idk.

What I'm seeing in aftercore and r11469 is that maximizing "hp -familiar -tie" recommends items for every slot, and maximizing "da -familiar -tie" recommends nothing (I'm already well past the da cap thanks mostly to Tao). These both look fine.

But when maximizing "hp, da -familiar -tie" instead of recommending all of the items that boost my hp, it recommends that I keep the earring of fire, nose ring of putrescence, and hardened slime pants. Switching to "da 1000 max, hp -familiar -tie" doesn't change the results. The best +hp items in those 3 slots don't drop me below 1000 raw damage absorption either, according to modtrace.
 
C

Catch-22

Active member
nworbetan said:
I don't understand how the bit shifting and masking works on a detailed enough level to know if the unexpected behavior I'm seeing could be caused by the shifting/masking code.
Click to expand...

When I looked through the code before providing a patch, I noticed that only the "pullable" amount wasn't being capped before shifting in the bits.

In other words; if you don't have anything in storage then what you're seeing is not a result of this bug :)
 
Last edited:
I

IronTetsubo

Member
Yup, different issue, post a new thread. :) When/if you do, I will happily post some suggestions/questions to help debug your issue.
 
holatuwol

holatuwol

Developer
Catch-22 said:
We're not programming embedded systems here though, so I don't really know why all the information is being crammed into one 32 bit integer.
Click to expand...
Me either, so I rewrote that code to not require it. I might have broken something, though. >_>
 
You must log in or register to reply here.
Top