#Phoenix firestorm viewer 4.7.7 code
With other things, like a potential alteration of the Pie Menu for an RP Community specificity of interaction & experience, new features could be implemented more easily with a restructuring of the code tree within contexts. A simple example of that is the method of putting "Mode"s subordinate to the Skins. The Firestorm viewer really is inefficient within contexts. I am a long time Linux programmer, so "Yeah, I am acquainted with the C Programming Language." as well. I have made edits of that particular code for use in my own Grid for a number of features with a history of not a single problem with working with that source code edition.Īs well, a lot of the Firestorm Viewer includes requisite program language comprehension of the languages of Python & Java, which I am somewhat functionally capable with.
I think that 4.7.7 is considerably stable & reliable. I have noted various other problems with that particular edition. The recent 5.4 has incurred numerous incidents of texture upload problems with resultant textures that have variable uuid code, amidst various other problems with texture uploads specifically. I find that Phoenix Firestorm 4.6 was stable & reliable. Then eventually, Linden Labs decide to implement the Composit Engine Features, though not all the SL Community Members need nor consider those important object features, so one group of Viewer users just use the basic SL Grid Module, & a separate group of Viewer users just use the SL Grid Module (with Composits) module. The project scope is to use the Phoenix Firestorm 4.6 source code for a parsed viewer that's stable & parses out the various viewer features into modules that can be utilized in various Virtual World Communities for differentiation of enabled features, & improves the ability to fix, enhance, or replace features without effect to the functionality of the viewer.įor an example, a RP Community could program or hire programmers to make a Viewer Module specific to their RP Community & features to facilitate their RP experience with the ease of enabling a Community Module for that community & restarting the viewer, with additional ability to again enable basic viewer features & restart the viewer & have the basic SL Viewer functionality restored to that same stable Viewer.įor specific example, a Star Wars RPG Community might collaboratively work on the development of a SWRP Basic module, & 2 separate complimentary modules, 1 for Jedi, & 1 for Sith, & that way the various other subgroups, like Mandalorians, Troopers, etc., could work on the development of their own complimentary Community Viewer Modules, for dynamic Viewer Functionality & enhancement of experience.įor other an example, an OpenSim Grid might have a Composits Engine feature within their Grid Software, & they make a Grid Specific Grid Module for their Grid, the total while that they make the presentation of the features to Linden Labs. Wanted: Viewer Developers for a viewer development team.
0 kommentar(er)
