|
Laukosargas Svarog
Angel ?
Join date: 18 Aug 2004
Posts: 1,304
|
05-03-2006 18:38
I've been trying to set topsize with llSetPrimitiveParams( [PRIM_TYPE, PRIM_TYPE_CYLINDER, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <ts, ts, 0.0>, <0.0, 0.0, 0.0>] ); where ts is a local float variable. This is in a single prim in the middle of a linked set. For some reason it's not working as expected and seems to be causing other prims in the link set to move! So I go to the WIKI again and notice it says ... topsize (removed in SL 1.9.1) is this true, is there a known problem with it ?
_____________________
Geometry is music frozen...
|
|
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
|
05-03-2006 18:54
Err. I haven't been around enough to test this. Why the heck would they remove top size? Some sourcing would help. Someone? Anyone?
_____________________
---
|
|
Laukosargas Svarog
Angel ?
Join date: 18 Aug 2004
Posts: 1,304
|
05-03-2006 19:03
indeed why, worries me slightly ! there's nothing in the release notes that says it is removed but here's the WIKI page where it says it is... http://secondlife.com/badgeo/wakka.php?wakka=llSetPrimitiveParams hopefully this is a mistake. And I've now more or less proved there must be a bug in my scripts somewhere causing the odd prim movement. But I'm concerned about using topsize if it really is to be removed 
_____________________
Geometry is music frozen...
|
|
Ardith Mifflin
Mecha Fiend
Join date: 5 Jun 2004
Posts: 1,416
|
05-03-2006 19:39
Topsize seems to have been replaced by taper for all prims. Why? It allows you to taper either side of the prim. Topsize would only taper relative to one face, whereas taper works in both directions. Why else? We already had the concept of taper for torii and rings, and we had the concept of topsize for cubes, prisms, etc. Why have two different terms for essentially the same effect? Especially when topsize was limited in the first place.
As far as coding goes, it seems wise to use taper instead of topsize. I sincerely hope they aren't planning to bork topsize support in scripting, though. It would seriously screw up older scripts.
Hope that might have been useful...
|
|
Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
|
05-03-2006 19:41
Naturally, I'm curious 'cause it means I'll have to rewrite a nice chunk of my builder script. Not a big rewrite, but... >.<
Thanks for the info.
_____________________
---
|
|
Laukosargas Svarog
Angel ?
Join date: 18 Aug 2004
Posts: 1,304
|
05-03-2006 19:58
From: Ardith Mifflin Topsize seems to have been replaced by taper for all prims. Why? It allows you to taper either side of the prim. Topsize would only taper relative to one face, whereas taper works in both directions. Why else? We already had the concept of taper for torii and rings, and we had the concept of topsize for cubes, prisms, etc. Why have two different terms for essentially the same effect? Especially when topsize was limited in the first place. As far as coding goes, it seems wise to use taper instead of topsize. I sincerely hope they aren't planning to bork topsize support in scripting, though. It would seriously screw up older scripts. Hope that might have been useful... Yes it is and thanks !  ::waves to Ardith::
_____________________
Geometry is music frozen...
|
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
05-04-2006 10:42
I'm not sure on this, but I think they wrote it so that old top-size values would work as new taper values in llSetPrimitiveParams without modification.
|
|
Seifert Surface
Mathematician
Join date: 14 Jun 2005
Posts: 912
|
05-04-2006 10:51
I tested it, it doesn't break existing scripts, unless perhaps you were putting in a top_size greater than 1.0 and expecting to get 1.0. Now the values from 1.0 to 2.0 correspond to tapering the other side of the prim.
_____________________
-Seifert Surface 2G!tGLf 2nLt9cG
|