Jump to content

clarashymonkey

Resident
  • Posts

    15
  • Joined

  • Last visited

Reputation

2 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you so much everyone. I now have my door moving! Not moving as intended, I hasten to add. Something to do with the orientation of the door prim itself I think. It's actually wandering about all over the place at the moment so I do not recommend anyone using the script as it stands. But movement is good so I can work on the rest. [UPDATE: wandering door problem solved! And it wasn't the script. My door is actually for a lift (elevator?), parts of which had somehow got rotated when they were linked to form the whole. It now works perfectly so, once again, thank you *smacking head for not thinking of it myself*]
  2. I am working on a door that concertinas along its x-axis in order to open and close and I have the concertina part working nicely. My problem is repositioning the door as it changes size so it remains butted up against the left-hand door post. It's refusing to reposition! It is part of a link-set (with link number 2) btw. And I am pretty sure I have the maths right. The trouble appears to be the line that should move the door prim but doesn't. I am sure that I am missing something blindingly obvious but I cannot for the life of me think what. Help? vector door_XYZ; // door position vector float door_LHS; // x co-ordinate of the left-hand doorpost float door_SIZ; // door width (variable) float door_MOD; // the amount by which the door shrinks/grows per iteration of the open/close routine door_operation(integer mode){ integer i; for(i = 0; i < 32; i++){ door_SIZ += (mode * door_MOD); // shrink/grow the door door_XYZ.x = door_LHS + (door_SIZ / 2); // recalcalculate the x co-ordinate relative to the doorpost llSetLinkPrimitiveParamsFast(2,[PRIM_SIZE,<door_SIZ, 0.01, 3.35>]); // resize the door prim llSetLinkPrimitiveParamsFast(2,[PRIM_POSITION,<door_XYZ.x, door_XYZ.y, door_XYZ.z>]); // THE BIT THAT DOESN'T SEEM TO WORK } } default{ state_entry(){ door_XYZ = llList2Vector(llGetLinkPrimitiveParams(2,[PRIM_POSITION]),0); door_SIZ = .15; // initial width of the door (open = 0.15; closed = 2.0) door_LHS = door_XYZ.x - (door_SIZ / 2); door_MOD = (2.0 - 0.15) / 32; } // there's a listen triggering the open/close routine with the appropriate open/close (-1 or +1) parameter }
  3. You're right, llLinkedMessage doesn't work. So llRegionSayTo it is then, it seems. And, as I now have to go that route, now I know that it speaks to an avatar's attachments as well as to the avatar itself … I think you have also just solved another little problem I could see heading my way in relation to a future part of the overall project I am working on. It all looked so simple as a flow-chart lol. Thank you again, anyway. I shall now put away the headache pills!
  4. Thank you so much. For some reason it was totally doing my head in. Getting the seat-object C to recognise the avatar was easy enough and I have even got it reading the data stored in the avatar's attachment but, in terms of the two talking to each other, that was as far as I got. I hadn't realised llRegionSayTo messages sent to an avatar would simultaneously message the avatar's attachments. Must remember that one! I wonder though, would the same apply if I was to use llMessageLinked? I mean taking advantage of the fact that the seated avatar becomes part of the seat-object's link-set, would those messages also be picked up by the avatar's attachments? llRegionSayTo just struck me as a bit of a sledgehammer to crack a nut when I first considered it.
  5. I think my brain has turned to mush. I have an avatar A, wearing an attachment B, who sits on an object C. In practice, A could be any one of a number of avatars, each with their own copy of the attachment B. I am trying to decide the most efficient way to have B and C exchange information in a one-off, one-way conversation — either B-to-C or C-to-B; both would do the job. Thoughts anyone?
  6. Thank you Wolfie. I thought what you said probably was the case but felt I had to ask. As to whether or not the offending variables need to be integers, I suppose the honest answer is no, except insofar as they represent quantities that are naturally integers and need to serve as divisors in only four instances — to yield the temporary percentage-type logical control variable 'x'. I just hate ugly looking equations, I suppose, but one pays one's money and make one's choice. Thanks again though. At least now when the project's mathematician complains about me butchering her pretty algebra, I can blame SL
  7. Me again! I wonder, is there a more elegant way of scripting the algebraic equation ... x = y / (K - z)? The best i can do is that given ... integer y; // defined as a positive integer elsewhere in the script integer z; // defined as a positive integer elsewhere in the script integer K; // defined as a constant positive integer elsewhere in the script such that K >= y + z ... then ... float x = (float)y / (float)(K - z); ... typecasting the RHS of the equation being (apparently) necessary to avoid z = 0 regardless of the RHS values. Is it just me thinking that looks too ugly to be as good as it gets? Is there a better way?
  8. Thank you so much Wulfie. DUH! Why I hadn't thought of that I have no idea. It's so obvious now that you mention it. Too close to see the wood for the trees I suspect.
  9. I think I already know that the answer to my question is no, but I thought i'd ask it anyway. Briefly, I have scripted a little drop-box in which people can deposit notecards as a way of contacting a SIMs management and, as far as that goes, it does the job, filtering out deposits that are not notecards, informing its owners that a new card has been deposited and so on. My question is: allowing for the likelihood that the drop-box may already contain several notecards whenever a new notecard is deposited, is there any way to identify that latest addition to the drop-box's inventory? Accessing each notecard's 'acquired' time-stamp would do it, but I can't find a way to do that. Any thoughts? Suggestions? Have I missed something obvious?
  10. Oh dear! Umm … okay so now that I have my data safely stored in the invisible text of my attachment's child prims, returning to my original difficulty, how do I get other objects (not part of the attachment) to access it? I had, perhaps foolishly, assumed that llGetObjectDetails would do the trick but, on closer inspection, while it appears to have a parameter for just about everything one could possibly wish to know about an object, almost down to the colour of its creator's undies, surprisingly OBJECT_TEXT or the equivalent seems not to be among them. So, am I back to square one? Back to exposing the data in the root prim's description where other objects (and end-users) can get at it? Now up against a bit of a deadline, I think i am just going to have to just go with that, but I am still open to alternatives if anyone has any. Sorry Molly
  11. Well I have done it and I must say it works brilliantly! Setting the child-prims' text alpha temporarily to 1.0 (visible) has also made debugging the rest of the suite so much easier, I am still kicking myself for not thinking to use PRIM_TEXT before. I have left the bits that will be queried by the on_rez checks in end-user accessible descriptions though on the grounds that (to quote my RL mentor) "a good castle should always have what appears to be a weak point to tempt attackers into foolishness". However, not all good news I am afraid because,, as he also rightly pointed out, the caveats SL has attached to the use of text for data storage (http://wiki.secondlife.com/wiki/LlSetText) do mean this method is far from perfect and therefore perhaps not suitable for everyone trying to solve the problem I had. Fortunately, I don't see anything in the caveats to trouble my little project so my gratitude for the suggestion remains undiminished. The integrity of the data I am storing is critical only at run-time you see and, if it is corrupt, that will be picked up by the aforesaid on_rez verification routines long before it can do any harm. Just thought I should point out the caveats though for the sake of my bottom and for the benefit of others who might be tempted by my enthusiasm to use the method for the long-term storage of critical data that cannot be easily replaced/reconstructed.
  12. Hadn't thought of using the child-prims' text. Thank you so much for that! More bytes too I see, so smacked bottom for me at bedtime! LOL It's just so obvious now that you mention it, I can't think why I didn't think of it before. DUH!!! I am already using colour vectors to store a few floats however, so I am getting there I think. With so much yet to learn, though, I am almost tempted to give another whimper, but learning new ways to achieve the 'impossible' is such fun! Again, thank you so much, Molly!
  13. I take your point but, actually, I have all the child-prims physically encased in the root-object so, while I agree their descriptions could be tampered with, the end user would (a) have to know they exist and (b) I think physically dismantle the attachment to get at them. Moreover, tampering with the most critical values results in a mismatch between the user-modified settings and those stored in a SHA1 hash during (authorised) first-use initialisation, causing a doctored attachment to die as soon as it is rezzed. In short, having accepted that total data protection is impossible, I was rather trusting to people's lack of tech-savvy to reduce the risk of tampering to a minimum; hence my reluctance to have the data exposed in a description any fool can see if they know how to click 'edit'. Just had the need for defensive programming drummed into me, I suppose — Murphy's Law and all that. I should perhaps just add that I am not overly OCD about it. It's just that parts of the mathematical engine that drives the attachment are non-linear so I have no idea what tampering would do to the output and would prefer to be nowhere near the attachment's wearer to find out. It's a bit 'biological' you see, so it could get horribly messy! LOL
  14. Thank you everyone for at least confirming that I haven't gone bonkers. For the record, I had already considered all of the work-arounds suggested (and a few others) but had hoped to avoid having to use them in the end product.. On balance, however, I think using the root-prim as a temporary 'session-only' data-store seems the least worst option available and I already have a working prototype. I suppose I just have to pray that end-users are too busy having fun to edit the root-prim's exposed description and thus modifying the data on which the rest of the script suite's concept depends. *wimper*
  15. I am trying to decide if I am attempting the impossible or missing something stupidly obvious, so I thought I would ask. Basically, I am trying to read the description of a child-prim contained in an attachment worn by avatars detected by the object containing my script. The detection side is all taken care of and, from that, I am able to read the description of the attachment's root-prim, no problem. I just can't work out how get into the rest of the attachment's link-set, where I have the attachment using child-prim descriptions for data storage. I suppose what I am hoping for is a cross between llGetObjectDetails and llGetLinkPrimitiveParams. Does such a function exist? Still learning LSL so any help would be greatly appreciated.
×
×
  • Create New...