Difference between revisions of "User talk:Becky Pippen/New LSL Functions"
(Relative Resizing?) |
Becky Pippen (talk | contribs) |
||
Line 1: | Line 1: | ||
Thanks for providing the info. The suggested relative resizing troubles me, since it accumulates error that breaks objects (besides this, no recovery when the position component fails due to not-completely-predictable SL behavior). For objects that only resize a few times, like most jewelry, the error does not grow enough to be noticed, and my concern is more principle than practical. But, I make some objects that resize many times, for example, as part of RP or in response to nearby AV actions, so they use absolute resizing. (Even for jewelry, I use absolute resizing, with a single-script resizer for low script time, but that stores original sizes and positions in memory. They can be re-read from a notecard in case of a script reset, but not during normal operation since that is so slow.) [[User:Xoph Adamczyk|Xoph Adamczyk]] 16:55, 22 January 2010 (UTC) | Thanks for providing the info. The suggested relative resizing troubles me, since it accumulates error that breaks objects (besides this, no recovery when the position component fails due to not-completely-predictable SL behavior). For objects that only resize a few times, like most jewelry, the error does not grow enough to be noticed, and my concern is more principle than practical. But, I make some objects that resize many times, for example, as part of RP or in response to nearby AV actions, so they use absolute resizing. (Even for jewelry, I use absolute resizing, with a single-script resizer for low script time, but that stores original sizes and positions in memory. They can be re-read from a notecard in case of a script reset, but not during normal operation since that is so slow.) [[User:Xoph Adamczyk|Xoph Adamczyk]] 16:55, 22 January 2010 (UTC) | ||
:Thanks, Xoph, you're quite right about the risks of repositioning this way, and I'm glad you pointed it out. The main point of the code snippets is to suggest a general loop structure for getting and setting parameters in all the prims in a linkset, not the specific parameter changes which need to be carefully considered for each product's use cases. I'd love it if someone contributed a more realistic example for a specific application. [[User:Becky Pippen|Becky Pippen]] 18:03, 22 January 2010 (UTC) |
Revision as of 10:03, 22 January 2010
Thanks for providing the info. The suggested relative resizing troubles me, since it accumulates error that breaks objects (besides this, no recovery when the position component fails due to not-completely-predictable SL behavior). For objects that only resize a few times, like most jewelry, the error does not grow enough to be noticed, and my concern is more principle than practical. But, I make some objects that resize many times, for example, as part of RP or in response to nearby AV actions, so they use absolute resizing. (Even for jewelry, I use absolute resizing, with a single-script resizer for low script time, but that stores original sizes and positions in memory. They can be re-read from a notecard in case of a script reset, but not during normal operation since that is so slow.) Xoph Adamczyk 16:55, 22 January 2010 (UTC)
- Thanks, Xoph, you're quite right about the risks of repositioning this way, and I'm glad you pointed it out. The main point of the code snippets is to suggest a general loop structure for getting and setting parameters in all the prims in a linkset, not the specific parameter changes which need to be carefully considered for each product's use cases. I'd love it if someone contributed a more realistic example for a specific application. Becky Pippen 18:03, 22 January 2010 (UTC)