Maria Korolov has an update on the Kokua Viewer at Hypergrid Business: Kokua viewer to support Imprudence exports. The Kokua/Imprudence developers have been on a bit of a holiday, taking some well deserved time. This January they were planning the development path and asking for user feedback. The general plan is now to stop development of Imprudence and move forward with the Kokua Viewer development.
One of the features of Imprudence is import/export of objects in OpenSim worlds and Second Life. Many build in OpenSim worlds and then move final projects to SL for use or sale. Some also move things from SL to OpenSim. So, the import/export is an important feature for many. Maria spoke with the Kokua developers about the feature.
The news is while the viewer will not initially have the feature it will eventually be added. While there are things with higher priorities to be addressed before import/export the feature is on the to-be-included list.
There seems to be some challenge making the future Kokua import/export compatible with Imprudence’s. The developers plan to make it compatible, if possible. Remember. The viewer and server must cooperate for the feature to work. So, it is not solely a viewer side thing.
Information on KoKua
A nice feature of the transcripts is the team’s addition of a Summary. That gives one a quick overview of the meeting topics.
The most recent meeting summary is:
ImpDev Meetup for February 8, 2012.
- Nicky Perian is now officially a team member (Long overdue)
- Import Export Tool, we’ll try to keep it compatible with Imprudence
- 4096 Bug is still an issue
- What code can we use from LL? (Regarding Oz Linden statement)
- Base Kokua off (this repo) then add our changes to it
- The team will try to attend OpenSim Conventions in the future
So what is happening in the Kokua/Imprudence meetings?
They are fighting Wiki spam. I am so glad WordPress has a spam filter built in. As of this morning Akismet has filtered out 20,507 spam comments. Considering I have only 1,296 approved comments, that is a 20 to 1 ratio.
The change from Imprudence to Kokua is probably well known by Imprudence users. So, that does not seem to be what’s up with this topic. Seems it is about getting a code repository setup that works for all the developers under the Kokua trunk in the code repository.
Part of the reason for this is apparently to simplify attribution of developed code and features. This is a big deal among developers, which is understandable. If one creates something, they should at least get credit for it.
Part of this effort is toward getting the code to build on the various platforms; Windows, Mac, Linux, and 32 & 64 bit systems.
32 & 64 Bit
This is a geeky thing. For most people the only things we need to know is 64 bit systems are the coming thing because they allow programs to use more memory and handle big numbers more easily. In general they are faster systems.
Software is built to either use 32 bit or 64 bit memory addressing. Unfortunately the changeover from 32 to 64 is not as simple as one might suppose. Creating a 64 bit viewer has some gotcha’s that have to be handled.
The interesting tidbit in the discussion is that in speaking with Oz Linden it was said the Lab does not have plans to build a 64 bit viewer. O.O
If you look at crash statistics for SL and Third Party Viewers, you find that the Win7 64 systems have far fewer crashes. This may be because they have more memory for leaks to fill before the viewer sinks (crashes).
Oz’s actual statement was:
Supporting 64 bit builds has, as you all know well, not been a priority for us. I don’t see it becoming a substantial one very soon (but my crystal ball is at the shop). I don’t want to start a discussion of whether or not that’s the right priorities or not; that wouldn’t be productive right now.
Contributions that make changes to directly attempt to build 64 bit versions (such as the many changes to the build systems that would be needed) are not likely to get much attention in the near term (I just don’t have the bandwidth, or the requisite building and testing infrastructure). That having been said, there is nothing at all wrong with pointing out and providing fixes for those places in the code (especially LL code) that will cause problems when we do make that leap are most welcome. If you make 64 bit support a priority, I encourage you to make all our lives easier in the long run by contributing the requisite code changes upstream.
Kokua 3 Base
One of the challenges for viewer developers is keeping up with the changes coming from Linden Lab. Most people are running the Lab’s main viewer 3.2.6, as I write this. I’m running the 3.3.0 Development viewer. Things change quickly.
The problem can be understood by imagining you and I each have a copy of a million word document. We are both editing it. At some point you need to add my changes to your copy without losing your changes. If we both changed the same sentence, how do you avoid losing your sentence and how do you know which change is a better. Plus if that sentence has a footnote reference that is not in your copy, what do you do with that?
The solution is to organize your document to allow insertion of my changes. So, you avoid mixing in your unique ideas with the general body of text. Then much of the merging can be automated. But, automation requires things be well organized. Creating the new trunk of Kokua to use viewer 3 code and making it easy to maintain is a current effort.
Most SL users are not going to care about all the versions of the Lab’s viewer that exist. For one developing a viewer it becomes an import issue. The Lab via Oz wants developers to avoid getting too far ahead of the Lab. If for some reason the Lab decides to change a direction, they don’t want the developers so far out front the change causes them to miss a turn and have to back up.
I suppose it is like following someone in a car that is behind you. If they are in sight and signal, you can make the turns they will make.
It seems the Kokua team has decided the Viewer-Development branch is the branch that is the just right distance ahead of the main release version.
Developers use information at http://hgbook.red-bean.com/ (written by a Linden, btw – according to Boroondas Gupte) to figure out how repository things work. Also (although it’s for the reverse direction) https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#wiki-Rosetta_Stone.
The 4096 Problem
In Second Life there is no 4096 problem. This problem is about the grid that regions are located on. You have seen locations in a region defined by X, Y, Z values, which while a 3D grid is not the grid we usually refer to. The grid we refer to is a 2D grid that can be seen in the world map within the viewer or on the Second Life Destinations Search Page or the OSGrid Grid Map.
Each square on these grids is numbered with X & Y values. The 4096 problem comes up when the grid is larger than 4,096 meters in either X or Y. The effect is a failed teleport when one tries to tp more than 4,096 grid squares away. This is not a problem within Second Life. In OSGrid its a known problem and region owners work around it by carefully placing their regions with the limit. But, it does happen that regions get outside the limit. With Hypergrid access it is more likely to happen as not all grids center around the same central grid point.
It seems this is a viewer problem. The team may have a fix. So, this may be a non-issue for Kokua. However, until the Lab adopts the fix those using the SL Viewer on OpenSim will have to deal with the 4096 problem.
The older style profiles were buried in a database accessible via the viewer. The new profiles change that and make them a web based thing. For those playing in OpenSim the profiles are the older style. So, the Kokua peeps have to decide how to handle profiles.
Justin Clark-Casey, a noted OpenSim developer, says there is work being done to develop compatible web profiles. OSGrid has non-standard web profiles, I suppose meaning not matching SL and OpenSim ideas of profiles.
You, as an SL user, never see all the URL’s used by the viewer. If you want to see them, open the Debug Settings page in the SL Wiki and search the page for http. There are several.
When you connect to another grid all those URL’s have to be changed. Each grid has to provide the web pages and services so the features in the viewer dependent on them work. We often see a mismatch in search. One can be in another grid and try to search. The results is often from the SL Search page, being useless in any other grid.
The challenge is that when you must build a viewer that connect with multiple grids someone has to run down all the URL’s. Tedious. And then they change. More tedium making updates.
It is thought that may be a standard protocol can be developed so that a viewer or other applications can ask for the information and update the values on the fly.
The Kokua Team is figuring out how to coordinate with other OpenSim and viewer developers. Part of that will be attending rel life meet ups.
Summing It Up
Other than the Lab… well… depending on the topic, few developers provide transcripts of their meetings. This is a nice aspect of the Kokua and Imprudence development.
It is hard to say how long before we see the next Kokua release, but it is on its way.