Archive for the 'Help Wanted' Category
July 16th, 2016 by NickyP
Pantera Pólnocy(sp) uploads youtube recordings of all Third Party Viewer (TPV) meetings. This is a great service to those of us that are working or just don’t like meetings. Linked is the 15 July 2016 meeting.
Discussed at the meeting was the lack of voice support for Linux and that no additional support from the vendor, Vivox, Inc. would be forthcoming.
Discussed also was that some TPV projects, Kokua included, had backed out the changes that broke voice on Linux. Drakeo provided the code that allowed Kokua to reinstate voice on Linux. Our implementation of Drakeo’s changes were to use separate source code files and compile voice at the end of the compile process during platform specific code compile. To maintain compatibility Windows and Mac code for voice were also moved to platform specific compile.
Oz Linden mentioned that security concerns led LL to the latest changes by Vivox that broke Linux. Reading between lines it appears that the security holes are, or have been, exploited in world by greifers. Oz recommends that the older versions of SLVoice not be used on any platform, including Linux, and that there are a series of changes planned,if not adopted, will break voice on all platforms.
Suggested was for Linux to run the Windows SLVoice.exe instance under Wine.
I have never run Wine so, I request a Linux user volunteer to wright a README file outlining procedures to use a Wine instance of Windows SLVoice.exe and have it operate correctly from Linux.
May 21st, 2016 by NickyP
We updated Kokua to upstream version 4.0.2 on March 29, 2016. Since then SecondLife (SL) updated to:
An HTTP Client Release
A Maintenance Release
The QuickGraphics Release
The HTTP Client Release is mainly under the hood, but is significant in the amount of code touched. In addition to SL code merges, Kokua over time has taken in code from Firestorm. For those changes we have taken in additional code from Firestorm to provide the HTTP Client updates. Nicky Dasmijn led Firestorm’s efforts and Kokua would likely be stuck in the poke-at-it stage if not for her work. Thank you Nicky D.
The Maintenance Release is just that, a series of bug fixes and minor enhancements.
QuickGraphics provides two features; Graphics Presets and Avatar Rendering Complexity Controls. These features come with User Interface (UI) changes that will require a learning curve to master. Inara Pey, ( @InaraPey), and Nalates Urriah, (@Nalates) have blogged about QuickGraphics since its inception as an SL project viewer. Linked to their names are Inara’s and Nalates’ posts. Please review their posts.
Our downloads location has installers with RLV and NORLV in the file names. The RLV build can be used in RLV mode or vanilla mode. In “vanilla mode” the RLV build acts just like the NORLV build by skipping over RLV-specific logic or by executing corresponding plain SL upstream logic instead. The logic of the skipping mechanism (for the technically inclined: “if”-statements wrapping RLV-specific code sections) itself has to be executed in either mode, but should be negligible in performance. NORLV installers deliver viewers that are ~99% free of RLV viewer specific code. There is some code developed by Marine Kelley in her RLV viewer that is not specific to RLV features. Those non-RLV-feature related changes in the RLV viewer make up the remaining ~1% of code from RLV viewer included in both our builds and enabled whether in RLV or vanilla mode. NORLV builds provide a fallback in case of illness or other unexpected events that prevent timely updates to RLV. At present NORLV is not delivered as a release viewer. Users may use test viewers in those cases where there is moral objection to RLV or for any other reason. NORLV is where all developmemt first takes place. For Kokua-4.0.5 RLV code remains at upstream version 2.09.17.
Kokua has no formal Quality Assurance (QA) and we rely on our users to run test viewers and report back and, depending on the problem, file a Ticket. The lack of formal QA is a blessing of frequent releases and a curse of buggy releases.
We need testers for this release. Especially for RLV viewers in both RLV on and vanilla modes. We need to know if Avatar Complexity interferes with RLV visibility restrictions.
For OpenSim (OS) users we have found that HTTP Client code crashes with teleport (TP) on grids that use unmodified OpenSim code. These crashes seem not present on OSGrid and 3rdRock grids that make use of HTTP for asset delivery. This concern and the pending Inventory Message changes in both the viewer and SL server have us considering a split from the one viewer for all approach.
Geir Nøklebye is lead on this split and all can monitor his work on Bitbucket . Kokua-opensim does not rely on upstream merges. Most all changes are cherry-picked from various repositories. As we progress test viewer installers will begin to appear with “_OS_” in the installer name. We haven’t determined a version number scheme yet, but we will not have the version number match the SL version for the same functionally. For now, the version begins with 4.0.2 our branch off point. As we progress, we will provide follow-up blog posts. This is a work in progress and if we are able to solve the TP issue and the Inventory Message changes are not as difficult to make as expected we may decide to stick with the “one viewer for all” approach.
Known SL appearance bugs that affect all versions of Kokua code.
Swapping between different wearables too quickly using “Wear” causes old wearables not to be removed from being worn when they should be – only reproduces on the Attachment fix/AIS3 viewers.
Appearance update is STILL broken after recent changes in 4.0.4 (314579)
October 1st, 2015 by NickyP
Volunteer needed to produce Kokua icons for Test and Beta versions. This would be reversing the colors of the present icons and adding TEST and BETA at the top, bottom or vertically on the icons.
We will give credit in About Kokua and the mercurial changeset for the submissions.
June 30th, 2015 by NickyP
Request for volunteers to test KokuaNT (new tools) for Linux 32 bit, Linux 64 bit, and Windows platforms. Linux versions will likely not run on any distribution older than Debian Stable, aka Jessie. Several distributions follow Debian Stable and KokuaNT should work on those. Initial testing on Linux Mint 17.1 64 bit was successful.
If this is your first time to test a Kokua experimental viewer please review our testing Best Practices.
We need someone with Mac OS-X Yosemite to build a Mac version. Past Mac build is on an earlier OS-X and due to other uses it cannot be upgraded to Yosemite at this time. Potential volunteers can contact me via email at firstname.lastname@example.org.
For linux users who want to compile/build KokuaNT; instructions are in the repository README.
April 23rd, 2015 by NickyP
Release 22.214.171.124441 brings Kokua to Second Life version 3.7.27, a Maintenance Release cohort, 3.7.26 Hoover Height cohort, and to RLV version 2.9.9.
Thanks to Gavin Hird aka Dayturn, for help sorting out OpenSim economy issues.
Gavin develops an OpenSim grid which uses Mac as its server host. I don’t think he is ready for direct log on yet (Gavin comment if different) but, his grid is Hypergrid capable. Additional information is available at the xmir blog.
If a test version is currently installed, the automatic update feature will not function. A separate download and install is needed.
Kokua does not use the RLV start-up restriction feature. This feature causes the viewer to have a black screen for as much as a minute when first starting the viewer. If this feature is important to you, use the RLV viewer.
For a complete list of changes please see the change log. CHANGELOG.txt
Please refer to Release Notes for more detail about fixes and additions in this release.
Kokua’s ticket system has a vote for individual tickets. I would like to use this to determine which is most needed for bugs and which is most desired for features. Also, there is an accumulation of old tickets that need review. If you submitted a ticket under the old Redmine system, those were copied to the ticket system and need review for relevance.
Click takes you to the Downloads wiki.
February 21st, 2012 by ZATZAi
Volunteer to be a Dev/Tester/Etc for Imprudence (Not Kokua)
Sunday February 26th @ 20:00 UTC / 12:00pm Noon Pacific
Hoagie Sim @ 3rd Rock Grid
As many if not all of you are now aware, after a lot of input from the public and our own discussion and thoughts on the matter, the current team has decided to move ahead with Kokua development to the exclusion of Imprudence. However we wanted to find an answer for our users who still prefer/rely on Imprudence but we weren’t sure what that was going to be, which was why after the town hall we stated the future of Imprudence was still to be decided. One developer outside our team had desired to join us or some time now, but he wanted to work on Imprudence not Kokua. Some of you may be able to guess that his person was onefang rejected, create of Meta-Impy. This gave us a series of options on how to proceed with either depreciating or continuing support for Imprudence.
There was much internal discussion on how this should be handled, we definitely wanted to move the existing team to Kokua. This extra help certainly meant we could at a minimum push out a final 1.4 release of Imprudence, but was it possible to do more? We decided to take a chance, and for the first time create two teams under the Kokua/Imprudence project (Perhaps we should call it Team Purple to simplify the joint name); the existing team members would work on Kokua and a new team of separate devs would continue work on Imprudence. These would be devs who would otherwise not work on Kokua, and the Kokua devs would largely not involve themselves with development of Imprudence as Kokua is now the flagship project (Though we’ll have occasional joint meetings and try to help each other of course). So it was decided to invite onefang rejected to join the team as the head of the Imprudence project, he’ll have to staff his team with devs and volunteers who are passionate about Imprudence like himself, so for all of you who love Imprudence he’ll need your help.
Thus we will be holding an Imprudence town hall of sorts, this Sunday February 26th at 20:00 UTC (That’s 12:00pm Noon Pacific) at our usual meeting place on the Hoagie sim of the 3rd Rock Grid. The purpose of said meeting will be to enlist volunteers to help develop and test Imprudence going forward, and to decide what direction to take it in. However unlike the recent Kokua reorganization, this will not be a “reboot” of the project but a continuation. So for all of you out there who lamented the “death” of Imprudence, here is your chance. Join us this Sunday, be you a potential developer or tester and help us to bring Imprudence into the future alongside Kokua.
October 7th, 2011 by ZATZAi
It’s been a little while now from the change-over from Jacek to myself (ZATZAi) and I’m finally starting to get a handle on things. I have some projects I’m working on with the others here on the team to try and make your Imprudence experience better in the future. Here on the web site front the plan is to better integrate the wiki, the forum and the blog to provide a more seamless experience and to make it easy to everyone to find what they’re looking for. Whether you’re looking for where to report a bug or how to do it, where to give feedback, or how to get support… The plan is to make the site and it’s features more straight forward and accessible to users who need more information or want to communicate but don’t know what the proper channels are.
On the client front, we’ve recently released Imprudence 1.4 Beta 2 which fixed a great deal of bugs from the first beta and we continue to work on the next release (No timeline yet, but I’ll try to post something as we get closer). On that front we could use some help. If you have programming experience with C++ and the Mac or Linux 32bit platforms and would like to volunteer please get in touch with us. We’re of course interested in anyone who wants to volunteer, but we’re in particular need of developers for those two platforms. So if you have a passion for Virtual Worlds, C++ experience and can compile the client on Mac and/or Linux 32bit and would like to help develop the future of Imprudence/Kokua, then by all means drop us a lines.
Please send inquiries to me directly for now, I’ll set up a form on this blog to make it easier in the future.
zatzai (a) kokuaviewer.org
August 16th, 2011 by Jacek Antonelli
The Kokua/Imprudence Project is looking for several volunteers to join our team! Besides finding some people to take over some of my responsibilities after I retire, we also hope to attract more developers, so that we can gear up development on Kokua.
Our team is made up entirely of unpaid volunteers; this is purely a labor of love. You will have the opportunity to gain experience and hone your skills, while being part of a team of wonderful people, creating great software used by thousands of people!
If you are interested in any of these roles, contact email@example.com.
We are looking for a dedicated volunteer to help with project organization. The project organizer will be responsible for running our weekly meetings, keeping track of project progress, posting status updates on the blog, and generally making sure that things keep moving along smoothly. This role does not require any sort of programming skills, but does require excellent organizational and management skills, and good English writing skills. The project organizer should be able to dedicate 5–10 hours per week to this project.
We are looking for an experienced Mac developer to join our team. In addition to helping with general development (i.e. creating new features, fixing bugs, etc.), this developer would be responsible for preparing Mac releases of the viewer, porting/testing viewer features on Mac as necessary, investigating Mac-related bugs, and developing and maintaining Mac-specific features.
In addition to a Mac developer, we would like to add several more developers to our team, so that we can speed up the pace of development on Kokua. Ideally, developers should have some prior experience with C++ or similar programming languages. Most importantly, developers should have enthusiasm for participating in virtual worlds; a drive to create high quality, easy to use software; as well as respect for other people, and a desire to understand their needs.
It is up to each developer to decide how much time and energy they can invest in the project, but active developers are generally expected to be able to dedicate at least 10 hours per month on development and maintenance of the viewer software. Of course, even if you can’t dedicate yourself to being a full-fledged team member, we still greatly appreciate patches and other contributions from the community.
October 29th, 2010 by Codie
We are looking for friendly volunteer people to help our users in forums, IRC, and inworld groups on as many grids as possible. We need people with a good technical background, that can file bug reports or help users in any ways they can. Multilingual people would be most than welcome, and obviously, a good technical background about the usual viewer issues would be a plus.
Please contact CodeBastard Redgrave if you would be interested to help. I can be emailed at firstname.lastname@example.org. Please include your avatar name(s) and on which grid(s) you can help, languages you can speak, your usual availabilities, and your platform (Win, Mac, or Linux).
Looking forward to hear from you!
January 11th, 2009 by Jacek Antonelli
Greetings and happy new year, everyone! I’ve been a bit quiet around here lately — a series of computer hardware failures stole three weeks of Imprudence development time from me, starting right after we released 1.0.0. Phooey! But my computer is all better now, so it’s back to work for me.
Happily, McCabe has been marching along during that time, and as you can see from his latest post, sound (and even video!) is now working great on Windows! Even with my lost time, I think we should still be able to have an RC ready before the end of January.
The biggest problem now, though, is that we have no Mac developer! Sound isn’t functional on Mac — and worse, no progress is being made. We’ve simply got no one who can work on it.
Wherever possible, we try to have the same features available on all platforms. As a Linux user for many years, I know how it feels to be excluded because of your choice of operating system, and I’m not keen to put anyone else in that position. But it wouldn’t be right to hold back the other platforms indefinitely, waiting for help that may never come — we’d have to move forward, with the Mac version remaining silent.
But I hope it won’t come to that. I hope that someone with experience writing, compiling, linking, and debugging C++ programs on a Mac will step up soon and help their fellow Mac users out.