Replex: A new viewer for SL and OpenSim

Replex-logoLatif Khalifa is well-known if the viewer community. Not only does he maintain the very excellent Radegast lightweight client for SL and OpenSim, he has also been a regular contributor to Singularity, the popular viewer using the v1-style UI. Now Latif is working on a v1-style viewer of his own.

Replex is still very much in the alpha phase of work; as such, there is no formal release version of the viewer, but alpha builds are available for download with the caveat that there is no official support as yet. There is, however, an in-world group where questions can be asked of other users and information exchanged. There is also an IRC chatroom #replex on Freenode where the developers can be reached via an IRC client or Freenode webchat.

The viewer itself is based on Singularity, unsurprisingly, given Latif’s close ties with that team, and there is an acknowledgement on the Replex website of their role in providing the Singularity source code. The viewer is available in Windows and Linux flavours as both 32-bit and 64-bit builds, and also for Mac in a 32-bit build.

The following is a very brief overview of the viewer; I don’t pretend to have covered all the options and capabilities; rather I’m just pin-pointing some of the features it includes.

Replex is a v1-style viewer based on Singularity
Replex is a v1-style viewer based on Singularity

As might be expected given its heritage, Replex has a default skin with a decidedly dark tint to it – although not so far towards the black default of Singularity, more a charcoal colour. The Singularity dark skin is also available via Preferences > Skins, as is the classic LL  v1.x blue skin and – something I’ve not seen in a while – the equally classic LL silver skin; this brought back some very old memories, as that was my preferred viewer 1.x skin when it came out.

The Replex change log lists recent features and additions to the viewer, and these are handily split between “Common” updates, indicating they are shared with Singularity (presumably in an upcoming release of that viewer), and those specific to Replex.

Toolbar Buttons

One of the more interesting updates from Singularity which appears in Replex is the ability to add / remove buttons from the viewer’s toolbar, a-la 3.x viewers. Obviously, buttons are restricted to the bottom of the viewer, but this is liable to be of interest to users as it allows some degree of customisation in the UI.

Change the buttosn you have displayed at the bottom of the viewer window in Replex, and coming soon to Singularity
Change the buttons you have displayed at the bottom of the viewer window in Replex, and coming soon to Singularity

Adding / removing buttons is a simple matter of opening the button chooser (View > Change Toolbar Buttons) and then checking those buttons to be displayed and unchecked those which are not wanted. There are a fair number of button options available, including debug options, windlight / sky /water / post-process effects, camera & movement controls, search options, etc. This can mean the button bar can get a trifle packed and a little hard to read if you go button bananas, but the feature is certainly a useful addition to the v1-style UI. Kudos, Lirusaito for the development work!

Emergency Teleport

Oddly enough, during the Simulator User Group meeting on Tuesday June 17th, a wibni (“Wouldn’t it be nice if”) comments was made about having a viewer-side capability to automatically teleport you somewhere if you happen to be AFK when a region restart occurs, rather than being logged-out.

I’ve no idea if the comment was passed as a result of someone peeking into the Singularity repository or taking Replex for a drive, because Replex has implemented this very capability using code also from Lirusaito.

Replex includes the option to define two LMs for auto teleporting you away from a region restart, should you be AFK
Replex includes the option to define two LMs for auto teleporting you away from a region restart, should you be AFK

Continue reading “Replex: A new viewer for SL and OpenSim”

Group bans: an overview

On Tuesday June 17th, Linden Lab released the Group Ban project viewer (version 3.7.8.290887) which, as the name suggests, allows group owners (and those they nominate by role) to ban individuals from their group.

Group bans, which are enforced server-side, like parcel and estate bans, are intended to remove troublemakers from a group / prevent them from joining the group. This article will hopefully provide an overview of the group ban tools within the project viewer (and which will eventually progress to the release viewer).

The following general points with group bans should be noted:

  • By default, only a group’s Owners role has the Manage Ban List ability for banning other avatars from a group /removing avatars from the ban list
  • The ability can be granted to other roles, if required
  • Roles which are granted this ability are also granted the Eject Members from this Group and Remove Members from Roles abilities
  • The ban list for a group can store a maximum of 500 entries. When this limit is reached, some avatars must be removed before others can be added
  • Group Owners cannot be banned from a group (just as they cannot be ejected)
  • When a group member is banned from the group, they are automatically ejected and will receive the usual ejection notification, but will not receive any notice that they have also been banned
  • A user who is banned from a group cannot join it either directly or through an invitation
  • If a group member is banned while using group chat, they may be able to continue using it until they close the group chat window (this problem also exists when ejecting someone from a group when they have the group chat window open)
  • Any attempt to invite one or more banned avatars into a group, whether individually or as a part of a list, will generate the message:  Some residents have not been sent an invite due to being banned from the group.

The viewer itself includes the necessary options to allow a group owner (and those they nominate by role) to:

  • Add or remove avatars from the group ban list
  • View the group ban list
  • Add the ability to ban avatars from a group to any other roles within the group, if required.

Applying Group Bans

Avatars can be banned from a group in one of two ways:

  • By selecting them in the group members list if they are already a member of the group
  • By using the Group Ban Picker to ban one or more avatars from a group, whether or not they are already members.

Banning via the Members List

  • Display your groups list (CTRL-SHIFT-G), select the required group and open its profile
  • Click on Roles & Members to open it, and then click on the Members tab
  • Locate the first avatar you wish to ban and left-click on their name
  • If there is more than one avatar you wish to ban, press CTRL and left-click on each of the remaining names
  • Click on the Ban Member(s) button
  • The highlighted avatars will be ejected and banned from the group, and you should see the normal confirmatory notification(s) that they have been ejected.
Banning someone from a public droup via the Members tab (l), and confirming they are listed as banned on the Banned Residents tab (r)
Banning someone from a public group via the Members tab (l), and confirming they are listed as banned on the Banned Residents tab (r)

To confirm the selected individuals have been ejected and banned, click the right scroll buttons at the top of the panel to scroll / jump to the Banned Residents tab. This should display the name of all avatars banned from the group. If the name(s) of the avatar(s) just banned do not appear to be listed, wait a minute or two and click the refresh button in the lower left corner of the panel. Continue reading “Group bans: an overview”

SL projects update 25/1: server, viewer, pathfinding and surprise guest

The Simulator User Group meeting on Tuesday June 17th was busy even before the unannounced guest dropped in (see below)
The Simulator User Group meeting on Tuesday June 17th was getting busy even before the unannounced guest dropped in (see below)

Server Deploys, Week 24

As usual, please refer to the server deployment thread for the latest information.

Main (SLS) Channel

On Tuesday June 17th, the Main channel was updated with the Group Ban project, which was previously on the LeTigre RC.  As the name implies, this project adds the ability to ban users from groups (see also SL Viewer Updates, below) – release notes.

Release Candidate Channels

On Wednesday June 18th the three RC channels should be updated as follows:

  • LeTigre should receive a new server maintenance project this week, which comprises an anti-griefing measure – release notes
  • BlueSteel should remain on the Sunshine / AIS v3 project, the viewer for which was promoted to the de facto release viewer (version 3.7.9.290582) on Monday June 16th. In addition, BlueSteel should receive the Main channel update with the Group Ban project and the anti-griefing update deployed to LeTigre – release notes
  • Magnum should remain on the Experience Tools project. In addition, Magnum should will receive the Main channel update with the Group Ban project and the anti-griefing update deployed to LeTigre – release notes.

SL Viewer Updates

Release Viewer

On Monday June 16th, the MemShine release candidate viewer, (version 3.7.9.290582, was promoted to the de facto release viewer. This viewer includes the final Sunshine AIS v3 updates (promoting the Lab to issue a blog post announcing the long-running project Shining is now complete), and also a series of memory leak fixes to help stabilise the viewer and hopefully reduce the number of memory related crashes.

Group Ban project Viewer

As noted above server-side support for the Group Ban project is being deployed to the main grid. To coincide with this, the Lab issued the Group Ban project viewer (version 3.7.8.290887) on Tuesday June 17th, which provides the necessary viewer-side support for accessing group ban functions. Initial instructions for using the viewer can be found in the release notes, and I’ve provided an overview as well.

Group Chat

Simon Linden recently completed an initial amount of work on group chat, implementing some small-scale optimisations which, while not expected to have “fixed” group chat, should have improved some aspects of using it, reliability-wise. He’s more recently had to work on what have been viewed higher priority items, but is hoping to make a return to group chat in the very near future and dig into it some more. “I learned a lot on the first pass,” he said on the matter during the Simulator User Group meeting on Tuesday June 17th, “we got a lot more information on where the load is.  Thus I have hopes the next round will be better.”

Other Items

Pathfinding and Terrain Editing

BUG-772 “Simulator refusing to rez objects after 10 hour timeframe” was raised at the Simulator User Group meeting on Tuesday June 17th. This is an issue where if you are carrying out terraforming work on a region with pathfinding enabled, and are also making frequent Pathfinding navmesh updates, your region will rapidly run out of memory. the way to avoid this is to complete the terraforming activity, then rebake the navmesh and restart the region.

LSL Enhancements

Ideas were tossed around the Simulator User Group meeting on the limitations of LSL, many of which may only be resolved through a complete re-build of LSL, something which is unlikely to happen, as Simon Linden indicated in the meeting, “I don’t think we’re going to touch the internal design of LSL if we can help it.” Which doesn’t mean there will not continue to be enhancements to LSL functions etc.

One suggestion made to get around some of the issues was for the development of a viewer-side scripting language which might handle certain local functions and abilities. Responding to this, Simon would only say, “That would be a wonderfully big project :).”

Continue reading “SL projects update 25/1: server, viewer, pathfinding and surprise guest”

METAbolt updates to 0.9.71.0

Metabolt-logoMETAbolt is a lightweight text-based client for Second Life and OpenSim offering a range of features and capabilities. At the start of the year, there had been concerns that due to the long delay between updates (the last being August 2013), work on the client had stopped.

However, as I reported in February, this was not the case, but rather CasperTech were stepping-in to take over the project, as was announced on the METAbolt website at the time.

While it has taken a while for things to move forward since then, the initial interim updates from CasperTech have now started to appear.

The updated METAbolt log-in / splash screen highlighting the fact CasperTech are now maintaining it (Feb 2014)
The updated METAbolt log-in / splash screen highlighting the fact CasperTech are now maintaining it (Feb 2014)

The first of these was to update METAbolt from release 0.9.69.0 (Beta) to version 0.9.70.0 (release notes) on June 13th. As an interim update, this release did not bring with it new features or capabilities, but focused more on bug fixes and under-the-hood updates:

  • Bug fixes from CasperTech and contributed by users – for which CasperTach pass on thanks
  • The removal of x64 support – the viewer is now 32-bit focused and installs into C:\Program Files (x86) by default. The reason given for this is, “If METAbolt uses over 4gb of memory, it’s really not doing its job as a lightweight text client. Let’s use faster 32-bit pointers instead!”
  • Initial work on providing Mono support for Linux and Mac compatibility, although as the release notes state, it will be a while yet before this is complete

As this release resulted in an issue with METAbolt plugins, June 14th saw the release of version 0.9.71.0 (release notes) which, as well as fixing the plugins problem, also added a digital signature to the installer to prevent any security warnings from popping up on download.

Both of the releases present METAbolt as an installer .EXE, rather than packaging them as a ZIP file containing the installer and support files, as with previous versions. A little more work is required on cleaning-up some elements, as the installer does still refer to “METAbolt (64 bit)” and defaults to naming the installation folder “METAbolt (64 bit)” under Program Files (x86). However, this is purely a cosmetic thing, and not something that interferes with using the client.

The latest releases mostly contain under-the-hood updates and bug fixes. However a major code refactor for METAbolt is underway
The latest releases mostly contain under-the-hood updates and bug fixes. However a major code refactor for METAbolt is underway

Given the focus with these updates is on under-the-hood changes, the look and feel ofMETAbolt remains largely unchanged from earlier recent releases, other than the revised log-in / splash screen. Which is not to say additional work isn’t already underway.Tom Mettam, now leading the METAbolt project indicates that there is a major code refactor underway; as a part of this, CasperTech apparently plan to offer “bounties” for people willing to assist with the work. Those interested are advised to keep and eye on the Issues section of the METAbolt GitHub tracker for more information.

While I have not covered every release of METAbolt through this blog, those unfamiliar with the client may want to read my initial review, mush of which still appears to be relevant, and check the METAbolt category of this blog for those updates I do have.

Related links

Viewer release summaries 2014: week 24

Updates for the week ending: Sunday June 15th, 2014

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information

Official LL Viewers

  • Current viewer release: no change from version 3.7.8.289922
  • Release channel cohorts (See my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • MemPlug and Sunshine / AIS v3 RCs removed, superceded by the Memshine RC released in week 23
  • Project viewers:

LL Viewer Resources

Third-party Viewers

V3-style

  • Black Dragon updated to version 2.3.9.9 on June 9th – core updates: please refer to the release notes (included here as the update had been published at the time of going to press)

V1-style

  • No Updates

Mobile / Other Clients

  • Metabolt updated to version 0.9.70.0 on June 13th and then 0.9.71.0 on June 14th – core updates:  bug fixes; initial work to provide Mono support for Linux / Max compatibility; removal of x64-bit version; fix for broken plugin issue; digital signature added to installer to prevent security warnings during download – release notes (both versions)

Additional TPV Resources

Related Links

SL projects update 24/2: viewer, LSL materials functions

 Server Deployments Week 24 – Recap

  • There was no new deployment to the Main (SLS) channel, although it was subject to a grid-wide restart following schedule maintenance on Tuesday June 10th
  • BlueSteel returned to the Sunshine / AISv3  inventory update, which requires the use of the Sunshine RC Viewer
  • LeTigre once more had the server-side group ban project updates deployed to it. See the release notes for details
  • Magnum returned to the Experience Tools project.

The RC channel updates were essentially the same updates as deployed in week 23, but subsequently overwritten following a grid-wide security issue update.

SL Viewer

The Snowstorm code contributions viewer appeared as a project viewer on June 12th. Version 3.7.9.290788 includes some 20 code contributions to the viewer, including:

  • STORM-68 Allow setting of default permissions on creation of objects, clothing, scripts, notecards, etc.
The new floater for setting default permissions for created items as it should appear in the Snowstorm viewer
The new floater for setting default permissions for created items as it should appear in the Snowstorm viewer
  • STORM-1831 Obtain LSL syntax table from simulator so that it is always up to date: this update allows the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to, eliminating issues with using manually updated syntax files within the viewer falling out-of-synch with the simulators as new LSL syntax as new functions and parameters, etc., are added
  • STORM-1966 Block installation on old and unpatched versions of Windows: this updates causes the viewer’s Windows installer to check to see Windows XP systems have the latest patches installed (i.e. Service Pack 3 for 32-bit XP and Service Pack 2 for 64-bit XP). Any XP systems not meeting these requirements will be unable to install the viewer until such time as they are updated. Additionally, Windows Vista and Windows 7 systems  lacking a Service Pack update will receive a warning, but installation of the viewer will not be blocked

For the full list of OPEN and STORM updates, please refer to the release notes.

LSL Functions for Materials

The Server Beta Meeting on Thursday June 12th included tests to see whether the new LSL functions for materials might offer griefing opportunities. Maestro Linden had created two 256 prim linksets using default prim cubes, one of which was scripted to use PRIM_NORMAL to continuously set a unique material on each of the 6 faces of each prim, and the other was scripted to continuously set PRIM_TEXTURE on each face to a different alpha-blended diffuse texture.

Two sets of four of these objects were rezzed in turn, and meeting attendees asked to monitor their viewer performance (FPS and UDP bandwidth) while the Lab watched the simulator.

Server-wise, performance was largely unaffected by either type of object, with the load being largely controlled by the built-in LSL performance controls. Throughout both tests, and with no  objects rezzed, script spare time remained almost constant around the 14-15ms mark.

Viewer-wise, both types of object impacted FPS, with most people reporting around a 50% drop from the materials-enabled objects, compared to around 40% with the texture changing objects.

Both tests saw an increase in UDP information being sent to the viewer, with bandwidth use increasing by a factor of around 3.5 to 4 (e.g. 180-200kbps to 700-800kbps) with the materials objects and a factor of around 5 to 5.5 for the texture changing objects. As indicated by Maestro, the lower bandwidth use by the materials objects was due to the throttles already in place for how quickly the viewer will look up materials properties.

The takeaway from this (and other tests Maestro has performed) is that scripted materials controls are unlikely to be a major source of griefing. The simulator seems to handle excessive use of script materials in its stride, and impacts on the viewer’s frame rate can be mitigated by using Develop > Show Updates to Objects (CTRL-ALT-SHIIFT-U) to block the offending object.

There are still concerns over potential bandwidth impacts, such as by combining the materials LSL functions with other scripted controls, and concerns how the viewer might be affected by peculiar uses of the materials functions (such as combining them with the already laggy animated mesh tails that are available). However, it seems that for now, the Lab will continue to monitor things to see what happens and whether anything unexpected does crop-up, rather than moving immediately to apply throttles to the functions.

In the meantime, the arrival of these functions has prompted people to start putting together feature requests to be able to animate diffuse (texture), normal and specular maps on an object / object face independently to one another. The Lab has previously indicated that trying to do this via llSetTextureAnim() would be “pretty ugly to implement or would need some careful design …” and that as such they have no plans to try this at present. It’ll be interesting to see if any feature request(s) put forward persuade them otherwise.