Ansariel Hiller

Maybe you should have read the whole context, but I'll repeat it for you again: If Apple is going to lock down the Mac the same was as iOS - which wouldn't surprise me the slightest if they are going to do that now they can easily run iOS apps on the Mac and vice versa - and you have to install whatever application through the app store, then of course you will have to submit your application to Apple for approval.

It's not because OpenGL is old, it's rather because SL is still using fixed functions and other long-deprecated OpenGL 1.1/2.0 stuff usually no vender does any optimizations for.

Could it be a result of a Frankenviewer? 🤔

That's the whole idea behind every Apple business decision - well... to lock the user inside their walled garden so they can milk them even more. For some strange reason, there are (still) lots of people that like being treated like that.

I wonder if that has something to do with sheep willing to pay astronomical prices for earthly products and the professionals that are forced to do the same for overpriced hardware upgrades. It also wouldn't be the first time a huge company almost went bankrupt because of a wrong business decision. With roughly 6% of the SL users on Mac OSX, I wouldn't move an OSX version in the range of financial fortunes. But there is more to the decision than just a different CPU with different instruction set: Due to Apple's shameless way of trying to hide their incompetence in providing a proper OpenGL implementation for years by declaring it as old, deprecated technology, LL is also facing the problem of switching to a different rendering engine if they want to continue providing OSX support in the future. The currently most-viable solution - switching to Vulkan - resulted in about 30% of the users not having hardware supporting it, based on a recent hardware survey. So you also have to decide if by the time they come up with the switch more users wouldn't be able to login due to Vulkan or because of no OSX support. Although given the fact the Lab are hardcore Apple users, we might see a decision based on personal preference rather than what would be best for business. 😏 I allow myself to quote myself from another thread: And what do you think the viewer is using? Hint: It's not Catalyst and it's not Swift! 😉

The only one hating seems to be you. I personally think the idea of switching to their own ARM CPUs has the potentional to backfire tremendously. Also the question was if the viewer will run on Apple's new CPUs - which is doubtful since I already explained the viewer uses the SSE2 instruction set and nobody knows if and how Rosetta 2 is able to emulate/translate this. If not, the viewer will - once again - need hardware-specific floating point/vector operations, just as it did in the early days. Aside from this technical point of view, we all know Apple's business practices and I would not be surprised if they will only allow installing applications on the new Mac via app store at some point - including the same rules regarding approval and in-app purchases as in place for iOS apps already. In which way this will "please" the professional userbase is going to be interesting to see if it happens. Funny side note: Running your iOS apps on the new OSX and Apple Silicon is nothing guaranteed as per se. Developers can control if their app can be installed and executed on a Mac - at least in that direction. Most likely it will be the same in the opposite direction. Numerous (also big) companies already stated they will not allow running their iOS apps on the new Mac. But hey... keep on dreamn' 😊

Ahhh... Apple fanboy! That explains a lot... 😏

You won't get that far without a proper video driver.

I'm waiting for how long people are exciting once the Macs are also completely locked inside Apple's walled garden... 😂 Imagine LL having to submit the viewer to Apple for approval for their app store and Apple rejecting it because of being a Fortnite 2.0 case with bypassing in-app payments... 😂

Who knows, who knows... The viewer users Intel-specific SSE2 instructions not available on Apple "Sillycone". LLVectorPerfOptions might see a comeback in some form... BTW: Posting the question in several forums usually don't yield more answers.

Anyone of you using the internal AO? If yes, see https://wiki.firestormviewer.org/fs_ao_crash_639

Copying various files from different viewers didn't help? 😏

SLPlugin.exe is not SLVoice.exe but belongs to the internal browser/media components which are trying to connect to a malicious website, most likely by an inworld TV around your location relying on some dodgy website to display their content.

What both @Oz Linden and @Rider Linden forgot to mention was, that you can create days longer than 24 hours (even Ethopia with their 13 months calendar didn't had that idea yet 😛), why is it you can only set an offset of from [-12;12] hours??? 🤔

Why don't you ask them? https://jira.secondlife.com/

Since Python is only used for build scripts and not to run websites, the deprecation issue is neglectable - at least on Windows, where you simply download Python 2.7 and install it, because Windows - it just works!

Yeah, using Python 2.7 for running build scripts (like any other viewer until LL finally updated their scripts to be Python 3 compatible)... man... those are some serious problems... as if the viewer would be executed on a webserver!

Complete nonsense! Evolution is the key. It's just that Apple a) favors vendor-lock in and b) simple wasn't willing to fix their broken implementation causing it to be stuck on a 15 year old specification because the deprecation argument just came in handy because of a)

"Since we are lazy a** f***ers and don't care about fixing our OpenGL implementation, OpenGL was deprecated in macOS 10.14. To create high-vendor-locked-in code on Macs, use the Metal framework instead. See rip-off." - fixed it for you!

It was added during the early days of server-side baking to enable fetching baked textures via HTTP since it was still done via UDP back then. For quite a while, they are already fetched via HTTP - unless client-side baking is used, e.g. on OpenSim. As Whirly already said that setting is not connected to any code anymore and you can ignore it for the time being it will be removed in next release.

You know you are getting boring, right? You said bugs are only relevant if you know about them, otherwise it's acceptable to release with bugs - what you said in a nutshell basically. This leads to the simple conclusion that there was no snapshot bug for the vast majority of our users. And those actually affected still had the chance of rolling back to an older version. What I was referring to are bugs that are inside your viewer you would have noticed at some point if you were actually using the viewer. Anyway, since I'm getting bored and we're not getting anywhere here: Brag on, Wayne! ...and since Oz actually approved your arbitrary changes to the complexity calculation, there is a big fat warning in front of your viewer in the TPVD. You are so funny at times! You don't need to be a rocket scientist to figure out those changes are actually a blatant violation of the TPVP and you only got away with it because nobody at the Lab cares about that small number of users. Anyway: I leave you with your thoughts that taking things into your own hands if you are explicitly asked to not do so is a great idea!

Do you have some broken record or what's your obsession with high resolution snapshots? But hey, most people haven't noticed that or it wasn't relevant for them, so everything ok for 99% of the users. Aside from that there are several issues in the viewer you would notice in daily use and are even reported to the LL JIRA - if you would actually use the viewer for things other than pushing pixels in the UI or tweak stuff for creating videos to brag with! You must be kidding, right? Everyone knows how you changed the complexity calculation the way you think it should be because you couldn't be asked to wait until LL overhauls the calculation. What does the viewer source code say about the calculation again? Exactly: /***************************************************************** * This calculation should not be modified by third party viewers, * since it is used to limit rendering and should be uniform for * everyone. If you have suggested improvements, submit them to * the official viewer for consideration. ***************************************************************** Wanna bet if Firestorm or another TPV with more than 250 users will pull such a stunt, they won't get away with a simple warning in the TPVD? Maybe we actually should and see if we can force a reaction from Oz, affecting your viewer as well...

And you have bugs in your viewer we already fixed years ago - shouldn't you be ashamed right now? How can you dare to have your users live with these bugs for years? In your position I would be careful who you start fingerpointing at, especially if your viewer contains an actual TPVP violation you only get away with because apparently Oz doesn't seem to care since it only affects 250 users or so... But for now I am happily waiting for your lesson about release managent which is most likely coming up next - I'm sure it will be good for a laugh or giggle at least!

What EEP release are you talking about? The is no actual Firestorm EEP release out yet due to the amount of bugs EEP still has - there is only a public beta for people to have a peek. But I forgive you overlooking that fact while raging...

You don't like the new "oiled pig" look once somebody puts on a tiny bit of shine? Well... I wonder if there was a reason Firestorm didn't release this rushed out piece of breakage yet - beside giving other TPVs the mandatory chance to brag and blame... 🤭