On Saturday December 14th 2013, the Firestorm team hosted another informal question-and-answer session. While the meeting was recorded, the Firestorm team are aware that many of their users have hearing difficulties, and / or prefer to read text. It is because of this that this transcript has been provided.
When reading it, please remember:
This is not a word-for-word transcript of the entire meeting. While all quotes given are as they are spoken in the video, to assist in readability and maintain the flow of conversation, not all asides, jokes, interruptions, etc., have been included in the text presented here
If there are any sizeable gaps in comments from a speaker which resulted from asides, repetition, questions to others etc,, these are indicated by the use of “…”
Timestamps are provided as guidance should anyone wish to hear the comments in full from any speaker on the video
Questions /comments were made in chat while speakers were talking. This inevitably meant that replies to questions would lag well behind when they were originally asked. To provide context between questions and answers, questions in the transcript are given (in italics) at the point at which each is addressed by a member of the Firestorm team, either in voice or via chat.
Please note: This transcript is provided for informational purposes only. As such, questions on technical issues relating to Firestorm and / or project-specific questions cannot be answered here unless one of the Firestorm team drops by.
The TL;DR Summary
The numbers in braces are timestamps which refer to the section of this transcript where more details can be read, and to the section of the video recording where the relevant comments can be heard.
Main Discussion:
The next release: will most likely be a stabilisation of the code currently in 4.5.1 rather than introducing major updates, although this is still to be determined. LL have a lot coming down the pipe, which Jessica was hoping would be ready for inclusion in the next release, but that is looking unlikely unless something significant happens to change things [0:00:25-0:02:48]
Response to the beta has been good, around 120,000 downloads, of which around 6,000 are for the Windows 64-bit version. A number of people have subsequently reverted back to the 4.4.2 release due to issues. There are significant issues with voice, Mac users have encountered issues arising from Cococa (Mac and Voice issues covered later as well).[0:02:48-0:06:03]
Reference is often made to “Linden Bugs”. This does not necessarily mean they are the Lab’s fault; it simply means that the SL viewer has the same issues [0:06:03-0:06:53]
Firestorm releases are currently roughly four months apart. Ideally this should be two months, which is a target, but needs to be balanced with the risk of overwhelming the support volunteers (who need to both learn and support new releases). Therefore, it might mean a compromise of a release every quarter [0:06:53-0:09:40]
Voice issues: Vivox problem, LL have it as well. Firestorm have a series of videos demonstrating the problem. If a user on FS 4.5.1 beta has the issue, the recommendation is to revert to the 4.4.2 release [0:09:53-0:10:46]
The FS Windows 64-bit has been well received and feedback has been positive. Most people are reporting imporved stability rather than improved performance compared to the 32-bit version [0:11:10-0:12:56]
Oculus Rift is coming to Second Life [0:13:10-0:15:27]
Leap Motion is coming to Second Life – and the Firestorm Team have taken a lead in the integration work with the viewer [0:15:27-0:22:49]
Firestorm 4.5.1 beta and Firestorm release numbering explained [0:23:02-0:26:35]
Why Firestorm block versions and why Phoenix isn’t currently blocked [0:52:02-0:58:41; 1::0036-1:02:56]
Firestorm Q&As qill be monthly from January, alternating between 08:00 SLT and 16:00 SLT month-by–month [1:12:03]
Q&A Session:
Would it be an option to have different branches for people to download …? – includes discussion on why FS does not have nightly builds and on joining the FS beta testers [0:27:56-0:37:32]
Can we hope for more tattoo layers? [0:37:35-0:39:19] – reply includes reference to Linden Lab User Group meetings, the forums in which such questions can be asked
Will the new version [of Firestorm] be in 64-bit, and is Fitted Mesh coming? [0:40:00-0:47:40]
Why is IM and local chat so laggy in the beta version of Firestorm? (Mac build) – known issue, with both Firestorm (FIRE-12172) and LL JIRAs raised against it [0:47:40-0:49:47]
Why will music streaming not work on 4.4.2 with the new Mac OS upgrade? – Mac OS X 10.9 Mavericks issue reported under FIRE-10630 There is also a list of Cocoa bugs specific to the Mac build [0:49:47-0:52:02]
Dealing with inventory “jump” issues and bug regressions [0:52:02-1:00:36]
Are older versions of Firestorm also blocked from OpenSim when they are blocked from SL? – any version prior to 4.4.2 will unfortunately be blocked from OpenSim when blocked from SL. All versions of FS from 4.4.2 onwards can be individually blocked from grids [1:02:56-1:04:13]
Has the FS team ever considered working on a mobile Firestorm product? – includes the FS April Fools from 2013, and accessing Firestorm remotely [1:04:16-1:10:17]
Has the FS team considered “drawing a line” on how far they’re veer from the LL codebase (e.g. additional feature input, etc.), in order to improve the release cycle and lessen the maintenance overheads? [1:13:20-1:21:01]
What drives the FS team to do what they do? [1:21:40]
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Tuesday December 10th, 2013 saw the main channel updated with the server maintenance project that was on the RC channels in week 49. This project includes a few miscellaneous bug fixes
Wednesday December 11th, 2013 saw the three RC channels updated with a new server maintenance project containing a single bug fix.
The RC channel bug fix is related to vehicles getting into a “bad” state where they appear sat upon / selected even if they have lost their passengers as a result of a region crossing. When in this state, they defeat the parcel / region auto return.
As the fix for this issue is currently only on the three RC channels and will not be promoted to the main channel until 2014 due to the code freeze / no change window, and because this issue may lead to vehicles accumulating in regions where there is a lot of traffic, Maestro Linden has requested that support move any main channel regions which are affected to an RC channel.
2014
These deployments were the last scheduled deployments for 2013. They also mark the last scheduled rolling restarts for the year as well, as there are no plans to restart any channels in either week 51 or week 52. The only exception to this will be if any major issue / fault occurs within the grid which necessitates a restart.
The next scheduled server-side deployments will take place in week 2 of 2014, the week commencing Monday January 6th, 2014.
Some information on updates which will be forthcoming in 2014 were given during the final Server Beta meeting of 2013. These include:
Andrew Linden’s work on “Uniform Scaling” LSL Functions for linksets (see part 1 of this week’s report). There are a couple of basic rules with the new functions: no prim in the linsket can be smaller than 1 cm or larger than 64m, and all prim centres must be within 54m of one another in order to be linkable. There will be two new functions as a part of this work:
integer llScaleByFactor(float factor): uniformly scale a linkset by the specified factor (e.g. 2.0 to double the scale). Returns TRUE if successful, FALSE otherwise
float llGetMaxScaleFactor(), float llGetMinScaleFactor(): return the maximum / minimum scale factors that will work in llScaleByFactor due to limits in place by prim scale and linkability distance restrictions
An update to llLoadURL, so it will have a 0.1s delay instead of 10s (although there is still a throttle in place to prevent someone from spamming somebody else in order to crash their viewer)
llGetObjectDetails() & OBJECT_STREAMING_COST will be amended to return data when targeting an agent. Currently, OBJECT_STREAMING_COST doesn’t give you much of anything when targeting an agent; once this change is in place, it will return the sum of the streaming costs of all worn attachments (excluding HUDs)
SL Viewer
The “Project Interesting” (viewer-interesting) RC viewer updated on Thursday December 12th to version 3.6.13.284757, which includes a number of fixes from the initial release:
BUG-4675 Viewer crashes while reading chat history
SH-4606 Interesting: Small objects do not load until they are very close.
SH-4627 [INTERESTING RC] “Object out of range” is not detected on teleport.
SH-4631 [INTERESTING RC] Parts of linked objects are not shown in new release Second Life 3.6.11
SH-4641 Interesting: Incorrect amount of system memory detected on Mac
This may be the last RC update for 2013, unless something like the Google Breakpad RC is slipped out for another round of testing on Friday December 13th.
STORM-68
As noted in part 2 of this week’s report, STORM-68 is a third-party contribution which will allow a builder / creator to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. Further testing has been taking place since my last update, and a number of issues and bugs have been resolved as a result. The test plan for the changes is complete and the viewer-side changes now look ready to go to LL’s internal QA. Again, this change requires server-side updates, so it is unlikely to appear in an RC viewer until the server updates are reasonably available on the grid, although this will hopefully happen in the early part of 2014.
Thursday December 12th saw the Kokua team release version 3.6.12.30743 of the viewer. This appears to be a fairly contained update, focused on updating the viewer with the recent SL viewer 3.6.11 GPU Table updates and the 3.6.12 NameUpdater changes. Neither of these involved functional changes to the viewer from LL’s side, but do bring Kokua to parity with the current SL 3.6.12 code base.
UK-english dictionary added to the spelling checker
Removal of packaged PCRE libraries from Linux 64-bit builds as they caused web kit to fail to load on newer Debian based distributions.
The release notes also point out that when the viewer is started for the first time following installation, there will be a notice and link to check graphics drive availability. The Kokua team urge caution if the option is taken to update drivers, as system breakages have resulted in the past. They also point out that the notice is a recommendation to check for updated drivers, not a requirement to update.
The CtrlAltStudio and UKanDo TPVs have both undergone self-certification and have been added to the Third-party Viewer Directory (TPVD).
The associated wiki page for CtrlAltStudio describes the viewer as :
The CtrlAltStudio Viewer has been set up in order to try out and share a number of ideas, the first being stereoscopic 3D display and some initial Oculus Rift support . It is based on the Firestorm Viewer which it tracks closely while adding particular features.
The associated wiki page for UKanDo describes the viewer as:
UKanDo gives a whole new perspective in Second life by using a camera placement adopted by the vast majority of third person video games.
Also includes RLV along with plenty of other useful tools. It won’t have all the gadgets/gizmos a lot of the bigger viewers have, the aim is to keep it as lite as possible with only the fixes, gadgets and gizmos we need to keep the Viewer stable and up-to-date! The Avatar happy! And to aid with building!
(Please note that descriptions are supplied by the viewer developers, not Linden Lab.)
Congratulations to both viewers, both of which I’ve been following in these pages. You can catch-up with them as follows:
The future of mesh garments / wearables created using the now SL-defunct mesh deformer was the subject of some discussion at the Open-source Contributions meeting on Wednesday 11th December. While the deformer was never officially adopted by the Lab for use within Second Life, it was available in various test and experimental viewers, and the code could also be included in self-compiled viewers if people knew how.
Fitted mesh is coming….what of the future for garments made for / via the deformer?
This means that there are garments within Second Life that were created and uploaded for / with the deformer code, and which can resize with viewers using that code. However, as is the case with Fitted Mesh, the clothing would not deform when using a viewer without the requisite code. The same will be true once the Fitted Mesh updates reach a release candidate status and start to be more widely adopted: while Fitted Mesh (and Liquid Mesh) garments, etc. will deform to an avatar’s shape, items created using the mesh deformer will not; they will continue to behave like any other rigged mesh item.
This likely means that as the Fitted Mesh code does become more widely adopted, people will stop using any garments / attachables created using the deformer code, and the availability of such items in SL and on the SL marketplace will decline over time.
Whether or not this means deformer-based items will vanish from people’s inventories is something only time will tell. From the Lab’s perspective, the work involved in trying to pro-actively determine a method of identifying assets using the deformer code and removing them from the asset servers / inventories isn’t likely to be worth the end result. Therefore anyone with “old” mesh deformer garments and attachables will probably retain them until they opt to delete them from their inventory.
It appears unlikely that viewers using the deformer code will be pro-actively blocked from SL. What is likely to happen is that the code simply will not be formally adopted by those variants of TPVs which do not connect to any other grid than Second Life. However, this does leave a further interesting question as to the future of the mesh deformer, which has potentially seen far wider use in OpenSim communities than Second Life. While it would seem likely OpenSim will adopt the viewer-side changes required to enable Fitted Mesh (at least in the majority of cases), at this point in time, it is not clear whether the mesh deformer will be entirely abandoned. Whether there will be sufficient pressure within OpenSim for the deformer code to remain in use, and whether TPVs will feel obliged to incorporate the deformer into their viewers / OpenSim variants of their viewers as a result, remains to be seen. Currently, the only grid which has any kind of significant investment in the deformer is InWorldz, which provided funds for the code to be further enhanced and adopted it into their dedicated viewer in July 2013.
Materials and Numbers
Statistics are always a hard thing to determine. Back in the day, there was much controversy over figures released as to the adoption of mesh within SL following its deployment. The figures offered-up by the Lab at the time were vague enough that they could be taken to mean that mesh was either being rapidly adopted, or was seeing very slow growth (with the reality lying somewhere in between). This was not an attempt by the Lab to fudge issues at the time; it simply underlined the fact that numbers aren’t always the best means of trying to quantify something, so it’s perhaps better to allow the passage of time to speak for itself.
The most recent figures for materials suggest that over half of the regions in SL now have at least one materials-enabled item within them, and around 10% of avatars apparently utilise at least one materials-enabled item. Again, these are figures that are likely to be interpreted either way, depending on how people look upon materials as a whole. Certainly, the term “object” is sufficiently vague so as to be pretty worthless as am objective yardstick, as it likely covers everything from an individual prim through to entire linksets, which leads to a huge variance in the visibility of objects using materials. On a personal note, I can only say I’ve made extensive use of materials in my house, and am more than pleased with the results.
I’ve used materials on my house; particularly on the stonework and stucco textures to provide added depth. Materials on the whole appears to be slowly gaining momentum
Upcoming Code Contributions
There are a number of third-party code contributions in development for the SL viewer, some of which I’ve previously reported upon, and which are now progressing towards a point where they may well have public visibility through the likes of a release candidate in the new year.
STORM-1981 and STORM-1831
STORM-1981, contributed by Jonathan Yap, is intended to change the behaviour of tracking beacons to help make locating items in a region somewhat easier (e.g. locating lost items or scripted objects which are causing issues, etc.). Under these changes:
Beacons would begin at a height of 0 metres and extend up to the maximum unassisted flight ceiling (5,020 metres)
The beacon colour will be blue from 0 metres to the base height of the object being tracked, and red from 5,020 metres down to the height of the object being tracked
Users can optionally set the beacon to pulse towards the target object using the CheesyBeacon debug setting (Advanced->Highlighting). The blue beacon will pulse up towards the object, the red beacon will pulse down towards the object.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.
STORM-1831 covers the work being undertaken by Ima Mechanic, with assistance from Oz Linden, to improve syntax highlighting in the viewer’s LSL editor by allowing the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to. This should eliminate issues with the current manually updated files used to manage syntax highlighting falling out-of-synch with new LSL syntax as new functions and parameters, etc., are added. Folded-in to this work should also be a change to the source code text allowance in the viewer’s LSL editor, increasing it from the current 65,000 characters to around 256,000.
The server-side cap updates required for both STORM-68 and STORM-1831 have been combined and passed into the simulator release stream, and while it is unclear as to when the cap updates will reach a server-side release candidate package, their progress is being tracked. Obviously, both STORM-1981 and STORM-1831 require viewer-side updates as well, and these will hopefully appear in viewer release candidate form once the server-side updates are sufficiently deployed.
STORM-68
A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. STORM-68 aims to add a similar capability to the LL viewer (and which will quite possibly supersede the capability in TPVs once implemented). This work is again coming from Jonathan Yap, although it requires server-side updates, which Andrew Linden has been taking care of. However, this work has hit some problems in viewer / server interactions, which may be down to timing issues between requests and acknowledgements being sent between the viewer and the simulator and vice-versa. As such, further testing is required, so it’s possible this work might take a little longer to appear in the new year.
As always, please refer to the week’s forum deployment thread for the latest news and updates.
Second Life Server (main channel) – Tuesday December 10th, 2013
The main channel was updates with the server maintenance project that was on the RC channels in week 49. This project includes a few miscellaneous bug fixes. These include a fix for BUG-4431, which Maestro Linden, speaking at the Server Beta meeting on Thursday December 5th, described as:
A fix for avatars with crouch / crouchwalk animation overrides. Previously, the llGetAgentInfo() LSL function would only return AGENT_CROUCHING if the avatar was playing the default crouch or crouchwalk animations, so if your avatar had an AO which replaced those animations, (either with llSetAnimationOverride() or possibly with classic AOs too), scripts couldn’t tell when you’re crouching. But with the fix, the function is looking at whether you’re actually crouching, regardless of which animations are playing.
This should be the only “visible” fix within the package.
Second Life Release Candidate Channels – Wednesday December 11th, 2013
All three RC channels should receive a new server maintenance project containing a single bug fix related to vehicles becoming stuck in the ‘sat upon’ state (which prevents parcel auto return).
This issue is related to vehicles getting into a “bad” state if they lose the passenger right at region crossing. The vehicle is left with what is effectively a “ghost rider” sitting in it, which defeats parcel auto return, leaving the vehicle in-world.
SL Viewer
The SL release viewer was updated on Tuesday December 10th to version 3.6.12.284506, formerly the NameUpdater release candidate. This release does not contain any updates to the viewer’s functionality, but does change installer naming and fixes an updater issue.
Code Freeze / No Change Window
Week 50 marks the last week for deployments to release, main and RC channels by the Lab for both the viewer and the servers prior to the Christmas / New Year code freeze / no change window commencing on Monday December 16th. The no change window extends through until the start of January, and will see no significant releases (other than possible emergency updates, if they are required), although there may still be updates to project viewers.
The main reason for the no change window is to allow Linden staff, notably support personnel, have a decent break over the holiday period without the risk of having to deal with significant issues as a result of a change or update immediately prior to the actual holiday period. To ensure this is the case, the code freeze starts ahead of the actual holiday period so that the Lab can ensure those final releases for the year which are made are robust and stable and unlikely to give a major cause for concern while still having staff available to deal with matters should things get a little higgledy-piggledy*.
Other Items
“Uniform Scaling” LSL Functions
Andrew Linden has been working on a set of “uniform scaling” LSL options which would allow an object / linsket to be rescaled via a single LSL call – such as uniformly increasing or decreasing its size by a factor of 2. The work is still experimental and won’t be deployed until 2014. However, commenting on the work at the Simulator User Group meeting on Tuesday December 10th, he said:
One problem with scaling by multiplicative factor is that the scale operation might fail for a number of reasons; there are four categories of failures: hit the “prim is too small” limit. (2) hit the “prim is too big” limit (3) violation of linkability rules for linked set (when making bigger) (4) misc failures because of navmesh or other things.
The current API includes three calls: (A) llGetMinScaleFactor(), (B) llGetMaxScaleFactor() ; (C) llScaleByFactor(float). I currently handle failures (1) through (3), and the llScaleByFactor() will return FALSE if it fails, but it won’t tell you why it failed. You can use llGetMaxScaleFactor() and friend to ask what the max/min multiplicative factors are possible for reasons (1) through (3). Needs some work, but it is in progress.
A further concern / failure point was raised at the meeting: rescaling an object containing mesh and hitting the land capacity for a region as a result of the LI value increasing. One suggestion for avoiding this would be to have a function which could determine how far an object can be scaled prior to hitting the capacity limit for a parcel (e.g. returns the potential LI for a given scale value before an object is rescaled; however how this might be accurately achieved is unclear, particularly as LI scaling with mesh objects can be subject to a range of factors.
It will be interesting to see how this progresses.
*For those unfamiliar with the term “higgledy-piggledy”, I offer the following explanation:
Higgledy-piggledy explained courtesy of Mr. Berke Breathed
Alina Lyvette released version 2.5.6 of the Android Second Life / OpenSim Lumiya client on Sunday December 8th, with a further release of version 2.5.7 on Monday December 9th; with both came a chance to have a real play with my latest toy: a gorgeous new Asus Google Nexus 7 HD 2013!
Between them, these two updates comprise:
2.5.6:
View your own profile and your transaction history
Send and receive group invites;
Persistent mute/block list support
Improved performance when handling large chat histories and of flexible prims in 3D mode
Fixes for an issue with touching complex mesh objects and a few known crash issues.
2.5.7:
Quick fix for broken Unicode support in instant messages
Support for editing scripts, both in inventory and objects.
Note that with this review, I am using a 7-inch display screen, and so have split screens enabled. If you are using a device with a smaller screen / without spilt screen functionality enabled, your screen displays may differ from those shown in this review. All examples may not be the only means of accessing specific functions; they are based on my preferred usage of Lumiya.
Viewing Your Own Profile or Transaction History
Until now, Lumiya has only offered the opportunity to view other people’s profiles. With version 2.5.6+ you can now view your own. you can also view your transaction history, which will list any transactions made during your current log-in session.
To view your profile, display the Chat or 3D world view and tap on the More option (three vertical dots) at the top-right of the screen. This will open a menu of additional options. Tap on My Avatar.
If you have split screens enabled, your profile will be displayed on the right, with the My Avatar options on the left
If you are not using split screens, tap My Profile to display your profile.
To view your transaction history, follow the steps above to display the My Avatar options, then tap L$ Balance option. All transactions which have taken place while you’ve been logged-in will be displayed.
Send and Receive Group Invites
Lumiya 2.5.6 starts into providing more group management functions with the ability to send / group invites with those groups in which you have be granted the required ability, or to receive group invites from others.
Sending A Group Invite
Currently, you can only send an invite to join a group to people recorded on your Recent, Friends or Nearby lists, there is no name picker to allow you to search for and invite anyone.
Tap Chat to display your Chat / Group options
Tap the name of a group to which you wish to invite new members. The group’s panel will open
Tap the invite icon located at the top right of the group’s panel.
Lumiya 2.5.6+: the new invite option for inviting people to join your groups
A pop-up is displayed, allowing you to select the person you wish to invite from your Recent, Friends or Nearby Lists
Tap the name of the person you wish to extend an invite. A role picker pop-up is displayed
Tap the role you wish to assign to the person. The role is selected and an invite is automatically sent.
Receiving a Group Invite
As with any graphical viewer, when you receive an invitation to join a group, Lumiya displays the invitation in you Chat panel, with the name of the person sending the invitation, details of the group you are being invited to join and option buttons to join the group or decline the invitation.
Persistent Mute / Block
Lumiya 2.5.6 introduces the ability to mute / block IMs and group chat sessions, either for the current log-in session or persistently across all sessions until the block is lifted.
Muting an Individual or Group
There are a number of ways to mute an individual or group:
Muting via the chat list:
If the person or group you wish to mute is in your local chat list, long-touch the name.
A pop-up menu is displayed:
If you have selected an individual, it will include the option to Block them. Tap this. You will be prompted to confirm your action; doing so will add the individual to your Block list
If you have selected a group, it will include an option to Close and Mute the group chat. Tapping this will prompt whether you wish to mute the group chat for just the current log-in session or permanently (until unblocked). Tap the required option to add the group to your Block list.
You can mute / block group chat for your current log-in session or persistently across all log-in sessions, including via other viewers
Muting via the Friends, Group or Nearby lists or from within an IM or Group chat session:
You can block someone via an open IM session, or by starting an IM session and selecting the mute option
Select the individual you wish to mute / block from your Friends or Nearby lists OR tap on the name of the group you wish to mute chat from in your Group list
The IM or Group chat panel will open. Tap the More option icon (three vertical buttons) to display a further list of options. Tap Mute.
You will be prompted whether you wish to cancel, or mute the individual / group for the current session or persistently across all log-ins – tap your desired preference.
Muting an individual in group chat:
Long-touch the individual’s name within the Group chat panel
A pop-up is displayed allowing you to Copy Message Text or Block the individual
Tap Block to add the individual to your Block list.
Muting via the Block list:
From Chat or the 3D world view, click the More icon (three vertical dots) in the top right of the screen
Tap My Avatar
Tap Block List to display a list of blocked individuals, groups and objects
Tap the ADD button (top right of the list)
A pop-up is displayed for your Recent, Friends and Nearby lists. Tap the required list to display a list of names
Tap on the avatar name you wish to block, it will be added to your Block list
Repeat for any additional names you wish to block.
Blocking an Object
To block a spammy object:
Locate it in Chat and long-touch it
A pop-up is displayed which includes the option to Block it
Tap the Block option to add the object to your Block list.
Unmuting / Unblocking an Individual, Group or Object
The easiest way to unblock an individual or group is via your More menu:
From Chat (or the 3D world view, click the More icon (three vertical dots) to display further menu options
Click My Avatar
Click Block List to display a list of blocked individuals, groups and objects
Scroll through the list to the item you wish to unblock and long-touch You’ll be prompted to confirm the action
Once you have confirmed, the individual, group or object will be unblocked.
Note that you can also unmute an individual or group by tapping on the name in your Friends / Nearby / Group list to start an IM / Group chat session, then tapping the More icon and tapping the Unmute option.
Script Editing
Lumiya 2.5.7 allows users to view and edit scripts to which they have the requisite rights both from within inventory and contained within an object.
Open a Script from Inventory
Tap the Inventory icon to open the Inventory panel
Navigate to the folder containing the script to be edited
Locate the script in the folder’s contents and tap it
The script editor is displayed, together with the selected script in view mode.
Open a Script in an Object
In the 3D world view, long-touch the object containing the script you wish to edit
Tap the More button to display additional options
Tap Open Contents. A panel displaying the objects content is displayed
Locate and tap the script to be edited. The script editor is displayed, together with the selected script in view mode.
Lumiya 2.5.7+: viewing and editing your scripts
Editing a Script
Tap the Edit Script button at the bottom of the script editor
Position the cursor at the point at which you wish to start editing
Use the Save or Discard Changes buttons as required.
Lumiya on the Nexus 7 HD 2013
And now, a short aside.
Until now, I’ve been running Lumiya on a Samsung Galaxy S2. However, when updating my mobile (cell) phone recently, my new service provider offered me a bundled deal of a new ‘phone and free Nexus 7 HD 2013 (and other goodies) for the same monthly tariff rate I had been paying for just the S2. Needless to say, I took the deal.
Lumiya has always worked well on the S2 for me, although it did struggled at times and the relatively small screen tended to make some operations difficult. With the Nexus 7 HD, Lumiya is nothing short of glorious.
Not only do I now have the benefit of full split-screen functionality on a screen big enough to handle it when operating in landscape mode, I have the power of two quad-core processors to handle the application and graphics and twice the available memory to play with. As a result, the 3D view is a joy to behold and move around in, with very fast rendering (as compared to the S2), and much smoother movement – both of which go a long way towards making Lumiya even more of a desirable travel companion.
The in-world view is also given something of a boost as a result of the Nexus 7 HD’s screen resolution: 1920×1200 which is a higher resolution than I’m getting on my main monitor (1440×900) and at an amazing 323ppi. This presents a really crisp, clean in-world image when using the 3D view which is very pleasing to the eye; so much so that I don’t feel a screen cap really does it justice.
My home on Lumiya and the Nexus 7
The Nexus does still struggle when using the High Quality Textures setting, particularly at higher draw distances (48-96 metres), but given the load this is placing on the tablet in areas rich in textures, many of which will be of very high-resolution, I’m not actually surprised by this.
As I plan to use (and already have used) the Nexus to do “serious” work when moving around, I opted to invest in a bluetooth keyboard to go with it; and I have to say it is an absolute joy to have – part of this article was actually written on the Nexus using the keyboard and Kingsoft Office. The keyboard really adds to using Lumiya in that it obviously avoids the need to use the on-screen keypad, and the cursor keys / WASD keys can make moving around a lot more natural in feel if you’re used to using them on a viewer. Another benefit with a keyovard is the reduction in the amount of finger prints and smears appearing on the screen as you work.
I’m actually rather chuffed with the keyboard, which I obtained via ebay for £15.00 (around 18.00 Euros or $24.00 USD). When not in use it forms a protective cover for the screen, clipping securely around the tablet. Despite being aluminium in construction, it adds very little physical bulk to the Nexus when “closed”, and also has the benefit of solid-feeling keys which have a decent travel distance, which aids typing considerably. With Lumiya, it certainly adds a huge amount of ease to chatting and (now) to editing scripts! If you’re a Nexus user and decide to get one, just make sure you get the version which matches your Nexus model (2012 or 2013).
A suitable bluetooth keyboard can further enhance using Lumiya
Feedback
Two more outstanding updates for Lumiya which significantly enhance its capabilities, although on smaller screen the script editor may have limited appeal due to issues of trying to correctly position the cursor for editing and seeing what you’re actually doing when an on-screen keypad is open as well. On a tablet, the editor performs much better, although big fingers may still have problems positioning the cursor. As noted above, use of a suitable keyboard easily overcomes this problem (although are not always easy to use when on the move), and also makes chatting and IMs massively easier for those who aren’t keen on on-screen keypads.
The group and mute / block options are likely to be heartily welcomed by those putting Lumiya to extensive use and / or who routinely visit busy places. Both work very well using the methods I’ve indicated in these notes, and the functionality appears flawless.
All told, these are more than worthwhile updates to Lumiya further enhancing its reputation as the go-to solution for anyone on android who needs to access SL for a broad range of tasks while on the move.
On Saturday December 14th 2013, the Firestorm team hosted another informal question-and-answer session. While the meeting was recorded, the Firestorm team are aware that many of their users have hearing difficulties, and / or prefer to read text. It is because of this that this transcript has been provided.
Inara Pey: Living in a Modemworld 