Hey folks.
It looks like maybe 'value' caches its results in order to prevent you from working around the inaccuracy of your results by doing multiple runs on the same object and taking the average.
For example, I have a pack that shows its weight as 20 stone. So I emptied it into a bag and tried the value again, and the weight still came up as 20 stone, even though it's empty. But the sid value was identical, leading me to believe that it might be doing that caching thing.
So if you forgot to empty a container before weighing it...how do you find out the container's empty weight?
I feel like this may be two issues.
Value "caches" for each login, perhaps. But also containers are a weight, seemingly no matter what is placed in them. That pack is 20stone, no matter what because it can only hold x < 20stone worth of items. Maybe?
I think it returns the capacity of the container.
Hmm.
Because assess says:
"It could probably hold around 64 stones."
There is a reduction of weight when things are worn and possibly contained. I'm not sure. Caching the value would be a heavy duty solution to something that's not a problem.
It may be a minimum based on the volume to help deal with room weights.
Yeah, I wasn't saying it -should- be cached. I was thinking maybe it -was- cached, though that would be as you say heavy duty.
Since 20 stone could be about right for the container AND its contents, yet it didn't reduce weight once it was emptied.
Wherever it gets that number from, something is odd if it reports the same both empty and full of a couple waterskins, a torch, etc.
Quote from: JackGibbons on June 12, 2015, 11:27:56 PM
Yeah, I wasn't saying it -should- be cached. I was thinking maybe it -was- cached, though that would be as you say heavy duty.
Since 20 stone could be about right for the container AND its contents, yet it didn't reduce weight once it was emptied.
Wherever it gets that number from, something is odd if it reports the same both empty and full of a couple waterskins, a torch, etc.
Could be a delayed update until the next time it recalculates its weight.
"Value" probably has a delay and a cache to prevent people from running stats on the returned values. This maintains the usefulness of the 'value' skill.
What the OP is experiencing is probably an unintended consequence of the cache, since the code was probably put in using the mostly reasonable assumption that objects don't change weight.
It could be fixed by adding a "check change in object weight" routine, so if the object is significantly lighter than it was the last time its value was cached, it automatically re-randomizes the weight around the new actual weight, outputs that, stores the new cache value.
If it is being cached (weird) then a lighter weight solution might be to randomly perturb the true number using some hash of the PC's name, or maybe days played, as a seed.
Quote from: CodeMaster on June 13, 2015, 02:12:14 AM
If it is being cached (weird) then a lighter weight solution might be to randomly perturb the true number using some hash of the PC's name, or maybe days played, as a seed.
Pure randomization methods are subject to statistical inference via repeated uses of the value command, unless (and this would be funny) you randomize the values with a consistent skew.
I think it would be hilarious (and probably consistent with human psychology) to consistently skew items with a low value such that the randomized mean is lower than the actual object value, and to skew items with a high value such that the randomized mean is higher than the actual object value. Objects in the middle would be more or less normal, although you could probably code an elegant solution that would generate a scale from -x to +x mean-skewing that correlated with the object values.
That is, there would be some value y where reported mean = actual value...objects with values below y would have reported means lower than actual value, and the difference between the two would increase with the difference between y and and the object's value. Vice versa for objects with values above y.
That is, players with a shitty value skill would consistently underestimate the value of cheap goods, and consistently overestimate thee value of valuable goods (same with weights, possibly, although you could restrict this code to coin values).
Quote from: Synthesis on June 13, 2015, 12:44:47 PM
Quote from: CodeMaster on June 13, 2015, 02:12:14 AM
If it is being cached (weird) then a lighter weight solution might be to randomly perturb the true number using some hash of the PC's name, or maybe days played, as a seed.
Pure randomization methods are subject to statistical inference via repeated uses of the value command, unless (and this would be funny) you randomize the values with a consistent skew.
I think it would be hilarious (and probably consistent with human psychology) to consistently skew items with a low value such that the randomized mean is lower than the actual object value, and to skew items with a high value such that the randomized mean is higher than the actual object value. Objects in the middle would be more or less normal, although you could probably code an elegant solution that would generate a scale from -x to +x mean-skewing that correlated with the object values.
That is, there would be some value y where reported mean = actual value...objects with values below y would have reported means lower than actual value, and the difference between the two would increase with the difference between y and and the object's value. Vice versa for objects with values above y.
That is, players with a shitty value skill would consistently underestimate the value of cheap goods, and consistently overestimate thee value of valuable goods (same with weights, possibly, although you could restrict this code to coin values).
Certainly a much more amusing failure state than 'consistently low' or 'broad range but with accurate mean'.
Quote from: Synthesis on June 13, 2015, 12:44:47 PM
Quote from: CodeMaster on June 13, 2015, 02:12:14 AM
If it is being cached (weird) then a lighter weight solution might be to randomly perturb the true number using some hash of the PC's name, or maybe days played, as a seed.
Pure randomization methods are subject to statistical inference via repeated uses of the value command, unless (and this would be funny) you randomize the values with a consistent skew.
I think it would be hilarious (and probably consistent with human psychology) to consistently skew items with a low value such that the randomized mean is lower than the actual object value, and to skew items with a high value such that the randomized mean is higher than the actual object value. Objects in the middle would be more or less normal, although you could probably code an elegant solution that would generate a scale from -x to +x mean-skewing that correlated with the object values.
That is, there would be some value y where reported mean = actual value...objects with values below y would have reported means lower than actual value, and the difference between the two would increase with the difference between y and and the object's value. Vice versa for objects with values above y.
That is, players with a shitty value skill would consistently underestimate the value of cheap goods, and consistently overestimate thee value of valuable goods (same with weights, possibly, although you could restrict this code to coin values).
That's why I suggested seeding the "random" number with something that doesn't change very quickly (like their name or days played). E.g., just take the length of their name and pipe it through a few iterations of Blum Blum Shub, and then you have a random number that is unique to that character but won't change on repeated calls to "value".
I like your skewing ideas though.
Small tangent: this kind of procedural generation based on a fixed seed is a good way to create behaviors that are randomized on a per-character basis, and might be an untapped resource.
Another example where this could be applied is if cure tablets were changed to all be "a white tablet". Each white tablet could then have a sniff description (sweet, cloying, floral, sugary -- some kind of near synonyms) that was randomized based on your character ID. This way you'd have to learn the cures anew for each character.
Or there could be special rooms where your character had an easier time with the Way, etc.
Quote from: CodeMaster on June 13, 2015, 02:05:53 PM
Small tangent: this kind of procedural generation based on a fixed seed is a good way to create behaviors that are randomized on a per-character basis, and might be an untapped resource.
Another example where this could be applied is if cure tablets were changed to all be "a white tablet". Each white tablet could then have a sniff description (sweet, cloying, floral, sugary -- some kind of near synonyms) that was randomized based on your character ID. This way you'd have to learn the cures anew for each character.
Or there could be special rooms where your character had an easier time with the Way, etc.
Why would the often very colorful things used to make these tablets magically turn white? Are you adding bleach?
Tablet stuff is another thread and an idea missing the obvious point (There's better fixes)
There is no reason to be discussing computer science either.