We have some news from the Firestorm Viewer Development Team today. Seems they have been suffering from burnout for a time. So, they have taken some time off and are now back.
It seems they have some new developers. Holy Gavenkrantz has apparently been a code contributor to Phoenix and Firestorm for some time. Now he is officially on the development team.
Armin Weatherwax was a lead developer for KoKua viewer. For whatever reason he has moved over to the Firestorm team and will be handling development of Firestorm for other grids, like OSGrid.
You may remember there is a thing floating round not so officially called the Havok Licensing thing. That is about Pathfinding, which if you don’t know is about creating Artificial Intelligence Characters or NPC’s (Non-Character Player) and your hopelessly uninformed, which I don’t understand if your are reading this.
Pathfinding requires the viewer to use a part of the code provided by the Havok Physics Engine people to work with the Navmesh, the path creation feature that can be used by Pathfinding Characters. Look at the image to see some of a Navmesh. The Navmesh is sort of like building roads for the AI Characters.
OpenSim does not use Havok for their physics engine. So, they do not have Pathfinding. If the viewer only needs the Havok code to render the Navmesh and there is no Navmesh in OpenSim grids, an OpenSim viewer does not need the Havok code.
The Havok Licensing appears to restrict a viewer using the license Havok provided Linden Lab to using the Lab’s grid. This means a viewer with the Havok code from the Lab can only connect to the SL grid. There is some ambiguity in the Lab’s intention in regard to the license, if not in the license wording. So, this may or may not be a problem. But, most developers are treating it as a real problem and that is really all that matters.
The Firestrom Team’s solution is to fork the viewer into two branches. One will have the Havok tools for working with Navmesh and be used with the SL Grid. The other will omit the Havok code and be used on OpenSim grids.
It will be interesting to see how this development works. It certainly sounds like the development could split into two supporting two viewers. As the Lab ads more features to their grid and OpenSim adds other features to theirs, I think we’ll start to see divergence.
Next Release?
So, when are you going to see a new release of Firestorm? We don’t know. BUT… they say soon. The implications in the article is they are waiting for the Lab to release Pathfinding. The word in the Pathfinding region is the PF Team is targeting mid July for a release of Pathfinding to the Release Channels. If, and it is a big IF, Pathfinding passes the Release Channel testing, we could be 5 weeks away from seeing Pathfinding rolling to the main grid. So, that could translate into a new release of Firestorm in late July.
There will be no second branch. There will be different build targets and depending on what target you have chosen you will either get navmesh support OR OpenSim support. They will be mutually exclusive, so you won’t get both at the same time.
While the difference is important to you, to most of us it is semantics.
Either way there will be code in one target that is not needed in the other. Whether that is in different branches or wrapped in one package and handled with compiler directives is the developer’s preference. I think either way it will get complex and add development and maintenance issues. Issues slow development and reduce stability, which can be over come. Good luck with that.
The FS team seems to be creating what may be argued is the most complex viewer being used in the SL and OpenSim worlds. Firestorm stability is already falling behind other viewers. Whether that is from the team’s choice to use a development tree targeting final releases and thus leaving LL issues in place in the viewer or a matter of dealing with issues is impossible to tell from outside. I think the complexity issues will likely become stability issues and eventually lead to a divergence. If the team is determined and willing to put in the time the issues can all be handled and divergence avoided whether code is forked or “IF’d”. Time will tell if I’m guessing correctly.
Maybe you should stop guessing if you don’t know, hmmm? Fact is that other highly advertised viewers have crash rates in the same league as Firestorm, with most issues inherited from LL’s official viewer.
I’m only guessing at why… the relative crash rate is published in the TPV Directory.
Hmmm… I wonder, wouldn’t make more sense to extend the viewer so to have a pluggable architecture, rather than forking the code? It would be easier to maintain.
It probably would. I suspect the FS Team is working toward that. I think the change in UI suggests that. It is hard tell whether LL or the FS Team has more modular code set without getting into the code.
I really don’t think you want to make a ‘switchable’ viewer. At some point in time LL will not trust that the Havok code (and any other future SL specific licensing) is not being used in the OpenSim part of the viewer. It will be far easier for LL to place ban tags on an OpenSim specific viewer to keep it from accessing SL than to feel they have to take apart a viewers code that is suspected of having the Havok code be usable elsewheres whether the on/off switch is there or not.
I’ve given up on trusting Linden Lab’s delivery targets.
We still don’t have the stuff from Linden Realms available to users.
It loos as though the Lindens can make things work while they maintain close control. Open it up to user-created content, and expect disaster as they discover what they didn’t think of.
I’ll say you are being overly pessimistic. They make some of their targets and miss others.
There is a huge rewrite of the SL code going on. Making some of the changes they have tackled is complex. The Infrastructure changes being made touch so many parts of the SL system they run into lots of surprises. Plus the SL system is unique and the Lab breaks lots of new technical ground. Often they are creating new solutions for things never done. It is not surprising the miss target dates.
>> There is a huge rewrite of the SL code going on. Making some of the changes they have tackled is complex. The Infrastructure changes being made touch so many parts of the SL system they run into lots of surprises. <<
Without mentioning that missing deadlines is quite the norm in software development, mostly when dealing with refactoring poorly documented code.
If Armin Weatherwax is now writing for Firestorm, does that mean Armin will no longer be working on Kokua or Teapot ?
You would have to ask him. But, it would seem to suggest he would have less time available.
There are no exclusivity restrictions as far as I know. Also, much of the code written for one viewer is usable in other viewers. So, writing a fix in two viewers does not take twice along as writing it for one viewer.