animats

Huge problem with many of the existing AI picture generators. Keep trying. I think the training sets need lots of pictures of dance, sports, and wrestling, so the model learns more of what human bodies look like in odd positions. I've been playing with Stable Diffusion, trying to get action shots. Now what would it take to make an SL avatar look like that?

That's something different - stateless scripts. Ones where a script reset when the script is idle is harmless. There aren't that many stateless scripts. Most scripts that seldom run have state. They know your shoe size, in the unlikely event you suddenly need to resize your shoes. There are hundreds of thousands, maybe millions, of chairs in SL waiting to be sat upon, and their sit scripts have state. It won't help for the biggest causes of idle scripts that take up space. I was asking only for protection against an incoming event blowing the stack before the script had a chance to check the length of the incoming item and reject it. That's a specific problem for systems of scripts with lots of internal link messages. A link message goes to all the scripts in a prim, whether that script needs it or not. That adds overhead. There's no filter for link messages and if the str value is too big, the script crashes. A simpler fix would be for LSL to have an optional filter for link messages. You'd give a list of the id values you want to see, and link messages with other IDs are ignored. This is useful for complicated systems of interacting scripts, where script to script messages need better routing control. It's not a general problem, though. 64 bit simulators are coming, apparently. The SL simulators are all still 32-bit programs running on Linux. This is kind of dated. That will permit more memory per simulator.

Another note. When I have draw distance set to 64m in Sharpview, only neighbor regions within 64m come up, no matter how long I wait, which is correct. If I then walk the avatar to a region edge, the neighbor region appears one minute later. As before, there's a one minute delay between receiving RegionHandshake and EstablishAgentCommunication. This is repeatable. I think I've seen that happen, on very rare occasions, when driving around mainland in Firestorm. You get to a region edge, the region hasn't appeared, but after a while, it does. I'm beginning to think this is a known sim side problem that, due to Sharpview's different timing, I see happening consistently. Anyway, I can make this happen any time someone wants to test.

Here's a Sharpview log. Lines that begin "From" and "To" show message traffic. The numbers in parentheses are the coordinates of the region. This is good old downtown Morris/Ahern/Dore/Bonifacio on the beta grid. To see the one minute delay easily, search the file for "state change". There's Morris, the login region, going live at 04:25:38. Ahern goes live at 04:25:44 when the EstablishAgentCommunication message is received. Exactly one minute later, at 04:26:44, Bonifacio and Dore get their EstablishAgentCommunication messages and go live. One minute delay, accurate to within a fraction of a second. Happens every time. If you look at Henri's log, he gets something very similar, but there's a 10 second delay instead of a one minute delay. Is there supposed to be a 10 second delay? If not, fixing that would make regions come up faster at login. I'm probably not sending something I need to be sending, as Henri says, but I can't figure out what it is.

Now sending throttle info once, to each region, immediately following RegionHandshakeReply. Using the largest values seen in the SL viewer. No effect on 60 second delay.

Yes. Put that in last week. No effect. My logs are very close to your logs in terms of what messages are sent. What's in the messages may be an issue somewhere. I just noticed that I'm not sending AgentThrottle. It would make sense that the default throttle settings might be low. I'll implement that next. This might be some throttling mechanism left over from the assets over UDP era.

Fixed Sharpview to use the simulator object cache API properly. Instead of asking for everything as if from an empty cache, it asks for ObjectUpdateCached messages. Those come in (98 objects each) and RequestMultipleObject messages are sent by the viewer to get those objects, currently in blocks of no more than 100. This has no effect on the 60-second delay for EstablishAgentCommunication. So that wasn't the problem.

Very helpful. Looking at Henri's log, it's very similar to what I get. Found something significant, though: 10:09:45.972Z - The first neighbor region, Ahern, gets its EstablishAgentCommunication. 10:09:55.977Z - The second neighbor region, Dore, gets its EstablishAgentCommunication. 10:09:56.340Z - The third neighbor region, Bonifacio, gets its EstablishAgentCommunication. Note the timing. First neighbor comes up quickly. Then there's a 10 second delay. Then the rest of the regions come up. This is very similar to what I get, but the delay for Sharpview is 60 seconds instead of 10. It looks like there's a deliberate delay server side, which can be 10 or 60 seconds. That's a precise 10 second delay, within 10 milliseconds of being exactly ten seconds. So what does that? What am I doing differently? Sharpview doesn't have an object cache yet, just mesh and texture caches. Sharpview always sets "send all objects" on RegionHandshakeReply, which is like starting from an empty cache. Might this be some throttling system so that, when you start from an empty object cache, the viewer isn't flooded with new objects? Sharpview isn't sending ViewerEffect, because avatars are just blocks for now. That's probably irrelevant. Somewhere server side, there seems to be a timer which can be either 10 or 60 seconds. Comments?

Is CasperVend still doing OK? (It's too bad HippoVend shut down. Competition keeps the operators from getting complacent.)

Visit Esperia, the cyberpunk roleplay region. There's a small mall off the entrance. If you want to visit the roleplay area, get a visitor tag at the entrance to avoid being shot at. Then see what people are wearing.

Minor note on things I've tried: The very first AgentUpdate always has a bogus camera_center value, because the viewer has to send an AgentUpdate before the simulator will send back ObjectUpdate messages that tell the viewer where the avatar is. So I've tried various initial guesses. <0,0,0>, <128,128,128>, and starting at <128,128,128> then slowly interpolating to the correct position. No effect on EstablishAgentCommunication. Tried changing the "far" value in the initial AgentUpdate. 0, 1.0, and 400.0 all produce the same results. I get the impression that while the viewer does have to send that guessed AgentUpdate to get things started, the positions in it don't do much at the simulator end, which is reasonable enough. Both sides know those values are bogus. Discovered that the simulator sends RegionHandshake twice. Confirmed with Henri Beauchamp that he sees that happening in his viewer. Now sending RegionHandshakeReply for both of them, which Henri says is necessary to prevent missing objects. Doesn't affect EstablishAgentCommunication. Tried sending RegionHandshakeReply once a second while waiting for EstablishAgentCommunication, in hopes of waking things up at the simulator end. No effect on anything. Tried sending AgentUpdate messages at faster and slower rates when not moving. No effect. Tried sending AgentUpdate messages as both reliable and unreliable. No effect. After all this, EstablishAgentCommunication comes in quickly for the first neighbor region, then at one minute for all the others, as before. None of the above has any effect on that behavior. Starting point is near the corner, far - 64.0 meters. The neighbor regions are sending ObjectUpdate messages as they should. It's just those EstablishAgentCommunication messages that contain the seed capabilities for the neighbor regions, passed back via the event poller of the login region, that don't show up on time. All this is on the beta grid, at Morris. It's so frustrating. Almost all the right stuff is happening. But I don't know the right incantation to make the last bit happen. Beautiful downtown Morris, beta grid. This is a region corner of Morris/Dore/Ahern/Bonifacio. When I look at this with Sharpview, the login region, Morris, where the agent is now, comes up immediately. The region on the right comes up in a few seconds. The region on the left and the region ahead come up almost exactly one minute after start. It's that one minute delay that has me stumped. (Some of the plants seem to be missing. They're present, just tiny. Each built-in Linden tree type has its own scale factor. They don't work like ordinary objects. I need to add more special cases for those legacy plants.)

If you have some leggings that are mod, set Transparency to about 50% and set Alpha Blending.

If the teleporter owner owns the vehicles, they could set up an experience where you seem to ride through a teleport, but you're really being re-seated in an identical vehicle at the receiving end. I'd like to see that for all those Japanese subway stations. Most of the Japan-themed sims seem to have a subway or train station that goes nowhere. They should connect.

There are many SL test regions. Most are near Bug Island. Bug Island, Bug Island 2, and Island for Unit Tests are open to everyone. Lag Me 1 through Lag Me 5 are accessible to Lindens only. Most of those are replicated on the beta grid. Some Linden test regions I've found useful: Bug Island - many hard cases for viewers. Rumpus Room - new Materials objects. Arowana - sandbox island intended for small boat testing. Has zero scripts and allows 20 minute rezzing, so it's useful for measuring the load of scripted objects. Unless you're doing some kind of development, most are not very interesting. Right now, a visit to Rumpus Room with the materials viewer is useful. So much shiny! One visit will cure anyone with reasonable aesthetic sensibilities of the desire to make large objects shiny. Chrome is an accent, people. Even at Peak Chrome, the 1956 Cadillac DeVille, maybe 15% of the vehicle surface was chrome. (OK, Cadillac reached 50% in front view.) Non-test regions of interest: Natoma - Ivory Tower of Prims. Examples of all the useful prim options. Lexicolo - Janet's Viking sim, Folkvang. More good moving objects than almost anywhere else. New Babbage - many high detail buildings. The most heavily loaded region I've ever seen no longer exists. It was a post apocalyptic region built around a diner. Someone had collected most of the good post-apoc SL objects and placed them in a sandy ruin.

Be glad you don't have to. This is a non-fun thing that needs to be fixed, not a fun new feature. There's stuff I'd rather be doing. I've done this before in my career, so I know how. Second Life is a large number of computers struggling to stay in sync to present the illusion of a big, seamless world. Most of the major bugs were fixed long ago. There are some ongoing intermittent problems. Most intermittent SL problems boil down to one of two cases. A is waiting for B, B is waiting for A, and they're stuck. That's most of the problems at login, teleports, and regions crossings. The other case is A and B are out of sync, they don't know the other end is out of sync, and they have no way to compare notes to detect it. That's interest list problems and some clothing problems. These long discussions are about such problems.

The protocol isn't that bad. It's a nicely robust approach. Simulators manage their connections to their neighbors and pass viewers from region to region without help from some central coordinator. So there's no single point of failure. Simulator failures take out only their own region. Servers can be added or deleted without affecting grid stability. The central services (login, baking, etc.) aren't on the time-critical paths. The entire SL grid hasn't failed in years. It's more reliable than most web services. Most failure modes at the message level seem to be "stuck" situations where A is waiting for B and B is waiting for A. Teleport, region crossing, login, and neighbor connection troubles all look like that. The other major class of trouble is where A is out of sync with B but has no way of either detecting or fixing that. Interest list problems are like that. Both of those classes of problems are time-consuming to chase down. Much looking at logs is required. Tools for looking at logs can help. Documentation and ordinary bugs are the big problems. This EstablishAgentCommunication thing looks to me like some ordinary kind of bug, complicated by lack of documentation on exactly how to do a neighbor connection properly. The Other Simulator uses the same protocol and doesn't have this problem when Sharpview talks to it. Enough computer science philosophizing for one day. Onward!

Since Monty Linden wrote that EstablishAgentCommunication is pumped by AgentUpdate from the viewer, I've been trying various things with Sharpview's sending of AgentUpdate messages. Turns out I was sending AgentUpdate as a reliable message. Switched to sending it as an unreliable message, and that helped. When idle, Sharpview sends it ever second. Twice, as hinted at by this code in the SL viewer. This works a bit better. Not reliably. But sometimes a little motion of the viewpoint, motion that doesn't cross the view distance boundary, will cause adjacent regions to send their EstablishAgentCommunication messages. In all this, AgentUpdate is doing its main job of moving the avatar around just fine. I can even log into the same area with another viewer and watch the avatar move. Whether sending reliably or unreliably, that works. It's only the mechanism that causes an AgentUpdate to be relayed to neighbor regions that seems to be not responding. Something in this area is very touchy and I'm not touching it properly, or at least not in exactly the same ways with the same timing that the C++ viewers do. There seems to be sensitivity to movement or timing that shouldn't matter.

The technical limitation is that rigged mesh can't drape. It's just offset from the bones by a fixed distance. There's no cloth physics, which uses too much compute time to do in real time. That's why long dresses and skirts don't work well; legs go through them. Form-fitting clothing works better. Even in games that use cloth physics, you might see a cape or a scarf with proper physics and collision draping. but full clothing physics is rarely used. If it is, it's probably only for the hero character.

Day cycle is a parcel property. It's set for land, and applies to everyone who visits there. The usual setup is a 4-hour day, with one dark hour out of the four. Some places have other settings. "NTBI" is on a 24 hour schedule set to New Jersey time. They take their day cycle seriously - some stores close at night. You can override the land's environment in a viewer, and make it be day or night all the time just for you. This messes up the look of some places. Especially ones where lights come on at night, or there are fog effects. Visit "New Babbage", which is foggy and lit like 19th century London, for a good example. You can mess with sun and moon position in "Personal Environment" to set your local day/night situation, but you can't currently tie that to a clock. It's confusing when, for some people it's night, and for others, it's day.

Should the Linden Memorial Park be used more? If you've had Premium or Premium Plus for a while, should you have a grave in SL, so your friends can remember you?

Tests as requested: This is the Dore (NW) Ahern (NE) Bonifacio (SW) Morris (SE) corner on the beta grid. The login region always comes up immediately. Logged in at region center of Morris with 64m draw distance. Neighbor regions appear when 64m distance crossed. Logged into Morris near corner. Ahern appears immediately, Dore and Bonifacio after one minute. Have done this many times; repeatable. Logged into Dore at region center with 64m draw distance. Neighbor regions appear when 64m distance crossed. Logged into Dore near corner. Morris appears immediately, other two after one minute. Logged into Bonifacio at region center. Morris and Dore appeared when walked into range. Ahern took 1 minute. Logged into Bonifacio near corner. Morris appeared immediately. Other neighbors took one minute. Logged into Ahern. Landed near corner due to landing point. Can't land at center. Bonifacio appeared immediately. Dore and Ahern took one minute. The Other Simulator: Logged in near region corner, all four regions come up immediately with no problems. Note that region handshakes always take place, and object updates start coming in. It's only the EstablishAgentCommmunication message that doesn't show up. I suspect there's some undocumented thing I need to do after login to get things going, but I have no idea what. As far as I can tell from the code, I'm sending what the SL viewer sends. I haven't yet reached the Wireshark level of reverse engineering desperation.

It's not entirely a silly subject. I've done a bit of work on this, because, in my experimental Sharpview viewer, I want to show more of the world than just the draw distance, so you have more of a sense of where you are. When you want to show the big world, this stuff matters. A few years back, I turned the SL map into a slippy map, so you can pan, tilt, and fly over. Above Second Life. (I have this online, but because of BUG-226430 I have to front-end the map content delivery network with a proxy, and it doesn't work reliably because the free proxy has bandwidth limits. You can try it but you get cut off before the whole map loads.) This lets you see the entire SL map, which is helpful when flying. This would be turned on for mainland and big estates, but off for isolated regions, so they see the usual infinite water. This models a flat world with an infinitely far away horizon. That's stage 1. At ground level, you need distant objects to have some elevation, or you can't see them. It's possible to get elevation data for a region and project the map data onto it. Someone did that at SL20B, and others, including me, have done it. This lets you see hills. It's possible to do better, but the SL map painted on elevation meshes is a good starting point for test purposes. A more advanced system might use Open Drone Map to make low-rez region models from pictures of mainland taken by drone bots. (Only mainland and big estates need this. You can't see isolated regions from off-region.) With this flat world, you'll see the tallest terrain in SL from everywhere. Being able to see Mt. Campion in Heterocera all the way from from southern Bellessaria would look wrong. Plus it adds overhead. So some kind of horizon would help. So it's useful to apply some curvature to the world. That's stage 2. At normal eye height, the horizon is about 5 km distant. Of course, if you get on top of something tall, you can see further. Curvature would only be applied to distant region impostors. Wherever you are, within draw distance and a bit beyond, would be completely flat. Distant mountains would be be partly below the horizon, and completely hidden at some distance. Above some height, object elevation doesn't matter too much and a flat ground map is good enough. It's not a perfect illusion but it will give a sense of place. Juggling curvature, draw distance, and impostor management is an interesting technical problem. More on this in future months.

If the lost-bot problem is brought under control, maybe the useless safe hub off to the west of Zindra and its waterway could be removed. Most of the Zindra safe hubs are used only by lost bots.The number of those is declining as LL insists on bots having the bot flag set. There used to be about 200 lost bots at the Zindra and Horizons safe hubs, but that seems to have declined a bit. Those regions could then used to fill in the unfinished rough edge of Zindra in the southeast corner. Three more regions there would connect up four dead-end roads and clean up an edge that just hangs off into space. Most of that could be saleable land, too. By the way, Zindra has a sizable ocean, but it's not used much because nobody can find the hidden rez zones. (There are two on the south side of the river at the Port of Kama City.) The people with beachfront property don't seem to sail much, if at all. Standard Belli-type rez zone markers would help. This is just low-cost municipal tidying up.

SecondLive seems to be a real thing, an Asian crypto social network. It's classic 2021 crypto metaverse stuff - wallet, coins, mining, play to earn. It's an Android phone app. You can overlay cute little dancing kawaii avatars on phone video of the real world, and share the videos. (YouTube link) It's kind of a mashup of Pokemon Go, Vocaloids, TikTok, casual gaming, and crypto. It's probably a Lose Money Fast scheme on the crypto side, but at least it has cute graphics. The fake Second Life viewer, on the other hand, is just a low-rent phishing attack to get malware installed.

That's a good policy statement. Road connection, Corsica. The Moles left a gap in the hedge for access, and it's up to the parcel owner to connect up somehow. Behind the "Under construction" sign is one prim of pavement which has some twist to attach cleanly to the Linden road. It's about 2 meters over the parcel edge at its furthest point. This looks far better than following the jagged parcel boundaries. I posted a picture once of someone who carefully ended their landscaping at the parcel boundary alongside a curved road. Looked awful. So, if you do this, make it look like it belongs there. This sort of thing is common. Most people never notice. Unless it's a pain for someone, . A low-hanging sign that blocked GTFO trucks was a problem once. Someone had a tree branch which interfered with the Zindra monorail. Moles took care of both. Problems like this come up in real life all the time. Who maintains the space between the sidewalk and the curb? Varies by jurisdiction. I live next to a creek in real life, and a tree growing out of the creek bank fell onto my driveway after a storm. Turns out the county owns one creek bank, the centerline of the creek is a city line, the tree may be on a property line but we'd need a surveyor to be sure, and we never did get a good resolution. Just cut off the part of the tree that was blocking the driveway. There are two places in Bay City where there is a curb cut in a Linden road to accommodate a private driveway. See if you can find them. Part of the fun of mainland is making the pieces fit together nicely.