1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 |
return manager
end
EVENT_MANAGER : RegisterForEvent ( "ZO_SkillsAndActionBarManager" , EVENT_START_SKILL_RESPEC , function ( _ , ... ) self : OnStartRespec ( ... ) end )
EVENT_MANAGER : RegisterForEvent ( "ZO_SkillsAndActionBarManager" , EVENT_SKILL_RESPEC_RESULT , function ( _ , ... ) self : OnSkillRespecResult ( ... ) end )
end
end
self : FireCallbacks ( "SkillPointAllocationModeChanged" , skillPointAllocationMode , oldSkillPointAllocationMode )
end
-- Debug: Trying to track down data in a bad state
internalassert ( SKILL_POINT_ALLOCATION_MANAGER : HasValidChangesForMode ( ) , "Skill point allocation manager has pending changes incompatible with current mode" )
end
end
end
end
self : FireCallbacks ( "SkillRespecPaymentTypeChanged" , skillRespecPaymentType , oldSkillRespecPaymentType )
end
end
end
end
end
end
--Purchase-only mode saves every change immediately
end
end
else
end
end
do
local EXPECTED_RESPEC_FAILURES =
{
[ RESPEC_RESULT_IS_IN_COMBAT ] = true ,
[ RESPEC_RESULT_ACTIVE_HOTBAR_NOT_RESPECCABLE ] = true ,
}
if result == RESPEC_RESULT_SUCCESS then
else
-- TODO: Companions, temporarily disabling respec failure errors while we are in active development
--internalassert(EXPECTED_RESPEC_FAILURES[result], string.format("Unexpected Respec Failure (%d)", result))
-- if we aren't in batch mode, the user has no way to fix bad state, so we need to hard reset for them
end
end
end
end
local anyChangesAdded = false
anyChangesAdded = true
end
end
end
return true
end
end
return false
end
end
end
-- Slots can be updated either by an external system informing the assignment manager of the new state, in which case we shouldn't dirty the state and trigger an apply,
-- or by the player changing the state themselves through the manager, in which case we should apply that change.
-- This protects us against superflous diff checking, and more importantly, protects against spamminess/message loops where we cause an update to trigger, which causes us to apply again, etc.
if isChangedByPlayer then
end
end
end
end
|