animats

Baby needs shoes. 29 LI animesh. Need shoes with a suitably low LI.

Animesh characters can wear shoes. They just can't afford them. Couldn't be that complex, could it? It could. 30016 triangles. On an animesh character, that's 45 LI. Per shoe. My whole character, is only 30 LI. Another shoe drops. 28,308 triangles. 43LI per shoe in animesh model. (Animesh LI: 666 triangles per LI at high LOD. 333 at medium. 167 at low. 84 at lowest. Compute all 4, use biggest number.) Anyone know some basic female sneakers or casual boots for a standard female avatar with an animesh LI of 1 or 2? I've been downloading demos, unpacking them, getting the triangle count, and deleting them. It's not helping.

I've used keyframe animation with canned paths before. This is keyframe animation with dynamically generated paths and collision avoidance. I just give it the destination, and it figures out the route by itself. It can find and reach avatars anywhere on the parcel. Including going up stairs. I haven't seen that done in SL by anyone else. It doesn't even seem to have been done for bots that are avatars. SmartMates (apparently the last survivor of the bot list on the wiki) doesn't have that. They just follow waypoints or the user that owns them. Smartbots offers a kitten, a gorilla, an alpaca, and a bodyguard. Those require a server, a paid account with the server operator, and an extra SL account. Now that we have animesh, we should be able to do that sort of thing entirely within SL.

Nice Lionheart mainland station, but no trains ever show up.

Yes. A key point for a new user is whether you want to ride a horse, or be a horse. Both options are available.

Oh, come on. L$70K for two 400m^2 parcels in a dead mall where most of the stores are vacant?

Somehow, about five years ago, San Francisco became part of "Silicon Valley". I live about 30 miles south of San Francisco, about 10 miles north of Stanford. Where I live wasn't considered part of Silicon Valley a decade ago.

Yes. However, the default "Thomas" avatar comes with a horse attachment. So that's a free option. Not too bad a horse, either.

Well, after leaving this running overnight, it seems to stay out of trouble. That alone is a big improvement over SL pathfinding. This is starting to look like the way to do NPCs. Keyframed NPCs have worked well in many places of SL, but they're usually stuck on rigid tracks. Now they can get some freedom of movement. Keyframed motion in SL is a bit strange. It's semi-physical; it can push or carry physical objects. Collisions with physical objects, including avatars, are detected. But collisions with non-physical objects are not. This includes other keyframed objects. On the other side, keyframed objects don't trigger collisions in llVolumeDetect, and are not avatars or physical objects to llSensor. llSensor will detect scripted objects with type "(ACTIVE|SCRIPTED) ", but that triggers on everything in range that has a script. SL's low-overhead tests for moving objects don't work. So doors don't open for keyframed objects. A useful test for doors is to use llSensor with type "AGENT|ACTIVE", then test for nonzero velocity for each object sensed. That picks up avatars, pathfinding animesh, vehicles, and keyframed motion. (Also the door, so that has to be excluded.)

Pathfinding in SL has been troublesome. I've made some nice pathfinding animesh characters, but they don't move well enough. Characters keep going off-path and running into things. They hit corners of buildings and spin around. They go off-parcel and get stuck. Under sim overload, this gets worse. Much worse. Slowing them down helps, but then they move like zombies. That's no good. There's keyframe animation, but that tends to be too rigid, following permanent built-in paths. The movement from keyframe animation works well; it's just too repetitive. So I've written my own pathfinding system in LSL. It uses llGetStaticPath to get a rough path, avoiding static obstacles. Then it uses llCastRay calls, many, many llCastRay calls, to check that path. If an obstacle is encountered, it runs a maze solver in LSL and works out a path around the obstacle. Once the path has been computed, the path is followed using keyframe animation. New pathfinding system tester. I'm using a bronze monolith for testing. I'll switch to an animesh character later. Just for testing, the planner puts down a trail of temporary markers. They disappear in about a minute. The green path is mostly from llGetStaticPath. That path hit the doorframe. The maze solver took over and corrected that. The maze solver's work is shown in yellow. Though the parking lot and around the parked vehicles. The maze solver worked out a path around the vehicles. The maze solver is grid-based, and the result gets straightened out a bit afterward. Where you see green on top of yellow, the green is the path it actually took. This is actually three maze solves in a row. Looks a bit more robotic than I'd like. Using keyframe animation means the characters follow the planned path at full speed, even on an overloaded sim. No more zombie-speed movement. No more banging into doorframes and tables.The movement quality is comparable to ordinary SL avatars. The turns are smoothed out and the character rotates going into and out of the turn; it doesn't stop dead and pivot in place. I'm currently running the monolith at faster than SL walking speed. No problems with that. Script overload shows up as a delay in starting movement. Maze solving in LSL is slow, but it's overlapped with movement, so the maze is usually solved before the character gets there. The system will avoid avatars when necessary. If an avatar moves into the path, the obstacle will be detected. But then there's a delay of several seconds while the planning system computes a new path. I want to use a "looking around, impatient" animation for my characters while they're on hold waiting for the planner to catch up. A big win with this is much better performance in cluttered areas. SL's pathfinding system needs a lot of open space. The minimum opening width for SL pathfinding is about double door width. Even then, the characters tend to bang into the edges of the doorframe. This system, if there's 1m of space, can get through. So it can get through a standard door. And maneuver around inside a restaurant or club. I'm thinking of a NPC waitress. All this requires a parcel with pathfinding enabled, and with big objects marked as walkable or static. The maze solver will handle going around little stuff, movable objects, and avatars. The maze solver can only handle an area of obstacles about 20m across, so big obstacles must be made static. This does not turn on the full SL pathfinding system, which has a constant overhead of about 20% of a sim's script time. Overhead for one character seems to be about 1ms per frame. 10 characters in an empty sim pushed the load up to 2ms per frame. So it's less than the built-in pathfinding for small numbers of characters, and there's no compute load when the characters are not moving. Not low enough overhead for large, active breedable herds, though. It doesn't seem to impact heavily loaded sims much, because it's making large numbers of llCastRay calls, and those are throttled. So it slows down rather than impacting the sim. That needs further testing. Vir Linden indicated at Creator User Group that making large numbers of llCastRay calls is OK. This isn't done yet, but it's working well enough for a demo. I have the monolith running at the Animats workshop in Vallone as a test, and you can visit if you like. The tester behaves much like my animesh NPCs, which use regular pathfinding, and approach new visitors. When there are no new visitors, it moves randomly between some patrol points. It doesn't have the social graces yet. It tends to bump into avatars and stop, it gets too close to them, and it doesn't say "Excuse me" like my NPCs. (This was way too much work. LSL is not a good language for something this complex.)

At region crossings, or randomly? You have to restart vehicle animations at region crossings to eliminate this problem. It's been around for years, but can and is dealt with in vehicle scripts.

You can set your account to foward IMs to email. If you answer the email with a text-only email, it goes back in world as a reply IM.

Cute. Suggest providing curtains. There are people who'd like a little private space of their own. (What's with that adjacent area where, for L$9, you can buy an access pass. I bought one out of curiosity, walked in, and was ejected after a few seconds. Apparently "zero time" on an access pass really means zero, not infinity.)

I've been doing a lot of scripting work lately, and I'm visibly in world when I do it. I have a workshop, and I use it as a workshop. That seems appropriate. I have a builder's yard out back for big stuff like escalators. Sometimes people stop by while I'm working and I stop what I'm doing to talk to them.

Wow, now we have sale and leaseback arrangements on SL. Just like RL. (Silicon Graphics did a deal like that with Goldman Sachs for what is now the Google campus. It worked out very badly for SGI, which was desperate for cash at the time.)

Thanks, Luca. That's what motivated me to work on this problem. You can see that the last movement update, the one that gets extrapolated, is bogus. That car was going along smoothly. If the predictor kept it going in the viewer in the same direction with the same rotation while the region crossing processed, it would look OK. But it's clearly extrapolating from bad data, and the car flies into the air and rolls. Or seems to. That's a viewer-created illusion. It leads people to make frantic steering corrections. Then they crash. The "Stop" setting stops that, but rather abruptly. This is embarrassing for Linden Lab. Really. They've had that bug since at least 2013, and haven't been able to fix it. A clip like that really shows how bad this is. Modern video games do not do things like that. This is the sort of thing that gets "Your game sux" comments from new SL users.

You are completely right. When I zoomed in, I got the down escalator. No bug. My bad.

I'm the author of the "stop at region crossing" code. Technical background here. Short version: There's a fundamental problem, that region crossings take time, during which the object is frozen in place. And there's a bug; the very last update sent to the viewer by the sim that's giving up the object has velocity and acceleration info which contains poor quality data. Those are both server side problems. Ones LL is unable to fix. We can try, in the viewer, to hide both problems from the user by guessing what the data ought to be. Available guessing approaches are Just extrapolate blindly what was happening before the object left the sim. (Old behavior, and Firestorm in "Predict" mode). OK for slow boats, terrible for fast land vehicles. Stop the object on screen hard during the region crossing. (Firestorm in "Stop" mode.) The pause is annoying but there is no bogus motion on screen. Drivers like this, sailors do not. Extrapolate blindly, but with a time limit (Current LL viewer behavior.) Prevents the worst effects while keeping the sailors happy. Evenly distributes the misery. I agree with Luca on this. Start out new users in "Stop" mode, which is understandable, and tell sailors how to get "Predict" mode for a peaceful slow sailing experience. Or at least set the default timeout in the Linden viewer to something small, like 100ms. (I've done about as much as I can do until LL fixes some server side bugs. Fancier viewer side prediction algorithms might help, but fixing the bad data that comes out of the sims would help more. Meanwhile, if you want to experience a smooth drive, set "Stop" mode, get a car from one of the demo rezzers of the car builders in Burns and drive around Heterocera. You will have smooth region crossing experiences, but a momentary hold at each crossing. I'm done with this for now, until LL fixes some bugs. I once said to Oz Linden at Server User Group, "You guys fix the sim side problems and we'll take care of the cosmetics". Between what viewer devs can do in the viewer and what vehicle builders can do in vehicles, we can make region crossings look and feel good. But we cannot make them not break. That's on LL.)

This all mesh object has two LOD models, and the lower one is different enough from the close-up that this isn't the problem. (I'd post a picture, but Vallone sim is offline right now.)

That might make sense at distance. But this is reversing in close-up. The zoomed-out version is correct. The zoomed-in version is wrong. Knowing that the viewer changes animation speed with distance is useful. Now we know where to look for the bug.

Are you outside the US? A friend was locked out for weeks due to LL not properly processing funds from a bank in Scandinavia. Despite letters from the bank to LL, the problem took weeks to clear up. She lost her oceanfront parcel and her in-world store was out of business for weeks. LL really needs to get properly plugged into the major non-US payment systems. And no, that does not mean making people use PayPal. That's Tilia's job.

Some keyframe animations look wrong at some zoom levels. Known bug. Tends to show up for distant rotating signs. It also sometimes affects my escalators. Here's a really strange situation. When you zoom in, the stair motion reverses. Strangely, it reverses for both the angled steps, which are keyframe motion, and for the flat steps at the top, which are simple texture animation. This is Firestorm, but it's known to appear in the Linden viewer, too. I can't update the JIRA because the bug report was merged into another bug, which I can't comment upon.

"Networked advertising" in SL does not seem to be doing well. Much of the ad space is selling - ad space. In back of the Linden info hub in Ungren is a huge wall of ad boards. Most are non-revenue. There are some political signs, some public service announcements, and a big ad for an area that went out of business last year. Signs over 110 meters high, over 200m high if you count the floating purple cube with an ad. 135m wide. And moving arrows on Linden land. There are some huge billboards in Corsica, based in tiny 4x4m parcels. Selling ad space. They're so tall that, driving by, you just see the post; the sign is too high up. As a business area, this looks dead. Although the ugliness lives on.

Unclear. Linden Lab says that. Whether the SEC and the IRS would agree is something else. LL is desperately trying to avoid having to register Linden Dollars as a security. That may or may not succeed. The SEC is regulating cryptocurrencies more strictly, and they are fed up with the issuers running off with the cash. Properly, LL should request a no-action letter from the SEC, like this one: https://www.sec.gov/corpfin/pocketful-quarters-inc-072519-2a1

Location, location, location. You want some barren hillside in Corsica, there's about 10 whole sims available. Corsica makes something very clear. Without water or roads, nobody wants it. Get 100m off a road in the interior of Corsica and you're on abandoned land. Even though people don't seem to drive much in SL, they want roads. Bellesaria got this right.