Innula Zenovka

You can only call functions inside a state, so you would need to start something like this: integer randchan;integer DIACHANNEL;list Numberlist = ["1", "2", "3", "4", "5", "6"];float Birdno;key owner;birdrez() { llRezObject("Humbirdsculpt12Atemp", llGetPos() + <0, 0, 0>, ZERO_VECTOR, ZERO_ROTATION, randchan); }default{ state_entry() { owner = llGetOwner(); DIACHANNEL = (integer)llFrand(-50000.0); llListen(DIACHANNEL, "", owner, ""); randchan = (integer)llFrand(-50000.0); llSay(randchan, (string)llGetKey()); birdrez(); llSetTimerEvent(Birdno); llOwnerSay ("Birdno is " + (string)Birdno); }//and so on...} Make sure you do something to reset the value of "owner" when the item is transferred, though.

Specifially, a bounds check error sems to be an all-purpose, "out of cheese" error message ("You" in this passage seems to be Babbage Linden): [8:51] Phantom Ninetails: Hard to decide what affected version to set..[8:51] Cago Hax: what does mean 'bounds check error' anyway ?[8:52] You: it's used whenever the LSL2 VM gets confused[8:52] SLezzer_LSL2 [script:Menu_manager]: Script run-time error[8:52] SLezzer_LSL2 [script:Menu_manager]: Bounds Check Error[8:52] You: often it means that a register has started pointing outside a script[8:52] Cago Hax: hum...[8:52] You: but it is used as a general error when the VM state stops making sense I most usually see it after I've tried to save a mono script and failed, because it won't compile and then forgot to compile it in Mono again after I've got it fixed.

There is a helpful article in the Knowledge Base on Opening Boxes

I do it a bit differently, on the basis that if there's more than 16 people in range, the sensor will only detect the first 16 of them, so the fact you don't detect someone doesn't necessarily mean they've moved out of range. So, once I've spotted someone, I grab their key, too, and use llGetObjectDetails to see if they're still around. Something like this: float frequency = 5.0;float range=96.0;integer max;integer toggle;key owner;key k;list detected;string s;vector pos;clean_list(){ list temp = llList2ListStrided(detected,0,-1,2);//pull out a list of the keys max = llGetListLength(temp); while(max--){//loop through the list of keys k = llList2Key(temp,max); if(llGetAgentSize(k)==ZERO_VECTOR//left the sim ||llVecDist(pos,llList2Vector(llGetObjectDetails(k,[OBJECT_POS]),0))>range){//still on sim but out of range integer n = llListFindList(detected,[k]);//find the agent's key in the detected list llOwnerSay(llList2String(detected,(n+1))+" is no longer in range"); detected=llDeleteSubList(detected,n,(n+1));//remove the key and the name from the list } }}default{ state_entry() { owner = llGetOwner(); } touch_start(integer total_number) { if(llDetectedKey(0)==owner){ toggle=!toggle; if(toggle){ llOwnerSay("Turning on"); pos = llGetPos(); llSensorRepeat("","",AGENT,range,PI,frequency); } else{ llOwnerSay("Turning off"); llSensorRemove(); } } } sensor(integer total_number) { max = total_number; while(max--){ k = llDetectedKey(max); if(!~llListFindList(detected,[k])){ s = llGetUsername(k); llOwnerSay("Just detected "+s); detected +=[k]+[s]; } } clean_list(); } no_sensor(){ clean_list(); }}

Two things. First, I'd normally put llSetPayPrice somewhere other than the money event, since the money event is only going to happen (thus causing llSetPayPrice to be executed in your example) after money is paid to the object. And you presumably want the prices visible before people try to pay. Second, by declaring (integer)PayAmount1; and so on inside the money event, you're in effect wiping whatever value they had before. So the code as you have it there can't work because the script doesn't know what integer(PayAmount1) is, so it's defaulting it to 0. Without seeing your whole script it's difficult to be sure, but I think, from what you say, I'd set llPayPrice inside the dataserver event, when i've finished reading the notecard and know what those integers are.

Venus Petrov wrote: Again, I am open to reading about cases where the identiy of a SL avatar has been forced from LL for prosecution. SL is not FB. That would certainly be a practical difficulty, though one doesn't know how LL, in practice, would respond to a request from a British court to furnish information to assist in the investigation of criminal activities allegedly committed using their platform as a medium. But the fact that LL might make it difficult to prosecute someone by not cooperating with the investigation doesn't alter the fact that there's no legal barrier in the UK, as opposed to practical ones, I can see to prosecuting someone for harassment (or anything else) using SL as a medium.

I wasn't commenting on the OP's complaint; rather, I was just making the more general point that our conduct in SL is regulated by, among other things, the criminal law in force where we happen to be when we log into SL. Not so long ago, members of an English white supremacist group got an unpleasant surprise when they were prosecuted here in England for incitement to racial hatred because of a website they ran in the USA. The court told them that it wasn't interested in whether the site was or wasn't legal in Florida, where it was hosted, but it was interested in the fact they controlled the site, and uploaded material to it, from England. As to SL, I think an English court would start from the basis that people have, in general, a perfect right to pursue their hobbies in peace and then try to decide the factual question of whether someone else's attempts to disrupt the complainant's attempts to pursue his or her hobby amounted to harassment in the everyday sense of the word. I'm pretty sure, for example, that some of Woodbury's activities, before they got banned, targetted against Prok, would have been illegal were any of the culprits in England while they were having their fun.

Venus Petrov wrote: I am open to reading about any successful claims against avatars in SL by legal entities anywhere in the world for harassment within the bounds of the SL 'world'. It wouldn't be a "claim against an avatar," of course. It would be -- at least in the UK -- a prosecution brought against an individual in the jurisdiction for following a course of conduct that a court thought constituted harassment, in the everyday sense of the word, in that they'd logged into their computer and harassed another internet user via SL. A prosecution would be difficult, certainly, because the prosecuting authorities in the UK would need to find out from LL who actually operated a particular account, but I don't see that, for example, this young woman would have enjoyed any legal immunity from prosecution under English law had she issued her threats via SL rather than Facebook.

Venus Petrov wrote: Linden Lab and RL users are subject to RL laws. What about avatars in SL? Who takes care of griefing issues? What about resident-to-resident disputes over SL matters? Surely not the 'law of the land'. If, however, harassment moves into RL and can be demonstrated that it has, then, yes, it is a matter for the RL legal authorities. ETA: I have just repeated what I wrote in my prior post. Perhaps you should re-read. Depends on which land you're in, I think, Venus. I don't think it's ever been applied to SL but, in England and Wales, certainly, the Protection from Harassment Act says, (1)A person must not pursue a course of conduct— (a)which amounts to harassment of another, and (b)which he knows or ought to know amounts to harassment of the other. (2)For the purposes of this section, the person whose course of conduct is in question ought to know that it amounts to harassment of another if a reasonable person in possession of the same information would think the course of conduct amounted to harassment of the other. It's not infrequently used against people who harass other people via Facebook and the like, and I see no reason, in principle, why it wouldn't apply to harassing someone in SL -- provided that the person doing the harassing is in the English jurisdiction when he's sitting at his keyboard griefing someone.

The bunch of ###'s and RLV Restrictions sounds to me like Marine's RLV's version of "Show Restrictions" (they appear the chat history window rather than in a floater). I've been working on RLV toys for the last couple of hours and things have been working ok for me. I did have to break off, though, to go to one of our shops in a release channel sim (can't remember the channel offhand but I can check tomorrow), where several scripted objects that need to pass chat commands between each other (not just rlv ones) seemed to have gone temporarily nuts. So maybe it was a more general issue affecting objects trying to communicate with your relay. ETA -- the shop where my scripts went temporarily nuts was on the Magnum channel. It may have been a local problem or more general, but something distinctly odd was happening for an hour or so.

You might want to check out some of the independent third-party forums listed in the wiki, where we aren't under similar constraints to those that apply here. I'm a regular at SLU, and I can also recommend Second Citizen Mk II. I'm sure the others are good, too, but I'm not familiar enough with them to comment.

It might be easier if you explain what you want the script to do, because it's a bit hard to figure that out from the code as it is. You're scanning for scripted objects -- pets, maybe? -- and it looks as if, when you find one, you're trying to find out something about it. But I can't really get much further and, to my mind, it's better if you explain what it's supposed to do rather than us take guesses.

Just to expand on what the others have said, what listen(integer channel, string name, key id, string message) means -- and I remember it took me a while to appreciate this -- is that channel, name, id and message are the names of variables, grabbed by the listen event, and available to the script in that event. So you can say something like: default{ state_entry() { llListen(99,"","","");//listen on channel 99 for messages from anyone } listen(integer channel, string name, key id, string message) { llInstantMessage(id, "Hello, "+name+"! You said \""+message+"\" on channel "+(string)channel+ " and your uuid is "+(string)id); }} If you want to make variables available outside the particular event, you have to use global variables, which means declaring them before you enter state default in the script, as you have done with CHANNEL and MENU_MAIN in your example. So something like this would work, too // Basic dialog scriptinteger CHANNEL = 42; // dialog channellist MENU_MAIN = ["Notecard", "Website"]; // the main menukey toucher;default{ state_entry() { llListen(CHANNEL, "", NULL_KEY, ""); // listen for dialog answers (from multiple users) // llSetText("Dialog Test",<1,1,1>,1.0); } touch_start(integer total_number) { toucher = llDetectedKey(0); // give the variable "toucher" the value of the uuid of whoever's just touched me llDialog(toucher, "What do you want to do?", MENU_MAIN, CHANNEL); // present dialog on click } listen(integer channel, string name, key id, string message) { if (message == "Notecard") { llGiveInventory(toucher, llGetInventoryName(INVENTORY_NOTECARD, 0)); //the script knows what you mean by "toucher" in a new event } else if (message == "Website") { llLoadURL(toucher, "Oddballs Second Life Forum", "http://www.oddball.be"); } else if (message == "...Back") { llDialog(toucher, "Select option", MENU_MAIN, CHANNEL); // present main menu on request to go back } }}

I don't know what open sim does and doesn't support... you could try having the objects all listen on different channels generated from their uuids -- something like this: integer my_channel = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF; -- and have sensor prim calculate what channel to use from that? I think that's reasonably safe from collisions unless, perhaps, you've drag copied them. Or maybe tell them to respond only to messages prefixed by their uuid?

The convention with nPose is that ladies sit first -- that's the only way to do it, I think. nPose's distribution system is in a bit of a haitus at the moment. I'll drop you a copy in world. Anyone else who wants one, please drop me an IM in world (not a notcard, please),

That's very good, and very long-awaited, news, FJ. Perhaps a rather more prominent announcement than this would be in order? It really has been a major inconvenience for a lot of your non-US customers, I think, who will doubtless be glad it's now apparently resolved.

You'd have to rescript the object anyway in order to remove the scripts from an old version after a new one had been sent out and I honestly really, really don't think it's a good idea. For one thing, lots of people (me included) wouldn't buy a scripted object knowing the creator could disable it remotely. It would also be considerably more complicated than doing a simple product updater (which will involve some rescripting, but nothing nearly so complicated as trying to remove the scripts from outdated objects, and which is a far safer method). Take a look at this thread http://community.secondlife.com/t5/LSL-Scripting/Updating-a-script-in-an-object-how-note-OpenCollar-does-it/m-p/851647#M1787 and also at Dari Caldwell's complete example of how to do a script updater at http://forums-archive.secondlife.com/15/8e/172797/1.html Using Dari's method, you would just need to send out one more version of your hud (which I assume must be transfer, no copy, from your stated concerns), updated so it can accept running scripts from subsequent updater prims you send out, and then you don't need to worry any more. Owners will then be able simply to rez the hud next to any updaters you subsequently send out, which will insert the new scripts and delete the old ones. It really is the better way to do it, for all sorts of reasons.

You can't delete stuff from people's inventories by script, and nor can you call llDie() successfully in something you're wearing. In theory you could tell the scripts in the old item to remove themselves after you've sent out a new one, but that would be a spectacularly bad idea, to my mind, for all sorts of reasons, and I mention it only to dismiss it. Why not send out an updater, rather than an updated item? That's what a lot of people do, and I find it, as a customer, a lot easier in practice to rez my hud on the ground next to the updater, and then continue to use the original hud, than I do to remember to delete the old one and replace it with the new one, particularly if I've moved the original from its default location.

What happens if you take out the remove() fuction from the two collision events and let the timer remove the bullet? I know you say you've tried delaying it a few seconds, but I suspect that's where the problem might be. I've certainly had issues in the past with scripts not managing to complete their tasks before deleting the object that contains them. If you hear the message then, at least you know that's where the trouble stems from. If if works then, setting it to non-physics as soon as it strikes the target, before it does anything else. I'm just wondering if, after hitting the target, it falls to the floor and calls remove() before it gets a chance to say anything.

If you don't want to wear an AO, you might try using one the TPVs -- Phoenix or Singularity, certainly, and maybe Imprudence but I can't remember -- that have a client-side AO. In effect, this means you keep your AO anims and configuration cards in a special folder in your inventory, and the viewer plays them from there in the same way an AO hud would play them from its inventory.

https://wiki.secondlife.com/wiki/LlRegionSayTo It's a very new function, but if you know the key of the object, it's ideal, I would think.

shorty Feden wrote: I see not difference than a swimming suit contest that people enter by paying money to do so. There is no money exchanging hands during the poker session only chips that came with the table. Shorty Feden I don't think that's the point, I'm sorry to say. The FAQ on Skill Game Compliance say If a game collects L$ in order to begin play, and L$ are promised when certain conditions are met, the game is subject to the wagering policy and must not be a game of chance. See the wagering policy above for more information If you put that together with the fact that the Policy Regarding Wagering In Second Life includes Poker in the list of "casino games" it's forbidden to play for money, I'm pretty certain that -- rightly or wrongly -- LL would regard your idea as a form of gambling.

There's a useful table of aspect ratios (it depends on the viewer, as Rolig says, and also on where you want to put the texture). There's also a very helpful -- well, I found it so -- tutorial on how to tweak aspect ratios of your images in Photoshop or Gimp before uploading them.

So, leaving aside issues like the Mono rezzing bug, does this mean it's better to compile short, simple scripts in LSO or in MONO?

I know that the idea is that we should eventually be able to specify how much memory we want a Mono script to reserve for itself, but I thought -- and I could be mistaken -- that at the moment, 64KiB get allocated to all Mono scripts, regardless of what they actually happen to be using at the time and regardless of how much they might ever need. I would have thought the fact the memory has been allocated to one script would mean it's not available to allocated simultaneously to another one. Am I mistaken in this?