Jump to content

Innula Zenovka

Advisor
  • Content Count

    9,638
  • Joined

  • Last visited

Community Reputation

3,512 Excellent

2 Followers

About Innula Zenovka

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Glad you fixed it. Reading through the thread, I was wondering if non-printing characters were causing the problem -- I found them a real nuisance until I adopted this technique when I read notecards: dataserver(key requested, string data) { if(kQuery == requested){ if(EOF != data){ data = llStringTrim(data,STRING_TRIM);//top and tail non-printing characters if(llStringLength(data)){//if there's anything left to read //go ahead and process the data } kQuery = llGetNotecardLine(strNotecard,++data); } } } That precaution saves a great deal of time and f
  2. Thanks so much for all you have done for Second Life, Oz. Wishing you all the best for a long and happy next phase of your life (far busy than the previous one, in my experience!).
  3. I'm sorry, but I don't understand what you want to happen. Why are you wearing it as HUD if you want other people to be able to click it? If you mean you want to wear it and for someone else to be able to send a message to it that bring up the menu for them, look at the script logic -- it fires the sensor when you touch the object, and presents a menu, based on what the sensor has detected, to the toucher. So if you want someone else to be able bring up a menu they can see, while you're wearing the HUD, then you have to make the sensor fire when it hears a trigger message, not
  4. In state entry, you have llListen(gChann, "", NULL_KEY, ""); Earlier, you have defined gChann thus: integer gChann = -29250; //make your OWN unique channel to be sure your not on someone else's. So if you want it to listen to a channel other than -29250, you might consider changing the number you assign to gChann. I'm not quite sure, though, what you want to happen when someone touches it -- at the moment it looks as if anyone can touch it (because you've set integer gOwnerOnly = FALSE;). When they touch it, it assigns their uuid as the value of tReq, and gives them
  5. @ModelAgenturWhat's the script trying to do exactly? It looks as if it's trying to use RLV for force sit people on something, but if it is, that's not how to do it. @sit:<UUID>=force will force the object's owner to sit on the object identified by <UUID>, assuming they have RLV activated in their viewer, that there's nothing preventing them from sitting (other RLV restrictions particularly) and that the object has a sit target set. So if I properly understand the script logic, someone touches the object, it scans for scripted objects within 96 metres (it will
  6. Nope. There is no way, using either conventional LSL or RLV, to listen to anyone else's IM's, unless you're a Linden with access to the server logs. Can't be done in SL. You can listen to chat and have a relay IM it to you (though that's against ToS unless the people whose chat you're monitoring are award you're listening in and have consented) but the mechanisms simply aren't there to intercept IMs.
  7. Just a heads up to other Sublime Text users out there -- my copy of Windows Defender last night started issuing erroneous (I hope) warnings about having found a Trojan in C:\Users\[My Windows Username]\AppData\Roaming\Sublime Text 3\Packages\LSL\windows\lslint.exe with the the unsurprising result that the Sublime Text syntax checker stopped running, which is very bad news indeed, at least if you're me. Since both Malwarebytes and GitHub seem sanguine about the package, I downloaded a new copy and felt confident in following the instructions at https://docs.microsoft.com/en-us/wi
  8. I'm a long time out of the OC world but I really think the next step is to join the support group for one flavour of OC or the other and ask for advice there. There will be some devs there, I am sure, who will be glad to talk you through it.
  9. No, there's rather more involved than that -- it's ages since I've set up an Open Collar from scratch but I do remember you have to follow a particular set of naming conventions for the root and child prims. I honestly can't remember about the perms, but that might be an issue, too. There must be an installation guide with the scripts you've got. Otherwise, got the website of one or the other of the two groups, see where to find their scripts and also look at the installation instructions you're bound to find somewhere on the site. It's not difficult, as I recall. But certainly
  10. I know that Open Collar forked, somewhat acrimoniously, a year or so ago, but I don't know what's happened since. That's the website for what I regard as the "Official" OC. The forked version is at http://www.opencollar.at I don't know what the differences are, and I've never tried making a collar using the forked code, but I would imagine the two processes are very similar. As to the split, I had both old friends and scripting mentors on both sides of the fight and, since I don't use either flavour of OC and have no desire to fall out with anyone, I stayed out of it.
  11. Just to double-check, are you familiar with this site, https://opencollar.cc and are you using their latest set of scripts? I would have thought the OpenCollar group inworld would probably be the best place to ask for help https://world.secondlife.com/group/45d71cc1-17fc-8ee4-8799-7164ee264811?lang=en
  12. For a projectile, though, I normally leave gravity alone (unless there's a good reason to change it) and handle what should happen in a collision event, since it's bound to collide with something sooner or later (and if it doesn't, it's temp on rez anyway, so it won't hang around long).
  13. Oh, I see. Remove gravity before the arrow hits anything, and turn off physics when it does, and if it doesn't hit anything (e.g. you fire it straight up in the air) it simply carries on moving until it runs out of energy and stops in mid air?
  14. Thanks for the clarification about what's happening server-side. But how does removing gravity and locking rotation work better than setting STATUS_PHYSICS to FALSE, which I think is what the OP is doing anyway and finding it doesn't stop the arrow quickly enough? Since the problem involves a delay between the arrow hitting something and the simulator doing something about it, I think the solution is going to be to anticipate what the projectile will hit, and where, and then plan to stop it when it arrives there (or rez a new instance there at the right time) but I think only experime
  15. This is always a problem because the arrow is travelling for some frames before the simulator registers that it's hit the target, sets it to non-physical, and gets the information to your computer about where the arrow is supposed to be when it stops. It's the same bug in the physics system that allows "wallwalkers" to blast you through solid walls, by calling llMoveToTarget to move you so quickly that that the simulator doesn't realise there's a wall in the way before you're though it. You ask for suggestions for a workaround. I'd start by lowering the projectile's velocity, to see i
×
×
  • Create New...