Milla wrote:Maybe the percentage calculation would be better if it adjusted the theoretical cap limit when a percentage greater than 100 percent is encountered.
I do respect Lunariel's resource cap bible, however, the true test of any theory is practice.
Maybe such adjustments could be restricted to verified resources (hence the need for verification), otherwise incorrect stat value may wreak havoc on the cap calculations after a while.
That is what a number of old seasoned crafters have done over the years. When I got my first 30k Vet Resource Crate deed I eagerly set up a script that pulled out everything reported at the .com site that was outside the cap. None of the alarms were correct, the resources that triggered the alarm were all reported in error.
The fault percent was about 0.2%, mainly two digits that were shifted, as in 487 for 478, but also some stats shifted place as when SR went into UT and vice versa. Also the wrong resource class, I guess it was easy to select the adjacent class from the drop down list. All these three options were frequent.
Name spellings is not in the .2% sine they never ever triggered the script. Name errors are found when you later on want to add Leiawascute only to find that name is already in use. Looking up the resource type you find the name Laiawascute but wrongly entered into the database. Name errors are not much we can do about but having observant verifyers.
I have mentioned it elsewhere, the submission logic could handle this. The best way, in my opinion, is to warn the user about the stat being outside the cap. Should the cap be in error (which I 99.99% doubt it is) and the user state s/he still wants to submit the data, that could go into a special log of "enforced submissions" which can be checked up by other players.
On the other hand, seeing something outside the cap range could stir up some verifying from the one first noticing it and either confirm the cap is wrong, or rectify the erratic data.
However, there should be no "silent correction
" of the data whatsoever. The main reason is that we do not know whether it is the digits of the stat that is in error, or if it is the stat types that are mixed up, or if the wrong resource class was entered. These three possibilities must all be checked up in manually by the verifier.