|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 05/Mar/07 08:55 AM
In your last example, when you say it "does not work", what is the actual result? I kind of got lost in your explanation.
it recolors the entire prim to the last entry. (black in this case) instead of coloring most of it green and one side black. it doesn't silently fail, or give errors, it just does not work as intended. The first set of commands paints the whole object green except side 0, which will be black, then sets the texture to "blank". The second command paints the entire prim black, and sets the texture to "blank".
I did the bug report first, then a friend told me to post it here too, so I did.
I've seen this issue too, thanks for posting it.
 Currently tearing hair out because of this one. Please fix it while I still have some of my lucious, flowing, golden locks left!
apparently this issue is propagated through to llSetLinkParams, because i get the same results when trying to change different faces.
these parameters DO NOT apply properly to different faces (only the first parameter is applied to all subsequently called faces): this parameter DOES apply properly to different faces: this is still broken in the beta (1.8...something? gah, numbers!)
i'd really like to see this fixed. soon! i have two products on hold waiting for this to work.... :/ There IS a workaround to the problem with the parameters that work with sides, although it's really annoying to code for:
if you stride each side of the call so that ALL the parameters are passed for that side, and then ALL the parameters are passed for the next side, and repeat for each side, you'll get the desired results. sorta like this: also, did anyone test the PRIM_TEXGEN param? is it affected the same as the other two? What about PRIM_FULLBRIGHT? I discovered this issue tonight, and the way it is working leads me to suspect the possible nature of the problem.
Any time you do a set of rules which look like: [PRIM_FOO,1,<other params>,PRIM_FOO,2,<other params>,PRIM_FOO,3,<other params>,PRIM_BAR,ALL_SIDES,<other params>] it seems to apply the last PRIM_FOO setting on all the sides as well, instead of just the specified side. If you rearrange it like so, it works: [PRIM_BAR,ALL_SIDES,<other params>,PRIM_FOO,1,<other params>,PRIM_FOO,2,<other params>,PRIM_FOO,3,<other params>] So, I figure what is happening is that it is buffering changes for different sides, but when it hits an ALL_SIDES, it tells the last rule of each type to also be set to ALL_SIDES. Anyway, that's the best workaround I can come up with. Do the ALL_SIDES rules first, then do all the individual side rules afterwards. Talarus: I don't think so. I've had this occur in rule lists where ALL_SIDES is never used at all, so whatever the problem is, it's more subtle than something happening when you hit an ALL_SIDES.
This has been around for too long
I have made changes to this logic in the havok4 beta (not yet released to early adopters - but soon!). Please do test it out, I am looking for feedback. In particular:
Kelly, why in the havok Beta? What does this have to do with havok?
Unsurprisingly, this bug seems to be in llSetLinkPrimitiveParams() as well.
Kelly, I'm working on a transforming object in Havok4 and am still seeing these bugs. Although less pronounced than they were in Havok1, the problem is not gone. Unfortunately, it's also not consistent. In the following example, the script should turn prim #6 on a linked set into a door.
llSetLinkPrimitiveParams(6, [ The shape transformations work correctly, but the door textures (face 1 and 3) are not applied until I run the script a second time. I just discovered the flexible bug myself. Interestingly enough, if you put flexible after PRIM_TYPE, it seems to work.
Any progress on this bug? I see there was an update October 11, but no indication of what changed.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
llSetPrimitiveParams has issues with multiple parameters in one call
