Over-equipped (OE) is currently not implemented. #584
Labels
No labels
area
blabot
area
client
area
encounters
area
launcher
area
missions
area
npc-behavior
area
performance
area
portal
area
quests
area
rdb
area
teams
area
trading
area
zone
priority
1
priority
2
priority
3
priority
4
shadowlands
state
cant-reproduce
state
duplicate
state
fixed
state
new
state
unrefined
state
verified
state
wontfix
type
bug
type
enhancement
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: prk/issues#584
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug
When an item is equipped, but the requirements to wear said item are not met, the item is not entering the Over-Equipped state.
To Reproduce
Steps to reproduce the behavior:
.getfull
for your choice of modifier..set
to reduce a skill it relies on to be equipped..getfull
to confirm no modifier change on the server.Expected behavior
When an item enters the OE sate, certain modifiers should be reduced.
More details here: https://www.ao-universe.com/guides/classic-ao/gameplay-guides-6/over-equipped
Screenshots

Character info:
Confirmed.
The client reports that a piece of equipment is over-equipped at appropriate breakpoints, but server values for parameters related to that equipment do not change to reflect the reduced effectivity. It appears that OE rules are not enforced by the server.
Should be fixed with project-rubika/engines#391
OE Confirmed to be implemented now. However, in-zone update doesn't occur, OE check seems to only be on zone currently and doesn't update stats dynamically.
Could you explain a little more what you mean by "in-zone update"? It should recalculate the OE stats whenever a nano enters/exits NCU, or when items are equip/unequip etc. It's part of what we call
RecalculateModifiers
.If you mean you manually adjust stats using
.set <stat> <value>
I dont think that triggers recalculation but thats sort of expected.Aha, something I wasn't actually aware of. Thinking on it, that makes sense considering the only situations where there is going to be a stat change is in those two circumstances (excluding something like Towers dying/Org contracts). Retested by casting a nano to force the
RecalculateModifiers
call and confirmed as fully implemented.Confirmed fixed as of UTC 16:55 - 17/02/24