• Content count

  • Joined

  • Last visited

Community Reputation

11 Good

About animats

  • Rank
    Advanced Member
  1. Avatar goes running when left alone

    SL doesn't seem to fully recover from some kinds of packet loss. Check those colored bars at the top right of the viewer window. One of them is the packet loss rate. If it goes red, things may start to go wrong.
  2. That's nice. It shows the direction Sansar is going - big experiences created by big companies for marketing purposes. Star Wars is a Disney property, so if this goes well, there will probably more Disney presence in Sansar. Lucasfilm has been trying location-based VR, says Variety. Opens December 16th in Orlando and London. Jan 5th in Anaheim. This is the cost-is-no-object VR experience. One play costs $30 and lasts about half an hour. The gear costs about $10,000 per player. The space has walls and objects that match the virtual environment, so the players can reach out and touch things, pull switches, and such. Looking forward to reports of how that works out. If enough money can make it good, there's a market. Then soon it will be cheap, and still good.
  3. Trouble with microphone

    In Alchemy, I get the message "Could not connect to the voice server" at startup about one time in three. I only have 6mb/s bandwidth. I suspect that the problem is network overload. When you start a viewer, there's an enormous network load as it starts up and loads all that content. After startup, load goes down.This network overload may interfere with the initial connection to the voice server. The voice server connection code should probably do a few retries before giving up. It gives up within seconds of login, which is too soon. If this is intermittent, that's probably the problem. The developers may not be testing this on low-bandwidth connections.
  4. I've seen that too, working on my own script for my own simple test vehicle in a mostly empty sandbox. I had to create a new script, copy the text from the old one, paste it into the new one, delete the old one, and rename the new one. Then the script worked again. "Reset scripts" didn't help. I'm doing a lot of region crossings in tests, and that may affect this.
  5. "Sex anywhere" systems

    There are several "sex anywhere" systems available in SL. There's "Arousal 2.0"/"Sex 2.0". There are all the VAW "sex HUDs". Anybody using those? Why haven't those replaced all the sex furniture? And does anybody have a system where each person measures themselves once and then everything just fits and lines up?
  6. Strip Clubs and Escorting

    Why would anyone pay for sex in SL when it's so easy to get for free?
  7. I really didn't want to get into the internals of the viewer. But here's the viewer-side problem. Look in around line 2505. There's the predictor which extrapolates moving object positions during lag: // Calculate predicted position and velocity LLVector3 new_pos = (vel + (0.5f * (dt-PHYSICS_TIMESTEP)) * accel) * dt; LLVector3 new_v = accel * dt; The code above is guessing, in the absence of update messages, where the object now is. Mostly that works. But when you cross a region boundary, there's often a small change in position, and probably in velocity and acceleration, followed by about a second of no updates. That code amplifies any small change followed by lag into a huge change. There's no bounding, other than some code which prevents huge out of range values, and no low-pass filtering. There's code that stops motion after no updates for a while, but that takes seconds to kick in, because the sim doesn't send frequent updates to the viewer during normal motion if the normal motion isn't changing speed and direction. The viewer assumes that no update means keep going in the same direction at the same velocity, with acceleration applied. This is purely visual; you'll see it in the viewer, and when the next update comes in, the position will come back to where the sim thinks it is. With velocity interpolation off in the viewer, that doesn't happen, but movement becomes jerky. Try turning off velocity interpolation in the viewer, which lets you see just the positions the simulator send sends you. Walk your avatar in a straight line. You''ll move in big jerks, several seconds apart. That's the don't send an update optimization in action. Now try walking while turning. This forces the simulator to send frequent updates, and the viewer will now update rapidly. There are real glitches and stalls at region-crossing simulator handoffs, but they're usually not that big. I've been testing with velocity interpolation off. This viewer artifact makes them look much worse. Then the user makes bogus steering corrections in response to the bad imagery, and screws up the real position. What's needed is something like a Kalman filter to maintain a smoothed velocity in the viewer, to be used for interpolation. Maybe clamp velocity to a low value during region crossings.
  8. I realize that. But try turning off "Velocity Interpolate Objects" and watch what happens. I've been testing in a large multi-sim sandbox island with little or no construction or activity, to see a clean situation. After waiting for everything in the sim to reach the viewer, network traffic finally drops off and there's little lag. With Velocity Interpolate Objects off, walk the avatar, holding down the up arrow key. The avatar will be stationary for 10-15 seconds at a time. That's because the server doesn't send frequent updates to the client when the avatar is moving in a straight line. Let go of the up arrow key, or turn, and the avatar is updated immediately. Usually, you don't see this effect, because the movement "interpolator" (really an extrapolator) hides it. This makes avatar movement look much better. Now try a fast vehicle across the sim boundary. Usually, there's about a 1-second pause and a rise of about 1 meter maximum. That's good; that means the server side is doing an OK job. (Sometimes the sim does come unglued, and you get messages such as "llStartAnimation: Script trying to trigger animations but agent not found". This is a known problem since 2013. There is a known workaround for vehicle scripts. That's all server-side. But flying through the air after crossing a server boundary and then coming back to normal is a client-side problem in velocity interpolation. That could be fixed in viewers. Since there are non-Linden viewers, it can be fixed without help from Linden Labs.
  9. I've been looking at why vehicle behavior when crossing sim boundaries is so bad. One problem is viewer-side. The effect where vehicles go flying off into space at a sim crossing and then come back is a viewer-side problem. Whatever extrapolation algorithm "Velocity Interpolate Objects" uses is flawed, at least in Alchemy. Try driving a vehicle at moderate speed over a sim boundary on a connection with some lag. You'll probably fly off into space and then come back. Now turn off off "Velocity Interpolate Objects" in the Develop menu, and repeat. Now you stall for about a second when crossing a sim boundary. That shows what's really happening back at the servers. Is this a problem in the SL browser, too? (I'm on 64-bit Linux, so I can't run the SL browser easily.) Please check, so a bug report can be submitted. The extrapolation algorithm needs to be fixed. It needs clamping, or a low-pass filter, or it may even be differencing two positions from different sims and getting some huge velocity. Or it may be a straightforward math bug. Extrapolation from derivatives is always touchy. But those huge bogus velocities that rubber-band back to normal are a viewer-side problem. Sim-side screwups don't return to proper positions. See, for example, [1]. This is the kind of bug that doesn't show for devs working on high speed connections with low lag to the servers. (There are other server-side problems at sim crossings, most reported about ten years ago and not fixed. But this one is viewer-side and probably not hard to fix. [1]
  10. Does LL want to fix SL

    Yes, the virtual-experience VR market is crowded. The problem with SL as a business is that users need a lot of free time. This limits the market. Sansar is go in, have the experience, go out. It's like the difference between Everquest and Angry Birds.
  11. "Kama City is one of the 3 largest urban structures of the grid. ... capital city of Zindra ... From all urban places, Kama City is the most populated of all." - Second Life wiki. Kama City looks quite impressive at first. Roads, traffic signal, monorail tracks. But very few avatars. It's such an empty place. Where there are people, they're often in a skybox. Or they're dummy accounts running dancers or sales reps in empty nightclubs or stores. The real estate situation is dysfunctional. Most of the buildings are empty dummies owned by Love Life or some other big realty agency trying to sell them. Nobody even rents them. Four abandoned parcels recently went up for sale. I bought one, a friend bought one, and the other two were bought by real estate flippers who immediately put up For Sale signs at twice the price. Next door is a large temple in a combination of Indian and Moorish styles. It's empty and for sale. Real estate is far overpriced for the demand. This makes no sense. Maybe Linden Labs should adjust the tier rates to make land-hogging unprofitable. Don't offer discounts on tier for owning large amounts of property unless the properties are contiguous parcels. That would eliminate the advantage real estate brokers have, while allowing large projects to get a discount. Anyway, I set up a small outdoor cafe in Vallone. It's a technology demo - you can knock all the furniture around, and when everyone leaves, it will all return to normal. Or you can just sit at a table and enjoy the fountain. Few people will ever walk by, but it looks nice.
  12. Fixed the problem by talking to the neighbors. Object entry ON, scripts OFF was just a bogus setting that they were given after a land auction. That setting breaks other things. If there are wandering birds or cats around, they'll die when they cross a property with those settings. So don't set your property that way. To see this working, visit my little cafe at Vallone/240/21/36. Sit in one of the chairs and enjoy the fountain. Then wreck the place. All the furniture, plants, and bottles can be knocked around. When you leave, everything goes back as before. Use weapons if you like. Let me know of any problems. Thanks.
  13. OK, the normal cases work fine. I've been able to deal with region crossings. (Turn PHANTOM and PHYSICS on, apply a velocity towards home until in the right region. Then use llSetPos.) But I've found a case that doesn't work. There are some problems if the object goes into another parcel with certain settings. A parcel with total keep-out for other objects is fine. The object hits the permissions wall, doesn't enter the parcel, and the script brings it home. But if the permissions are set to Object entry for Everyone ON, Run scripts for Everyone OFF, the object can get in, and then its come-home script dies. This leaves the object stuck, perhaps in mid-air, in phantom mode.The property owner or the object owner can return or delete it, but otherwise it's stuck there. Other than that, it's looking good.
  14. Sitting pose height

    Get an account on the beta servers. No upload charges.