Jump to content

WolfBaginski Bearsfoot

Resident
  • Posts

    1,238
  • Joined

  • Last visited

Posts posted by WolfBaginski Bearsfoot

  1. The sim-crossing problem is certainly related to the general Mono-script problem. Physical vehicles need scripts, and however they come into the region, the Mono-problem applied. The Sim hesitated. Add the complexity of actual sim crossing.

    The Mono-2 fix does make a big difference. But I've also paid for some thoroughly awkward vehicles, things like scripted colour changes with no way to remove the scripts which do that. It makes for a lot more data to transfer from sim to sim, and that doesn't help.

    There's clothing items which do the same. There are better ways of handling the problem now, but a couple of years ago the onlt usable method was to put a script in every prim.

    As far as I've been able to find out. it things do run slow, you can temporarily be at one of several "wrong" locations within the new region, depending just where in the transfer cycle yoiu might be. And where the Sim thinks you are may have little to do with where your Viewer thinks you are. It doesn't help if one of those temporary locations is protected by ban lines or security orbs.

     

     

     

  2. I don't know what you plan to do next week, but I think you've managed to bust things big-time.

    The Mono-2 fix seemed to work, at least on Mainland.  Sim crossings were not perfect, but they worked. I was able to drive significant distance with only minor rubber-banding. But there was that scripting problem which was revealed.

    Since you fixed that, Sim-crossing has become as bad as it ever has been Sometimes sims behave as if they're just not there, and if the viewer doesn't crash, the only thing to do is log out.

    I count myself lucky if I can make a half-dozen sim-crossing without disaster.

     If you can't fix problems as basic as that, why should I expect Mesh to be worth the trouble.

     

     

     

  3. It is possible to run something pretty easily. Just google on simonastick

    That's a complete Windows distribution which can run off a USB stick.

    Without access to the Asset servers, it's a bit limited. It needs a lot of work to set up an environment, The scripting might be awkwardly different, sometimes. But you don't need any connection to the Internet to run the server.

    I can see it being useful for some things. I don't know how the land tools compare, but if you can do the same things with an SL Private Island, you can test the planned terrain before you ever have to start paying tier. 

     

  4. You obviously don't read everything I write about the Lab. It is not unknown for me to get a trifle heated. I can use  all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and... satire.

    I can make a few wild guesses about why this wasn't spotted earlier. And the communication could have been better. But they're getting a fix out, and I've not seen any sign of the fix breaking something else. So I find it hard to get emotional about this. I know enough to know that I have no chance of understanding the details. It's not impossible that the server code is a tangled mess of accumulated crud, which is the very devil to work on. I wonder if they even know enough to write the specification for a Server 2, in the way that they obviously did for Viewer 2.

    But this time, they are getting the job done. Which do you want? Grovelling apologies, or working code?

  5. The JIRA system is part of how they manage how they fix problems, so I don't see a problem with that. Some companies, we wouldn't even see that much information.

    It does seem strange that, with both pre-release testing and the RC stage, this wasn't spotted until it went out on main channel. But we don't know about the things which don't get that far.

    I reckon they're working pretty fast on this, but their communications could be better. Look at the notice on Status.

     

    Thinking back, I might have spotted something was wrong last week, but I was in a place where the script-load varies a lot anyway. But I was on the right RC and seeing high script times. 

  6. I've been noticing problems for nearly a week, and with different Viewers. It's great north-south strips not loading across the whole map. Sometimes the gaps are filled at lower resolution, sometimes not.

    I don't speak JIRA but I did put in a support ticket. 

  7. The estimate for my local County Show was 65,000 people.

    The timezone I'm in, I might not see the peak figure for SL, but I've known things start to feel laggy when things are that busy.

    Oh, and Baloo, about HTTP textures: other people tell me that turning it off will speed texture loading  It rather sounds as if changing texture-loading method is seen as a magic button, fixing the problems whatever the starting position in. And that just doesn't make sense.

    Oh, that must be the magic of SL that they were all going on about.

     

  8. OK, they're very different events. And the RL County event can handle far more people than the whole of SL can. But, several times, I was acutely struck by the differences.

    1: The County event is easier to navigate. Some parts of the show have been in the same place for decades, because they use specialised buildings and other permanent features. But there has been a consistent broad layout pattern for as long as I can remember. Certain types of trader have been in about the same place for over thirty years. Add to that clear signs and markers at the intersections of the grid pattern. SL8B has more detailed information in the coordinate system, but in-world it can be confusing enough to figure out which direction you're facing. "SL8B Marvellous" Which direction is that from where I am? It's a tricky balance in VR, because we do have maps. and maybe Landmarks, but after a few minutes of walking around at random, I felt confused. No sun shadows and (see later) no distant landmarks.

    2: The lag didn't help. There's no avoiding it, but it's likely that people with run on lower-quality graphics just to be able to move around. Which means they're not seeing distant objects. Frankly, texture-loading generally seems to be slower than it was a year ago. That changes the whole dynamic of display and signage. And if you're not seeing from a distance, the high-up signs might not be in the field of view when the wall does rez. The eye-catching features of reality just aren't usefully visible.

    3:  Ever seen a Show Catalogue? A list of every stand, and every event? I've found event lists, but they're lacking. They're just times and names. I'm not big on the dance-halls and DJs and discotheques of SL, and there was nothing I could see that meant anything to me. (I can't say the gesture-spam at the events I did attend was any help.) Yes, there's the section in the Destinations guide. That turns SL8b into a point-to-point teleport tour of the selected highlights, and rest of the show becomes irrelevant.

    4: While I remember the way the start was announced in the "Featured" blog, default on the Dashboard, and the amended details were hidden in "In World", including a different start-time, seemed a little careless.

    I'd sum it all up as poor communication Sometimes, it might be the stand designers, but I'm left with the feeling that the event, as a whole, hasn't been organised to make it easy for the visitors. 

     

     

     

  9. Yes, the non-existent region problem seems to have struck again, a couple of minutes ago, when crossing from Burandt to Miller, at the start of the road bridge. In fact, the scenery was slow to rez, then the bridge rezzed, and then everything vanished on the Miller side of the boundary, before I was translocated to Burandt (0,0,0), with nothing visible but a flat white plane, occupying Burandt region-space only, apparently with a snow texture.

     

  10. My AV  is maybe on the tall end of reality (not that it's exactly meant to be real), but I'm not one of the giants. In any case, we can have two distinct scales in many situations. There's the visual scale, based on avatar appearence, and scale effects arising from such things as Physics limits. Nothing can move faster than 572mph and that's an insane speed to try and cross a sim boundary at.

    Yet people making working models of rifles, and use them in simulated combat. The bullets move at around half that speed (there are quantisation effects), somewhere around 1/15 of the speed of a real bullet, maybe a dozen times the speed of an Olympic sprinter, so you have a lead a moving target is if it was a thousand metres away rather than a hundred,

    That sort of difference, weapon-effect scales and scenery scales, is commonplace in wargaming with scale models.

  11. I think something has gone wrong, but I'm not sure I have enough data to pin it down, and I don't speak JIRA

    1: All this has happened since the completion of roll-outs this week.

    2: In some cases, I know the Le Tigre RC server is involved. In other cases I'm not at all sure which versions of the Server code were involved.

    3: Both problems have been seen the current versions of Firestorm and Phoenix. That is, V1 and V2 codebases, both programs having worked well for at least a week before the problems started.

     

    Problem 1: A region becomes isolated from all adjacent regions, with nothing visible. I've had this happen with the Furness and Uzume regions.

    Problem 2: Region-to-region transfers, whether by teleport or by crossing the boundary, are sometimes incredibly delayed. This can lead to large-scale rubber-banding, up to 5km in one case  By the time it gets that bad, it's likely to fail completely, with the Viewer exiting. It's clearly worse with scripted vehicles, and I have some which are decent, some dreadful, for the number of scripts used.

    Problem 3: Failure to initiate a group chat session. There's a initialisation-error message in Firestorm. No message in Phoenix, but the chat session doesn't start.

     

     

  12. For the walking, I'd check Preferences, but it's not something I'ver ever come across.

    The Bridge is an LSL script that gives the Viewer some extra features, by adding ways of getting data from in-world. It's not fully matching what it can do in Phoenix, so it doesn't matter much for this version. The solution to this sort of  problem is to detach the Bridge and delete from inventory, and then re-log to a quiet sim. Firestorm should then create a new version. This is a sort of general asset-loading problem and that's a general solution.

    The only possible low-lag region I recall is Pooley. There are others. 

     

     

  13. I use Phoenix, and now Firestorm (Phoenix has a few features I find very useful which are not in Firestorm yet), and there's certainly been some bad behavious recently. Texture loading can be horrible. So this may not be a viewer problem. It's worth having a different Viewer available to check on thse things.

    I don't know how to change it in actual Viewer 2, but one common piece of advice I've heard is to try switching off HTTP texture loading. I infer that something isn't quite right in how the server-systems and the Viewer talk to each other.

     

  14. Finding Rez zones can be tricky, but there's a lot of navigable water on the combined Heterocera/Atoll continents. There's a new coastal channel on the North side of Bay City, connected via the ANWR channel to the Atoll continent.There's also a chain of connected small seas. though some of the channels are are a bit dodgy.

    There's also some deep-water seas south and east of the Sutherland Dam--really deep water that's good for submarines as well as surface ships.

    There's a Ban-Line HUD which warns of looming ban lines and shows possible rez zones

     

  15. Since there's a Warthog on sale on TurboSquid for $10, which has been there for several years, If the IPholders cared, how come they haven't noticed? Sorry, but I think the OP was careless. I don't know if this was the source, but it is so easy to find that I really hope the Lindens are not so prone to jump to conclusions.

  16. These restarts can even be helpful, sometimes. Maybe it's hard to tell, with the code changes, just what gets cleared up by the restart, but I've known "ghosted" AVs trapped at a region boundary (possibly some sort of Bot), and restarts clear that.

    I suppose it's hard to avoid awkward restart patterns, with multiple sims on the same machine, but it does seem to me that the non-RC restarts are too big a lump, with no easy way of predicting the timing. My home is in an RC region, and I've got a pretty good prediction of the timing. Looking at the Status lags, the RC rollouts look to fit into hour-long blocks pretty well (though you look to have started earlier than you'd announced on the 8th).

    So if there were three or four main-channel servers, code-identical but with different labels, and you announced that Block 1 restarts would begin at 5am, Block 2 at 6am, and so on, it would be easier to plan around. 5 hours is a big block of time to plan around, even if the time-block is off-peak.

    And I don't think it would ne a bad thing to have a few minutes of planned slack in every hour, a chance to take stock on how the roll-out is going. Is the current Main Release Channel block too big to properly manage?

     

     

×
×
  • Create New...