Jump to content

Fluf Fredriksson

Resident
  • Posts

    117
  • Joined

  • Last visited

Everything posted by Fluf Fredriksson

  1. I'm just sad that I had to spend half an hour reading forum posts and LL's answers to the forum posts to find out what the heck it all meant. Pointing people at a mile long TOS page full of legal jargon wasn't ever going to go smoothly was it?
  2. Now lets look at that as a non US payer who wasn't paying annually, who wants 2048m of land total... Quarterly payments will no longer be available so... US version: $11.99 per month premium + $7 per month land = $18.99 per month or $227.88 a year so (227.88 x 100) / 365 = 62 cents per day Non US version with 20% VAT: $11.99 premium + 20% VAT + 3% Transaction charge = $14.82 per month. $7 land + 20% VAT + 3% Transaction charge = $8.65. Total $281.66 a year or 77 cents per day. That's a very very expensive MMO. Most multiplayer online games are around $10 a month. 32 cents per day.
  3. Doesn't make it any less nuts. The price hike just made me go look at what SL was costing me. ¯\_(ツ)_/¯ I gain more money in my bank. LL drains some of the non-US payers out of the system (they already pay around 3% just to pay in $). It's all good. EDIT: Question for US SL premium payers ... Would you try and reduce what you pay to LL if it cost you 18% to 23% more on top of the price hike? Because that's what a lot of people outside of America are looking at.
  4. I think what they mean is .. they will deduct the VAT (sales tax) from the $99 annual fee they get and pay it anyway. But it's a sucker punch in pricing strategy. Anyone (outside of America) that wasn't paying the annual fee to avoid a larger lump sum payment, will now see it as an extra burden to pay monthly or quarterly. Best option? Go basic and drop the premium. It's a very USA centric strategy. But it gets worse .. if you dig into the cost of owning land in SL vs premium membership .. Say you have a premium account, you have 1024m2 of land, you decide you want another 1024. It's actually cheaper now to make a second premium account, group the two 1024m2 land parcels and take the L$ stipend than it is to have 1 premium account with 2048m2 of land. I haven't extrapolated how far this new crazy economic strategy goes, but it could be that the cheapest way to increase your land allowance up to a considerable size of land is to make multiple premium accounts (until the $ cost per land finally becomes cheaper than another premium alt allowing for the stipend pay back). A part of me thinks that's just ill considered pricing strategy by LL. Another part of me thinks it's a cynical attempt to make it look like more people are signing up and are online (you'd have to log in on the alts sometimes to transfer the L$ to your main account). Either way. It's highlighting the ridiculous cost of owning mainland in SL. Look at just about any mainland sim in SL and it's mostly empty abandoned land. It doesn't cost LL anything at all if you purchase some of that land and move on to it. They are already running that server. They are already paying that cost. You are doing them a favour. So the end result of LL's recent price hike for me? I'll probably reduce my land ownership to keep the annual cost down, and that in turn means I'll be paying less to LL than I was before the price hike, because doing both now seems too expensive for what I get out of SL. Slow hand clap LL "Well Done".
  5. Cheers & thanks to all LL monkeys involved. After the "random disconnects" nightmare fix, and now whatever you guys have been furiously hitting with spanners, sim crossings are about the smoothest I've ever known them to be. Whatever it was you guys did, it seems to have worked! Source: Approximately 350 sim crossings with only one "unsit bug". NOT BAD AT ALL!
  6. I sorta hoped this topic was dead. "Is it just me or?" ... Since LL rolled EEP back out to a few of the server channels .. (Hello Black Stars!).. Sim crossings have got more difficult again. No disconnects, but since the timeout is much longer now, you're stuck way up in the air for much.. much.. MUCH.. longer. Wave goodbye to whatever vehicle you were on, it's 5 sims+ away by the time you regain control. Yes, those were the golden times. That brief window you had between "We fixed the disconnects!" and "Here's EEP again!".
  7. As of April 25th. Yes this is fixed for both sim crossings and teleports. "This" is random disconnections on sim crossings or teleports. Having a problem crossing a sim boundary smoothly was not fixed and was not what LL was trying to fix. But I find I'm getting fewer "unsit" bugs on sim crossings now as well as no random disconnect issues. If you are still getting disconnected on sim crossings or teleports, it's possible it's a problem with your computer / network. If that all looks good then you probably need to raise a JIRA describing the problem, because for apparently the vast majority of people, the random disconnection issue is solved. Also. Nope. The Linden's haven't told us what they did and it seems highly unlikely that they will.
  8. @animats It sounds like you've collected a lot of information on the "old style" sim crossing problems. If you haven't already, it's probably worth creating a JIRA bug with the problems you know of laid out as clearly as possible.
  9. Resolved - We have finished updating main grid regions with a fix which should reduce incidence of teleport disconnects. Thank you for your patience during this time. Apr 25, 15:37 PDT https://secondlife-status.statuspage.io/incidents/10gthjdtjjky https://secondlife-status.statuspage.io/incidents/3g3fshq350wq
  10. I know you don't want to hear this, but that's not the problem that LL have been trying to fix for a month. You didn't get disconnected. The random disconnection issue is fixed.
  11. Well it's pretty much official from me. Whatever fix LL rolled out on the 24th April has fixed sim crossing random disconnects for me 100%. The entire Yavascript S1 route completed in one run using Firestorm on Linux. If you asked me before March 18th if that was possible, I'd have said highly unlikely. To whichever LL codemonkey(s) that figured out what to roll back / reconfigure, my sincere thank you. I hope they get you another monitor, a nicer keyboard and a more comfy chair. You deserve it. To LL in general. That was one monumental ***** up. I'm sure it has cost you both revenue and users. You can't afford to keep doing that.
  12. @animats Thanks! Nice post. That's more information in one forum post than we've had out of LL for over a month! I hope your optimism for a genuine fix is well founded. I have a feeling though that after today's sim roll-outs and tomorrow's (seemingly related) server maintenance, it might be declared "good enough" and back to the EEP roll out.
  13. Well. Only time for 1 test so far since the server roll out, but it's promising. "Cautiously optimistic". Entire H4 run completed, just over 2 hours online with no disconnect problem using Firestorm (Linux). Previous average disconnect time 20-45mins, with one 1h45m run. So that does look like a very significant improvement. But... Only one test run. It's possible that's random good luck, but given the results of previous test runs, statistically unlikely. Finally I can go back to using Firestorm. Phew. Sadly some of you still seem to be in disconnect hell, and as usual we have no idea what LL changed. I guess it's possible it has only improved things for some people? Without a bit more information from LL it's impossible to know. Edit: Oops. Typo!
  14. For the sake of quenching the nay sayers out there, I'll put down my findings on different client experiences during the current disconnection problems in more detail. If it helps people who are interested in sim-crossing activities in SL, that's great. Ideally we want the problem fixed though. Around the beginning of March I decided to complete all the Yavascript pod routes again for reasons not worth explaining here. Using Firestorm (my usual viewer), this was going fine. The 18th March was the last time to date that I have managed to complete any of the Yavascript pod routes using Firestorm. I didn't try any pod routes on the 19th but I was aware from my own experiences and friends that teleports were a problem that evening (UTC). On the 20th I went back to the pod runs. All hail the sim crossing disconnection demon. For a while I suspected recent changes in the Firestorm code (I compile from source), but that doesn't seem to be the case. However when I tried CoolVL for a comparison a few days after the 20th, once again I was completing pod routes. So here's the list again of Pod Routes for the doubters. Completed routes: C1, C2/N2, C3, C4-Tea2 H1, H2, H3, H4, H6, H7, H8 G1-North, G1-South, G2, G5, G6 J1, J2, J3, J4, J5, J6, J7 M1, M2, M3 N1 S0, S1, S2, S3, S4, S5, S6, S7, S8 T1, T2 Z1, Z2, Z3, Z4 Incomplete routes: C4-Tea1 G7 H5 N3 46 routes. Of that list, 8 were completed before March 18th using Firestorm. That leaves 38 routes. 4 still incomplete. For those of you that have never tried to complete a Yavascript pod route, some of those routes cross hundreds of sims and take many hours to complete. The information I'm giving you here is based on literally thousands of sim crossings. 33 of those routes have been completed since the start of the current server disconnection problems (March 20th) using CoolVL. One of them was completed using Alchemy. None of them have been completed using Firestorm. Zero. Nada. Zilch. And not for lack of trying. During the disconnection problems, I have tried various tricks. I've tried Firestorm with sky rendering turned off and/or Windlight shaders disabled. No big difference. After starting a "Pod run", Firestorm will normally give me a disconnection error message after 15-30mins of sim crossings. For a long time 45mins was the longest it managed. On one evening it managed 1h45mins, sadly still not long enough to complete the pod run I was on at the time. That gives us an idea of the degree of random in the disconnection problems. (Yes I time the pod runs). In comparison. CoolVL has managed far in excess of 3 hours constant sim crossings. Completing routes and still allowing a TP to start the next route. It's not immune to the current problems, but they happen much more rarely. Most pod failures are the "old style" problems, where you find yourself standing on a road after a while with no pod under your ass. I've tried Kokua a few times, and so far it's disconnection performance appears roughly equal to Firestorm. The current Singularity for Linux build has problems with the CEF (HTML) plugin for me, so I haven't tested it. I recently tried Alchemy out if interest. It's an old build but compared to CoolVL still a modern v2 viewer. So I just wanted to see if changes since November 2017 (it's last release) made any difference. Results are patchy. It can achieve a very long run sometimes, although that may just be freak occurrences. It may be failing at other times simply because it's so out of date. (It doesn't understand Animesh for example). Since the source code seems to be no longer available, and the variance in time before disconnection is so huge. I've given up testing it. Any other viewers that I haven't mentioned have not been tested. So if someone on here is telling you that all viewers will suffer the same disconnection rates, and that any user analysis of what's going on is worthless, and we should all just read a book until the Linden's fix it. They really have no idea what they are talking about. It probably is worth trying other viewers, but beware the random run of good luck. If you get good results, check it a few times to make sure it's not just a lucky run then share them. Cheers.
  15. I have given you substance and reasoning to support their position over many hours and many hundreds of sim crossings. You are choosing to ignore that well informed advice because it doesn't suit your narrative. I am the one being objective. You are the one who is being subjective by ignoring well research information because it is contrary to your un-researched opinion. Others on here already have you marked as a block worthy troll. I hope I've managed to make that view seem more reasonable for others in this thread. Have a nice day.
  16. What makes you say I'm testing on something that Linden Lab isn't working on? That doesn't make sense. Yes all clients are affected. As I said in my post, the source of the problem is server side. Some clients however are having a lot more trouble than others. You said "Your friend is showing bias, based on their own experience and conjecture" .. no they are possibly not. Different clients are handling the current server problems differently. WOW do we all use different computers? It's amazing anyone ever debugs anything! *_* tell me more of your wisdom! You are the one that raised hardware as a possible issue in testing. I was simply stating that all my tests are on the same hardware. They show a clear difference in some client sim crossing disconnect rates under the current circumstances. Are we clear on that? Now pop quiz. Will you change your statement "Your friend is showing bias, based on their own experience and conjecture" ? Because it's clearly wrong. Completed Yavascript routes during testing sim disconnection issues: C1, C2/N2, C3, C4-Tea1, C4-Tea2 H1, H2, H3, H4, H6, H7, H8 G1-North, G1-South, G2, G5, G6, G7 J1, J2, J3, J4, J5, J6, J7 M1, M2, M3, N1 S0, S1, S2, S3, S4, S5, S6, S7, S8 T1, T2 Z1, Z2, Z3, Z4, Incomplete routes C4-Tea1 G7 H5 N3 That's evidence of the testing I've been doing. Would you care to provide me with evidence of extensive testing that you've been undertaking that supports your opinions?
  17. Network speed - Same for all tests, Internal timeout margin? - Yes could well be different between viewers. That's what I was trying to point out. Despite LL claiming all viewers have the same problems, they do not. Hand off channel used - ?? Care to explain ??. Some system hardware - Same for all tests. OS - Up to date Linux I specifically said my testing is on sim crossings. Welcome to the "I only TP sometimes and I don't have much problem" club. Take a seat, read a book.
  18. After many many *many* hours of testing sim crossings, I can tell you that at the moment Henri's CoolVL is much less prone to the disconnection errors on sim-crossings (Teleports not tested to a degree where I could confirm or deny either way). The now horribly out of date "Alchemy" viewer also seems to do surprisingly well on sim-crossings, but I've not put enough hours in to testing Alchemy to confirm one way or another yet. I was hoping the problem would be fixed before I'd be able to. It does seem to me that this is a two sided problem. Viewers that I've tried based on LL's latest viewer code (Firestorm / Kokua), seem to give up earlier on a sim crossing error or delay than CoolVL and possibly Alchemy. However the source of the errors are server side, and even CoolVL / Alchemy are still sometimes tripped up. Yes it is a very random error. Yes you need a lot of hours testing over many weeks to be able to confidently say what I just said. Yes I have done that. This is where Solar tells me that I must be wrong. I'd like to be wrong. I'd far rather be using Firestorm at the moment. EDIT: Going back over the stats, I don't have enough data on Kokua to group it in with Firestorm on failure rates.
  19. Agreed on more info required. I'm not having a problem free, joyful SL life if that's any comfort. Even I'm getting bored with being pleased I have slightly less disconnects one day (and then far more a few days later), and I have a fairly high tolerance for bugs usually. Like many others I'm starting to wonder what other games / things to do of an evening I could be doing instead. I can see @MBeatrix's logic in suggesting that we all keep doing what we do so we can log a bunch of disconnects for the Lab. But I'm also beginning to see the alternative logic in just not logging in for a few weeks. Maybe if login numbers / hours in world drop drastically enough LL will do something drastic to fix it. Thinks .. I haven't finished Borderlands 2 yet ..
  20. I can't blame LL for really not wanting to roll back to say 18th March. It may even be impossible by now. They would need snapshots of all the different server states back then, and would then need to make dif / changlogs of everything they did since then so they could re-implement it in stages. After a month I'm unsure if they would even have the snapshot backups available to do it if they wanted to. Maybe. Who knows? Anecdotal TP vs. sim-crossings note though. I've noticed that if I stick to just Teleports, often they can go fine for a while (sometimes not), and if I stick to just sim-crossings, they can occasionally be fine for a while (I managed 1h45m on Firestorm the other day, more than double my previous record since the problems began). BUT.. If I finish a sim crossing marathon, then try and teleport it almost always fails first time. Not that it helps much. "A problem shared..." as they say. To give them some credit, it does seem like LL have been trying to improve things behind the scenes. My average times before a fail seem to be slightly improved .. Just sadly they haven't nailed the source of the problem yet.
  21. It seems very very very unlikely that the February DNS changes would be biting SL in the ass. One of the things I spend a while quadruple checking when the disconnects started happening was DNS queries. I couldn't find any significant problems getting DNS replies for any of LL's servers (but I did slightly improve my DNS caching and response times). The rest of your summary describes a painful predicament for LL to be in. With so many potentially contributing changes it's going to be hell eliminating possible causes, or even just rolling back to a previously known good state. Practically impossible in fact since they seem intent on keeping EEP running. The previously known good state didn't have EEP rolled out. I think by now the LL crew need to be nearing panic mode. I can't see many new users making it past a day or two before they decide "SL is buggy and why would anyone pay money to log in to that?". When there's still no fix after a month, it's time to attempt damage limitation by at least letting the users know what's going on in a lot more detail.
  22. While I'll stand by what I wrote above, it's still basically guesswork as to what the current problem is. Deeper knowledge of the system would well help them debug it faster, having less long standing undiagnosed bugs in the code would probably make it more resilient to problems like this, but the source of the current problem is apparently unknown to all. [My Magic 8 Ball says .... "systemd" .. hm .. shakes it again]
  23. systemd strikes again :) (Jessie introduced systemd to Debian)
  24. Well, as previously said in the thread. The problems people are having are very random. Sometimes you get a few days with very few problems, then boom, you get a few terrible days in a row. I've had both teleport and sim crossing failures, using Firestorm I can't cross sims for more than about 20 minutes before I get a disconnect message. Teleports sometimes work, sometimes don't. We sort of have to rely on LL collecting the stats on how many disconnects they are seeing and of which type. It seems any individual's experience is unique.
  25. Well ... no. Apparently there's been fairly regular staff turn over at LL over the years, so not many (if any?) of the people there now will have the kind of in depth knowledge of the code that the original coders would have. Pile on top of that a reluctance to improve on or solve problem areas that have no visible financial gain for years now (accountancy led project management at it's finest), see long standing JIRA issues for proof. Anddddd ... No ... No they don't. Not any more. If they can't be bothered to debug why sometimes you can't see the sim next to you for several years. Don't be surprised if they can't debug why teleports and sim crossings fail. Until it looks like it will cost them money, they aren't interested, and when it does look like it will cost them money, they haven't invested any time or effort in being ready to fix the problem. ¯\_(ツ)_/¯
×
×
  • Create New...