Smart Skirt Script... Help please!!!

Just a quick note that I've uploaded the latest version of SkirtSitter to the duchyofdarkmere forum thread I gave above. There are three additions to the script:

a) "Copy/Paste" position/rotation data from one animation state to another. This provides one general solution to the "cannot walk/fly/etc and edit" problem.

b) Ability to dump out all the position/rotation data to chat. The user can copy this to a configuration notecard, which the script can subsequently read back. Allows backup of settings, and the ability to rapidly set up a large number of geometrically similar skirts using the first as a template. The notecard system is completely optional however.

c) A command to "wipe" the script, clearing all stored data.

Erm. Well, I do Victorian outfits, so I have gone into the 60 prim region, the highest being around 80 prims. Not all of this is just the flexi panels: things such as ribbons and bustles add to it as well.

Personally, I don't mind the chat commands, but I think most customers like the Dialog boxes. Unless you can come up with a work around, customers who move their skirts will need to reset all the positions. Otherwise, the Skirt Adjuster will simply move the skirt back the second the script is running. I can see how this might confuse and frustrate a customer who isn't clear on how the script works.

So, ideally, the drop downs for the *customer* will not have resets so much as tweaks. Most of these adjustments will be on the attachment z axis, some on the x axis, very rarely on the y. I summoned my meagre scripting skills and tried to write a dialog on drop down that adjusted the up down (eg. touch the up button, and sitpos.z=sitpos.z+.01; etc). The script completely borked and stopped adjusting.

Assuming you can get the customer adjustments to work, one thing you might consider is putting all the listens for the creator adjustments in a separate script. This script would communicate via linkmessage to the base script, then you could delete it when the creator is done with it, thereby reducing the listen events.

Oh, and in general, any extra adjustments are good, but really not that necessary. I wouldn't want to have a running script for each panel for lag reasons. (hmm...although a gesture with a lady holding her skirts up when curtseying or walking would be grand)

For me, being able to tinker is important. As a small AV, I usually have to mod most prim-skirts I buy to get them to fit properly, and this in turn affects the script settings. Also, if you change the animations you use, you need to change the script settings - settings that leave a skirt reasonably well positioned for an AV seated in a non-crossed-legs pose, will have your knee protuding through the skirt if you decide to cross your legs. The skirt designer has no way of knowing what animations the end-user will use.

However, I could live with re-installing the "tinkering scripts" when necessary, if this provided other advantages (simplicity or efficiency of code, etc).



This would be a very useful feature, yes. Let me give you a recent example.

My latest purchase includes a lovely flexi-prim-skirt that falls beautifully whilst I'm standing, absolutely no gaps between any of the individual prims. When I rotate that skirt into a more horizontal orientation (to support sitting down), small gaps open up between some of the prims as they "fall" differently. Using the proposed feature, one could adopt a "quick fix", by simply moving a few of the prims around to minimise the gap. Alternatively, one could do a general redistribution of the prims around the waist of the skirt, bringing more from the back (the bottom when sitting) around to the front (top).

You may well have already solved them , but I could see some significant difficulties in implementing this in LSL. I'm assuming you'd use something like llSetLinkPrimitiveParams to avoid placing a script in each prim, but storing the position/rotation data for each "moved" prim could still amount to a lot of data. Might even need to store that across multiple scripts?

Thanks Lindal, Arikinui, Finora, Virrginia, and Cale for your responses! This post is gonna be ultra-geeky (even by my standards), but I wanna get these script design ideas out there, in case RL keeps me from a timely implementation. Yep: it'll definitely need multiple scripts, but I was kinda probing for hints as to how to most sensibly farm-out the work. Right now, I'm envisioning three classes of scripts, two of which have multiple identical instances:

1. A single "Main" script that controls the overall state-of-play and farms out work to the other scripts. (I was toying with splitting this as well, to separate out the "recording" and "playback" functionalities, but now I'm thinking this might just be a state transition.)

2. A bank of "BAS" scripts that record and play back the prim settings, one per recorded BAS, and

3. A bank of "effector" scripts that perform the actual llSetLinkPrimitiveParams() calls, to get around the 0.2 sec delay built-in to that call. It's tricky to set the count for these, and the "right" number really depends on the number of prims in the skirt that individually change position and rotation depending on BAS.

(For this kinda stuff, it's really annoying that llRemoteLoadScriptPin() can't populate its own prim, and I'm not eager to use a second prim--so some user judgment may be needed, along with the usual hairy instructions that go with installing multiple copies of a script. llRemoteLoadScriptPin would come with its own baggage: each to-be-populated prim would have to have been preset with llSetRemoteScriptAccessPin, and I'm just paranoid about the exploit potential of remote-scriptable attachments, even though it shouldn't be a problem.)

The basic idea is to use llGetObjectDetails to get the position and rotation of each individual prim in the skirt, and record those that differ from the "default" condition*, per BAS. This should avoid having to put a script in each prim, which would have been necessary before the introduction of this LSL function in 1.18.3.

One thing that I'd never even considered is the possible value of per-ANIMATION settings, augmenting the per-BAS ones, to handle the dreaded "crossed-leg" scenario. For now, I think it best to punt on that--not because of script complexity, but because I really don't want to be doing llGetAnimationList, like an AO... although, in fact, that could be done only in BASs that have recorded per-animation settings, so it wouldn't have to be a lag-monster. Anyway, that would be one of those "future release" features; there's always a chance LSL will get something like a CHANGED_AGENT_INFO or agent_info() event to make this (and AOs, etc.) more efficient.

It should be trivial to add an optional function that does per-BAS setting of flexible path parameters, but it would have to give all the prims the same setting, because there's no way with current LSL to get these settings from another, unscripted prim. (Well, one could include/exclude prims by name, but I dread writing up instructions for that. Or one could push out recording-state-only scripts with llRemoteLoadScriptPin, with the aforementioned caveats about that function.)
____________
*There's a bit of hand-waving here. The idea is to minimize memory consumption by only recording each BAS's delta from default. But when the BAS changes, the prims that need to change are those that differ from the preceding BAS, not just those that differ from the default. So maybe the "Main" script does the actual playback, keeping track of which prims need tweaking with each BAS transition, and the per-BAS scripts are just memory.

Aieee, Qie! That sounds like my skirt might have a script in every prim, and be smarter than me.

I'm completely LSL-challenged, but would a different approach be possible? What about having multiple copies of the skirt, one for each base position? Have a second object that contains the script, call it a master skirt controller. Depending on your pose, the master controller swaps out the skirt you're wearing for the appropriately-modified skirt in your inventory.

Oh, I'm LSL challenged. The script for the skirt-sitter isn't that bad, just plug in the script part of it and go. You go to the appropriate pose and then edit the skirt into position and hit record. Only thing is there isn't any documentation on setting up the config card in the FAQ

I'm not to sure about the suggestion, because SL has a bad track record when it comes to 'quick rezzing' stuff from the inventory. Sometimes it works and sometimes it leaves your bare bottom in the breeze

OMG, this is sooo simple! Just literally cut and paste the text from the chatter onto the note card. Cale, big thanks for making this so 'script-kiddie friendly!'

Ah, no, most of the sleight-of-hand in that long-winded post was to explicitly *avoid* having a script in each prim, thanks to recently-introduced LSL functionality. (The place where that would still be impossible would be recording of per-prim settings for things other than position and rotation--notably flexible path parameters that changed differently for different prims in different basic animation states; so I mumbled a bit about how that could be done by per-prim scripts active just during the recording phase, but that's beyond what I'd actually propose doing now.)

I'd have to puzzle over the "skirt-swapping-script" idea. There's no way for a script to get at a skirt in your own Inventory, but it could in theory rez one from *its* inventory and have it ask permission to attach, but that would be pretty inconvenient for the skirt-wearing public, I think. In build-enabled parcels, it could rez new prims and link them together with itself... but I think no way to get rid of the old ones without each prim having a sort of "suicide" script that activates when it's de-linked... and rezzing and linking would be a real lag source. So... this seems hard. But I like the elegance of the concept, and would be very happy to learn of a simple approach!

But anyway, I for one embrace our new smartSkirt overlords!

I don't suppose we're fortunate enough to have the client not render objects that are invisable (alpha=0.0)? If it wasn't for the additional render load, it might be tempting to have all the skirts rezzed at once, and just make the not-currently-in-use ones 100% transparent and have all their scripts bar a controller go inactive.

Just thinking out loud here, don't mind me.

That would be a fair number of prims, and with that many prims, I am sure that one or two would lag in the set alpha, making for a stray skirt panel or ribbon flying about.

Rezzing a skirt would have the downside of creating a bit of an unattached skirt moment Besides, who wants to agree to permissions every time you stand up?

I think your original idea using llSetPrimitiveParams sounds more workable. I confess that I'm not quite following the trick to keep the scripts out of the prims, though. You can now reposition a child prim using a script in the root?

Well, according to /109/70/214665/1.html#post1705009, objects with transparency actually get rendered *twice*. (A later post in that thread suggests that it doesn't matter if the transparency is from a 32 bit texture or applied via llSetLinkAlpha(), though it didn't sound definitive about that.) And they would still be prims to the sim, so there'd be some lag involved in maintaining their geometry and pushing it out to all the viewers. Really no idea the relative lag impact of that, versus some scripts doing prim geometry on attachments. (I hate empirical questions that require actual work to answer.)

Yep, that's the magic of llSetLinkPrimitiveParams(), which was introduced in 1.13.4. But there's no corresponding llGetLinkPrimitiveParams() -- so during the "recording" phase, no way to find out the child prims' parameters. What's brand-spankin' new, though, is llGetObjectDetails(), which seems to be working in my trials for getting just the position and rotation of child prims. (That's why all the fuss about flexible path parameters: we can *set* 'em, but unlike position and rotation, we just can't *get* 'em.)

If I bought a smartskirt, I wouldn't ever want to have to deal with it. It should come adjusted for basic sits (not the funky sits, with knees up and stuff, just basic.)


It would be nice, but a major hassle. Perhaps if the end-user REALLY wanted to tweak her skirt, she could ask the designer for a tweakable version of the script. My average skirt-buyer, though, probably would have difficulties with this.

3. Concerning flexi-prims:



Mine don't... all flex parameters are the same. Those are just my skirts though. And, no, I wouldn't want the flex parameters to change with animation state; I worked very hard to get them to move just "so" while walking, etc.


Anywhere from 12 to 24. I don't go higher than that. Some huge ballgowns have a gazillion (I saw one with 128 once) but I'm guessing that average flexi skirts are around the tens to twenties range.

I don't know if there is any interest, but I wrote a tutorial for the Attachment Set skirt adjuster (the free one Carricre Wind has put out):

http://labicyclette.blogspot.com/2007/10/attachment-set-tutorial.html

Not having used the other skirt adjusters, I'm not sure how much is applicable to those, but I suspect that things like the skirt positions would remain the same. Also the drop in script that stops the script in lag areas will work for those (if it is not already built into the script), just replace "AttachmentSet OSS" with the name of your script.

Happy virtual sewing, everyone!