Just when I thought I was finished writing for a bit, Oz Linden had to go and post a comment on the prior entry that really kicked my brain into overdrive. That one simple phrase concerning that Linden lab was indeed working on Global Windlight, but only able to use the presets that the users have pre-installed left me stammering.
Yes, Global Windlight settings are something that is highly needed, but there is a reason why Phoenix viewer can only use what the users have pre-installed and thus have a very limited selection and scope for what that ability allows. Generally speaking it’s because they control a viewer development while Linden Lab controls both a viewer development and server development.
Why is this important?
It makes all the difference in what you can accomplish when implementing a new feature such as Global Windlight Settings. The reason Phoenix can only use what the viewer has as presets pre-installed is because they have no authority to make Windlight setting XML files into a deliverable asset attached to the Region/Parcels. This is the key difference between what Phoenix accomplished and what Linden Lab can accomplish with the same idea.
However, this seems not to be the case after reading the comment from Oz Linden, because Linden Lab is pursuing essentially to clone the approach from Phoenix. Sure, they’ll make it more accessible than adding a line in the description of the parcel/region but other than that it’ll work the same way with the exact same limitations.
That’s just lazy, Linden Lab.
You mean to tell me, and the world, that there isn’t a single programmer over there that didn’t think to make custom presets at the region and parcel level saved as an asset to be delivered to the users upon entry along with the countless amounts of other assets being served upon entry, and then apply those downloaded Windlight settings?
I refuse to buy that line. An entirely new asset type was created for Physics layers, and quite a lot of coding must be going into the Direct Delivery system for Marketplace (kudos btw for that). And then you get to Windlight and the company acts like they are under the same constraints as the 3rd Party Viewers…
It’s essentially saving a Notecard to the asset server… Albeit a formatted notecard for XML settings, but nonetheless the data involved would be negligible at best, and deliverable in the same manner as a notecard asset attached to the region/parcel settings by the owner. That same notecard XML asset file would also make a great way to trade Windlight Settings and make them accessible – through setting them as an asset type and allowing Windlight Settings as an item in Inventory. Drag and drop into the Region panel or Parcel settings panel to apply. Or as a normal user of the system, simply double click the Windlight preset in inventory to apply it.
What about people who don’t want to have Global Windlight settings?
Handle it in the same manner as media.
Windlight – Global: Auto | Verify | None [Dropdown Menu] in Properties –> Graphics.
You have an asset server and an army of programmers with access to every single aspect of the Second Life code. Don’t try to bullshit the community by pretending to be under the same constraints as Phoenix viewer for implementing Global Windlight settings. Implementing Global Windlight settings with the same constraints as Phoenix is plain ass backwards and lazy.
It’s also a lot of wasted time and effort if you ever bother to actually make it into a custom asset later down the road, because then you end up supplanting the old method (local presets only) with the ability to define custom presets and have them delivered as an asset attached to the region/parcel later on – creating a disconnect in methodologies.
Go back to the drawing board, stop being half-assed about it, and do it right the first time.
Is there a Voice of Reason department at Linden Lab? If not, there should be. The sole purpose of that department would be people like myself wandering around and pointing out the blatantly friggin obvious and expecting higher standards.