The “Mary Sue Protocol” (“MSP” for short) is a simple challenge/response protocol for RP UI add-ons within WoW to communicate with each other and publish text information to other clients (such as RP character names and descriptions).
Creative Commons Zero v1.0 Universal
2
stars
1
forks
source link
Remove assumption that unit fields won't change #32
This is incorrect in a few edge cases - the first is something that LibMSP tries to account for where a neutral-faction Pandaren is created and then selects a faction later on in the levelling process. LibMSP updates the msp.my data automatically in this case, however any other players that queried for the "GF" field before that change occurred would never see the updated faction once selected.
The other edge case is where a character is deleted and recreated, in this case basically any and all of the unit fields could change with the GU (GUID) being a guarantee.
Odds are the only reason this was never noticed was because these fields probably aren't used by many people, however rather than keep a broken assumption around it's better to fix this before we forget about it and move on only to then get bitten
ourselves one day in the far future.
Realistically since these fields are seldom used, the impact of allowing them to be re-requested as frequently as other fields shouldn't be a problem - and in the grand scheme of things the data these fields would otherwise transmit should be minimal at best, especially given the common case of them not actually changing.
To demonstrate I ran a quick test ingame without and then with this change applied, first starting off with a Human Warrior that was deleted and recreated as a Paladin:
Initial request:
Post-recreation:
As the time values for the unit fields was set astronomically high, any re-requests for them were never honored and LibMSP was stuck with some old data.
With the change applied, the initial request fetched the Paladin data:
The time fields are no longer set to high values, and so when the Paladin transformed into a Monk a re-request went through successfully and LibMSP was no longer wrong:
This is incorrect in a few edge cases - the first is something that LibMSP tries to account for where a neutral-faction Pandaren is created and then selects a faction later on in the levelling process. LibMSP updates the
msp.mydata automatically in this case, however any other players that queried for the "GF" field before that change occurred would never see the updated faction once selected.The other edge case is where a character is deleted and recreated, in this case basically any and all of the unit fields could change with the GU (GUID) being a guarantee.
Odds are the only reason this was never noticed was because these fields probably aren't used by many people, however rather than keep a broken assumption around it's better to fix this before we forget about it and move on only to then get bitten ourselves one day in the far future.
Realistically since these fields are seldom used, the impact of allowing them to be re-requested as frequently as other fields shouldn't be a problem - and in the grand scheme of things the data these fields would otherwise transmit should be minimal at best, especially given the common case of them not actually changing.
To demonstrate I ran a quick test ingame without and then with this change applied, first starting off with a Human Warrior that was deleted and recreated as a Paladin:
Initial request:
Post-recreation:
As the
timevalues for the unit fields was set astronomically high, any re-requests for them were never honored and LibMSP was stuck with some old data.With the change applied, the initial request fetched the Paladin data:
The time fields are no longer set to high values, and so when the Paladin transformed into a Monk a re-request went through successfully and LibMSP was no longer wrong: