Windows 10 PC. , but that's not it, because now I understand it a lot better,
RECAP: The goal is to get to 11 pen on Tuotilo's (7 + 2devoted + 2haymaker) in secondary while wielding your devoted weapon in primary. This bug prevents that (max 9 pen; 7 + 2devoted, but no haymaker), but not in the way I thought when I posted above. SO...
--- UPDATE --->
-------------------------------- TLDR; -----------------------------------------------------
The bug isn't really about devoted... it's about haymaker...
There are two effects here: 1) The UI display - these Pen bonuses (can) display wrong if you stay in the inventory screen because the game is paused. Easy fix: keep "refreshing" it by leaving inventory to un-pause the game (this was the devoted issue I posted above, no big deal; in combat you always get devoted on the shield) and 2) Tuotilo's modal activation conditions - basically it can benefit from haymaker, but i can't activate haymaker, so unless your primary is also unarmed, haymaker won't activate.
---------------------------- EXPLANATION -----------------------------------------------
THE PAUSED-UI ISSUE (misleading, but not a bug):
In combat Tuotilo's will always (seems to always) get the devoted buff, so the devoted portion of this is more or less irrelevant. It's is just a UI quirk (more an oddity than a bug). Because inventory pauses the game, but allows you to still make changes that trigger all sorts of checks about how a newly equipped item interacts with other items, passives, modals, etc. Usually, but not always, instantaneous checks update correctly paused or not (ex. adding might will increase your damage on paused inventory screen instantly), However, some instant checks apparently can fail in some circumstances (which I have no desire to test enough to map out lol). I'm guessing the problematic ones are coded to occur as a sequenced chain of checks that makes sense in normal gameplay/combat, but pause might allow for situations where you can only trigger a portion of the chain, I think the Tuotilo's checks that depend on its weapon type (shield or unarmed) are like this, but a good illustration of checks that ALWAYS fail to update on the inventory screen (which is anything with a cool-down, i.e., all the weapon modals).
MODAL STATUSES, TRANSITIONS, TRIGGERS AND PAUSED-UI INTERACTION (working as intended):
This is not a bug, but you need to understand weapon modal mechanics to understand the Haymaker/Tuotilo's bug explained below). Weapon modals may SEEM to have two possible statuses (the two that show in the log), A) activated & B) deactivated (based on only one condition: the green button on/off). However, that is not correct, the two things in the log are actually:
TWO transitional actions/events, A) Activating, and B) Deactivating, which transition between...
THREE possible statuses, 1) Activated, 2) Deactivated, AND 3) Inactive, which aren't all three distinguishable in the log, because...
In the log "activated" means only one thing: Event X and Event Y > transition A) > to status 1), however...
In the log "deactivated" can mean either of two things: (resulting in different statuses), based on which event(s) triggered it...
Event Y and event X (not) > triggered transition B) > to status 2), or it could mean...
Event Y(not) > triggered transition B) > to status 3).
Two of these statuses (1 & 2) don't rely on ONLY the green button on/off condition (Event Y above), but also a weapon check (event X above). Status 3) deactivated is actually triggered by ONLY the green button, so the status transition trigger conditions are :
A) Activating to:
1) Activated (Trigger: green button on + weapon equipped); [X and Y above].
B) Deactivating to
2) Inactive. (Trigger: green button on + weapon NOT equipped); [Y and X(not) above].
3) Deactivated, (Trigger: green button off); [Y(not) above].
Status 2 & 3 are basically different states of "activation readiness". There are two possible states of activation readiness, one is higher readiness (one trigger condition is already met; a single action activates) and the other is lower readiness (neither trigger condition is met; two actions required to activate). ALWAYS: 2), Inactive, is high readiness, since it requires green button on. The flip-side of that is that ONLY 3), deactivated, can be low readiness (X(not) + Y(not), since no other state allows green button off. However, 3), deactivated, could ALSO be high readiness, because its sole criteria means it could ALSO be weapon equipped/green button off (X + Y(not)).
This probably seems laborious, but the two transitions are necessary to distinguish from the three statuses because the transitions are different from each other, and trigger events that interact differently with the Paused-UI.
Transition B), Deactivating:
occurs instantly
updates correctly whether paused or not.
Transition A), Activating:
does not occur instantly
triggers a very short cooldown
won't update if the game is paused.
Backing out of inventory for a second then back in will refresh everything.
THE TUOTILO"S / HAYMAKER MODAL/PRIMARY WEAPON INTERACTION (THE BUG): If you take any two of these things, they interact simply, and consistently, in the expected way. Assuming green modal buttons are on, take, for example, the simple Haymaker-Primary Interaction; if primary is unarmed then haymaker active. Or, leaving primary as unarmed for simplicity Toutilo's-Haymaker interaction; easy - Haymakers modal buffs it , and you can even stack the mall shield modal if you want (this leads to proposition 1 below), see screenshot 1).
Uploaded Images
Proposition 2: may seem obvious, but its the SIMULTANEOUSLY part that is non-obvious, because it could easily be set up so that its a shield when its doing shieldy things, and an unarmed weapon when it's doing weapony things. Note that we know that a weapon can RECEIVE two modal buffs at once, but we do NOT know if a weapon can ACTIVATE two modal buffs at once (yet).
SO... THE BUG.... FINALLY... FIGURE 2 (Below) EXPLAINS....
A NON-MONK CAN GET 11 PEN ON TUOTILO's, BUT...
EQUIPPING A WEAPON IN PRIMARY STRIPS HAYMAKER FROM SECONDARY AND DISABLES IT <---- THE BUG ----
POSSIBLE EXPLANATIONS FOR THIS BEHAVIOR (in hopes there is a work-around)
{EDIT: THIS VERSION IS FUZZY, SO I POSTED A HIGHER REZ VERSION A COUPLE OF COMMENTS BELOW THIS.}