|
|
|
[
Permlink
| « Hide
]
jessica lyon added a comment - 31/Jul/08 07:38 AM
YAY for Linden Labs breaking content.. once again. Making changes without considering the thousands of creators and tens of thousands of residents who own items which rely on push. Yay for thinking ahead. Please fix this. Thank you.
Now I have to worry about exceeding MaxINT when creating push content, this isn't as much of an issue as updating all of my old scripts and upgrading 60% of my purchased items.
I hope to god that this was unintentional I honestly do not get why LL keeps messing with the push. Again i will have to adjust the scripts in my products and awnsering a lot of IM's and notecards form residents that have purchased my products...and explain them why some features don't work anymore. Pls, undo this change.
It would be really nice if the fix for this could get into the batch of the first of post-Mono physics fixes
Been a while since we've heard anything on this one...
Tomorrow will be October...
Something that may be have contributed to the problem is the way teaching tools for LSL gives examples of the use of llPushObject() and the push value integer. For example, the example given on LSLWiki: (http://lslwiki.net/lslwiki/wakka.php?wakka=ExamplellPushObject
 ) does not give significant emphasis to making certain the number falls within proper limits, but instead simply suggests using a string of 9s for a "very large push".
It is true that the number of 9s in the example code is only seven digits, while the number of digits in the maximum possible push is 10, but it is reasonable to assume that inexperienced coders, who want "more bang for their buck" will simply tack on a few more 9s, rather than editing the integer to a correct value within limits. This is compounded by lazy teaching with phrases such as "When coming up with the velocity to push, the max will be 2147483647. Anything over that will act as 2147483647. " (From the wiki example page) This gives the new programmer an "out" for lazy programming. Boundary conditions of this sort cannot be relied upon to STAY boundary conditions. If there is a maximum allowable value for a constant, it should be an error for it to be beyond that number – but properly, it should have BEEN an error from the beginning. Now, the genie has escaped from the bottle, and to change that boundary condition would break things that have resulted from this laziness. The only thing that can be done now is to fix the boundary condition so it goes BACK to the expected behavior – i.e., that over-max values default to the max, not to zero – but that teaching methods change so that future generations of scripters do not come up thinking it is perfectly acceptable to just slap any old number in there, and the "maximum" will be handled for them. It isn't THAT hard to look it up. Or you could put the maximum in the tooltip for the function. That way, years from now, maybe future devices won't have the maximum munged. Tested on Beta Grid under 1.25. Appears to be working properly now. Checked with a pushing device with push level set to "9999999999" and it pushed at the same level as at 2147483647. Prior to this, setting beyond max reduced push to nothing. Many other pushing devices also work properly that were not working at all before.
|
||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Change in llPushObject strength cap behavior 1.22 -> 1.23 simulator release
