Quistess Alpha

So, to turn down complexity, I'd make V and R mostly identical, just have one 'shared radio system' which can be listened to or not. When 'listening' is turned on (either a R goes on duty, or a V needs help) the HUD requests a URL (via llRequestURL) and forwards it to the server. The server adds the URL to a list, forwards the URL to all other URLs on its list, and responds with an updated list of all URLs it has stored. the HUD updates its internal list of all other URLs. similarly for changed region, turning listening off etc. the server and all HUDs in the system attempt to keep a shared list of every listening URL. when a HUD wants to send a message, it just HTTPRequests every URL stored in its list. The main limitations are A) the total memory of the server, and B) total memory of the HUD scripts and C) the maximum message lengths. As long as care is taken to set HTTP_BODY_MAXLENGTH in requesting scripts, there shouldn't be much practical limit on message sizes. assuming each URL is about 200 bytes, you start to run into problems at about 125~150 simultaneous users, as the scripts need to store both the old list and an updated one at the same time. if you 'cheat' and make assumptions about the format of URLs, you can drastically increase that at the expense of the system possibly breaking in the future. Different 'channels' could could fairly easily be set up for different shared lists, the laziest way would be to just have a different server for each 'channel'. If a request to a server's previous URL returns 404, use llEmail to ask the server for its new URL, which it should re-request in its changed event on CHANGED_REGION_START. as long as the server object is never moved to a new region (actually maybe even if it is?) its UUID and by extension its email address remain constant, even through region restarts.

Yes, and I might also mention LSL supports scope-based variable overloading, As an example of both: default { state_entry() { integer x; { string x = (string)x; // x is type integer to the right of '=' string y = x+ "s"; // x is of type string at this point } ++x; // x is an integer, the string overload went out of scope. { string x = "x"; // variable name overload need not use the previous value before it is masked. } } } /* there is no closing comment indicator should compile.

except for possible weird edge cases, like '/*' being allowed without a corresponding '*/' after the "end" of a script, I think you've thought of most of them. do+while and else+if are interesting parsing wise, but similar to many other languages.

My grandparents got a whole jar-opening machine that is probably bigger than most of the jars its supposed to open. It works. . . if you're patient enough to wait a full 5 minutes for your salsa and make sure it still has batteries. Warm water and rubber grippers (or honestly just a sleeve sometimes works) are the way to go.

I think it depends on context, I'd easily believe they can clone a voice enough to fool the other ai that checks voices for 'bank verification' or w/e, but I don't think it's to the point it can fool someone listening to it for a full 5-minute 'my wallet was stolen by a Nigerian prince' scam.

You could try and 'guess' whether a ship has a high sail, based on the name of the vehicle (a 'sailboat' is more likely to have a high mast than a 'canoe') but it would be difficult to account for every possibility.

I'm fairly sure some 'nice' doors use llTargetOmega in a clever way, but I've never found the motivation to try it for myself. (I presume there might be some fine tuning to get it to look perfect.)

premium still pays for upload, I think it's there to contrast vs premium plus which doesn't pay for uploads.

If this were applied 1:1 to LSL as a 'script permission', and putting aside the issue of breaking almost all existing content, I don't think adding a 'hey can I have permission to show you a message?' prompt before certain kinds of messages would help anyone.

I scripted a folding knife that did a few tricks for KuddelMuddel a while back, but don't see it in their MP store. You could try looking at their in-world store or asking the proprietor directly.

you need to set that ID to the ID of the person wearing the object, which happens to always be the owner of the object: key ID = llGetOwner();

How many people do you think will read this, with less than 10 minutes till the auction closes?

Ooh a simple math problem! A full region costs ~200USD per month and can host 100 simultaneous agents, so, if an estate owner has a 'just for bot parking' region they have to charge each bot a bit more than 2USD/month to break even (taking into account, non-optimal occupancy, the actual price to a user would be a fair amount higher). Interestingly, homesteads and open-space regions would cost more for bot parking, It's not much, but that's a lot more expensive than it currently is to park a bot (basically free).

The story I've heard is keys store the 128 bits they represent when actually representing a key, in addition to their string representation. Thanks for the testing and writeup!

Scammers don't want to 'delete your account', they want to steal your L$ (and your RL $$$ too), which, depending on how smart they are, is a lot harder to undo than just pressing a reset button. I hear LL knows what they're doing in remedying those cases, but even so. . .

If you care what the avatar is sitting on, you can use llGetObjectDetails, OBJECT_ROOT , but you still have to check on a timer (or maybe a control event but that would be kinda wonky, I'm almost tempted to try that with llSetMinEventDelay to see if it would reasonably work though.) ETA: if you don't need to detect ground sits, this mostly works: integer gSitting; default { state_entry() { llMinEventDelay(2.0); } attach(key ID) { if(ID) llRequestPermissions(ID,PERMISSION_TAKE_CONTROLS); } run_time_permissions(integer perms) { if(perms&PERMISSION_TAKE_CONTROLS) llTakeControls(0x06000300,TRUE,TRUE); // 0x06000000 is the sum of the undocumented left+right 'rotation detected' controls. // 0x300 is normal left+right rotation. } control(key ID, integer level, integer edge) { integer sitting = llGetAgentInfo(ID)&(AGENT_SITTING|AGENT_ON_OBJECT); if(sitting!=gSitting) { gSitting=sitting; if(gSitting) { llOwnerSay("Is sitting"); }else { llOwnerSay("Has stood up"); } llOwnerSay((string)sitting); } } } but if you're not that hyper-concerned about efficiency and need ground-sit detection, then just replace the control event with a timer, and set the timer in state_entry instead of the minEventDelay, and remove the attach and run_time_perms events.

If you're uploading the images yourself, try 512x512 or 256x256 resolution, If it didn't have to be projected, I'd suggest Media-on-a-prim or parcel media. (IIRC parcel media movies work on particles but not as projector lights.)

Supposedly, once in a blue moon, email scripts just stop receiving all new emails until a region is restarted.

llCreateLink has a 1 second built-in delay. llEmail has a notorious 20 second delay and has been reported to break until a region restart every now and again. I'm not saying it can't be done, it's just not a scaleable solution.

experience KVP doesn't have findkeys. and managing LSD is A) new, B) wildly innefficient and cumbersome to manage across multiple linksets.

not very much memory, no. you could easily fit it within the constraints of say experience KVP, perhaps even a few different stores sharing the same experience. Problem is the architecture, sure you cna store the data, but the tools we have for in-world only don't make getting it back out again convenient. KVP lets you index by exactly one key, and the size of data per key is finite (you can easily work around that by adding related keys, but it's a pain.) so, you could index by say the buyer, but then it would be very hard to re-sort everything by purchase date. External-to-SL databases are built to solve that kind of problem already, it's easier not to reinvent the wheel.

Some places do not allow entry based on Payment info on file, or avatar age, and some people haven't set up the ability to visit moderate or adult regions. Some regions are just offline for maintenance sometimes, and if a region is full, sometimes premium members can get in when basic residents can't. Without a more systematic examination beyond an anecdotal 'the landmark didn't work when I tried to use it' it's impossible to say whether the landmark is wrong or the person didn't meet some condition for entry.

Are you sure the issue is with the embedding in a notecard and not the landmarks themselves? If you give the friends the landmarks say, in a folder are the same ones still broken?

FWIW, I usually see this sort of post in the commerce-> wanted section.

I have a pair my alt wears constantly, lemme find a link. . . https://marketplace.secondlife.com/p/EQUAL-Gracie-Kitten-Heels-BLACK/20184249