animats

No, it's with a few others in a big empty room. VR game level loaders just aren't going anywhere. The best VR game seems to be Beat Saber, which is a very simple thing done very well.

http://maps.secondlife.com/secondlife/Toothsum/124/150/28 Yes, the other link somehow lost the region name.

My real point is this: It is far easier and cheaper to bring SL up to modern game technology levels than to try to start up a new virtual world and get users to use it. Failed new virtual worlds include High Fidelity, Sinespace, Sansar, Worlds Adrift, Facebook Spaces... Two have shut down and the other three have few users.It's just not working out. (On the technical front, I'd previously mentioned Nostos, which was supposed to be a big shared world running on Spatial OS run by NetEase from China. So that was going to be the real test of new big-world technology. Launches next month. Turns out, "shared" is smaller than expected: "Nostos is an open world multiplayer game set in a vast tranquil wilderness scarred by an ancient war. 4-20 players create persistent sessions..." So it's sharded like Sansar, but unlike SL. So far, nobody but SL has a big shared world that works. Despite Improbable spending $500,000,000 trying. So, fixing up SL remains promising, vs. attempting a new start.) (I watched the final moments of Worlds Adrift. In the end, nothing but clouds remained.)

If you go to Server User Group regularly, it's clear that important things are not being addressed because of staff shortages. Or look at the JIRA, for bugs long marked as "accepted" but not fixed.

There are lots of things that could be done to speed up SL. Everybody who knows how game engines work internally and has looked at SL knows this. But with Sansar getting more development resources, nothing is happening. There seem to be only three or so SL server developers. When Simon Linden is on vacation, server releases stop. This is a staffing problem, not a technical problem. SL's job postings include several people for Sansar's back end, but none for Second Life's back end. (On the technical front, here's my personal list of things that ought to get fixed.) Idle scripts must use zero compute time. Not less time, zero. Idle script time is a huge drain on server resources. I once suggested to Oz Linden that it was using half of sim CPU resources. He indicated it wasn't quite that high. But it's high. Main cause of sim overload for sims with few avatars present. Probably requires someone who can get into the internals of Mono. Might need a Mono consultant to make some changes to Mono's CPU dispatching. Collect all the viewer code that decides which textures to load at which resolutions into a policy module. Smarten up the policy. Classify recent avatar movement as "stationary/moving/moving fast" and "fixed look direction/looking around". Pick desired texture resolution to show based on that. If you're stationary and not changing look direction, top priority is high texture resolution on what's in front of you, so you can see all the detail at Fashion Week. If you're moving fast, go for moderate texture resolution in the direction of travel out to draw distance, with lower resolution off to the side, so you can see where you're going. The same criteria should affect LOD decisions. Also, for each object, store one color, chosen by reducing the textures to 1x1, with the object. Objects rez in that color rather than grey. So trees in the distance are green blobs, houses in the distance are brown blobs, and roads in the distance are grey blobs. Add a little blur during rendering when in blob mode, and the result will look like fog in the distance. Much better visual effect than all grey blobs. Once level of detail and texture control are behaving better, adjust them automatically to maintain a minimum frame rate. This will make the system feel livelier. Build some good tools to log, and decode into a clear form, the message streams from sim to viewer and sim to sim. The existing tools tell you an object update went by, but that's about it. This would help chase down intractable and intermittent bugs that have been unfixed for years. Good task for a new hire; they'll learn the system but can't break much. Better LOD generation. The uploader's LOD generator is awful. Replace it. Once something good has been found, go through the existing assets, find awful low and lowest LODs generated by the old generator, and replace those. Good background task to run at low priority on AWS. Impostor generation. Every major 3D game has impostors, 2D billboards that replace distant objects with flat pictures of them. Except SL, which only has impostors for avatars. Hierarchies of impostors - object, building, parcel, sim. See for kilometers. Feel the big world. More modern rendering. Principled BRDF? Leave that to a rendering expert.

I'm writing a pathfinding system, and I'm up to 3 scripts already, just to get them to fit. Soon, 4. More before I'm done. Intercommunication uses link messages and JSON. Current breakdown is: Initial route planning (uses llGetStaticPath, then finds and brackets obstructions.) Maze solver (solves mazes of up to 41x41 cells 0.5 m on a side to get around the obstructions.) Debug marker display (this puts temporary objects in-world to show the path being generated) Those are all running. To be added: Path to KFM list conversion, with speed and turn changes to make the movement look human (slow for turns, go wide on sharp turns if space is available.) Cache to store 10-20 previously computed routes, to speed this up. Path execution (monitors the KFM progress and does ray casts to detect any new obstacles) All this to do what llNavigateTo is supposed to do, but won't do reliably or with motion better than zombie grade. Since LL refuses to fix all their pathfinding bugs, I have to work around them. I've seen a chatterbot that uses about 20 scripts to store its phrase vocabulary.

LSL isn't that bad for what it does. A few minor optimizations I'd like, to increase performance and reduce memory usage: For lists, if you write lst = lst + ["abc"]; the compiler should recognize that as an idiom and do a replace in place. This should apply generally to anything of the form lst = (some expression containing lst). Programs execute exactly the same, but use less memory and go faster. CPython uses this optimization on strings. They're supposedly immutable, and adding a character to a string should mean a copy. It doesn't really work that way internally, since that would be very inefficient. Along the same line, if you pass a list to a function, it doesn't need to be copied unless it appears on the left side of an assignment within the function. The "lazy lists" feature of the Firestorm LSL preprocessor should be standard, and optimized as per the first item above. This gives lists array-like random access performance without affecting existing code.

I'm not selling NPCs at this time. But I usually have some pathfinding characters running around Animats's Advanced Vehicle Development in Vallone. I also usually leave one running at Animesh 1 on the beta grid. If you go there, they'll find you, approach, say "Hello", wait a bit, and walk off. Now that overloaded sims are the new normal, it's tough getting pathfinding to work reliably. My characters have extensive recovery code, yet they still get stuck occasionally. Pathfinding sets a heading and speed for each character, and updates that course when it gets around to it. On an overloaded sim, characters continue too far, blind, because the pathfinding system is responding slowly. They get stuck in objects or even go off the parcel.

The seller can offer it for rent, but they can't really rent it out, because neither the owner nor tenant can rez anything there. If someone rents it, the owner has to take down the auction.

What is the current recommended swim HUD? I've been using ZiSwim, but the creator is long gone and it has some problems.

Time to check back on those giant billboards based on 4x4m parcels on Corsica to see if Governance got to them yet. Maybe LL should charge a minimum tier per parcel, to discourage that sort of thing. Anything below 512m gets rounded up to 512m for tier billing purposes.

Linden with a space. A parcel can now be for rent, developed, and on auction all at the same time. These auctions seem to work much like eBay at its worst. High minimum bids, so that most auctions close unsold. Then the seller puts the parcel up for auction again, maybe tweaking the price a little. This fills up the resident auction list with overpriced parcels. That's why we need a "minimum bid" and "price per square meter" in the listings. And the ability to sort. Maybe if a seller puts a parcel up for auction with a minimum bid, and it doesn't sell, the seller should be charged the auction fee, based on the minimum bid. That would discourage high minimum bids.

A casino to play in, or to hold up? (Besides, the way to make money in GTA V is to speculate in the stock market.)

I see parcels owned by "AuctionServicesLinden". That would seem to indicate that the parcel would not be in use. But the parcel is still available for rent, and has a rent box. If you rent it, the seller cancels the auction, says the instruction notecard. Or you can buy the parcel for the auction minimum price. This is kind of weird, but apparently permitted. There seems to be a new thing for buying parcels, filling them with junky stuff, and then putting them up for auction. The auction listings are uninformative. The resident auction summary listings don't show the minimum bid price, region name, or the price per square meter. You have to click on each entry for that. A more useful table would help. Looks like someone tried too hard to make the table "mobile-friendly".

Before I bought land, I used to go up to the third floor of a library in New Babbage. Nobody goes there.

Here's an idea: "remote scripts". This is something halfway between existing LSL scripts and using an external web site. You'd check a checkbox to indicate a script was a "remote script". You'd get a choice of LSL or C#, because Mono can run both. Remote scripts would run on ordinary web servers under LL control. They'd be associated with an in-world object, but would work a little differently than regular scripts. Remote scripts could make LSL calls allowed for the object, but they'd be slower, because they'd be sending messages to a proxy on the sim to ask for something to be done. Remote scripts would know the object and user to which they belong, and permissions would work accordingly. That's the big advantage of having this inside the LL world. Remote scripts and regular scripts could send messages to each other. Remote scripts would have access to a key/value store, like experiences do, and optionally to an SQL database, if you'd created one via some LL web interface. So you could store real data. There might be a charge for having a full database, but you should get 10KB or so of key/value store for free. This provides enough data storage for vendor systems, game managers, etc. Remote scripts would be able to open on-screen windows for dialog boxes, using the "media on a prim" mechanism. They'd be full web pages if desired, but normally they'd just be generated by some standard UI library. So remote scripts could offer a full user interface. As with media on a prim, there's a connection between viewer and web server that bypasses the sim servers once set up. So this wouldn't add to the load on the sim servers. Remote scripts would be semi-persistent. Variables would be preserved for a while, but not forever. If the script was idle for a while, it would receive an "idle" event, and the script would have to save its state to the key/value store if it needed to pick up from there later. On the next use, the script would start from It will get a default state entry the next time it is used. This keeps from having to store huge amounts of inactive script state forever. Remote scripts could be much larger than server scripts. A few megabytes, at least. This would essentially be LL offering shared web hosting with some extra SL integration. You could almost implement such a connection in LSL right now, using your own web server. But it would be better if LL did it, because the security and integration would be tighter. Use cases: Appliers, resizers, and such. Anything that needs more dialog options than the LSL dialog boxes support. In-world creation and editing tools. LSL is too cramped for that, but with an external server and C#, it becomes possible. A good place to start would be in-world paint. (You'd still have to pay the upload fee to use the result in world, of course.)

It shouldn't be that hard to support C# on the Mono engine. Open Simulator does that. The problem is keeping the size of scripts down. With a real programming language with real data storage, people would want much larger scripts. Those come out of sim server memory. If people started pulling in C# libraries in scripts, memory consumption would go way up. You can do real programming in LSL. It's not fun, but it's possible. Here's a maze solver I wrote recently, for my NPCs.

Ah. Collision detection is falling through because the movement in one frame time is more than half the thickness.

Autodesk said no to Apple for the entire PowerPC era. Autodesk products were never ported to PowerPC. They've done it before when Apple did something stupid.

Avatar behavior on moving platforms is smarter than that. Get on one of the trams in New Babbage and just stand. You'll move with the tram, with no walk animation. Until the next sim crossing; then you fall off the tram, going through the wall. Elevators and escalators in SL generally work. My moving sidewalks carry avatars fine without triggering a walk animation.

In early 2010, Linden Labs acquired a social network which was supposed to be "Facebook for avatars", "Avatars United". They shut it down in late 2010. That was from the era when, for a while, it looked like the future included the ability to move from virtual world to virtual world, perhaps taking some of your stuff with you. From 2009, via the Internet Archive: Welcome to the world’s most open community for MMOs! Register today, hook up with your friends and improve your virtual life… one application at a time! "It's like Facebook for your virtual personas." So, LL has been there, done that.

Yes. Autodesk called Apple's bluff. Autodesk has said they will not support Apple's private graphics API.

That's puzzled me for some time, too. I thought that Sansar might be investor-driven, but according to Crunchbase, it's not. LL hasn't had a funding round since a series B in 2006, says Crunchbase. Bloomberg doesn't have much on LL. LL seems to be self-funding Sansar from SL income. Worst case is that LL took on debt to fund Sansar, and if Sansar is killed, the debt comes due. But that's pure speculation. Equity usually shows up in Crunchbase, but debt doesn't necessarily show there, especially for privately held companies. Benchmark Capital and Catamount Ventures each have two board seats, so they are presumably the biggest investors. Neither of those firms is a top investor in VR. So it doesn't look like "we're funding the headsets, we need to fund the content". Headset funding is mostly from Facebook, which owns Oculus, NTT and DoCoMo, which are the latest big investors in Magic Leap, and Microsoft, HTC and Panasonic, which are big enough to do this on their own. None of those seem to have money in LL. Sinespace, the most successful player in the "VR game level loader" space (which is them, Sansar, and High Fidelity), claims 10,000 active users spending about US$17 per month, with Sinespace taking 30% of in-world transactions. That's only $600K a year, about a third of the average fast food outlet's revenue. That's who Sansar is chasing. There just doesn't seem to be much revenue in this space. The numbers don't work. So I don't see why LL keeps pouring money into Sansar. Does anybody see a route to profitability?

Many people overestimated the demand for VR, from Zuckerberg on down. One of the things driving VR was that the consumer electronics industry is desperately looking for the next "must have" product. Desktop PCs and smartphones have peaked. Tablets were less popular than expected. 3D TV flopped so badly it disappeared from the market. Internet of Things for the home didn't work very well and remains a niche. Same thing for 3D printers. Google Glass was a flop. So too many hopes were pinned on VR. 2017 was supposed to be the year of VR. What actually happened was that VRChat peaked at Xmas 2017, at about 5,000 users, and went downhill from there. VR games other than Beat Saber have not been very successful. VR headgear nauseates about 5% - 15% of the population. That's worse than roller coasters. (There are people who thought augmented reality would be the next big thing. It might be if the price comes down, a lot. I've tried the Microsoft HoloLens, which starts somewhere around $3500. That needs to drop by about a factor of 25 to 50 before it can power Pokemon Go. The over-hyped Magic Leap One, on which over a billion dollars has been spent, is in the same price range and has about the same limitations, including a very narrow field of view.) (About two years ago, I posted on the Facebook page of a well known "thought leader" that VR headsets were the next 3D TV. He threatened to ban me. I wonder how he's getting along.)

Nice, but the rate for that sort of thing in the SF Bay Area is maybe US$150,000/year. How big is your budget?