Tag: Imprudence News

Imprudence catch-up

Posted on by Inara Pey

imprudenceI’ve been meaning to run a catch-up on Imprudence since mid-April; my apologies to Onefang Rejected and crew for not doing so sooner.

My last report on Imprudence, back at the end of February, made mention of the fact that Onefang, who had been working on the Meta-Impy viewer (itself forked from Imprudence 1.4.0), had come forward with a stated goal of continuing Imprudence’s development and joined the Kokua / Imprudence team. After that, things went quiet as far as the rest of the world was concerned. However, this didn’t mean nothing was being done.

Recent Updates

In April 2013, the team released first experimental version of Imprudence 1.4, referred to as 1.4.0.3 exp 0, the first major release of the 1.4.0 code which had been in beta status for a very long time.

The update included a lot of under-the-hood work with many bug fixes from numerous contributors, improvements to the build processes, code clean-ups, the removal of the Google translate option, updates to the grid list, port of inventory category capability from Cool VL viewer, addition of a MOAP radar, and security improvements to the storage of users’ passwords.

This was followed almost exactly a month later, in May 2013, by a further release – referred to as 1.4.0.3 experimental 1, and which included further fixes and updates which built on the work released in 1.4.0.3 experimental 0.

With both releases, Onefang took time out to address a range of questions on Imprudence, and roughly outline what the team hope to achieve. His comments were caveated by noting two important points:

  • There is a fair amount of catching-up to do, and it will take time for the team to get there, so people shouldn’t expect everything to be done at once
  • The team is small, and all of them volunteer to do the work. As such, it has to be slotted-in between real life obligations, etc. Therefore, progress may be subject to interruption, and users were (and are) asked to bear this in mind.

Looking Ahead

In terms of bringing Imprudence in-line with some of the major updates other viewers have / are seeing, Onefang had the following to say (as noted in his replies to comments following the 1.4.0.3 exp 0 release – scroll down to read all of his replies in full). There are no time scales attached to any of the following because, again, the team are working on a volunteer basis and are subject to RL interruptions and obligations which may impact progress in one or more areas.

MOAP (Media on a Prim)

Robin Cornelius provided the team with the MOAP radar functionality, and subsequently with a working patch which includes most of what is required to get MOAP working in Imprudence, so the team hope to have this working “soon”.

Mesh Rendering

Currently, imprudence uses the “old” rendering code which cannot render mesh objects (boxes, cylinders and weird shapes result). Replacing this code is a major task and will take time to complete. As such, the aim for the time being is to catch-up on other code elements and come back and address the issue of render code update / replacement for a later date.

However, Onefang has been experimenting with code that bypasses the bulk of the old render code for meshes, and steps in at the last moment to add the mesh after the rest of the render is done. This approach has worked well as a proof-of-concept, and he hopes that if it can be shown to work “for real”, it will offer a possible interim capability for Imprudence to render mesh until such time as the rendering code can be properly overhauled / replaced.

Imprudence and mesh
Imprudence doesn’t currently support mesh rendering, as shown above with the LAQ mesh cottage (see inset for how it should look). BUT, while it may take a while for comprehensive mesh rendering support to be implemented, Onefang Rejected is looking at an interim solution which may allow Imprudence users to correctly view mesh objects in-world

Second Life Server-side Baking / Appearance

The team plan to make Imprudence SSB/A compatible in the future. This will not happen prior to SSB/A going live across the SL main grid (Agni), nor is it likely to happen any time immediately after LL have deployed SSB/A. However, Imprudence will be looking to support it as and when they can.

Grey people will be the order of the day for Imprudence users on Second Life once SSB/A is deployed - at least until the Imprudence team get SSB/A support implement, which they are looking to do in the future
Grey people will be the order of the day for Imprudence users on Second Life once SSB/A is deployed – at least until the Imprudence team get SSB/A support implement, which they are looking to do in the future

Materials Processing

Again, earmarked for inclusion in Imprudence, but not necessarily on the immediate horizon.

Other Things on the List

Obviously, the above is not the extent of the team’s plans, but tends to represent the items they are most asked about. Overall, the “to do” list includes a lot of work and covers things such a multiple attachment support, pathfinding support (NPC support for OpenSim), avatar physics, parcel privacy support, scripting additions, RLV/a updates, HTTP updates, and more.

Progress on Imprudence can be tracked through the project issue tracker.

Patience, Young Padawan!

Imprudence remains a popular viewer, and runs well on OpenSim. That OneFang and the team are committed to keeping the viewer going and bring it up-to-par with other viewers and both with OpenSim and Second Life is to be highly commended. It may take a while for some of the updates to reach the light of day, so some patience may be in order for those who’d like to continue / resume using it with SL in particular.

Related Links

Call for Imprudence volunteers – meeting this weekend

Posted on by Inara Pey

When the decision to proceed with the development of Kokua was made, a problem remained for the Kokua / Imprudence team in how to support those users in the wider metaverse who still prefer to use – or even rely on – Imprudence. While the team hoped to be able to bring the 1.4 release of Imprudence to maturity, it was noted that this would only be done if it did not impact work on Kokua.

Following on from this, Onefang Rejected, aka David Seikel who is known to many as the developer of the Meta-Impy Viewer (itself based on Imprudence 1.4) stepped forward with a stated desire to continue Imprudence development.

As a result of Onefang’s willingness to volunteer himself, the Kokua team have opted to bring him into the fold as a team member, where he can hopefully build and lead an Imprudence-focused team that will work alongside of, but independently from, the core Kokua team.

To help establish this new Imprudence team, the Kokua / Imprudence project has put out a call for volunteers, requesting that anyone interested in getting involved in Imprudence as a  developer or tester or some form of support category put themselves forward. Those wishing to join the team are asked if they can attend the next All Hands meeting, which will be devoted to Imprudence and its future.

As ZATZAI (Sean Greyhound) put it in the Kokua blog, “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.”

The meeting will take place at the usual time and venue: 12:00 midday SLT (20:00 GMT), Sunday February 26th at the Hoagie sim of the 3rd Rock Grid. Requests for further information should be directed to the Kokua / Imprudence blog.

Imprudence celebrates its birthday and a new project organiser

Posted on by Inara Pey

Just on a month after Jacek Antonelli announced she would be retiring from the Kokua / Imprudence project, the team have announced they have a new project organiser in the shape of  ZATZAi Asturias.

ZATZAi, aka Sean Greyhound in SL, has been active in SL since 2005, and among other notable activities, helped organise the in-world elements of SLCC 2007, and his appointment has been warmly received.

Also, this weekend see Imprudence celebrate its third birthday, and the team are marking this with a series of events across a number of grids. In Thursday 1st, they celebrated on their “home” grid, 3rd Rock. Over Friday and Saturday, they’ll be travelling to InWorldz, OSGrid and Second Life, with an open invite for friends and supporters and everyone else to join them in celebrating. Here’s where:

  • Friday September 2nd:
  • Saturday September 3rd:
    • OSGrid at Imprudence, commencing at 13:00 PDT
    • Second Life at Rouge, commencing at 22:00pm PDT
Purple rules: the Imprudence sim on OSGrid

Happy birthday, Imprudence!

Jacek Antonelli announces retirement

Posted on by Inara Pey

Jacek Antonelli, one of the major driving forces behind Imprudence  / Kokua has today announced she is retiring form the Imprudence team. Her announcement in part reads:

After 3 years of serving this project, I will be retiring effective September 1. As often happens in life, the priorities in my life have shifted over time, and it is now time for me to focus on other things.

Obviously, this will be a major transition for the project. But, I will be working for the next month to make it as smooth as possible, so that everything can continue with minimal disruption. At this time, we have not yet decided who, if anyone, will replace me as “benevolent dictator“, or whether there will be some other form of project leadership. Of course, we will keep you guys informed as the details are fleshed out.

My retirement is not an occasion for somberness, but rather for fond reflection on the past, and hope-filled anticipation for the future. I am proud of the work we have done and what we have accomplished so far, and I look forward to the great things that will be accomplished after I am gone. What’s more, I am immensely proud that we have accomplished all this without compromising our principles or our integrity, even when the road was most difficult, and the temptation most pressing.

Imprudence has been a major force in the world of third-party Viewers, and the team, lead by Jacek, have rightly gained themselves a loyal and enthusiastic following. Over the years, Imprudence has often been a pathfinder for new functionality, and/ or has striven to meet the most-needed requirements of users.

It is not entirely clear what will be happening in the future – the team have a month to get things sorted out, and hopefully both Imprudence and the still in-initial-development Kokua will remain with us, and the vision of seeing Imprudence 1.4 stablised and Kokua gorwing into its worthy replacement will be realised over time.

As a former Imprudence user myself, I’ve always appreciated all the work the team has put into the Viewer, and I personally wish Jacek every good wish and every success, both in her virtual and real lives.

Thank you for everything you’ve done, Jacek.

Imprudence returns

Posted on by Inara Pey

Following the recent discussions on the TPVP which led to some needed rewording, Imprudence have announced they will continue to support Second Life.

While SL may no longer be the primary “market” for Imprudence (and Lord knows the OS environment needs a viewer with Imprudence’s strengths), that they have reversed their earlier, and somewhat irrational action is to be strongly commended. So to is their willingness to engage in the issue of clarifying concerns around the TPVP’s ill-considered wording.

Kudos, Imprudence!

TPV: First casualty

Posted on by Inara Pey

imprudenceImprudence issued a statement earlier this week that they are withdrawing from Second Life as a result of the Third Party Viewer (TPV) Policy. In the statement, they set out their reasons as to why they are withdrawing, pointing to clauses 2b, 4a(i), 4b(iii), 7a and 7d, and 8c and 8d as being “unreasonable”.

Having gone over the TPV a number of times, I have to say I find Imprudence’s position for the most part hard to understand, as their interpretation of four of the clauses then mention seems to be wilfully subjective and misleading; while their reaction to two more of the clauses seems to lack any professional clarity of thought.

Imprudence state that (4a)i, (4b)iii, 8(c ) and 8(d) require us to promise to obey Linden Lab’s every future whim and that as such, the Imprudence team are unwilling to make such broad promises, not knowing what they may request.

This is a very sweeping statement, with Imprudence further claiming that 8(c) requires that they agree to stop using or distributing the viewer at Linden Lab’s request and that 8(d) requires that they agree to add, modify, or remove parts of the viewer at Linden Lab’s request, within a time frame dictated by Linden Lab.

However, these claims can best be described as over-exaggerated. Here is what clause 8c actually states:

If a Third-Party Viewer or your use or distribution of it violates this Policy or any Linden Lab policy, your permission to access Second Life using the Third-Party Viewer shall terminate automatically. You acknowledge and agree that we may require you to stop using or distributing a Third-Party Viewer for accessing Second Life if we determine that there is a violation.

Note my emphasis: the qualifier is clear. If a third-party Viewer breaks the TPV Policy, the Linden Lab require it no longer access Second Life. This is far short of Imprudence’s blanket assertion that Linden Lab require they “agree to stop using or distributing the Viewer” – a denial of access to Second Life clearly does not prevent them from continuing to distribute their Viewer for use on OS Grids, etc.

Similarly, clause 8(d) states:

If you are a Third-Party Viewer Developer, you agree to provide any content, data, executables, or for Third-Party Viewers based on our viewers, any source code that we may request to verify compliance with our policies, licenses, the GPL, or the law. If we believe that your Third-Party Viewer is not in compliance, we may request that you add, modify, or remove features, functionality, code or content, and you agree to comply with the request within a reasonable timeframe specified by Linden Lab.

Again, note the qualifiers I’ve emphasised. There is really nothing unreasonable here – if you wish to play in Linden Lab’s sandbox – which, by connecting to their servers and services a Developer is in fact doing – then sorry, Linden Lab have the right to ensure, so far as is possible (or, as I’ve stated elsewhere, give the perception they are ensuring) that your code does not constitute a threat to their services in and of itself  (excluding, obviously, mods any user introduces – which the Developer should again be able to prove relatively easily via the provisioning of their own source code).

Similarly, it is hard to see why Imprudence should be so upset of clauses 4a(i) and 4b(iii). Clause 4a(i) refers  to data received from Linden Lab’s servers – data for which Linden Lab has certain legal responsibilities (likely to be both State and Federal in nature (such as data privacy laws). As such, their various policies, terms of service, etc., must reflect such requirements  – and by extension, they need to ensure (or again, give the perception) that they are doing all they can to ensure that this data is protected when used by the software connecting to their servers.

Similarly, clause 4b(iii) relates to the protection of user data and makes a perfectly reasonable request that third-party developers take steps to ensure such data is kept secure when passing through their systems (and remember, if you use their Viewer, your login information, etc., goes through their servers). As such, it is in Imprudence’s best interests to ensure such data is protected at least to the same degree as on the Linden Lab servers. It is hard to see Linden Lab being so stupid as to issue requests for user data protection that exceed their own, and frankly – one would hope that Imprudence already have the necessary safeguards in place to ensure the data is as secure as possible.

Given that both these clauses relate to potentially sensitive data, I find it hard to accept that Imprudence, as responsible code developers would find a request to take reasonable steps to protect such data objectionable.

Indeed, in this, I find Imprudence’s own assertion that If and when Linden Lab makes any request of us, we will use our own judgement to decide how best to handle that particular request to be at least as presumptive and arrogant as anything in the TPV – even to the point of suggesting that if they see little need to protect user data, then that is their call, and nothing to do with either Linden Lab or the users of the Imprudence viewer.

Frankly, when all four of these clauses are viewed in their proper context, it is very hard to see how any professional software developer would find them in and of themselves reasons to reject the TPV Policy. That the Imprudence team opt to refer to the clauses somewhat out of context and apply highly subjective interpretations to them suggests that it is the thinking at Imprudence that is at fault, not the thinking behind the policy itself.

Clauses 7a and (d) have been the source of much wailing and gnashing of teeth across the Viewer development community, but again – as I’ve previously said – it is hard to understand why. While 7(a) is indeed poorly worded, and unnecessarily mixes Viewer use with Viewer development – there is absolutely no reason why the entirety of Section 7 of the TPV cannot be handled by a Viewer developer issuing their own EULA as a part of the distribution / installation package. A responsibly written EULA would clearly protect the developer for undue liability, and wouldn’t be in violation of GPL.

Certainly, it is what Kirstenlee Cinquetti has already done with her Viewer – and I’m pleased to see at least one voice of reason on the Imprudence website has raised the same point.

Which brings us finally to clause 2b. And here Imprudence have a point. As stated, the TPV Policy effectively restricts the export of content from SL to the creator. Period. If the user’s name is not on every prim, every animation, pose, script, contained in a linkset or whatever – then it isn’t going to be exportable.

This does – to be fair – read as overly restrictive. As if one is to remain fair, the clause seems to be less related to preventing content theft as it is about preventing “valuable” content being removed from Second Life per se – which LL have always looked less-than-favourably upon. Frankly, it is hard to fully justify LL’s stance on limiting content export so tightly: this automatically disallows the export of Group-created content for the purposes of back-up, and also disallows the export of content created by one person but sold under a license agreement to another. As such, I can see Imprudence’s concerns – just as I can see the issue LL face in trying to invoke the perception of protecting people’s creations when given the crudeness of the ownership / permissions system.

I doubt Imprudence will be the last of third-party developers to walk away from the Second Life sandbox. Each one that does will be a loss to the community to some degree, to be sure. How many do so on the basis of rational thinking as opposed to acting in a fit of pique, however, remains to be seen; and I have to say that having gone through the stated reasoning behind Imprudence’s move, I do feel it is a case of pique getting the better of them.