Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by animats

  1. I just tried flying around there. Over the Bingo Strait at Barbarossa. No problems with the little Duoquito, and the blue helicopter on the right seemed to be doing fine. I was able to land and hear voice chat (there's an info hub there), take off again, and enter and exit that sim from all four sides without problems. Spent about fifteen minutes flying around the area, visiting about 20 sims. No problems. I'm quite critical of region crossing problems, as is well known, but I'm not seeing them here.
  2. It's always good to have a backup system. Just in case.
  3. OK. I just removed my free motorcycle rezzer, installed the day Bellesaria opened, to be fully compliant. Back then, there were no rez zones and no way to get around, so it was needed and used. Now there are enough rez zones.
  4. Part of the idea of Project Arctan is to get people to care more about their avatar render cost. How to make this work without breaking existing content is a regular subject of discussion at Creator User Group. Vir Linden is gathering more data. There's no consensus. The viewer has the power to render an avatar at any level of detail, as an impostor, or as a jelly doll. How it should use that power is a big question. How do most avatars and clothing look at "medium" LOD? Acceptable as background characters? Maybe the viewer should be dropping avatars to a lower LOD or to impostor mode sooner. This beats dropping the frame rate to single digits. One approach would be that avatars only go to "high" LOD when in hero mode; close to the viewer and occupying lots of screen space. There's nothing wrong with high-detail avatars provided that only one or two are in that mode at a time. What we don't have now for avatars are good intermediate stages between "insanely complex" and "jellydoll". I'm very aware of this because I do standalone animesh characters. Those have a high LI cost and object-type LOD handling, so they have to be efficient or they blow the parcel's LI budget. They also have to look good at lower levels of detail, because they're often shown that way. I'd like to see the "medium" level for avis be around the complexity level of a good animesh character - 20,000 tris or so. (You can look at things at a lower LOD by opening the Firestorm menu and setting the LOD setting to some very low value. It's instructive to set it to zero and see what's still visible.)
  5. That's when you need a pro architect. Frank Lloyd Wright's Fallingwater. Custom designed for the site, of course. One of the most famous houses in such a location. Gives a good idea of how to layer levels to fit terrain. A combination of glassed in levels with balconies on stone supports can fit most hills.
  6. Now that's a good idea. The animesh will need to enable llAllowInventoryDrop. The animesh sends a message to a sittable object that it wants to sit there. The sittable object replies with a sit target, an animation name, and uses llGiveInventory to give the animesh a copy of the animation. The animesh gets a "changed" event with the CHANGED_ALLOWED_DROP flag. Then it has to examine its inventory for new stuff, possibly discarding any unwanted new items. It finds the new anim. It moves to the sit target. It plays the new animation. Now it's sitting on the sit target with the proper animation. Right. You don't get the link of a real sit, so it won't work for vehicles. But it's enough for the basics. Thanks.
  7. Animesh sitting is going to require some cooperation between the animesh and the sittable object. It's not likely to work on existing sittable objects. There's no "Sit" cursor, and animesh can't answer dialogs. It's also a big job for the LL devs, and they're overloaded. If LL wants to take this on, that would be nice, but it seems unlikely right now. However, if we had minimal support in LSL, which is what I'm asking for here, open-source AVSitter and similar code could be modified to use it. Then anything which uses an updated AVSitter could accept animesh. Someone has already done something like this as a mod to AVSitter, but the sit animations have to be in the animesh. So it's a short step to making it work in a general way.
  8. When an avatar sits on an object, it becomes part of the object's linkset, and the object can apply animations to it. Animesh can't "sit". So they lack a way to get access to and run a sittable object's animations. So, a proposal: If an animation has Copy/Mod/Trans permissions, then llGetInventoryKey will return its UUID. But there's not much you can do with that UUID,a as far as I know. With a texture, if you have the UUID, you can set that UUID as a texture anywhere in SL. But for animations, llStartObjectAnimation only accepts a name in the object's inventory. It does not accept a UUID. So, what if it did accept a UUID, the way llSetTexture does? Then an animesh and a sittable object could communicate; the sittable object could tell the animesh what animations to run. The question is, are there major security objections to this? llStartObjectAnimation only works for animesh, so this doesn't let avatars do anything new. My interest is in animesh NPCs. I'm trying to get them to do more of the things avatars can do. They can't sit. With a cooperating script in a sittable object, and this minor change, we can make that possible. Comments?
  9. Some of the problems with mainland builds could be helped with a class, perhaps at Builders' Brewery, on "how to build in difficult terrain". Topics such as: How to build on hills. Most prefab SL buildings are for flat ground. Putting them on hills is usually done either with terraforming or with some huge blockish slab underneath. Some examples of best practices would be helpful. How to connect to a Linden road. This is often hard to do neatly. Some roads have rocks or high curbs or jaggy parcel boundaries. Linden advice on allowable encroachments would help. Sometimes you just have to reach a bit beyond your parcel to make the connection work. Such work needs to look like it belongs there. This is especially important for GTFO hubs, because they will have truck traffic. For the hard cases, it should be possible to pay for mole work and get a curb cut. How to clean up terraforming messes. Where the original moles built rolling terrain, parcel owners have often flattened their lots. A few generations of ownership later, each parcel is flat, at a different level from its neighbors, and there's a cliff at the edge of each parcel. Much abandoned land looks like that. If someone good at this gives such a class, I'll go.
  10. You can use key/value pairs in a locked way using the llUpdateKeyValue function with "checked" set to TRUE. That's a "compare and swap" operation in computer science terms, a way to avoid race conditions in asynchronous operations. When you want to set something, you do an update with what you think the old value is. If some other script changed it while you weren't looking, you get an error back from the data server. Then you can get the current value and try again.
  11. Just because it's industrial, it doesn't have to look awful. The climbing ivy improves the brick wall. A friend's freight hub. Simple and well-kept. Decorative fencing helps here. Should SL have zoning? Something to think about for mainland. Bellesaria is single-family residential, with occasional public areas. One of the big landlords has about five different zones, from single-family residential to heavy industrial. New Babbage has building inspection for city consistency and quality.
  12. I use voice when possible. Usually I chat in local. Lately I've been using IMs too much because my local chat window is clogged with debug messages from stuff I'm working on, but I expect that problem to end soon.
  13. Anyone have an measure of how much more Bellesaria space is needed to satisfy the backlog? Is it going to take a few more continents?
  14. Yes to both. If a parcel goes up for auction, it should be priced to sell, not to just sit there. Otherwise it's the same thing as putting a sell price on a lot and waiting for months or years. The auctions need to keep moving, rather than clogging up with overpriced parcels being re-listed. If the high bidder is below the seller's minimum bid, the seller should be offered the opportunity to sell at that price or decline. If they decline, it should cost them something. At a minimum, they shouldn't be allowed to relist that parcel at that price for some months. Has to drop at least 10% to be re-listed. Sale prices and unsold property non-sales should be public, so stats can be accumulated. Then we can have a price estimator like Zillow for Second Life. LL might offer a listing of parcels for sale at set prices, for sellers who want to do that. A Land Marketplace.
  15. Link messages seem to be completely reliable unless you overflow the event queue for a script. The queue for each script has a capacity of 64 messages. Exceed that and you lose link messages and other events, with the newest events being lost. I've tested this, and it really is exactly 64 messages. Remember that link messages are broadcasts - every script in the prim gets all link messages sent to that prim. So mixing high-traffic messages to fast scripts with low-traffic messages to slow scripts in the same prim can cause trouble. If you delay too long in a script, with llSleep or many calls to built-ins with long delays, you can lose messages. Also, every script that accepts link messages must always have enough free memory for the biggest message sent to its prim by any script, or you will get a stack/heap collision. Within those constraints, all problems I've had with link messages have been from problems in my own code. I'm running an elaborate NPC system with heavy message traffic which will time out and send error messages if it loses a link message, and it's not reporting such errors. I'm not sure about listens. They have throttling rules and a filtering system. Anyone know for sure?
  16. I didn't know that history. Is that the story behind this sign? Around Zindra, there are other remnants of that effort - the mall in Mosh, the Zindra Alliance tower, the Zindra Help Vortex sandbox. Things seem to be looking up in Zindra in and near Kama City. In the past month, I've seen five new gas stations, one a GTFO hub. Zindra hasn't had GTFO before. People are moving in and setting up non-sex businesses. I'm seeing more people show up at my workshop. Southern Zindra, which is more suburban and has less mole work, has a huge amount of land for sale or rent.
  17. Not really. Somewhere there's a timing related bug. Anything which affects region crossing timing can affect region crossing success. This creates the illusion that user behavior or vehicle behavior or some performance related change in the code might be the problem. The real problem is that it's timing sensitive at all. We know it's timing sensitive because it's possible to force serious region crossing failures by adding network lag to the viewer using network testing tools. I've done this on the beta grid and made videos for a JIRA. Conversely, you can do some things in vehicle code that help. But you can't totally fix the problem from the user side. I've tried. So have others. Almost everything else in SL is reasonably delay-tolerant and does not fail fatally due to race conditions. You may get some performance degradation, but even with a second or two of network lag or sim overload, most important things don't break. That's impressive. But not region crossings. Those are brittle. They need to be more robust. (Early in my career, I spent years finding and fixing timing related bugs inside a major mainframe operating system. So I've been there and done that. Not fun. But sometimes, you just have to do that. It takes people time and money.) (I've said my piece on this. It's up to LL management now.)
  18. Yes, been past there many times. When I want to relax, I sometimes drive all the way around central Heterocera on that route. But I never went inside the MoleMart before. Useful road components available there for free. There's a list of some of the locations where more free landscape items are available, for when you need to match a mole build. "The locations are: the railway station in Bay City, with content packages for constructing buildings there; the boat house in Half Hitch, with textures and objects to use around the seas; the Mole Mart, with various "general use" items; and the market in Nautilus, with objects and textures to help decorate and extend your Nautilus home." There's also a mole outlet in the mall in Mosh where you can get Zindra streetscape items. Any others?
  19. What are you using? There will probably be someone here familiar with it who can help. Modeling this isn't that hard. Model the outside walls as a floor plan. Extrude upwards for the wall height. Add a floor to fit. Allow a small gap, about 0.05m, between floor and walls, because the uploader's concave object decomposer is not too bright, and tends to cut up concave forms in strange ways. It does better if you use simple convex geometric forms. Add a ceiling to fit. Same rules. Make a big solid object with a triangular cross section for half the roof. Make two more, cut to almost but not quite touch the first, for the cross-roof. You can't use the attic, but probably didn't plan to anyway.
  20. I don't consider this a problem impossible of solution. It's just one that's expensive to solve. I've had a long career in Silicon Valley, and have some idea of what I'm talking about here. Here's what Linden Lab is facing. They have a huge system written in C++. It's a real time system. Those are rare and outside the experience of the average programmer. It's a big, distributed, real time system. Those are even rarer. Probably less than 1% of programmers have ever worked inside anything like the sim side of SL. It's not anything like web services. The protocols are different, the constraints are different, and there's much more persistent state. (The web works even with bad code because you can reload pages and restart servers freely. The one part of web servers that really has to be reliable, the database, is a solid technology decades old. SL is not like that.) Thus, the huge pool of web programmers does not provide good candidates for working on SL internals. SL is a unique system. There is nothing else like it. A new hire can't ask questions on Stack Overflow. There are no books on the technologies used. For almost everything else that's really hard, from machine learning to self-driving cars, for Hadoop or Rust or UE4, there are books, courses, and conferences. Not for working on SL. There's no external support. It's not even much like a standard massively multiplayer online game. Those are typically a standard game engine in the client, with a single server managing a shard of the game world for a small number of users. SL is a huge cluster of tightly coupled machines with a lot of coupled state. Anybody who works on SL has to be a good C++ programmer who can figure out code with few comments. The original designers are long gone, the internal documentation is limited and incomplete (you can read the message format documents, on the wiki, to see this), and, judging by the viewer code, the code is not extensively commented. This is what technical debt looks like. Some of that technical debt has to be paid down. The sim to sim protocols need good analysis tools, error checks, and documentation of all the states and how they change. You have to have an unambiguous definition of correct operation and a way to check for it to find and fix incorrect operation. That's months of work. The upside is that whomever does this will really understand what's going on, and hopefully document it so the rest of the team does, too. There are programmers who can deal with that. In Silicon Valley, they are very expensive. About $200K a year in San Francisco. (Yes. Look on a job site like Glassdoor for senior C++ jobs in San Francisco. The average apartment in San Francisco rents for US$3400/month.) Someone who can do this could sail through an interview at Google or Facebook. Someone who takes that job is taking a career risk. They could get into a growth area like self-driving cars or ad targeting, where there's a next job around the corner if this one doesn't work out. Experience inside SL doesn't directly translate to a job anywhere else, which, in an industry which wants people productive on day one, is a big problem. So it can be a career setback. That means LL has to pay extra money. Or you could hire some juniors and train them up, which would take six months to a year before you could trust them on anything critical. They'd start at maybe $100K a year. If they're not making $150K two years in, they're gone. And you have to manage them, which will take at least a quarter of the time of a senior developer. You can try remote work, but it's risky with something this tightly coupled. Fixing region crossings probably costs a year and about US$500K. That's the problem.
  21. Don't blame a user. I've documented failures, filed JIRAs, posted videos of repeatable region crossing failures on Vimeo, put logging of sim to viewer messages in Firestorm and put the results in a JIRA, put logging in vehicles and had them log failures to a server and published the statistics, and gone to Server User Group for a year to complain. Region crossings are still broken. No additional effort from the user side can help much. It's a sim-side problem. Sometimes, we don't know why, some component of an avatars/vehicle/attachments set doesn't make it from one sim to the other. That's what a failed region crossing really is - some parts made it and some parts didn't. You're stuck partway through the process, and re-connection of the components can't take place. So you're stuck. With enough logging added to the viewer, some of us have seen this happen in the message traffic to the viewer. But we can't find out why. As users, we can't see what went wrong sim to sim. That's LL's job. (There are other problems with region crossings that don't involve a total fail, like those nose dives and rubber banding. Those are separate bugs.) The elephant in the room is this total region crossing fail bug, the worst breaking of immersion in Second Life. This bug devalues mainland, inhibits large-scale roleplay and events, and limits free movement in SL's big world. As far as I can tell, there are only about two developers deep inside the sim system at LL, and they're the same ones working on EEP, the conversion to AWS, the sim overload problem, and any new bugs that come along. LL has too few people trying to do too much. Fixing this requires several more really good C++ programmers and more money.
  22. Just sent in a ticket on this. When I logged into Vallone sim, the sim seemed fine, but it had become an island - water on all sides, and couldn't walk out. I logged out and logged into the adjacent sim, Charlesville. Everything looked normal; I could see into Vallone, and could walk into Vallone. But my escalator steps were slowly advancing into the sky instead of staying with the escalator, indicating broken keyframe animation. Tried logging into Vallone with the LL viewer on a Windows 7 machine, instead of the usual Firestorm on Linux. Broken in the same way - surrouned by water, can't get out. Got the message "Your clothing is still downloading", and about half the objects in the sim were missing. Persisting for at least 20 minutes now; it's not just the neighbor regions are restarting. Anyone else seeing this? The world is missing.
  23. Seems to be a bug in Firestorm 6.3.2. As far as I can tell, the "Stop" option for "Movement at Region Crossing" no longer works. It's BAAACK! We had this fixed. But some people didn't like the hard pause at region crossings. Above the ground, below the ground - still broken. Short version - at every region crossing, there's a short pause while one sim process hands over control to the new sim, which implies copying a lot of data across a network and some handshaking with the viewer. SL viewers try to guess what's going to happen during the pause, to make region crossings look seamless. The guesser is not very good if you're moving faster than walking speed. I put a fix in Firestorm to not guess at all. That's "Stop" mode, and it's been in Firestorm for months. It's good for fast vehicles, and really bothers some people with slow boats, because it looks jarring. LL picked up on this and put in their own fix, which is the old guesser with a new time limit on how far ahead it can guess. When Firestorm picked up that code from the LL viewer in 6.3.2, that apparently broke the "Stop" setting. Hence the pictures above.
  • Create New...