Jump to content

Innula Zenovka

Advisor
  • Content Count

    9,513
  • Joined

  • Last visited

Community Reputation

3,037 Excellent

5 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. That's why, if you want to snap an object back to the original visual rotation when you stop llTargetOmega, you need to do something that forces the viewer to re-redraw the screen -- Calling llSetText with the opacity set to 0.0 and then clearing it will do the trick. So does switching the colour of a hidden face.
  2. As Wulfie says, the reason the rotation is resetting is that you're using llTargetOmega to rotate the object. llTargetOmega is client-side, which means when you call it, the simulator sends a message to your CPU and GPU telling them to draw the object as if it's rotating smoothly until further notice. When you blink the light on and off, that sends a new message to your computer, telling it to redraw the object with the light at the new setting, along with all the other object properties the simulator has stored, including the object's rotation. It also over-writes the llTargetOmega call, so the object stops moving unless you explicitly tell it to keep on rotating by calling llTargetOmega again. If anyone ever needs to do this, and wants to avoid having the object flip back to the starting rotation each time llTargetOmega gets turned off, you need to keep on periodically updating the object's actual rotation on a timer each time the omega changes by 10 or 15 degrees or so, to ensure the object stays visually more or less in synch..
  3. This is from the Read Me in my installed package # Installation This bundle is designed to work with the latest version of [Sublime Text 2](http://www.sublimetext.com/2). [v1.3.2](https://github.com/makopo/sublime-text-lsl/releases/tag/1.3.2) or later will work with [Sublime Text 3](http://www.sublimetext.com/3) as well. ### Using Sublime Package Control The easiest way to install this is via [Package Control](https://sublime.wbond.net). * If you just went and installed Package Control, you probably need to restart Sublime Text before doing this next bit. * Bring up the Command Palette (<kbd>Command</kbd><kbd>Shift</kbd><kbd>P</kbd> on OS X, <kbd>Ctrl</kbd><kbd>Shift</kbd><kbd>P</kbd> on Linux/Windows). * Select "Package Control: Install Package" (it'll take a few seconds) * Type and select "LSL" when the list appears. Package Control will automatically keep LSL/OSSL Bundle up to date with the latest version. ### Using Git Alternatively, if you are a git user, you can install the plugin and keep up to date by cloning the repo directly into your `Packages` directory in the Sublime Text application settings area. You can locate your Sublime Text `Packages` directory by using the menu item `Preferences -> Browse Packages...`. While inside the `Packages` directory, clone the plugin repository using the command below: git clone https://github.com/Makopo/sublime-text-lsl LSL ### Download Manually * Download the files using the GitHub [\*.zip](https://github.com/makopo/sublime-text-lsl/archive/master.zip) or [\*.tar.gz](https://github.com/makopo/sublime-text-lsl/archive/master.tar.gz) download options. * Unzip the files and rename the folder to `LSL`. * Copy the folder to your Sublime Text `Packages` directory.
  4. https://github.com/buildersbrewery/sublime-lsl But you should be able to install it automatically from the Sublime Text Package Control menu. From the instructions there: open Sublime Text open the command palette via Tools > Command Palette select Package Control: Install Package select =BB= LSL
  5. No idea -- you'd have to ask Builders Brewery about that. You're right, of course, 3211 is the current build (and I can confirm that it works perfectly well with that LSL package, which updates automatically once you've installed it). As I say, you'd have to ask whoever maintains the instructions there, but perhaps they may refer to Sublime Text 2.n build 4073 or something like that. Just follow the instructions there about what packages to add, and in what order, and you should be fine. I mentioned it only because I know a friend of mine always has difficulty setting it up on a new machine, while I find it really intuitive.
  6. Great! You might want to take a look at Sublime Text, too, which has a great LSL add-on that allows you to compile the scripts in the editor to check them, too. https://github.com/buildersbrewery/sublime-lsl You need to follow the installation instructions carefully, but it's worth the time, I think.
  7. I'm not sure I understand, Kyrah (and I'm very conscious both that I'm risking going way off topic here and I've probably missed something really obvious) but I've always wondered why can't you use llRegionSayTo(kVictim,iLockMeisterChannel,command). My cuffs should hear that, so long as they are attached. And when the sender receives the confirmation, it can check the message is from my cuffs with llGetOwnerKey(id) in the listen event. As I say, it's probably obvious but I've never really dug that deeply into your system's internal workings -- I know how to script furniture using it, but that's not the same.
  8. Yes, I understand that, but ever since we've had llRegionSayTo -- several years now -- I've been using that function whenever possible , combined with distance checks in the sender or receiver script as appropriate, unless I really do want to broadcast a message to all potential receivers in the area rather than to the object I want to affect. So if I want to chain someone with Lockmeister, I use llRegionSayTo since there's no point in having the simulator check all objects on the region listening on the Lockmeister channel to see how far they are from the furniture when I know which particular avatar's attachments I want to target.
  9. You ask, "What happens when a object, whose creator has depended on whisper range being 5m max, uses a whisper in a region where the whisper chat range has been raised to shout distance or higher?" At present, whisper distance is 10 metres, so if I want to be sure that the sending object is no more than 5 metres away, I would use a filter like this listen(integer channel, string name, key id, string message) { if(llVecDist(llGetPos(),llList2Vector(llGetObjectDetails(id,[OBJECT_POS]),0))<5.0){ //object is within 5 metres, so respond to it } } What's confusing me is that I am trying to think of a reason why I would want to know what function a script is using to send my script a chat message unless I wanted to know the maximum possible distance it could be from the receiver, and since I can already easily tell exactly what that distance is anyway, I'm struggling to see why I need to know the maximum range for llWhisper or llSay, so long as I know the script has received the message and how far away the sender was. Since I know how far away the object is, and I can use that to decide whether the script should process the message, why do I need to know whether the object 7 metres away is whispering, saying, shouting or using llRegionSay? OK, if I know the range for llWhisper has been reduced to 5 metres on that region, I can exclude the possibility that the object was using llWhisper rather than any other chat function, but since I know exactly how far the object is away from the receiver anyway, I struggle to think why I would need to know that a message might have been sent by one function rather than another. I mean, I receive a message from an object, and the script calculates it's 15 metres away. Under what circumstances does it matter whether the message was sent using llSay or llShout? All that tells me is the maximum distance away from which it could have been sent, but I already know the exact distance anyway. The only time I can imagine needing to know that the range of llSay is vs llWhisper is if I want to have a greeter send a message, but since I can trap the recipient's ID in the event that triggers the message, I would normally use that to check on the distance anyway and then, if I want to respond, use llRegionSayTo, so I don't spam everyone in earshot.
  10. Well, no, but I don't see how your proposal tells me that, either. You wrote, "I am proposing the constants "whisper_chat_range", "normal_chat_range" & "shout_chat_range" be added to llGetEnv() so content creators can update their content to detect if these chat range values have been changed in the region their content is operating in." That tells me that, if I send a message using llSay, in what range objects or avatars will hear the message. It doesn't tell me whether the object is using any particular function, only that if the maximum range for llWhisper on a particular region is n, and I can hear an object that's more than n metres away from me, then it can't be using llWhisper. The only time I can imagine wanting to know what the maximum range is for llWhisper is if I don't want anyone outside that range to receive it, which I can do now to by calculating the distance between the sender and the recipient when then recipient does something that triggers the message (or when she's detected by llSensor or whatever) and then sending the message using llRegionSayTo only if the recipient is within however many metres I want it to be. When else would I need to know it for a script?
  11. Yes, I see that, but when you're trying to differentiate the various calls, you're really asking "how far away from the receiver is the transmitter?" At the moment, I find that out by calling llGetObjectDetails(id,[OBJECT_POS]) in the listen event and then calculating the distance between the sender and the receiver. Then I know exactly how far away the sender was, and I can use that information as I choose. What can my listening objects not already do using the method I describe that they will be able to do with your proposed new feature?
  12. Thanks. But since it looks as if we'll need to rescript stuff anyway, what's the advantage to your suggestion rather than simply using a test like this in the listen event? if(llVecDist(llList2Vector(llGetObjectDetails(id,[OBJECT_POS]),0),llGetPos())<20.0){ //do stuff } What do we need the extra function for?
  13. I would use this kind of logic integer iDialogChannel; integer iHandle; key kToucher; list lMainMenu =[ "SubMenu 1","SubMenu 2" ]; list lSecondMenu; list lSubMenu1=[ "Tea","Coffee","Orange" ]; list lSubMenu2=[ "Egg","Beans","Bacon" ]; string strCaption= "Please choose an option"; list lOrderButtons(list buttons) { return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4) + llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10); } default { state_entry() { iDialogChannel = (integer)llGetSubString((string)llGetUnixTime(),-6,-1); } touch_start(integer total_number) { llListenRemove(iHandle); kToucher= llDetectedKey(0); iHandle = llListen(iDialogChannel,"",kToucher,""); llDialog(kToucher,strCaption, lOrderButtons(lMainMenu),iDialogChannel); } listen(integer channel, string name, key id, string message) { llListenRemove(iHandle); if(~llListFindList(lMainMenu,[message])){//message from the main menu if("SubMenu 1"==message){ lSecondMenu= ["Back"]+ lSubMenu1; } else if("SubMenu 2"==message){ lSecondMenu= ["Back"]+ lSubMenu2; } iHandle = llListen(iDialogChannel,"",kToucher,""); llDialog(kToucher,strCaption, lOrderButtons(lSecondMenu),iDialogChannel); } else if (~llListFindList(lSecondMenu,[message])){ if(~llListFindList(lSubMenu1+lSubMenu2,[message])){ llRegionSayTo(kToucher,0,"You chose "+message); } else if("Back"== message){ iHandle = llListen(iDialogChannel,"",kToucher,""); llDialog(kToucher,strCaption, lOrderButtons(lMainMenu),iDialogChannel); } } } }
  14. Additionally, the wiki article on llGiveInventoryList contains an example that readily be adapted to do what the OP wants http://wiki.secondlife.com/wiki/LlGiveInventoryList
  15. Why not declare the list InvenList once as a global, and then building it once in state_entry, and rebuild it in the change event if the inventory changes? Why rebuild the list every time you use the vendor?
×
×
  • Create New...