Wanted: Viewer Developers

[JasonClandestino]

Wanted: Viewer Developers for a viewer development team.

The project scope is to use the Phoenix Firestorm 4.7.7.48706 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.

For 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.

For 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.

For 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. 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.

Questions or Comments are welcome.

Gracias.

Edited October 5, 2018 by JasonClandestino

[Callum Meriman]

4 hours ago, JasonClandestino said:

4.7.7.48706

1. This version is from March 2016. Why such an old, obsoleted viewer? 

2. Do you know c++ and the source as well? Or just dreaming of leading a team of developers

 

 

[JasonClandestino]

I find that Phoenix Firestorm 4.7.7.48706 was stable & reliable.

The recent 5.0.11.53634 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 have noted various other problems with that particular edition. I think that 4.7.7 is considerably stable & reliable. 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.

As 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 am a long time Linux programmer, so "Yeah, I am acquainted with the C Programming Language." as well.

The Firestorm viewer really is inefficient within contexts. A simple example of that is the method of putting "Mode"s subordinate to the Skins. 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. That as well would ease any burdens of tracking down & fixing a probable bug.

Various people are familiar with the HBO Series titled "Westworld", based upon the 1980s film of the same title. For an example, with module developments for the viewer, a module titled "Entourage" could be created, which allows the user to login 3 avatars at the same time, with 2 of the avatars controlled like the "Final Fantasy" party members. Yet other a module could be created for Chat Droids, with somewhat further developed aiml like chat bot files for your party members. If you had a separate machine to run Entourage & Chat Droid, you could make your own "VirtualWorld" (of similitude or likeness of compare with "Westworld").

As well, various viewers like Radegast & RLV implement various features that were important developments for the Virtual World Communities. A Viewer Programming Language functionality could provide considerable enhancements to your Virtual World experience. The basic RLV scripting features, with inclusion enhancements to the Radegast "Alice" plugin could provide the functionality necessary to simulate your own rendering of the great & inspiration parts of the Westworld series concepts.

In short, if I am left to work on the Viewer Project alone, I'd do that for just my own Grid. The project scope is not really about showing off my great programming prowess to the various probable curious onlookers, not actually, though I thought that various other interested & savvy developers would provide a vast perspective of community needs, as well as assist in the implied time restraints of providing the community with a functional & useful Viewer code with the project plan briefly described within this post topic.

Edited October 6, 2018 by JasonClandestino

[Ansariel Hiller]

The degree of a bug-free OpenSim compatible viewer is directly proportional with the availability of the OpenSim reference viewer.

Regarding creating a modular viewer based on the current LL-based viewer code: Good luck with that!

[Willow Wilder]

19 hours ago, JasonClandestino said:

Wanted: Viewer Developers for a viewer development team.

Waiting for the list of perks, benefits, incentives, remuneration being offered to said team. Thanks! 

[ellestones]

i would recommend something relatively easier to begin with

modularise the application rendering engine so that the users can float the dialog windows out of the main window onto the computer desktop without any drop in render performance

do this first before anyone else and Firestorm will crumble into dust before your eyes. And the Firestorm devs and the devs at LL also will start calling you, God

[Callum Meriman]

 

19 hours ago, JasonClandestino said:

The recent 5.0.11.53634 has incurred numerous incidents of texture upload problems with resultant textures that have variable uuid code, amidst various other problems with texture uploads specifically

A huge part of being in a development team, let alone being their leader is working with bug reports.

Have you considered it would be rather a good test of your skills to debug the (numerous) "texture upload problems with resultant textures that have variable uuid code" problem? You could find a reproducable test case, and lodge a well written Jira. I am not sure how far your knowledge of Java, Python, and K&R C will take you, but armed with the test case you could then dive into the source and fix it. Fixed you could submit the patch to one of the various teams for approval.

Unless you plan a feature dead viewer, doing that would be less work then endless merges moving forward, especially as your fork becomes further and further diverged from everyone else.

[Whirly Fizzle]

14 minutes ago, Callum Meriman said:

"texture upload problems with resultant textures that have variable uuid code"

I'm not even sure what this means  lol.

14 minutes ago, Callum Meriman said:

A huge part of being in a development team, let alone being their leader is working with bug reports.

You also need to be proficient in cat herding!

 

[Callum Meriman]

Just now, Whirly Fizzle said:

I'm not even sure what this means  lol.

I was wondering if it were "The UUID isn't constant, it changes each time I upload the same texture" Hopefully a repro will help make this bug clearer.

[Beq Janus]

12 minutes ago, Callum Meriman said:

I was wondering if it were "The UUID isn't constant, it changes each time I upload the same texture" Hopefully a repro will help make this bug clearer.

Perhaps that's a bug in Java.

Oh wait, I forgot, there is no Java in the viewer. 

Then there's all that python too, but perhaps that is there to help Whirly keep her cats in check?

[JasonClandestino]

1 hour ago, Callum Meriman said:

I was wondering if it were "The UUID isn't constant, it changes each time I upload the same texture" Hopefully a repro will help make this bug clearer.

&&

1 hour ago, Whirly Fizzle said:

You also need to be proficient in cat herding!

&&

(I'm Tribal Mayan, & she's probably aware of that. ((I'm not being sensitive, not actually. If a white American suggested to a Black Man that the white American has a black Dodge Charger & the Black Man complained, especially within a particular context, I really think that I would be considerate enough to consider that the Black Man might have a point to complain, & this actually is a serious topic. It's not a "sensitivity", not actually. It's about "consideration" (((I really don't expect that much out of you "programming white gurus with a big plan for the future" not actually.))) )) )

1 hour ago, Callum Meriman said:

A huge part of being in a development team, let alone being their leader is working with bug reports.

It seems I picked up a couple of Firestorm Devs that really are not interested in my posted topic, not actually.

I'll politely ask those couple of people not to comment in my topic further, not at all.

Edited October 6, 2018 by JasonClandestino

[Callum Meriman]

I am actually not an FS dev. I worked for a little while on Singu, and so I am a little aware of how difficult merges can be. At the moment I am unattached to any team.

My comments are serious.

Another dev skill is not to be thin skinned. IRC can be brutal sometimes.

 

I wish you well in your project.

[JasonClandestino]

2 minutes ago, Callum Meriman said:

I wish you well in your project.

Thanks for that much, though I stand behind my previous request. I'm talking about a serious Dev project, not in requisite of banter with FS Devs, concisely, not actually.

Thanks though, Callum.

[JasonClandestino]

18 minutes ago, Beq Janus said:

Perhaps that's a bug in Java.

Oh wait, I forgot, there is no Java in the viewer. 

Just to address the inquisition & implication:

https://community.secondlife.com/forums/forum/352-sansar-for-second-life-residents/

&&

https://highfidelity.com/

Quite a lot of research & things involved in this posted topic. That's quite some conjecture on your part, Beq.

(I'm suddenly less bothered when I get few replies to my posted topics.)

Edited October 6, 2018 by JasonClandestino

[Whirly Fizzle]

This guy is good.  Maybe he can help.

 

[Callum Meriman]

11 minutes ago, JasonClandestino said:

https://community.secondlife.com/forums/forum/352-sansar-for-second-life-residents/

&&

https://highfidelity.com/

Not sure what they have to do with the SL viewer at all? Neither of them are even remotely related to the viewer codebase. Not even the same licenses, HighFidelity is Apache 2.0 which might pose some legal issues, and Sansar is proprietory.

Have you grabbed a copy of HiFi from their repo and then compared it to the 2016 FS code you are hoping to work with, they are very different.

 

Effectively one is a plane, one is a car. They both carry passengers, but nothing in each is related to the other.

[Beq Janus]

2 minutes ago, JasonClandestino said:

Just to address the inquisition & implication:

https://community.secondlife.com/forums/forum/352-sansar-for-second-life-residents/

&&

https://highfidelity.com/

Quite a lot of research & things involved in this posted topic. That's quite some conjecture on your part, Beq.

(I'm suddenly less bothered when I get few replies to my posted topics.)

I am unclear where Sansar or HiFi come into this. You were asking for Java and Python skills to work on the Second Life viewer, (specifically an aged version of Firestorm). Viewers directly derived from Linden Lab's code base have no Java in them. The only Python that exists in the Viewer code base is a set of scripts that are used in testing and debugging and have nothing to do with the viewer itself directly. 

There is a Java-based viewer for Second Life, Lumiya, it runs on the Android platform and is (unfortunately) not open source.

I think the objective you have is laudable. A fully modular viewer would be very flexible and potentially powerful, making it performant might be tough though. The derision that you see in this thread comes largely from the assumption that you can achieve those goals from the cited starting position. In my humble opinion, you would be better able to achieve your goal by starting from the beginning not from something as complex and ingrained in the LL architecture as FS. You dismissed Ansariel's comment, and yet it was perhaps the most apposite in this thread. The second life viewer is a highly complex piece of software consisting of many hundreds of thousands of lines of code, the nature of the design means that it lacks the appropriate seams/interfaces that would allow you to disentangle the functionality easily, it really is not the right place to set out from. At the same time, a major refactoring of that codebase would move you so far from the Linden Lab code base that maintaining the merges with the ever-changing Second Life functionality would be a project all of its own=, but perhaps you do not need to keep compatibility?

I honestly hope you have success in your endeavour and get to return here and say "I told you so". 

[JasonClandestino]

6 minutes ago, Callum Meriman said:

Have you grabbed a copy of HiFi from their repo and then compared it to the 2016 FS code you are hoping to work with, they are very different.

 

4 minutes ago, Beq Janus said:

I am unclear where Sansar or HiFi come into this.

I'm just considerably sure that each of you spent a total of less 5 minutes even considering what "High Fidelity" or the point of "Java" in the context of a new Viewer Development have to do with anything that you want to ramble on about, while I'm trying to attract people with serious interest in my posted topic (again).

[Ansariel Hiller]

 

On 10/5/2018 at 10:10 PM, JasonClandestino said:

Wanted: Viewer Developers for a viewer development team.

The project scope is to use the Phoenix Firestorm 4.7.7.48706 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.

3 minutes ago, JasonClandestino said:

I'm just considerably sure that each of you spent a total of less 5 minutes even considering what "High Fidelity" or the point of "Java" in the context of a new Viewer Development have to do with anything that you want to ramble on about, while I'm trying to attract people with serious interest in my posted topic (again).

What now? Turn an ancient Firestorm release into a modular viewer or start a new viewer?

But again: Good luck with what you are trying to do! Seriously! Just thinking about the number of OpenSim users and how many of them actually provide patches for OpenSim compatibility...

[Callum Meriman]

1 minute ago, JasonClandestino said:

I'm just considerably sure that each of you spent a total of less 5 minutes even considering what "High Fidelity" or the point of "Java" in the context of a new Viewer Development have to do with anything that you want to ramble on about, while I'm trying to attract people with serious interest in my posted topic (again).

I've spent quite a bit of time, months, working with the High Fidelity source code. It has no relation to the viewer code at all.

Have you even cloned the HighFidelity repo? Have you cloned the FS repo? Do you have a working build environment on your PC? Can you compile the viewer yet? Do you have your fork on GitHub or elsewhere already? Have you started writing patches for it so we can look at the commits?

I am dead serious Jason, look beyond your indignation and try to understand what I have said above. If you want to attract people with the skills to do this, then you need to be able to answer the questions I am posing and you need to demonstrate you can as well.

[JasonClandestino]

7 minutes ago, Ansariel Hiller said:

What now? Turn an ancient Firestorm release into a modular viewer or start a new viewer?

There were various problems with the 2 Firestorm releases since the release I want to parse out.

 

I'm sort of finished babysitting my posted topic for the attention less the interest.

[JasonClandestino]

Furthermore, within the future, if I start a topic within the secondlife community forums, I want the right to block a person or number of people that want to reply, concisely.

[Ansariel Hiller]

7 minutes ago, JasonClandestino said:

There were various problems with the 2 Firestorm releases since the release I want to parse out.

Yeah? Where are the JIRA tickets for it? Did you provide fixes? I mean, with your skill and experience it should be easy, right?

[Whirly Fizzle]

6 minutes ago, JasonClandestino said:

There were various problems with the 2 Firestorm releases since the release I want to parse out.

What problems specifically? Can you describe the bugs & give a repro?
Did you happen to file a JIRA issue?
I can't find any JIRA issues from you on the FS JIRA or the LL JIRA apart from BUG-225604 - "ULTIMATE_CONTROL" (Look it up)

[Whirly Fizzle]

1 hour ago, JasonClandestino said:

I'm Tribal Mayan, & she's probably aware of that. ((I'm not being sensitive, not actually. If a white American suggested to a Black Man that the white American has a black Dodge Charger & the Black Man complained, especially within a particular context, I really think that I would be considerate enough to consider that the Black Man might have a point to complain, & this actually is a serious topic. It's not a "sensitivity", not actually. It's about "consideration" (((I really don't expect that much out of you "programming white gurus with a big plan for the future" not actually.))) )) ) 

Um no. It was a joke.
Running a team of viewer developers is like trying to herd cats.
Nothing to do with race.  WTF.  Just stop it.