alexx Ohmai

LSL Tools extension for VSCode is also pretty up to date, I haven't had any issues using linksetdata ect through it. https://github.com/Minuit-Ferina/vscode-lsl though you don't really need the repo link cause you can search and install it through VSCode's extension panel also lol. (edit: i have pre-release version installed so there's also that lol.)

do not rely on llGetTime(), as this is susceptible to lag and other script runtime factors. You want to save llGetUnixTime() as a variable either using the object keystore or as a variable in the script itself. call variable = llGetUnixtime(); on attach to save the unix time when the object was attached, and then periodically check against that to determine if their wear time has ended or not. an example: integer attachedAt; float expieryAt = 10; /* 10 seconds */ /* checking expiery global function */ checkexp() { if((attachedAt + expieryAt) <= llGetUnixTime()) { llSetTimerEvent(0); llDetechFromAvatar(); } } default { run_time_permissions(integer perms) { /* trigger most your events from here. this confirms they've attached and given permissions to detach. */ if(perms & PERMISSION_ATTACH) { /* Check if we already set an attached time to not overwrite it */ if(!attachedAt) { attachedAt = llGetUnixTime(); llSetTimerEvent(0.1); } else { llSetTimerEvent(0.1); } } } on_rez(integer rez) { llSetTimerEvent(0); llRequestPermissions(wearer, PERMISSION_ATTACH); } timer() { checkexp(); } }

I typically inserted my own replace substring function whenever I needed it lol. having a built in function is nice though. less to put in the script! string omReplaceSubString(string msg, string search, string replace) { integer i = llSubStringIndex(msg, search); for(i>-1; i != -1; i=llSubStringIndex(msg, search)) { msg = llDeleteSubString(msg, i, i + (llStringLength(search)-1)); msg = llInsertString(msg, i, replace); } return msg; } Edit: Only thing I didn't handle was the number of times to replace, I never thought that far outside the box nor ever really had too lol.

Sorry, i don't frequent the forums very often but your assessment of a for loop is correct. you have an initializer, a test, and an action within a for loop. I typically like to initialize with a variable. for(i=0; i > 100; i++){} for example will loop until the variable i is greater than 100, carry out any tasks within the loop, and then increment i by one and test again to see if i is greater than 100. As for reading the data one object at a time, assuming you store them in an array or even using object data storage, you can just get the number of objects in the array and iterate over them, initialize a variable for your data to send at the function level to store it. then send before it reaches 1024 characters in length by checking its length before adding data to it. (alternatively by checking its length + the length of the data to add and seeing if that'll put it above 1024 before sending.) as for the part about "it's activated on-touch" don't rely on this as a method of checking if someone is in the same region, for a lot of cases in sl it will be true, but if your script runs in a region that has neighboring regions, people in those adjacent regions can still touch the object. which would cause a regionsayto to fail. which is why you'd want a check to determine if they're in the same region before trying to regionsayto. that part is as simple as checking llGetAgentSize within the touched event to determine if they are or aren't. default { touch_start(integer touch) { if(llGetAgentSize(llDetectedKey(0)) != ZERO_VECTOR) { llRegionSayTo(llDetectedKey(0), 0, "Welcome to the region!"); } else { llInstantMessage(llDetectedKey(0), "You're so far away!"); } } }

Scripts can't trigger the touch events of other objects In your specific case you would need two scripts, a Host, and a Client. the host would be the main menu object and the clients would be the rezzers, the clients would listen out for the host's instructions to know when to send a menu and who to send that menu to. That's just one example of how it could be done. this means the client's would also need code to handle rezzing of the scenes, and storage of positional data relative to the rezzer's position. That being said, you wouldn't be able to do this with one script since the target's existing scripts are no-mod. you'd either have to start studying up some LSL or pay someone whatever their rates are for a project like this.

Two things you want to do for the sake of efficiency. 1.) Swap to llRegionSayTo() 2.) Combine as much data into one string as possible. for point 1. you can use llRegionSayTo() to send the data to them, i'd recommend checking if they're in the same region if this is going to be somewhere that has neighboring regions, otherwise the region say will fail. this will allow you to fall back to llInstantMessage() in such cases. for point 2. strings can be a max of 1024, you can utilize for loops and do the math to combine data into a single string by comparing length left vs length of string to add. and if string to add is too long, send the data and start a new string. you can utilize for loops and "\n" for a newline where applicable. This will allow you to send more data in less strings, which is overall better for sending data to an agent as even llRegionSayTo() gets throttled if too many messages are sent on channel 0, but also data isn't always received in the order it was sent to the agent, so if you require message integrity you're better off formatting where you can. This approach also allows you to fall back to llInstantMessage() more reliably.

you've jinxed it now ?

the only problem i have with saying its a DDoS attack is the very implication it has. Often saying "we're being hit with a DDoS" is a companies way of saying "we don't know what is going on." or "we messed up somewhere and don't want to admit it." But all that aside. if it were a DDoS it would certainly need to be directed at LL even in the slightest to take down logins and in world services at the scale it is. considering its hitting users on multiple regions and even logging users out due to time outs.

*shakes the cupcake to make sure it doesn't rattle.* well ok then

Something about these cupcakes doesn't sound right >.>