Solar Legion

Heh, you can probably guess which comments there are from me.

Why oh why is it that people will ignore notices/notes on Blog comment sections? The TPV I use clearly has it marked when you're typing out your comment that they do not and cannot offer Support through their Blog comments ... Yet people not only continue to seek support there, they get downright confrontational when told the avenue they're trying to use is not for Support ....

We .... have one on the MP .....

No worries.Still waking up and a bit more snarky than I ought to be!

I could have sworn I mentioned it by name in at least one post ....

I only just realized exactly when this thread was created .... Dear OP: As others have noted, Linden Lab had nothing whatsoever to do with the Windlight presets you are grousing about losing. Funnily enough you really didn't "lose" them either, unless a "clean" install removes the entries for them in the Quick Preferences Sky drop down that is - which you'd have only yourself to blame then for not making proper backups. Oh wait, most (if not all) are listed in the Library as well! Oh and let us not forget that someone took the time to convert them and place the conversions up on the MP for free. The thread thus far also has - buried in it - pointers and such for fixing some of the issues. EEP has been out and present in most TPVs for a while now with FS being pretty much the last one to implement.

Havok has been in the Second Life Viewer code since before I signed up in 2006 - you must be talking about one of the updates that borked things Some of the present issues have fixes external to whatever Linden Lab did At least one person - not sure if it was here or over in the FS Blog comments - noting that their frame rate issue was being caused by a particular windows update At least one "fix" implemented by Linden Lab introduced some problems and needs to be reworked (Object Occlusion in water distortion/reflection) I'd have more to list but I just rolled back out of bed and am considering just rolling back in.

It's a bit worse than simply not updating the GSP in that regard. Timing aside, no indication whatsoever was given that the rolls were to implement a server side fix requiring a restart. Not on the GSP and not on the Release Notes page. The sort of thing that makes me rather hesitant to give them the benefit of the doubt going forward.

Then I further stand corrected and incredibly irritated as well. Ordinarily the GSP and Release Notes are very clear on fix implementations. This time however they left those details out, giving the impression that the fix and restarts (as well as the Release implementation date) had nothing more to do with each other than coincidence - something which I am quite wary of regarding correlation/causation. When implementing such a fix in such a manner it is imperative that it be written out/properly documented.

Two things: If you do not care to speculate, then don't mention anyone by name. The last time I checked the GSP, there were Rolls scheduled originally for later in the week/early the coming week - these were moved to Friday. I prefer to go by what information is directly presented. I was mistaken as to the timing of the rolls (they were shifted). For that and that alone I apologize and stand corrected. Aisha, have you even tried to alter the region/parcel level EEP settings on the region in question? That will answer if the restarts/updates truly had anything to do with the fix. As of the Release Notes page, the version in question was rolled in on Thursday - this may be improperly marked. There is no mention of an EEP fix unless such is meant to be a part of the rather generic internal tweaks.

No. I do not own the objects in question and the holder for the account passed on. I am keeping them there (interactive pets, KC brand, no idea if they do much HTTP communication work outside sending stats to the external server) as a sort of remembrance. ETA: For things like this ... I do tend to worry a bit more than 'normal'.

I just hope that when this is fixed, we don't have to rerez any objects ... This would be rather problematic for two objects on one of my parcels ...

I just wish we could change those altitude markers. For my rental parcel, anything that is not at ground level is presently above 3000 meters and would be a right pain to move to new altitudes - under the way Firestorm had things set up originally, I could set my sky presets such that everything from ground to just under 3800 meters was one preset while the rest was another. Though that's more or less a personal thing as those who are regularly on the parcel tend to use their own settings anyway. Still, would be nice ....

I usually get my information from the proper channels/sources and observation. Those rolls were scheduled very clearly prior to any mention of EEP needing a fix. Frankly I have a rather large issue with any user speaking in the place of a Linden on such matters and will defer to what is shown/directly observed. GSP showed that the rolls were scheduled at the time and were not underway when I logged back in. EEP was fixed at the time. Either someone forgot to update the GSP (possible) or they rolled much later than one would expect. Either way there is no mention whatsoever on the GSP stating that the fix would be implemented with the Rolling Restarts. The EEP issue quite clearly states at 12:53PM PST that the fix was implemented. So sorry - not taking any end user's word on the matter. Especially one that felt the need to respond to a reaction. And yes, I am a fair bit crankier today than normal and not nearly as willing to deal with much. Also yes, I am being quite pedantic on this. I am well aware that the fix might have required a Restart to get it to take - I am just as well aware that this is not always the case when dealing with what appears to be a permissions issue, server side. @Oz Linden- If my reading of the GSP is wrong, care to make a correction? ETA: The thread regarding Web Communication has nothing whatsoever to do with the above and is irrelevant to both the reaction and subsequent (brief) back and forth.

That's nice. The Rolling Restarts were scheduled well before the EEP fix. No mention of Restarts whatsoever was made in regards to the fix. Furthermore when the fix was implemented, the rolling restarts had yet to even show up as in progress. Now then, since you're not a Linden I suggest you not make definitive statements on the matter. ETA: So it is also quite clear - Web Communication being down has nothing to do with my reaction or with what was being reacted to and thus is irrelevant as part of your response. Have a nice day.

If no roll was announced then no roll was needed. I logged in and was able to set up my parcel's EEP once the status changed over to Monitoring. The Rolling Restarts (which have yet to occur) are unrelated.

Backing up your settings means nothing in this instance. The entire viewer/install folder is what I backed up as a precaution and is a precaution I always take when such a major update comes. Meh - either way, you're apparently stuck now.

The update was not "forced" at all and if you'd made proper backups you'd not be having much of an issue The primary culprit for the FPS drop appears to be a "fix" implemented for Water reflections - a "fix" that can be turned off in your settings, see my earlier response with a link to the relevant forum post The Firestorm team had rather little choice in polishing up and releasing an EEP enabled viewer - fuss at Linden Lab for that feature set.

The setting referenced here fixed the FPS drop (for the most part) for me.

Heh, so by the end of the day the AUR (Arch User Repository) entry for Firestorm-bin ought to be up to date. Ought to be interesting to say the least.

Server Channel has/had nothing to do with how the TP Routing permissions were affected (or not) by varied Group Roles and permissions. The trick with Estate Managers and Groups is a bit ... convoluted to say the least.

There are on screen keyboards that allow you to swap to an old fashioned T9-Multitap layout and functionality. I use one myself - I find it much faster than plinking out a response with the "full" keyboard or even the swipe through function some of them have.

I've had several cellular phones, ranging from the older flip-phone and early single body types to modern smart phones. Why do you think the T9-Multitap system was developed? Heck some of those even had rudimentary Predictive text. Past a certain point there was no need whatsoever to tap on the same button several times to select a letter, number or symbol. What I cited above is the known, technical limitation of the time - that is not something one can "agree to disagree" over. What we can agree to disagree over is the laziness that followed once that simple, 160 character limit was no longer an issue.

Yeah, no. Not even then. That absolutely irritating practice got its start thanks to the same limitations Twitter had when it was launched - 160 characters per SMS. Unlike today where systems allow for much longer messages through MMS. Back then, it was "tolerable" and "understandable" as a way to circumvent the limit .... there is no excuse now.

Yeah, funnily enough what is being described with the Group Owner role .... is not something I have noticed behavior wise. Rather, wasn't when I used a Landing Point. I - as Group Owner and Group Creator - could not circumvent the Landing Point from outside the Region. In case it makes any difference: The parcel is Group Owned/Deeded, not simply set to the Group.