Jasdac Stockholm

While we're spitballing ideas anyway: Another benefit of allowing remote linksets to fetch data is that it allows the community to set some standards for metadata. Perhaps a PIN of 0 could be used as a "my data is public, please read me" setting. Trying to read from PIN 0 on a linkset would just return an empty string and not throw an error. That way the community could agree on some standard keys for features like: Footstep sounds: Footstep scripts could parse this for UUIDs for footstep sounds. Paired with the links having a short bit of info in the description like "FS:A". Then when you cast a ray at your feet, see FS:A in the description, you can fetch the list of sounds from the LSD key "FS::A" and play those sounds while walking. Right now what we do is store all the footstep sounds in a script, and set short tags for them to be read from the description. Such as "WOOD" for wood surfaces, just to be able to fit them into the description length. This would eliminate the need for storing all the footstep sounds in a central HUD, allowing for less script memory use and an infinite variety of sounds. Climbing: In GoThongs, to climb ladders, shimmy walls, ropes etc we use an invisible prim spawned by each user's HUD called a supportcube. Currently the HUD raycasts for prims with a climbing tag in the description. The tag is followed by positions, animations, and rotations used as keyframes. When the climbing starts it seats the player on the prim, starts the animation, and moves them along the path using llSetKeyframedMotion, resulting in a much less stuttering way of climbing than if you were to use llSetRegionPos or updating sit targets. The problem is that the description is very limited, so the description could instead point to an LSD key which had this metadata. Another perk of doing it this way is that you don't need a single script in ANY of the ladders/ledges in the entire level/sim! Poseballing: In GoThongs/Fright we also used the supportcube system above to setup sit positions. This allows couches, beds, sofas etc to parse the description of the object for animations and positions. The HUD then sits the player on the supportcube, aligns, and poses the player based on the description. The problem with this is again that descriptions are very limited in size, and I don't think I've been able to make a seat that can handle more than 4 users at a time. The upside of doing it with metadata is that none of the seats need a single script, the user only needs their HUD script and a script in the supportcube. When it comes to larger areas, that's like 40-50 identical poseball scripts that can be deleted. TL;DR: by using metadata and a HUD for interactions, you can remove a ton of scripts from your world objects when making experiences, games and such.

These games aren't installed, they're playable anywhere, so experiences won't do anything. Experience keys are also async, which LSD is not. And if you have your own server then HTTP requests becomes a significantly more powerful alternative to experience keys.

I feel like this would be significantly more useful if we had a way to remotely access said data. One of the biggest issues when making games in SL is trying to sync data. Like trying to sync player HUD UUIDs in an active game between a multitude of HUDs. With an object description, you're limited to 3 UUIDs. Using the chat system to do that is laggy, async, and prone to events being dropped. The #1 issue when developing large games on SL for me has been to keep things synced. What I'd like to see is something similar to remote loading: llSetLinksetRemoteDataPin(int pin) llRemoteLinksetDataRead(key uuid, int pin, string name); And if the wrong pin is entered, do the same thing as llRemoteLoadScriptPin and sleep the script + delay. That way you can pass the pin using messaging or if you want it to be public, just use a constant number. I don't see the value in being able to write from another script, only read. While previously using prim media URLs to sync data, the best design has always been to assign write permissions for specific values to specific scripts, then using link messages or say messages to have that script update the value. Otherwise you have to battle race conditions.

If it helps, the rolling sim restart today just turned a sim from fast to slow. It also rolled back the region by some 10-15 minutes. After a manual restart, the sim returned to being fast.

I've noticed a different behavior on this recently. After a sim restart items rezzed through a script (llRezAtRoot etc) start instantly. But when rezzed from your avatar inventory, it takes multiple seconds to begin.

I just witnessed it happening. I rezzed a cube with an ownersay on rez before rezzing a large build and it output it instantly. After rezzing the large build it also worked instantly. But a few moments later I rezzed it again and it now took 2-3 sec before outputting the ownersay. I also added a timer to it, and the timer doesn't trigger either until a few sec after rezzing it. Removing the large build had no effect, the test script still took multiple seconds to output anything. It wasn't a gradual slowdown. It was instant the first time, then took multiple seconds. Script: default { on_rez( integer total ){ llOwnerSay("IT BEGINS"); } state_entry(){ llSetTimerEvent(.5); } timer(){ llOwnerSay("Tick"); } }

Alright so a possible workaround for those working with the RLV @setenv_preset command: You can use @setenv_asset:uuid=force instead. But this means you'll need the UUID. I took the presets @KT Kingsley referred to and copied their UUIDs onto my server. Then setup an API so you can convert preset names to UUIDs. The API is a simple GET request to: https://jasx.org/api/windlight/?SKY=<sky1>,<sky2>... Example: https://jasx.org/api/windlight/?SKY=[TOR] Night - Nocturne,[TOR] Night - Anwar Response: { "SKY":{ "[tor] night - anwar":"0c65d69d-f19b-3317-b24d-592d128a6b4e", "[tor] night - nocturne":"81903a0f-c102-bd2c-aad0-e16e92ad841b" } } The preset names in the response are always lower case, since the RLV command is case insensitive, and this will make it easier to compare. Hopefully this will help someone automate the process of converting their presets to UUIDs.

I know it's an old thread, but since the issue still persists and I've found some more info: The bug doesn't only affect on_rez/attach. It seems to prevent the WHOLE SCRIPT from running any code for a few seconds upon rez. I had the same issue with collision events not raising at all while the sim is rez-bugged. I'm gonna try some other events like timers etc to see if those are affected too, which I suspect would be the case. A forced sim restart still fixes it. I think the automatic Tuesday sim restarts might also be related, as I usually have issues after those. I'll try to verify this on Tuesday. And no, the AWS migration didn't resolve anything.

My biggest gripe is that they decided to not include all the Firestorm windlight presets, which means that my games now render broken sky settings due to missing presets. And locking EEP to experiences means it's completely useless in sandbox & open source games. I guess I'll have to spend my Christmas break writing an RLV/notecard based alternative to this stuff. What a headache.

Haven't tried, I'll do it once the region bogs down again

Since I can't post on the JIRA, here's some info I've gathered myself and from my userbase: The issue seems to be that on_rez takes forever to trigger. Items spawn in a timely fashion. The issue affects all sims, but only starts appearing after the sim has been running for a while. I'm not sure if there's a certain event that triggers it, or if it's some sort of buildup. This means if you restart the sim, it'll run fine for a while. This is a simple script that rezzes an object that triggers some particles when it rezzes, and then dies. The object has a light emitter on it, so you can see it spawns in a timely fashion, the particles however do not. https://i.gyazo.com/75c6970aed8dc069831111a851747549.mp4 After a sim restart, this is the same script: https://i.gyazo.com/f4b84a9f396c6e2e3e61909ec281a11f.mp4 It's been present for a few weeks now. Hopefully that helps someone.

A possibly easier way of sending and receiving data is using the LSL JSON functions http://wiki.secondlife.com/wiki/Json_usage_in_LSL Then you could send data something like: string tex_1 = "a8aae143-39dd-49d6-909c-7640619e2b3b"; string tex_2 = "6debb190-2d88-454b-bb8d-7ea6e046eb79"; string output = llList2Json(JSON_OBJECT, [ "tex_1", tex_1, // key value pair "tex_2", tex_2 // key value pair ]); // Output now looks like this: "{\"tex_1\":\"a8aae143-39dd-49d6-909c-7640619e2b3b\",\"tex_2\":\"6debb190-2d88-454b-bb8d-7ea6e046eb79\"}" Then on the reading end: key input_tex_1 = llJsonGetValue(message, ["tex_1"]); // Get the tex_1 value from the JSON object string key input_tex_2 = llJsonGetValue(message, ["tex_2"]); // Get the tex_2 value from the JSON object string // Make sure the keys are valid keys before setting if( input_tex_1 ) llSetLinkTexture(1, tex_1, ALL_SIDES); if( input_tex_2 ) llSetLinkTexture(2, tex_2, ALL_SIDES); A benefit of learning how to use JSON is that it's used in a vast amount of languages.

I believe there have been things like this in the past, but they all tend to go belly up within a few years and then everyone's data is lost. Experience keys has a simple database functionality. But it's limited to certain sims I believe

Is the root prim one of the moving panels? I'm not sure how helpful it is, but you can affect multiple prims in a single call using PRIM_LINK_TARGET, for an example: llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN, [ PRIM_POSITION, <0,0,0>, // Set the child prims to the root prim's position PRIM_LINK_TARGET, LINK_ROOT, // From here on, affect the root prim PRIM_POSITION, llGetPos()+<1,0,0> // Set the whole linkset to +1m on X from its current position ])

I was actually considering mentioning that in my post, best holiday!