Jump to content

animats

Resident
  • Content Count

    2,170
  • Joined

  • Last visited

Everything posted by animats

  1. 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.
  2. http://maps.secondlife.com/secondlife/Toothsum/124/150/28 Yes, the other link somehow lost the region name.
  3. 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.)
  4. 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.
  5. 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.
  6. 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.
  7. The Gor books are fantasy novels of male domination of women. If you want something else, find another novelist upon which to base your roleplay.
  8. 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.
  9. 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.
  10. 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.
  11. This tiny success encourages throwing more resources at Sansar. "IQ Mag reported that the Fortnite event was the most-attended concert in history and Sansar gives Linden Labs an opportunity to capitalize on that excitement with regularly produced content." It allows LL to pretend that Sansar is the Next Big Thing. That's a problem for us in SL. Sansar eats LL's development resources. The SL server development team is so tiny that with Simon Linden off for a few weeks, server releases have stopped. LL isn't trying to hire anyone for that team. Sansar, though, is trying to hire a "Senior Backend Engineer" and an "information security specialist".
  12. What is the current recommended swim HUD? I've been using ZiSwim, but the creator is long gone and it has some problems.
  13. 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.
  14. The Sansar team has been able to pump up usage briefly with special events. The users don't stay around after the brief peak. See Forbes article. That's the July 12 spike. Sansar is trying to emulate the success of a DJ concert in Fortnite. That was 10,000x larger than the one in Sansar. “This is the future of live music, and we’re excited to have Monstercat on board.” - Altberg. Maybe LL can sell Sansar to Monstercat and exit.
  15. 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.
  16. 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.)
  17. 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".
  18. Before I bought land, I used to go up to the third floor of a library in New Babbage. Nobody goes there.
  19. 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.)
  20. 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.
  21. Ah. Collision detection is falling through because the movement in one frame time is more than half the thickness.
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...