Wulfie Reanimator

Log into the Jira (https://jira.secondlife.com, there's a blue Create button at the very top of the page) with your SL account and file a ticket, posting a suggestion here won't do anything really as it'll just get lost in the sea of posts.

The current TOS doesn't mention anything about letting others access your account, so that's not necessarily true. In the past it has been both against TOS, and permitted with the caveat that "You are solely responsible for all activities conducted through your Account whether or not you authorize the activity." Edit: Apparently I can't Ctrl-F these days.

I'm not arguing that land can't be cheaper, I was clarifying for others in this thread that AWS isn't as cheap as you made it seem.

AWS has different pricing for different kinds of servers, with bulk discounts, and you also pay for the processing time. (If you don't do anything with it, then you might only pay a couple bucks.) It can easily cost hundreds of dollars a month to rent "a virtual server" from AWS. (Not that it costs LL that much to run a single sim, since multiple sims will run per server, but it's also not the only cost they have.) The pricing for AWS/Google can sometimes make working with them kinda weird. For example, at my workplace we actually lose money if something is "a quick fix" because we pay more for the server to build our software than we can bill the customer for developer time spent.

Do you happen to know what the current "framerate" is for reflection probes? Last I checked, I think it was once per minute (which is fine, just checking).

Physically-Based Rendering Texture editing tools aren't in the scope of this project.

Loop is the most general way to do it. You could write a custom function that applies a given character X times, and that's about as convenient as you can get. Depending on your specific use-case, you could also go the other way around and do llGetSubString("***************", 0, n); assuming you know the maximum length you'll need. This way would be more speedy and memory-efficient (since you're not creating a bunch of immediately-discarded strings).

SL currently uses Specular & Glossiness. The new PBR implementation will be using Metallic & Roughness. The 'levels of shine' will be the same, but will look significantly different due to reflection probes.

Drag from where?

It would stop others from logging in despite having your password, though, if LL actually enforced it for viewer login. But until then it's kinda just there. 🙂

There's been some discussion in a different thread, here: https://community.secondlife.com/forums/topic/493161-server-status-499/

My math was wrong because I misread my own previous post: (Was looking at full + homestead, instead of just full region.)

It costs only half of what you'd pay for a full region too, all expenses included.

None of this is personal information.

These bots are nothing new, they've existed almost as long as SL. If they were breaking TOS or doing something nefarious, we'd know. Most likely they're just survey bots, not spies. If you're bothered by them, enable avatar hiding in your parcel. If they happen to teleport into your parcel, enable banlines for a few days.

I don't think so, the only way for scripts to communicate out of SL is via HTTP. All scripts are running on LL's servers after all, so it's not like they could just talk to a process ID on your computer.

Testing these has made my brain hurt. A lot. 😩 Things I've experienced: Garbage collection just doesn't happen.. for minutes.. with an empty list and no event queue. The script crashes between lowering the memory limit and resetting it. The script crashes at random points after llDeleteSubList, depending on which calls would come after it. (The script will crash at the same line every time, if no code is changed.) if there's 4 llOwnerSay (raw string input) calls and llGetListLength, it crashes on llGetListLength. if there's 3 llOwnerSay (raw string input) calls and llSetColor, it crashes after the first llOwnerSay. if there's just llOwnerSay(llGetFreeMemory()), it crashes before output. A ""working"" script will stop working if I only remove debug logging from outside of the branch where pruning is done. The script correctly prunes data and memory is instantly freed when starting from a pre-filled list (llGenerateKey) for quicker testing. Honestly, just wait for Linkset Data to be released in the next week or two and run away from all this.

Just to give some context to this, it's done as a basic security feature. When a login is prevented because it was attempted at a very different location (different state, country, continent...), an email is usually sent that the account owner can open and click "yes, this is fine." After that it should be possible to log in on the second attempt.

that's just a small extract from a larger essay on LSD which was an interesting read. So, to better answer #3: I would say that it's not a bad idea at all, and on the surface, it seems to be a very good idea to start transitioning away from link_messages to using LSD for inter script communication. However, as I think about it, if we simply just replace the current message_linked event with the new linkset_data event then any savings mentioned above would be a wash overall. At least in some cases where immediate consideration of data changes is concerned (like vehicles). But, other situations where data is more situationally used in conjunction with other events, instead of having to have each script test and see if that data is relevant to it every time there is an update, if the subscripts just need to check for a stored value when it's actually needed, then I can see that having an overall benefit in the end. I'm unsure if LSD would be the solution to reducing script events, but it could be. On one hand, if there are 10 scripts tracking changes in LSD, changing any key would cause 10 events (since they all get notified of that same key changing). While with link messages, you could spread each script to a different prim and send a targeted message to just that script (1 event vs 10). On the other hand, you could just omit the linkset_data event entirely and each script will just call llLinksetDataRead on the key they're interested in. That way there's zero events while every script is using the latest LSD value the moment they need it... assuming that no issues or side-effects crop up with performance when used on a larger scale. It's gonna be interesting to see how things pan out if/when people start using this feature.

I've just updated the wiki pages for these functions since their descriptions were fairly misleading, and the examples didn't really cover enough: https://wiki.secondlife.com/wiki/LlTeleportAgent https://wiki.secondlife.com/wiki/LlTeleportAgentGlobalCoords Writing those examples was a fairly upsetting process, since the LookAt "direction" behaves completely differently based on the destination, and there's no neat way to find out whether a teleport would exit the current region. For llTeleportAgentGlobalCoords: You have to keep track of your current region's global coordinate, so you can compare it with the global coordinates of your destination. vector current_region; default { state_entry() { llRequestSimulatorData(llGetRegionName(), DATA_SIM_POS); } changed(integer change) { if (!(change & CHANGED_REGION)) return; llRequestSimulatorData(llGetRegionName(), DATA_SIM_POS); } dataserver(key query, string data) { current_region = (vector)data; } touch_start(integer num_detected) { llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); } run_time_permissions(integer perm) { if (!(PERMISSION_TELEPORT & perm)) return; vector global_coord = <232704, 291072, 0>; vector region_pos = <122, 122, 40>; float angle = 45 * DEG_TO_RAD; vector look_at = <llCos(angle), llSin(angle), 0>; if (current_region == global_coord) { look_at = region_pos + look_at; } llTeleportAgentGlobalCoords(llGetOwner(), global_coord, region_pos, look_at); } } For llTeleportAgent: You have to keep track of the landmark's global coordinate, and then calculate the total distance to the destination. This one is especially tricky to implement because the landmark's coordinate can either be a region-local coordinate like <100, 130, 40>, or a global coordinate + region-local offset like <-131704.6, -24381.2, 22.48>, depending on whether you're in the same sim or not. string landmark; vector destination; default { state_entry() { if (llGetInventoryNumber(INVENTORY_LANDMARK) > 0) { landmark = llGetInventoryName(INVENTORY_LANDMARK, 0); llRequestInventoryData(landmark); } } changed(integer change) { if (!(change & (CHANGED_INVENTORY|CHANGED_REGION))) return; if (llGetInventoryNumber(INVENTORY_LANDMARK) > 0) { landmark = llGetInventoryName(INVENTORY_LANDMARK, 0); llRequestInventoryData(landmark); } } dataserver(key query, string data) { destination = (vector)data; } touch_start(integer num_detected) { llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); } run_time_permissions(integer perm) { if (!(PERMISSION_TELEPORT & perm)) return; float angle = 45 * DEG_TO_RAD; vector look_at = <llCos(angle), llSin(angle), 0>; float sim_size = llVecMag(<1,1,1>); float distance = llVecDist(<1,1,1>, destination / 256); if (distance < sim_size) { look_at = destination + look_at; } llTeleportAgent(llGetOwner(), landmark, ZERO_VECTOR, look_at); } } These examples cover a semi-common corner-case where the destination is something you will teleport to from multiple regions (including the destination itself). Without this kind of handling, you might arrive at the destination with the wrong orientation.

They're off by default. 🙂 (I checked with a brand new forum account.)

...how... The second command, using look_at <-1.0,0.0,0.0>, points me toward the South-West corner (not West as we should expect). All of these point me toward that corner: < 1.0, 0.0, 0.0> <-1.0, 0.0, 0.0> < 0.0, 1.0, 0.0> < 0.0,-1.0, 0.0> Edit: Oh, now I get the behavior. If the teleport would cause the avatar to enter a different sim, that's when look_at behaves as a direction. If the teleport happens within the sim (for llTeleportAgent or llTeleportAgentGlobalCoords), look_at acts as a position. Neither wiki page specified this, now they do.

That's the one, you can see the same rocks in the same orientations. 🙂 (Particularly the three round rocks in a line near the center-left on the left image, and bottom-left on the right image.)

I thought that could've been the difference, but after trying llTeleportAgentGlobalCoords, both functions definitely use look_at as a position instead of a direction. (The avatar will always face a given point regardless of where in the sim they land.) Both functions were tested on Firestorm and the LL viewer without any difference in behavior. Do you have a script I can review? This is what I used, it just teleports you 3 meters up while setting the look_at target to a position from local chat: default { state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); } run_time_permissions(integer perm) { if(PERMISSION_TELEPORT & perm) { llListen(0, "", llGetOwner(), ""); llOwnerSay("Send look-at position in local chat to teleport."); } } listen(integer channel, string name, key id, string message) { vector look_at = (vector)message; integer valid = (look_at != ZERO_VECTOR) || ((string)look_at == message); if (!valid) return; llTeleportAgent(llGetOwner(), "", llGetPos() + <0,0,3>, look_at); // llTeleportAgent(llGetOwner(), "landmark", ZERO_VECTOR, look_at); // Same behavior: // vector sim = <232704, 291072, 0>; // llTeleportAgentGlobalCoords(llGetOwner(), sim, llGetPos() + <0,0,3>, look_at); } } I've updated the wiki for llTeleportAgent and llTeleportAgentGlobalCoords.

I think you're mixing up correlation and causation. The documentation says that llDialog will shout an error "if any button's length is longer than 24 bytes." It's not a problem if the button name is too long to be displayed visually.. it just can't reach 25 bytes. The first page might work perfectly fine if a person with a long name isn't on that page (even if they are on sim). When you move to the next page and a new list of buttons is generated (with the long name), the error is shouted.