Changing a prim's height and adjusting llSitTarget

I'm a new scripter, trying to catch on. I need some advice. I want to create a pedestal that's a sit target. Right now, something simple: a table top on a column. I'd like the column to grow in height (not just scale up, but scale and translate), and as it increases in the z axis, the table top needs to rise, as well as the sit target.

Ideally, this happens while the avatar is animated on the table top.

I've got the basic pose script working fine, it's the dynamic changing of one prim affecting another prim I'm having some trouble with. Do I need to use link messages?

TIA

Hmm, the main problem I see is that you'll sit on the table once, and then a script will resize the table... However, once you sit in one place it basically "locks" you to that place and that camera-angle.. In ottttther words....

I would make your table and your "table top" two seperate items. Then, when you "resize" the table, make the table top move up and down. That way, you're really sitting on the table top and as it moves up and down, you move up and down.

In other words, the sit-target can't dynamically rise - the only way I know is to make 2 seperate objects - since they're not linked you might need to use a listen to make the base of the table tell the table top "move up/down this far"...

or have it unlink, move and resize, then relink . . . then it won't have to be two items you have to rez each time you put out . . .

I may be wrong but I don't believe you can resize objects when an avatar is sitting on it. Or, maybe that's only physics objects. I forget.

Logan and Rodrick: I sort of thought about making the sit target just relative to the table top, and having the table top rise as the pedestal increases in size, but I wanted it to be low-lag, so I wasn't thrilled about listen() events. Maybe I can do the unlink - size - relink, but I wonder what happens to the sit target when the center of gravity changes with the link changes.

Harris: you can scale objects with an avatar sitting on them.

thanks for the hints. I'll post once I figure something out.

I just know in relation to what I've tried with vehicles...

When you sit on a seat in a vehicle, and try to make that root prim seat or any of the child-prim seats move (just the single prim using llSetPrimitiveParam as opposed to moving the whole linkset), the AV's position stays the same. It's like once you sit, you can't change that offset and you're stuck. Yes, you could unlink them, dunno if it would work but it's a good idea - unlink them, prim you're sitting on moves up, base-prim(s) scale, and then they relink - and only become unlinked when it moves. I just haven't done much with scripted linking/unlinking of objects yet...

thinking out of the box... you could cheat
If this is gonna be used on you ground-level floor - you could make the column its full length from the start - but embed it into the ground so that only a short piece protrudes.
Link the table-top to this and make sure that your movement script is in the parent.
When an av sits, just move the entire object up.
Would that work for you?

hmm, yes, like a hydraulic lift. Then the center of gravity won't change, so the offset stays fixed. Might work, but only in specific areas.

So far, my best attempt at doing this with multiple pieces is to leave them unlinked, and chat messages from column to tabletop about height. As the column grows, it sends a message so the pos.z of the table top increases. kludgy.

Second best bet: leave it as one prim, and just raise the whole thing off the ground. Not the nicest visual effect.

I'll be honest, I haven't played with the unlink - move - link method yet.

aha! that gets me thinking. you know how many RL systems consist of a few concentric cylinders (like a 3- or 4-part telescope)? the inner tube is linked to the table-top, once again the pair move together, COG stays the same, sit offset stays the same. The other cyliders are slaved in using the messaging system you describe.
Don't allow the cylinders to collapse/extend their full length, leave a bit of overlap in both positions - always position each cylinder in the center of its nominal range - and you should find that even if the system lags, the whole things sticks together without annoying gaps or overshoots.

That's a great idea! And would look pretty good too. Each cylinder would just need to move itself along its central axis within some boundary limits. Wouldn't look "magical"; it would be quite true to life.

Did you do the hydraulic lift sketches yourself?

Yeah, it's amazing how often this happens. We get frustrated at the limitations of the system within which we work, and are forced into thinking of smart work-arounds for the problems we experience - only to end up with something that looks better than our original idea!
yup - you gotta love Photoshop!

As an afterthought, you might want to make all the cylinders solid - I *think* the render engine will be slightly happier with intersecting cylinders that with the extra faces involved in hollow tubes. Can anyone confirm/deny this?

Making the cylinders hollow will give you an extra face to render on each cylinder, and won't gain you anything if you get the coding right as no-one will see them.

If they're linked I'm pretty sure the physics engine will happily ignore the fact they're interpentrating as long as you don't enable physics. Oddly, if I understand some of Andrew's posts on the matter correctly, if they're NOT linked and not physical the physics engine will prefer that too, it says "Oh, they interpenetrate but they're allowed to" and moves on. If you hollow them it stops and says "Their bounding boxes interpenetrate, but they're hollow, oh, they dont' really interpenetrate" and then moves on.

So yes, I guess you gain a tiny bit of speed advantage from making them not hollow as long as you can get the movements OK without using physics.