Jump to content

Jenni Darkwatch

Resident
  • Posts

    1,703
  • Joined

  • Last visited

Posts posted by Jenni Darkwatch

  1. @JCampbell:

    Rolig and Void are both lightyears ahead of me in scripting as are quite a few other residents. :) Roligs answer would have been my suggestion too. If you _do_ need to teach script-to-script interaction, here's a little tidbit that might help (the ownerOf function in particular):

     

    // Little helper function to get the owner key of any object (by object key)key ownerOf(key object) {    return llList2Key(llGetObjectDetails(object, [OBJECT_OWNER]), 0);}default {    state_entry() {        llListen(0,"",NULL_KEY,""); // Warning: Listening to channel 0 like that is not a good idea     }    listen(integer iChan, string sSender, key kSender, string sMessage) {        // Basic check to make sure we're getting chat from an object that belongs to us, not from some stranger        if(ownerOf(kSender)==llGetOwner()) {            // Do something here            llSay(0,sSender+" belongs to the same owner as me and said: "+sMessage);        }    }}

    This script could, obviously, be written to consume less ressources by ditching the function and streamlining the check, but it's IMO easier to read as is. I wrote it from memory, so it might not compile due to typos.

    If there is a better way to do this (aside from obvious optimization) I'd be happy to learn :)

     

    • Like 1
  2.  


    Rhonda Huntress wrote:

    Odder yet, as long as I have my mouse over the SL window, my boobs behave and sit still.  I click over here on the web browser and they start shaking like a couple of maracas.

    That's a side effect of the client yielding CPU time. The physics code wigs out (only on your screen) if the client lags. Try a busy sim, you'll get the same issue (depending on your CPU and settings).

     

  3.  


    Jonna Korhonen wrote:

    I'm more interested in what is responsible for creating the effect. If avatar physics is managed by the users viewer (client side) then everyones settings are going to be different. How much does the various forms of lag affect physics as well. I played around and for settings that looked okay on me turned out quite wrong on someone else when I gave them the layer to try out.

    It's entirely clientside, just like the old crappy "make everyone jiggle" code. Lag affects it a great deal, and if you run low FPS, it's equally bad. From what I can tell (I have SL on different PCs with different hardware), it looks identical on all avis if the CPU isn't totally hogged. As soon as FPS drops into below-20 range things get "interesting". The main factor there seems to be gain. If gain is high, it'll get... wiggly when it lags.

     

  4. As an aside to what others already said, it also highly depends on what area you're at. A lot of RP sims use HUDs, often very badly written ones, which shoot memory use and script count per avi through the roof. Then there's nonhuman avis. I won't mention names, but a few very well known makers of animal avis have utterly ridiculous script counts and mem use over 10MB per avi. The average seems to be around 4 or 5 MB per avi.

    Another example: My favorite avi had, out of the box, around 110ish scripts using up around 8MB. Thankfully the creator made all scripts fullperm, so I went to town with it. Result: down to 29 scripts and 1MB, and I'm not even done yet.

    SL requires a programming culture that simply doesn't exist anywhere else anymore. Scripters should(!) be aware of the ressources they use... open listeners, timers, memory use, the damned mono bug which currently seems to mandate old-style LSL compile for anything attached to an avi... the list goes on for a while.

    Script limits should be a wakeup call, though I'm afraid the limits will be so high that even people with resize/recolor scripts in every single prim they wear won't be affected by it, hence the "limits" won't be anything more than a token effort. On the other hand, LL has given us the tools to pretty much police script use ourselves. Just boot people who don't meet your limits off your land.

  5. The trick to realistic physics settings seems to be in understanding what the sliders actually _do_. It took me a while, and I'm not sure I figured it out correctly (I'm not usually in human shape).

    Max Effect is just that... a general amplifier of the "bounce" effect. The higher this slider, the higher the initial bounce impulse. It seems to correlate to the effect of the softness slider in flexi prims. This one gets directly opposed by "Damping", the last slider (more on that one below).

    Spring is kind of a "center spring", it pulls the body part in question back to its neutral position. If that value is low, the body part "swings" around the center more. If it's high, there's not much bounce. :) It seems to be akin to the tension slider in flexiprims.

    Gain... that one is a bit of a mystery to me.

    Damping. That one works directly against any bounce. The higher it is, the quicker any bouncing subsides. For me, the best analogy here is what I'm wearing. I.e. breasts: Nothing at all? Low damping. Swimwear? Medium damping. Corset? High damping. :)

    It appears that if any of the sliders is set to zero, the corresponding body part doesn't move at all.

    Presuming I wear swimwear, I'd probably go for something like these (values are Max Effect, Spring, Gain, Damping):

    Breast Bounce: 36 33 37 24
    Breast Cleavage: 30 3 9 50
    Breast Sway: 32 2 9 45

    Belly Bounce: 46 24 14 36 (barely noticeable on a skinny girl)

    Butt I generally leave turned off... IMO the bounce/sway there looks ridiculous and wrong.

    These values are for Breast Mass 0 and Breast Gravity 31, Breast Drag 84 (in the Advanced Parameters section). I left Belly and Butt at their defaults (Mass 0, Gravity 0, Drag 30).

    I really wish some Torley...er... Linden lab employee would make a good guide on that one, explaining EXACTLY what the sliders do ~g~

     

    p.s.: Apologies if the values are a bit specific... I'm really VERY rarely human. Sorry.

    • Thanks 1
  6. That post seems... a lot of hot air, no facts, no nothing. Build almost any prism with sculpts, then build one with mesh. Difference? A ton less vertices for mesh. How that's going to lag servers any worse is beyond me, though. Physics maybe.

  7. I tried the llGetLocalPos method too, but it doesn't seem to update either - in the end I went with plan B and just added a menu driven adjuster. It appears to me that it's either insanely hard to get a prim position for any attached prim, or entirely un-intuitive. Or I'm just too dumb to understand how it's supposed to work.

    Thanks for the assistance anyway, Shockwave.

  8. I guess I should have been more clear:

    Of course I wear the linked object, and the results are when wearing it and moving the whole linkset around. I merely need a way to determine the position of a prim in a regional context - when that prim is attached to an avi. I'm aware of the issues with animation (it's clientside and the prim doesn't follow it) but that's not a problem.

    The desired result is that I know _exactly_ where the prim is in region coordinates, so I can use it as destination for a moving object and/or rez something exactly at the prims location. Something like rezzing a bubble around a wearers head - move the attached object up/down to get a decent fit. There's other ways to solve this, attached prim would be the most logical for me.

  9. Oke, I _know_ this has been asked before but I can't find the answer anywhere. According to the wiki, llGetRootPosition() is the avi region position. llGetPos() is the avi region position if it's in the root of an attached object, and the prims' region position if called in a child prim. Except, that last part seems to be wrong or I'm misunderstanding the way it works.

    If I create two boxes, link them together, and put the script below into the _child_ prim, the results never change even if i reposition the object on the avi:

     

    default{
        touch_start(integer iNum) {
            llOwnerSay("Avi:"+(string)llGetRootPosition()+
                       " Pos:"+(string)llGetPos());
        }
    }

     

    If I edit the linked set and move it around... it doesn't change position (I moved it three times, no change):

     

    [13:50] Object: Avi:<78.42548, 138.16290, 4052.70200> Pos:<78.62835, 138.37140, 4052.70200>
    [13:50] Object: Avi:<78.42548, 138.16290, 4052.70200> Pos:<78.62835, 138.37140, 4052.70200>
    [13:50] Object: Avi:<78.42548, 138.16290, 4052.70200> Pos:<78.62835, 138.37140, 4052.70200>

    What am I missing?

  10. Its a bug, has been for a while... it depends, I think, on who initiates the conversation. No idea if a fix is in the loop or not, and it has nothing to do with display names either. These days the log files are only named with the username, never with the display name (at least not on my machine).

  11. it all depends on how sure you need/want to be with your communication. Time+Owner is guessable, that's why it's generally frowned upon as auth mechanism.

    The principle is that even if a potential miscreant knows _exactly_ how the auth mechanism works, they should be unable to break it. For most SL use where no money changes hands, that's probably overkill.

  12. You could simply use llFloor(llFrand(2^23)) I'd think. If you need something that doesn't require the initial exchange of nonce value you could poissibly use a timer value, though that does by default make it less secure. Of course, I don't know how secure (random) LSL llFrand is either.

×
×
  • Create New...