Tag: HTTP updates

SL project news week 46/2: Code freezes, avatar baking, interest list wierdness and more

Posted on by Inara Pey

Server Deployments

Wednesday November 14th saw the same code deployed to all three RC regions in preparation for the US Thanksgiving week code freeze (see below). This primarily brought all three RCs to the same code level, release-wise and fixed a bug discovered in week 45.

There will be no rolling restarts in week 47 (week commencing Monday 19th November) due to the code freeze.

SL Viewer Update

The beta viewer rolled to the last of the 3.4.2 releases on Thursday November 15th, with the release of 3.4.2266995. Providing the crash statistics remain good (they were very positive for the first 24 hours), it will be going to the production (release) viewer QA in week 47 and should result in the release of a new version of the viewer shortly after the Thanksgiving weekend.

This beta contains a lot of updates and improvements, as well as a wide range of fixes for issues encountered with earlier releases up to and including the previous beta release, 3.4.2.266708, issued on November 8th. For a comprehensive list of changes, please refer to the release notes.

At the same time, the development viewer rolled to 3.4.3.267061, marking a further update of the development viewer to the 3.4.3 code, which should be appearing in the next release of the beta viewer. This include the new viewer-side code for the HTTP texture fetch project developed by Monty Linden as a part of the Shining Project improvements.

The code for faster texture fetching / rezzing has moved from a project viewer into the viewer-development stream and is present in the 3.4.3267061 Ddevelopment viewer release and should appear in the beta viewer after the US Thanksgiving weekend

As the holiday period is approaching, viewer releases will be slowing down, but the aim remains to try to clear the backlog of waiting merges and updates by the New Year with a view to resuming their more usual cycle of releasing a development / beta update around every three weeks. Once things are back on track, LL will be looking more closely once again at the question of disabling tcmalloc completely within the viewer.

Code Change Freezes

The official dates for code change freezes during the upcoming holiday periods currently stand at:

  • Week 47 – Monday 19th November through to Sunday 25th November
  • Week 51 – Monday 17th December through Sunday 23rd December
  • Week 52 – Monday 24th December through Sunday 30th December.

No status has yet been given for the New Year week (Monday 31st December through Sunday 6th January 2013.

Avatar Baking

Bake fail: work on new service progressing

On Friday 16th November, Nyx Linden provided a brief update on the Avatar Baking project, which again forms a part of the Shining project improvements to Second Life. In short:

  • The viewer code is starting to look stable. However, merging the new code into the existing viewer code is liable to be somewhat more “painful” (Nyx’s term) than had been hoped
  • Work is progressing on the server-side elements (the composite baking server), with the code reaching a point where avatar texture can be generated server-side
  • Currently, the plan is to continue working on both sides of the equation, with the aim of ensuring the new code is successfully merged into the viewer development branch, and then offering it in a “very alpha” form to TPVs so that they can start merging it into their code and assist with testing. As this happens, one or two regions on the beta (Aditi) grid will be set-up to allow testing on the new service.

There is still no time frame for the appearance of the viewer code in the development branch or any test regions on Aditi, but in Nyx’s view, both are liable to be on the horizon “pretty soon”. Overall, the plan still remains to have at least a two month period from when the code is made available for testing purposes through to the official implementation of the new service.

Interest List Demonstration and Weirdness

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

This work is being undertaken by Andrew Linden in a number of stages, the first being to clean-up the code related to information sent to the viewer from the simulator relating to objects in the camera’s viewing range such that only objects actually in the camera frame are updated (if updates are required) and that objects outside of the current camera frame are not updated, thus reducing the amount of data both the server and the viewer need to process, which should lead to performance improvements.

It is possible to visualise the update process using a viewer debug setting (Develop > Show Info > Show Updates to objects or Ctrl+Alt+Shift+U) to show object updates being received by the viewer. This shows updates in three colours: red, which indicates the viewer is receiving a “full” update on the object (generally because it is being “seen” / is within draw distance) for the first time; blue, which indicates the viewer already has data on the object and is receiving “terse” updates relating to changes in the object’s appearance / position relative to the viewer’s camera position; and green, which indicates the object has been deleted / remove from the camera view, and updates are about to cease.

On the 15th November, Andrew used this debug setting, together with a set of scripted “bouncing” cubes to demonstrate his improvements to this update process. Observers were asked to focus their camera on the cubes, which were initially static and had no coloured data stream associated with them.  The cubes were then set bouncing, which generated a stream of blue “terse” updates, indicating the motion of the cubes in the viewer was being updated. However, when observers angled their camera to view the space above the cubes (so the cubes were not directly in their world view), the update stream ceased – indicating the viewer was no longer receiving update data for the cubes.

This may seem a small change, but it does dramatically decrease the amount of information the viewer has to process relating to in-world objects, and should result in performance improvements within the viewer. In the future, further work will be undertaken to enhance the interest list code even further – such as prioritising the order in which objects in the world view are actually rezzed, so that items closest to the camera view are rezzed first, etc.

HUD Issues

Following the demonstration, however, some people started noticing an odd issue: they could right-click on the centre of their screen and reveal a prim attachment belonging to someone else’s HUD. Chieron Tenk was the first to raise the issue, although Ana Stubbs also quickly reported the same problem.

Chieron Tenk posted an image of the problem: a prim appears in the centre of his viewer which, on inspection, appears to be linked to a HUD worn by Rex Cronin

After initial confusion, investigation revealed it was possible for anyone to find they had random prims from other people’s HUDs appearing on their screen, simply by attaching a HUD or a prim to their own screen. Concerns were further raised when it appeared that events might be able to be triggered if the prim was touchable.

I find I have a prim belonging to Ana Stubb’s Mystitool appearing on my screen

The issue appears to be tied to changes made to the interest list code on the test region, and is obviously going to be the subject of further investigation on the Lab’s part prior to the interest list project being carried forward.

Related Links

SL project news: week 42 / 2: viewer, mesh, shining and more

Posted on by Inara Pey

SL Viewer

After hopes that the latest beta version of the viewer would prove stable enough for things to start flowing again, it turns out that its crash rate is hovering around the 14% mark, with Oz reporting that a substantial portion of the crashes, which still appear to be related to memory problems, occurring as users exit the viewer. While these may go unnoticed by users, LL still want to bring the rate down to something closer to the release viewer (which is currently 10%).

As such, further candidate version of the beta viewer is being built, which should be released on Monday 22nd October with the hope that the changes being made will do just that. However, it is fair to say that the level of optimism within the Lab that this will be the case is currently low. Until the problem is resolved, further releases of code for projects are likely to remain blocked.

This issue is now the primary delay in moving a number of projects forward, including the Baker Linden’s Group Service project, Monty Linden’s HTTP texture project, updates for the Steam link-up and a host of other internal and contributed elements.

Mesh Deformer

A revised version of Darien Caldwell’s proposed addition for arbitrary shapes in the mesh uploader for us with the deformer

Darien Caldwell has been continuing to work on getting the deformer to work with arbitrary human shapes, and has some success. She has also ben working to refine the new options on the mesh uploader to cater for custom shapes, indenting the options to make it clear that they are a part of the Deform to Avatar Shape check box item (see right). Also, and while awaiting feedback from LL, she has moved the option to export an avatar shape as an XML file from a sub-menu on the Develop Menu (DEVELOP -> AVATAR -> APPEARANCE TO XML) to the Advanced Menu on her version of the Mesh Deformer project viewer.

However, as she comments on the JIRA (STORM-1716) for the deformer, there is also a problem.

Essentially, there are certain sliders (eleven in all) associated with armature bone length, which already deform mesh without using the deformer (see her JIRA comment for the full list of sliders). When these are adjusted to create a custom shape for making mesh items, problems arise because they are then deformed by both the viewer and the deformer, leading to odd results under certain situations.

The issue appears most pronounced when working on individual body elements, such as the upper body (as defined by SL) when using a custom shape (such as when creating a jacket). However, in a “full body” mesh, the problem is somewhat less pronounced.

Deformation issue: on the left, an “upper body” flesh-tome mesh (analogous to, say, a jacket) built to a custom shape is worn on that custom shape (in black). Note the mis-match. On the right, the same mesh, but combined with lower body elements applied to the same custom avatar shape. A much closer fit

As the sliders are placed closer to their default values, the issues become less and less pronounced. Darien had suspected this might be an issue, but until she started working with shapes other than the default, she had no way of determining if a problem existed. She has also a nagging concern that a small adjustment made to the deformer code itself might be having an unforeseen impact. However, from his own understanding as to how the deformer works and when discussing the matter at a delayed OpenDev meeting on Thursday 18th October, Oz Linden agreed this was unlikely to be the case.

When using custom shapes with the “problem” armatures set closer to their defaults, the problem is still present in “upper body” meshes (l) but is somewhat less pronounced, and again is barely noticeable on a “full body” mesh (r)

Currently, and assuming I’m understanding the matter correctly, the “fix” for this problem seems to be to define a custom avatar shape in SL, then adjust the eleven “problem” sliders to their default values prior to exporting the shape data to an XML file which is used shape to create the required mesh items (body, clothing). Once the finished items has been uploaded to SL, it can be worn with the shape and the desired settings for the eleven affected sliders can then be restored with the result that the mesh should deform as expected.

Darien will be carrying out further tests on the issue prior to offering her version of the deformer for wider use.

HTTP Libraries

As a result of beta viewer issues, it’ll be a while before everyone benefits from faster texture rezzing – but work continues on related services

While the viewer side of the new texture fetch library is blocked from going further than a project viewer at the moment, Monty Linden has resumed work on the server-side of things. Commenting on this at the TPV/Dev meeting on Friday 19th October, Monty had this to say, “I’ve been working on server-side work … and as part of the next part of the HTTP work, there will be a server change, grid change. sim OS change. And I just want to let everyone know that at some point we’re going to have to put up some beta servers on the beta grid and start some testing … It will be an interesting change to the services.”

This work is related to the number of connection an agent can have open to a given service – essentially the development of a “fairness policy” with regards to service connections. The changes and the policy itself are liable to be fairly dynamic as they come into effect and LL monitor use and potential abuse and start to focus down on ensuring a reasonable balance is met. This will require extensive testing from TPVs to ensure their viewers are handling the new services correctly, whether they can operate within the policy in terms of number of retries or back-offs on a failed connection, etc., and whether they need to limit the number of connections users can manually open (where this is the case).

Other Bits

Viewer and FMOD

No major news on this since reporting it in week 41. It is still LL’s intention to do something about it, however no resource has been allocated to it as yet  – with emphasis on the “yet” from Oz Linden. One of the hold-ups here is (again) the ongoing problems with the beta viewer, which require resources and effort to resolve.

Mountain Lion Support

The the TPV/Dev meeting on Friday 19th October, Oz reported that the Lab were making “great strides” on updating their Mac support for OSX 10.8 Mountain Lion, including gatekeeper support, and that the information should be available “quite shortly”.

64-bit Builds of the Official Viewer

The subject of 64-bit one that frequently arises in relation to the official viewer, particularly when mentions is made of memory leaks and the like, and it comes up not only among users. Remarking on it in the TPV/Dev meeting, Oz Linden said, “It is a bullet we have not yet decided to bite, but at some point we’re going to have to.”

He went on to point out that LL are already approaching a point where they’ll have to build OSX versions of the viewer in both 32-, and 64-bit, and that, “At some point the cost/benefit will tip the other way.” As such, he stated that any help LL can get from TPV developers in getting the code “64-bit clean”, etc., would be welcomed. In the meantime LAA support for the viewer has been merged into the development viewer (viewer dev) and is locked behind the current issues with the beta viewer.

SL projects update, September 26th

Posted on by Inara Pey
Update 28th September: Please also refer to an update post on some of the projects / news given here.

SL Viewer Status Updates

Linden Lab have been working hard on a range of viewer-related issues, notably crash rates and memory leaks, which have slowed the viewer update a release process up over the last few weeks. In terms of memory leaks, tcmalloc has been identified as the culprit, with Linden Lab deciding that dropping it is “probably a good idea”, according to Oz (tcmalloc has previously been implicated in crashes linked to the use of things like Microsoft’s Skydrive). There have also been an issues with LL’s statistics system which have meant that the viewer hasn’t necessarily been accurately tracked in terms of crash rates, etc.

Beta Releases

As it stands, LL hope to have the blocks on the various code merges removed during this week, which should see a rapid series of beta releases coming down the pipe. This work commenced with an initial 3.4.1 beta release (3.4.1.265134) emerging on September 24th. It will be followed by around three or so additional and rapid 3.4.1 build iterations aimed at confirming the viewer’s stability and at replacing various fixes which had previously been removed from the viewer code while trying to identify the causes for the viewer crashing / suffering memory leaks. It is expected that each of these iterations will be on the beta release build channel for a couple of days, prior to being replaced. Following these there will be a series of project updates, the first of which gatekeeper compliance project, which is also targeted for a 3.4.1 release build.

Project-related Releases

Once the stability of the beta viewer has been confirmed, it is anticipated that project-related code will be merged into the viewer, most likely starting with 3.4.2 builds. Among the releases planned for 3.4.2 is Monty Linden’s HTTP Library Services and Baker Linden’s Group Services code. These are currently targeted to reach the beta build channel in week 40 (week commencing Monday October 5th).

These releases will at some point include the Steam updates currently in a Development branch as well, which might in turn mean that Second Life could be ready to appear on Steam in the very near future, once these updates have reached a release version of the viewer.

Account creation prompt: heading for the beta viewer

Group Services Project

The Group Services project is an attempt to improve the management and editing of large SL groups by replacing the current UDP-based service (which has capacity issues with the size of group lists it can comfortably handle) with a new HTTP-based service. The project viewer for this is already available (for Windows, Linux and OSX.), however, as mentioned above, the current plan is to get this into the 3.4.2 build stream alongside the HTTP textures project, possibly in week 40.

Originally, the server code for this project was due to have been rolled to the RC channels during week 38, (week commencing September 17th), but the channel deploys were postponed after QA issues were found. As a consequence, the roll-out was due to take place on Wednesday 26th September, but has again been postponed.

There has been some confusion as to the aim of this project, with some people believing it is focused on fixing group chat issues such as  lag and chat failing to start. This is not the case at all; as stated above, the project is aimed at improving the management and editing of large groups (10K+) through the use of a new HTTP service.

HTTP Library Services

As indicated above, the first phase of this work, covering a new texture fetch service, should be appearing in a 3.4.2 beta release of the viewer in the near future.

HTTP Libraries project viewer: improved texture loading and rezzing

Please use the page numbers below left to continue reading this article

Pages: 1 2

Recent SL viewer activities

Posted on by Inara Pey

It’s been a while since I’ve reviewed any of the official SL viewers from LL, so here’s a quick round-up of recent releases.

New Log-in / Account Creation Prompt

The new account creation prompt, displayed if the viewer does not locate any user settings files on a computer, and which first appeared in the 3.4.1.263582 release (August 16th), now looks to be the default option for all development / project viewers. It is part of both the most recent Mesh Deformer project viewer (3.4.1.264215, August 31st), and the new HTTP Group Services project viewer (3.4.1.264495, September 7th). However, it has yet to filter through to either the Beta or release versions of the Viewer.

Account creation prompt: now standard on all development / project releases of the SL viewer released since August 16th (click to enlarge)

Mesh Deformer Project

August 31st saw a new release of the Mesh Deformer (3.4.1.264215), which includes a revised mesh uploader floater with deformation options for the male and female shape.

New deformation options

According to Nalates Urriah, the new options invalidate all test items so far provided for the project, and new samples are now required, although no comments to this effect appear to have been made on the JIRA or elsewhere, so they may have been confined to a user group meeting. Details on how to provide test items can be found in Oz’s forum post on the matter. The JIRA (STORM-1716) for this project is still open for viewing and comment.

Group Services Project Viewer

As noted this week, there is now a Group Services (group management) project viewer available for testing the new HTTP group management service. The server-side of this project has yet to be rolled-out to Aditi, so it cannot be tested as yet. However, Baker Linden, who is developing the service, is apparently updating the JIRA, SVC-4968 (which is still publicly viewable) with the project status, and has indicated he’ll post when the server-side elements are available for testing.

The viewer is available in Windows, Linux and OSX flavours.

HTTP Libraries Viewer

The HTTP Libraries project viewer (3.3.3.262585) appeared on July 27th. This project, which Monty Linden is driving, is currently aimed at improving texture downloading and rezzing as a part of the Shining project.

HTTP Libraries project viewer: improved texture loading and rezzing

Texture loading / rezzing would appear to be significantly faster on this viewer compared with other offerings, although there also appear to be what might be placebo effects associated with it. Some people have reported that floaters, etc., seem to load more slowly, and some have reported various performance improvements outside of the HTTP library changes.

Beta Viewer and Release Viewers

The Beta viewer (3.4.0.264445 at the time of writing) continues to be focused on pathfinding, with fixes and updates going into it on a weekly basis – which is why the pathfinding tools have yet to release a release version of the viewer.  The removal of JIRA numbers from the release notes now means that tracking issues previously being watched is that much harder (even if the JIRA themselves are no longer accessible, having the JIRA numbers still visible facilities easier identification of issues being specifically tracked).

Similarly, the release viewer (3.3.4.264214) appears to be focused on bug fixes and general improvements, with the release notes currently benefiting from the retention of JIRA numbers, making scanning for specific fixes easier.

Performance

I carried out basic performance tests on the viewers listed above using Dimrill Dale as my sample sim, during a period when there were the same number of avatars in the region (5, including myself). Tests were carried out in the same location on the region, looking in the same direction and with the same viewer settings (e.g. Graphics on high, Draw Distance set to 260m, using default time-of-day, with deferred disabled / with deferred enabled and lighting set to Sun/Moon+projectors, etc.). While all such tests are rough-and-ready, these did tend to show that all of the viewers offer the same performance on my default PC (see the sidebar panel on the right of this blog’s home page for system details). My results were:

  • Non-deferred: 18-20fps
  • Deferred with Sun/Moon+ projectors: 8-10fps

Similar figures were also obtained using the current Firestorm and Exodus viewers, although with deferred enabled and Sun/Moon+projectors active, Firestorm was slightly down at an average of 17-18fps, the other viewers being closer to an average of 19-20fps.

HTTP and Group Services updates

Posted on by Inara Pey

There are a number of projects underway at the moment to improve various aspects of Second Life performance. Some of these have been reported on as a part of the Shining Project, others are being dealt with elsewhere are reported on through the likes of the SL Scripting User Group and the fortnightly TPV/Developer meetings.

The following is by way of a brief update on the ongoing HTTP Library and Group Management projects with information taken from the most recent TPV/Developer meeting (recording link).

HTTP Library

The focus of this aspect of the Shining Project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / viewer communications, and it is under the management of Monty Linden.

Discussion on progress with the project commences at 36:36 into the recording.

The project code (textures only) is with the Linden Lab QA team and is expected to be in the 3.4.1 viewer once it has been released by QA. In the meantime, the HTTP project viewer was updated at the end of July. Many people are noticing improvements in viewer performance that go beyond initial texture loading, although there have been reports of other aspects of the viewer which use HTTP apparently being “slower” to use. This latter issue is most likely a false impression, with Monty commenting at the August 24th meeting that, “Most parts shouldn’t be affected. It’s competitive, when you’re doing both texture downloading and some of that work … but other things aren’t being cheated if you’re not downloading textures at the time.”

An issue has been noted in older Macbook Pro systems (late 2007 into 2008 dual-core systems, although the span of the problem isn’t clear) using nVidia drivers, wherein the expected speed-up with cached data which can be seen on other systems isn’t occurring. Monty is still investigating this. Overall, however, feedback on this project has been positive.

Group Management Functions

Large group loading: a familiar problem

Baker Linden has been working to resolve this problem, and his plan is also to go the HTTP route, which will require changes on both the server and the viewer sides of the equation. His comments on progress start at 42:53 into the TPV/Developer meeting recording.

The server-side code for an initial implementation of the solution has been passed to LL’s QA and is expected to be rolled to selected regions on the Beta (Aditi) grid soon.

In terms of the viewer, the plan is to develop a Project Viewer, which will be made available in the near future for people to use with the Aditi test regions. How soon this viewer is likely to appear is open to question – the code will initially need to be passed by LL’s QA (who may have received it on the 24th August) prior to the viewer being built. Once in the project viewer repository, the code will also be available for TPVs to produce test viewers of their own.

How long the testing period will last is also open to question and dependent upon feedback / issues arising. However, the plan will be to follow the usual pattern for roll-outs in that once the code has been tested on Aditi and necessary updates made, it will be rolled to a main grid RC for more more involved testing. This is important, as there is a significant different in the number and sizes of groups operating on the two grids. For example, the largest group on Aditi numbers some 40,000 members; on the main grid the largest group is about 112K, and there are many more groups with between 40K and 112K members.

One thing that has been made clear is that there will be no attempt at backward compatibility with V1-based viewers on the Lab’s part; the new code will be aimed solely at the V3 code base. However, V1-based viewers will still be able to use the UDP protocols for group management, although the LL servers will limit UDP access to groups with 10K members or fewer, so V1-viewers will have some more code backporting on their hands.

There will also initially be some issues around the new HTTP protocol. For example, in the first implementation, the data will be uncompressed. This means that a 40K member group is around 5Mb in size, which can take up to a few minutes to download, depending on someone’s connection speed, so some frustrations are liable to continue. While data compression will eventually be used, this is not planned for the initial implementation.

The discussion involved providing an option to routinely clear-down group lists based on people’s last log-in date, or who have not logged in for a (group owner specified) number of days. However, LL are not going to implement such a feature on the grounds that it could lead to mistakes being made, and people being accidentally removed from a group.

Time Scale and Implementation

As mentioned above, there is no definitive time scale for this work to be completed. Testing is liable to take several weeks at the very least, so it is unlikely the new group management capabilities will be rolled-out on a widespread basis for at least another month, or possibly longer.

However, and like the upcoming new avatar bake service, once the server code is available on the grid, the switch-over will be transparent. If a viewer has the code to use the new group management HTTP service, it will do so, if it has not been updated, it will continue to use the UDP service (with the aforementioned 10K “cap”) until such time as that capability is “retired” from the grid.

Project Shining: project viewer released for new HTTP Library

Posted on by Inara Pey

A part of the Shining project is to improve the underpinning HTTP messaging that is crucial to simulator / simulator and simulator / Viewer communications. As commented upon in the notes from the TPV/Developer meeting on July 13th, the initial focus on this project is to provide an initial texture fetch library for the viewer, together with a “wrapper” that will allow further http code enhancements to be added over time.

On Friday July 27th, Linden Lab made the initial code available within an LL project viewer (SL Alternate Viewers). The availability of the code, and LL’s plans / hopes for it were discussed during the TPV/Developer meeting also held on the 27th July. The discussion can be heard in full on the meeting recording, the key points from which have been summarised below.

During the discussion, both Oz and Monty Linden (who is leading the project) had the following to say:

  • The code is currently free-standing, although there will eventually be server-side protocol changes made to better support it (as well as further capabilities to be added to the libraries), which should further improve robustness and overall performance
  • Even without the server-side changes, the Lab hopes that the code itself will make things “a little bit better” for those using older routers, particularly Linksys WRT routers (Monty indicated server-side work would most probably be required to improve things for people using Belkin G-series routers)
  • While  the libraries are close to what is expected to be the “final” code (barring bug-fixes, etc.), it is unlikely they will be integrated into the Development Viewer for at least the next two weeks. The reason for this is two-fold:
    • The code needs to be merged-up with 3.4.0
    • Integration is dependent upon what kind of experience is had with the code “in the field”
  • LL hope that people will use the project viewer, and TPV developers will integrate it into experimental releases of their own, so that greater feedback (via JIRA entries, etc.) can be obtained in terms of:
    • General experience reports – completeness, reliability, robustness, improved rezzing, etc.
    • Whether the new code is helping to ease the strain faced by the likes of Linksys WRT routers, and what (if anything) it is doing to people’s home networks
    • (From the TPV developers themselves) design comments on the code itself, whether it is felt things have been missed, if there are issues in integrating the code into TPVs, etc.

Again, note that the code is currently only related to textures; the “more ubiquitous” uses (as Oz has previously put it) of the new http library within the viewer have yet to be implemented, so HTTP inventory, etc., is currently unchanged.

Oz asked the question (of Monty), as to whether it would be a problem if TPV developers were to convert some of the additional HTTP functionality for use with the library. Monty didn’t see any major issues, other than the new library introduces the concept of a policy class, rather than the current global priority scheme, and this has not been fully implemented as yet, because it is not required in this first pass. However, additional functions could share the policy used for HTTP textures, and that would “still be productive”. Monty further indicated that there is a “to do list of intent” included in the code as a file, which TPV developers can look at if they are minded to look at committing to some of the work themselves.

Related Links