Jump to content

animats

Resident
  • Content Count

    2,348
  • Joined

  • Last visited

Posts posted by animats


  1. 14 hours ago, Kurshie Muromachi said:
    • There is nothing such as procedural vegetation or SpeedTree in Sansar. The vegetation you see in the picture was created by a user.
    • I agree with other SL members that avatars are... to put it lightly, not the greatest. Although, it appears (having watched Discord) that some frequent creators within Sansar think the avatars are fine. To each their own I suppose.
    • Avatar motion is crude at the moment and feet placement can get weird at times depending on surface. Sansar users are awaiting animation capability.
    • There are people making such stuff. At least with dresses, skirts, etc. Thing to note is that clothing items are baked once you complete your look and rez back in world. So, draped type stuff, or any cloth physics for that matter, don't physically react in world. Apparently, that is to come later but their focus for now is getting user retention and engagement worked out.
    • Inara Pey has a summary posting (including an audio byte) in regards to the thing about LL's consideration of an engine such as Unreal.

    Thanks. That's even worse than I thought. It's embarrassing. There are Unreal Engine MMO games by amateurs that look better. A virtual world is basically an MMO with user building tools. Here's a 3 year old Unreal Engine demo.  Sansar should have looked that good.

    A new virtual world needs something like SpeedTree to fill it with nature. When you want to build something, you start by clearing the land, just like real life. Then the world doesn't look so empt at startup. High Fidelity starts out with a big, empty grid, so it looks deserted.


  2. I watched that video. They're still years behind modern video game quality.

    • Sansar has good vegetation. It looks like they licensed SpeedTree, the procedural tree, grass, shrub, and flower generator. Everybody licenses SpeedTree for games. It could potentially be in the SL viewer. It's mostly viewer-side; you tell it "put tree here" with some parameters and it generates a tree. Each tree is different.
    • Why are Sansar avatars so fat? Possibly because they're using convex hull collisions, which are really fast to compute.  That can't handle a narrow waist.
    • Avatar motion in Sansar looks no better than in SL. In the demo video, they can't even keep the avatar's feet on the ground. There's jerky motion of other avatars. The guy on the Golden Gate Bridge walks right through the railing.
    • The fashion release doesn't show anything that drapes.

    It looks like LL really did roll all this themselves, instead of licensing Unreal Engine or one of the other good game engines. Unreal comes with full source, so splitting it into server and viewer is possible.


  3. 7 hours ago, Theresa Tennyson said:

    Some time ago there was a book called Motel of the Mysteries, which is set in a future time when an archaeologist digs up a 20th century motel that was buried by a cataclysm and comes up with spectacularly inaccurate explanations for what he finds.

    Your posts remind me of that book sometimes... The Dunkin' Donuts store was almost certainly made by somebody who felt like making a Dunkin' Donuts store and has no connection to the real-world business.

    I read Motel of the Mysteries. And yes, SL does feel like that. You look at something built by a user long gone, and admire, or wonder why. Many thousands of hours went into building those abandoned places. It's like touring roadside America. Or Cars, the original movie. I do go to busy places and belong to groups, but I also like to check out the scenery of the big world.

    The Dunkin' Donuts shop is clearly a fan project when examined close up. At one time, there were big companies with a presence in SL. It was going to be the next World Wide Web, the next Myspace, the next Facebook. Most bailed long ago. This might have been a remnant of that era, but it's not.

    Aldrin, above, commented that "I have to wonder how many people are ever really logged in to SL. ... I really wonder if there are ever more than 10,000 real people logged in at any one time, and if SL is in fact largely dead." That's what prompted my response. He may be right.


  4. Think of Sansar as a way to make stupid YouTube videos easily, and it starts to make sense as a business. Look at Twitch.tv. Read about their scale and revenue. Twitch.tv is about 40% of the live streaming traffic in the US. And it's just people watching other people play video games. Sansar TV needs to go live, not just upload to Youtube. With ads, of course.


  5. 14 hours ago, BilliJo Aldrin said:

    I have to wonder how many people are ever really logged in to SL. So often I search for active clubs to check out,  I get there and there are a dozen or 20 avatars parked in the sky at 3000 meters inflating the traffic numbers. I assume those are all logged in and counted in the total, but I really wonder if there are ever more than 10,000 real people logged in at any one time, and if SL is in fact largely dead.

    Driving around the mainland, the number of non-bot active avatars is very small. Dunkin' Donuts still has an outlet in Bay City with a 'bot making donuts. I wonder if the company has forgotten about it.

    Boating is strange. I have a fast boat, and started going to green dots on the world map to see what other people were doing with boats. They're avatars standing at the bottom of the ocean. Almost all of them. They don't respond to IMs.  Anyone know what they're doing? It takes resources to stay logged into SL. Why stay logged in and do nothing?

    Sansar's design, of disconnected "experiences", may reflect the failure of Second Life continents. What action is left in Second Life is in contained areas - islands or skyboxes. For that, you don't need the big continents and their management problems.

    Second Life has become feudal - each land baron has an iron grip on their own territory. Sansar is feudal by design. "Experiences" have single ownership. Some SL real estate operator just bought their own continent.


  6. After two months in SL, I haven't seen much petty rudeness in SL from avatars. I've been in the steampunk regions, the newbie regions, the adult regions, and the biker regions. Just not a big problem. There's some snarkyness, but that's part of the fun.

    Real estate, though... I'm really annoyed by those "eject from your property in zero seconds" security orbs, ban lines that trap avatars, and "object entry allowed, scripts cannot run" parcels. That's  griefing.

    • Thanks 1

  7. I realize that. I've been to small, busy places, but I wanted a sense of the big world. It's amazing and sad that so many people built so much stuff, and then left.

    Here's the end of the road trip

    .simclairstn_004.jpg.5d9e8238d5d561c9c9d30cace8435e1a.jpg

    (Come on, LL, put something at the end of roads. A barrier. A MoleMart. A "Dead End" sign.)

    • Like 1

  8. I've been working on making vehicle sim crossings work better.   I can now drive fast around SL for two hours with few problems. So I'm looking for some good road trips. Any suggestions?

    I've driven around the Circuit de Corse. That's great. I've driven around Heterocera, which has some good spots.  I've driven across parts of Sansara, most recently the region around the airport in Bradmoor. (In Sansara, I've enountered three bots, two AFKs, an abandoned hearse in the roadway, and no active users. The mainland is deader than I expected, even though 34,000 people are logged in right now.) I've explored Kama City. What am I missing?

     

    simclairstn_001.jpg

    • Like 1

  9. Typical real-world size information for objects in Second Life

    All dimensions in meters. Data from various architectural sources.
    Rounded off to 0.005m.

    Furniture

       Dining table height     0.750
       Chair height            0.460
       Kitchen counter height  0.915
       Bar height              1.010
        
    Buildings
     
        Door height             2.135 (Real world. SL tends to run bigger due to oversize avatars)
        Door width              0.920 (ADA compatible)
        
        Brick dimensions        0.100 × 0.070 × 0.200
        Cinderblock dimensions  0.410 × 0.200 × 0.200
        Stair tread height      0.180
        Stair tread spacing     0.280

    Brick and cinderblock dimensions include mortar, so these values are suitable for repeating textures.
    Stair tread spacing is a minimum

    New Babbage, New Berlin, and Mopire City are built to realistic dimensions. The New Berlin people are behind that avatar height measuring post found around SL.

    Avoid oversized brick textures in urban areas; it makes your building look out of scale. Steps with non-standard tread height just look wrong.

    Oversized doors and high ceilings are OK if you don't overdo it. A 2.5 meter door will allow 8 foot avatars. If your avatar can't fit through a a door of that height, your avatar is too big.

     


  10. 4 hours ago, Callum Meriman said:

    I am not convinced those vehicles can recover from it, they are exhibiting other issues due to lousy design that could be confused as the same fault, I don't think it is.

    Can you be more specific? Have you tried a Murasaki vehicle? I suggest the motorcycle or the dune buggy. I've seen both of them go through a clear multi-step recovery sequence, as I've described. I've never seen that fail except at a four-sim intersection, and I've spent about an hour and a half driving those things around.

    Here's what driving looks like with these fixes: https://vimeo.com/249634075

    This is going too fast for safe driving, but shows what it looks like to drive around 80KPH in SL.

    • Like 1

  11. I've been communicating with a builder of military vehicles in SL, and he points out that the vehicle may be able to move the avatar across a sim boundary with llSetRegionPos(). That may be how Murasaki does re-seating. But that LSL call has a distance limitation. It won't move an object more than 10m outside the sim boundary.

    The rail car, unlike most vehicles, keeps going until you tell it to stop. You don' t have to hold down a key to keep it moving. So, when an avatar is unseated from the rail car, the rail car may be too far away in the next sim for the avatar to catch up and be re-seated. This is also a problem with heavier boats, which take a long distance to stop, and I've seen this happen once there. If that's the problem, there are ways to overcome it.

    For the military guys, this is a big issue. There you are, in the middle of a battle, and suddenly you fall out of your tank or off your torpedo boat. You're dead.


  12. (To recap, what we're working on here is a very hard case, hitting a double sim crossing at high speed. The regular case of just blasting across sim crossings is already working. Yesterday I spent about an hour riding a Murasaki motorcycle while running in the modified Firestorm viewer , and never had a serious problem.)

    I'm now able to get the same failure in both the modified and release Firestorm viewers. What makes a difference is how recently the region was crossed, not which viewer. When I wait a few minutes, launch a viewer, start at http://maps.secondlife.com/secondlife/Aglia/161/142/85, and head northwest in a Murasaki railcar at speed 4, a partial unsit happens almost every time. if it doesn't happen, driving back and forth through the sim crossing does not fail. This probably means it works better when some info is in cache.

    Before, I thought it was something I'd broken, because I'd test with my viewer, find a problem, and immediately rerun with the release Firestorm and not see the bug. But apparently not. It's more related to how recently those regions crossings were made. 10 minutes between tests seems to be enough for whatever is being cached sim-side to time out.

    After the failure, the avatar is in a sit position above the tracks, and the railcar continues down the tracks by itself. Not too far; after a while it disappears but is not returned. There's no "Stand" button. Movement cursor keys do nothing. But there's a nearby scripted sittable object, a rope, and clicking "Sit" on that.causes a rope climb. After that, the avatar has been returned to normal.

    If the avatar is just left to sit there, after a few minutes, the top left menus in Firestorm stop working. Bottom menus still work. It's like event processing is stuck and the queue is full.

    I have Firestorm logs of all this with Debug level logging turned on. Anyone good at reading those?


  13. I'll have to try that location.

    Murasaki Creations has figured out how to recover from most half-unsits. How remains a mystery. I've sent them IMs in both English and Japanese, and am waiting for an answer.

    I'd looked into doing recovery like this, but I was thinking of using llUnsit to get a clean unsit, then move the avatar to the vehicle, then use RLV to do a force sit. Their approach is better.

    The half-unsit situation seems to be when the avatar is in one sim and the vehicle is in another, but they are still linked. This isn't a valid situation. But apparently the vehicle still has enough of a link to the avatar to do some things to it.

    Moving something across a region boundary from a script is possible. I have a script which does this on all the furniture in my little cafe in Vallone. If you knock over the furniture and bottles, they roll around, and when there's nobody around, they all return to their place. This works even if the objects are outside the region. You can't use llSetPos to cross a region boundary, but you can use llSetVelocity to move objects across regions. So that script recovers objects by turning Physics off and Phantom on, then applying a velocity towards their home position. This gets about 10m of move per call, and the object can move through other objects. Soon the object is in the correct sim and near home. A final llSetPos puts it back in place, and Phantom is turned off, returning the objects to normal solidity.

    Murasaki is probably doing something like that. The big questions are 1) how do you detect the problem, and 2) which LSL calls work on an avatar with the permissions you get from sitting. I didn't think the vehicle had enough permissions to do all this, but maybe it does.


  14. 2 hours ago, Callum Meriman said:

    I think another way to check this could be a script dropped in the vehicle to report substantial changes between the root prim and avatar "prim"

    I have a vehicle scripted to report that. On some unwanted unsits, the distance between root prim and avatar increases drastically, and on some it doesn't. Puzzling.

    How do you do a reseat from a script? It's not supposed to be possible to force llSitOnLink() unless you're an "experience", according to the wiki.  But maybe it's allowed in more situations. If a script has PERMISSION_TRIGGER_ANIMATION it's reasonable to allow llSitOnLInk. Then a vehicle script could do an unsit followed by a sit to clean things up. it's also possible to force a sit via RLV, but that requires more permissions.

    As for the rail car, I've now had that failure occur once with the current release Firestorm, without my mods. So I didn't break it entirely.  I'm trying to establish communications with the author of the script, but they may be long gone. They also say in their profile that they speak Japanese only. Nobody else seems to have this capability in vehicle scripts.


  15. I'm chasing down an obscure bug in this.

    Murasaki Creations has a range of vehicles which recover from almost all serious sim crossing failures. You can get demo versions of them at their store. (Visit; it's a lot of fun,) They can handle the "unseated at sim crossing" problem. It's amusing to watch. Sometimes, at a sim crossing, the driver ends up on the ground. When that happens, there's a delay of a few seconds. Then the driver gets moved to the vehicle, but isn't seated properly. About two seconds after that, the driver gets seated in the right place, but isn't animated. About two seconds after that, the animations turn on, and you can drive off. This works very well.

    But near a sim corner, where four sims meet, with my browser fixes, sometimes the recovery fails. The avatar ends up on the ground, unable to move. The vehicle is still in place on the ground, or driving off by itself. After a few seconds, the vehicle disappears.  It's not returned. A teleport will free the avatar. But until the next logout, the avatar takes 10 seconds at every region crossing instead of the usual half-second. No idea why. Most likely, the sim is looking for some essential but nonexistent asset, like the vehicle or a part of it, then times out.

    Fortunately, I can reproduce this bug with a little rail car from Murasaki. Since it's running on tracks, it hits the sim crossing the same way every time. Here's the test spot where I hit two sim crossings very close together: http://maps.secondlife.com/secondlife/Telea/250/0/83. If you want to try this, get one of the free Railstar work cars from the vendor at Murasaki Creations. Go to the SLRR res area nearby at http://maps.secondlife.com/secondlife/Pini/139/59/94 rez the work car and head east. The trouble spot is next to a small platform with a hole and rope.

    I'm curious about how they do the re-sit in the vehicle script. I didn't think an ordinary script could do that. An "Experience" can do a llSitOnLink, but regular scripts can't do that.

    • Like 2

  16. 1 hour ago, Callum Meriman said:

    I know that only too well, driving around the continents as much as I do. It's quite a bit of training to teach yourself not to react to messed up visuals of the sim change, but to keep powering on in the roads direction. To ignore the mess on the screen for those few seconds. Sadly, even that can put you off the side of the road into a ban line, especially on twitchy vehicles.

    Oh, yes. One of SL's major bike builders told me that some people just can't handle that at all and give up entirely on vehicles. I can understand why. You just can't relax and let your reflexes drive. It's worst for people who have good identification with the vehicle. I was just out riding my real-world horse, which gave me a chance to think about the mindset here. My current horse is a big, sensible warmblood I can relax with. I've owned some hot Thorougbreds, and I could never relax on those. At any moment, they might suddenly spook at something. Driving a vehicle in SL is like riding a flaky horse. The horse, though, has good self-preservation instincts, which SL vehicles do not.

    I've been trying vehicles from Murasaki Creations in Burns. I just spent about half an hour riding one of their demo bikes. No unrecoverable problems. They have an amusing fix for the "unsit" bug. Unsits at a region crossing still happen; I had four in half an hour of fast riding. But the bike stops, and after about two seconds, the avatar is moved to the bike. First the avatar is seated badly. At that point you can drive again. Then the avatar is seated properly. Then the riding animation cuts in, and you're back to normal. Very nice. I made it back to the bike shop with the demo bike intact.

    With my Firestorm fix, their bike consistently goes where you point it. I just hold down up arrow, and make a steering correction every second or two. No need to worry about sim crossings.

    Quote

    This patch really is a benefit for road use, I doubt I can go back to the normal behaviour there. The patch is destined to become part of my standard viewer roll-up.

    Great!

    Quote

    The flying shadow x (from Dutch Harbor by the way) problem turned out to be the sim where I moor some of my boats not working for it only, rebooting that sim fixed the problem. Sorry for the false lead.

    Also great! That had me puzzled and worried.

    Quote

     

    I was able to sail on it from SNO down around Nautilus, and back last night, a simple, mostly straight route, and your patch worked flawlessly. The stop isn't as disconcerting as it is on the Pride of Baltimore, or the N+K Frigate (which is available for demo in Wicktro - but it's very advanced to sail, four sets of left right steering to cope with) on a small sail boat I can live with the pause.

    With all my testing, no unsitting yesterday, and only one camera loss which self recovered. That's something, if this new behavior helps.

    After this fix, it may be time to look at camera control.  A big part of the annoyance with the stop at sim crossings is that the camera doesn't stop immediately when the object it's following does. It closes up on the object being tracked, then falls back after the object restarts. The idea is to have smooth camera motion, but the effect is terrible when you're driving. This is worse with aircraft, because they're faster, and the camera often overruns the aircraft and turns around, totally disorienting the pilot. If the camera stayed in position relative to a boat, in open water you'd barely notice the stall. Same for aircraft.

    I pushed a new version of the Firestorm changes out to Github. With these, the sim doesn't stop animations and sounds, so movement sounds continue and flags and sails continue to flap even though the vehicle is stuck waiting for new instructions from the sim. This will help smooth out the sailing experience. I've tried it with the Destino cabin cruiser demo at Dutch Harbor, which is complex enough to take four seconds for a sim crossing. (That boat has a working instrument panel, shower and TV.) The most visible effect at slow sim crossings is that the wake changes. Please try that fix to Firestorm and let me know what you think. Thanks.

     

    Quote

    I notice there is a variable number of bounces in the llObject part of this (infos message) but as it's not world, I think that's not a problem. Walking into a void sim border and watching the logs is a funny thing.

    Good that you're testing that. As you've probably noticed, the sim crossing clipping and edge of world detection now use common code.

    Quote

    All in all, this is in the right direction, especially for motor bikes!

    It sure beats being blown off the road every two minutes.

    • Like 2

  17. 6 hours ago, Theresa Tennyson said:

    For research:

    Demos of popular high-end boats that can be tested across many connected regions: http://maps.secondlife.com/secondlife/Dutch Harbor/138/139/26

    Various free sailboats: http://maps.secondlife.com/secondlife/Dex/160/56/22

    Drivable demos of ground vehicles with very good scripts for long-distance travel in a region with well-developed roads: http://maps.secondlife.com/secondlife/Burns/240/50/64

    Demos and low-cost cars/motorcycles using the most popular ground vehicle scripts in a well-developed built-up area: http://maps.secondlife.com/secondlife/Gama/208/221/36

    Demo prop planes and helicopters testable over multiple regions: http://maps.secondlife.com/secondlife/Honah Lee Trudeau/127/116/22

    Free and rezzable demo combat aircraft testable over multiple regions: http://maps.secondlife.com/secondlife/Jadu/166/38/32

    A wide variety of free vehicles of reasonable quality (i.e. they aren't twelve year old crap): http://maps.secondlife.com/secondlife/Takes/177/119/23

    Thanks very much. I agree. I went to Dutch Harbor and tried a Laser One, the small but advanced sailboat. I need more sailing experience to evaluate that properly. But sim crossings were not much of an issue with the modified Firestorm I'm using right now (which is one rev ahead of the Github sources.).

    The Sumi dune buggies at Burns are great! Somebody worked through all the hard cases in scripting, like detecting an unsit and re-seating the driver. And they have vehicles with suspensions. Most land vehicles in SL are all unsprung weight and behave accordingly. Those vehicles work much better in the modified Firestorm than in the stock Firestorm. In the stock Firestorm, they go under the road, off the road, and then snap back. In the modified one, they slow down to a stop briefly and continue. Their little scooter, the Sumi Motochamp, gets pushed off the road at a sim crossing at  http://maps.secondlife.com/secondlife/Imperial/1/1/87  in versions of Firestorm with and without the fix. Haven't figured that one out yet. Their demo Jeep is great. I want to buy one, but can't find the vendor for that item.

    The Shelby Cobra from the place down the road is quite drivable, too. Again, it works better in the modified Firestorm. First gear is too fast for parking, though. This fix is consistently an improvement for ground vehicles. More later.

     


  18. 17 minutes ago, Callum Meriman said:

    First off, please let me clarify something @animats, I am all for any work that will improve vehicles accross the board. Please take any critisism you see from me as constructive, even if the wording sounds harsh. I'd love you to find a fix.

    Even with the broken code, with these very preliminary tests I did above -- the improvement in car, bike, and horse was very clear to me. Driving on a  road became far more enjoyable. At this early time I am thinking the patch could be a huge benefit to road users. Even simply walking between one sim and onother felt a little nicer without rubberbanding.

    My plan tonight might be to do the old atoll rally course and see if I can get through it with less problems than the current beta (firestorm compiled) viewer. Rubberbanding there was always a pain. Although I will revisit the Shadow-X when my crew can log in.

    ...

    But, I also look at this with the eyes of an avid sailor and pilot, and thats where I have just a little doubt right now, especially with how this interacts with huge ships, the tall masters.

    And another thing to recall is there are a lot of races on water. How will this affect a yacht race? Not just the performance of one ship over another who doesn't have the patch, but how competitors will feel with this substantial change.

    I'll keep posting in this thread as my testing happens and as i get more idea of your code - and maybe even suggest some patches too. Saves messing up the Jira for now.

    60 knots is an edge case and not so great for comparison at this point. I am talking under 12 knots for the tall masters, at that speed, on a 512 LI, 60 meter long ship, you didn't notice the rubberband. It was smooth as silk. Now there is a 10 second pause. 

    On a reasonably speeded catamaran - the Shadow X at 20 knots - the rubber band in about 10 meters, I can't speak for the pause yet as that boat doesn't seem to be running for me yet - I likely need to reboot that sim. I will see, and comment later.

    Absolutely, one careens under the road, or flies up in the air. What makes a car/bike/horse crossing worse is the forward rotation alters with bumps in the prims you are on. It makes you want to take your hand off the throttle as you cross and rubberband, then reapply throttle once you snap back.

    No doubting the benefit for road users - but this can't (early stage statement) be to detriment of a boat or plane user. A solution has to be there for everyone, even if it's a debug setting that enables it, or keeps the old. The debug setting can be brought into the phoenix button, quick menu, trivially then.

    Again, very early stage comments from me. I've simply not tested this enough yet.

    Good points. There's an inherent conflict here. Time does stop for an object sim-side during region transfer, while for the human user and the viewer, time continues to run. Something has to give. I chose to make the viewer track the sim as closely as possible. This is honest, and gets rid of many annoying problems. The velocity extrapolator was generating badly bogus results. You'd see motorcycles go sideways, into the air, into the road, through solid objects, and then snap back. The driver would reflexively make a steering correction based on the bogus motion they were seeing, and really screw things up. This is mostly a ground contact problem - water and air vehicles don't suffer badly from it.

    A solution that does what you want involves some degree of faking it on the viewer side. Let me try a few things. More later.

    This is all viewer-side, so it shouldn't affect races.

    I'm reading up on how sailboats work in SL. I suspect what broke the Shadow-X was seeing zero velocity in a script. The script thinks the boat is dead in the water, which messes up the sail calculations. I'm testing a version which doesn't do that.


  19. 2 hours ago, Callum Meriman said:

    Hmm, ok, I see what you do now, instead of the vehicle continuing to move interpolating it's current course, you stop it dead at the sim border while the handover happens, then resume. Similar to what the SLRR is doing in LSL on the trains.

    This leads to a pause of 1 to 10 seconds.

    Advantage, one can actively steer into a sim border and not spin out of control before the usual snapback.
    Disadvantage, it completely breaks immersion for those who can pilot properly. Especially on high prim ships.

    As this is pretty immersion breaking it's going to be a matter of personal taste. Leaving motorbikes out of this for a moment, a decent skipper will cross a sim without sudden movements, so won't see the spin much anyway.

    Test 1: Flying Shadow X - Broken completely. No longer works. I need to test more sailboats to find out why this has happened, but the Shadow X is a pretty unusual craft.

    Test 2: Boss Jetski - Works

    Test 3: Halob 8 Hovercraft - Works pretty well, the skid of a hovercraft could put you into a sticky situation all too often.

    Test 4: Pride of Baltimore - 7 second delay, this is a huge 193 LI schooner. Sim crossings are normally not noticed.

    Test 5: N+K Falcon Frigate - this is a 512 LI ship, the biggest complexity possible, as it's so slow and big one never notices sim crossings. 10 second delay.

    Test 6: SLRR SchienenMoped - SLRR has a scripted delay already, this patch doesnt seem to hurt it.

    More to come. 

    Try the new version; the one you have mis-clips when you cross a region boundary at an angle.

    The immersion-breaking problem is a classic one. I tried a 60-knot boat in the release Firestorm browser. When you hit a sim boundary, you overshoot and are yanked back. The velocity extrapolation keeps you going while the sim is stopped during the transfer. Now your position in the viewer is ahead of where the sim thinks you are. So it gets yanked back on the next update from the sim. Try it where you have some nearby objects for a reference to see this.

    But in open water, you don't notice the yank-back as much. Water mostly looks the same. This creates the illusion that you didn't stop. On land, you see the yank-back and it looks terrible.

    This was named the "surreal time" problem by Randy Farmer and Chip Morningstar, who did Lucasfilm's Habitat decades ago and were the first to hit this problem. The rate of time flow is inconsistent between the sim and viewer in some situations. This comes up in most MMORPG systems. It affects shooting of moving targets, which is a much bigger deal in gaming than in SL. In some systems, inconsistencies like that are drifted back into sync. Let me see what I can do.

    I tried a fix which keeps the velocity as seen by scripts nonzero while the vehicle is stuck at the sim crossing. This keeps the engine noise, etc. going while the vehicle is waiting for the sim crossing. That will need heavy testing to make sure it doesn't break something else. That might fix the Shadow-X. Its scripts are probably bothered by the velocity suddenly going to zero for no good reason.

    The Flying Shadow-X is l$2500. Is there anything cheaper that breaks?

×
×
  • Create New...