Active within Second Life since 2008, Kev was heavily involved in BURN2, the Department of Public Works and SL8B, serving as a core team lead in all three, as well as being an advisor to the LEA.
A special commemoration and celebration of Kev’s SL life will be held on Saturday May 19th at the Burning Man Deep Hole region, from 18:00 through 21:00 SLT. All those who knew him, or who wish to remember his contributions to Second Life are invited to attend, memorials may be made to standup2cancer.org.
In addition, a photo memorial to Kev is being arranged: those wishing to contribute Second Life snapshots are asked to contact Marianne McCann in-world.
Condolences are offered to Kev’s family, and all who knew him in Second Life.
Given Daniel and Kev were close friends, I would ask that you leave messages of sympathy on Daniel’s blog as a mark of respect of their friendship and Daniel’s loss. Comments are therefore closed here. Thank you.
Simon Linden has posted to the Server topic area of the technology forum about a new SL server feature, “region idling” which commences today, Wednesday 16th May.
This will see those regions that do not have any avatars either in them or camming into them to lower their frame rates and script processing, thus reducing their load on their host CPU. This should in turn improve the performance of the other regions running on the same hardware.
The idling itself should be entirely transparent to users, with the region immediately returning to “full speed” should anyone enter the region or cam into it. However, Simon does warn of a possible caveat to the transparency:
We expect this feature to be totally transparent to users. Residents will not see or be on regions that are idling. Scripts, however, may observe the effect if they are using the llGetRegionTimeDilation() function, and may require fixing.
There are some additional points to note with this capability, which are addressed in an FAQ also posted to the forum. These include:
Regions are not turned off or shut down. They merely run at a slower frame rate when nobody is there. They will appear exactly the same way as before in search, the world map and other Second Life features
Region idling cannot be manually disabled for a region
Any scripts that use LSL network functions will suspend region idling for a short period of time to allow them to function normally. This will allow scripts that connect to outside services via email, http and xmlrpc to run as expected.
The roll-out of the function will commence with the Blue Steel release channel, and will then be progressively rolled-out to the rest of the grid in the coming weeks. Anyone suspecting region idling is having an adverse effect on their region is requested to file a JIRA (no specific project given), providing clear information on the problem and the exact times it happened.
Update 14th May: My thanks to Oz Linden for pointing out that if you apply a Local Texture in-world, and then modify the original image file in a suitable editing tool and save it again, the viewer picks up the change and automatically applies it in-world (see Comments). I’ve also clarified that Local Textures can be used for clothing and skins within the text of this article.
Local Textures is a means by which textures stored on your computer can be applied to in-world objects on a temporary basis, allowing you to judge their suitability for use prior to uploading.
In this, it combines functionality currently found in many third-party Viewers (TPVs) in the form of the Local Bitmap Browser, with the added capability of being able to apply a selected texture directly to an object in-world within your own world-View.
The option, contributed by Vaalith Jinn, the originator of the Local Textures Bitmap, has been available within a number of recent Development builds of the official Viewer, and is now available in the latest Beta release (255742), so expect to see it in a mainstream release very shortly. (It should also be noted that the option is already available in both Dolphin and Niran’s Viewer.)
Using Local Textures
Local Textures is accessed from the Texture tab of the Build floater:
Texture picker: note the Local radio button (circled)
Note that there are now two new radio buttons on the Texture Picker itself – Inventory and Local. The former will, naturally, allow you to browse the textures within your SL inventory as we’re all familiar to doing.
Clicking on the Local option, however will change the Picker to display the following:
Local texture panel
This contains three new buttons, described below.
Add: Opens a window allowing you to browse your hard drive(s) to find textures.
An individual texture can be selected by double left-clicking on it or by left-clicking once on it and then clicking OPEN
Multiple textures within a folder can be selected using either SHIFT-left-click or CTRL-left-click (which can also be used to de-select individual items from a multiple selection
Selected items are added to the list panel to the right of the buttons
You can browse as many folders as you wish and add items to your list, but you cannot select folders themselves
Remove: (only available if a texture is selected in the list panel) removes an unwanted texture from the list
Upload: (only available if a texture is selected in the list panel) will open the usual texture upload panel, allowing you to upload the selected texture to your inventory with the usual L$10 fee and use it from there. Note that bulk uploads are not supported from the button.
When you have added one or more textures to the list panel, clicking on an individual texture within the list will apply it to the selected object / object face. Note that as these are only local file associations, the applied texture will only be visible to you; no-one else will see the texture (the object/face will remain untextured in their view).
Applying a local texture – only visible in your own world view
Textures added to the list panel will remain available to you until such time as you log-out of Second Life, at which point this list will be emptied.
Note that clothing and skins can be tested in the same way – just use the Edit Appearance floater and the New Clothes / New Skins options.
Local Textures and Temporary Textures
Local Textures might also sound like the Temporary Textures upload capability also found in many TPVs, but there are notable differences:
Temporary textures appear in your inventory, usually with the prefix “temp” for the duration of your current session in SL, then they are lost
Temporary textures can be see in-world by people other than yourself; this makes it ideal for things like collaborative building, where joint decisions need to be made prior to the selection and upload of textures
There have been rumours that LL are looking to “break” temporary texture uploads with the release of Local Textures. This does not appear to be the case at present; LL have so far given TPV developers no indication that they expect to see Temporary Textures removed from Viewers. Certainly, Dolphin is running with both Temporary Texture uploads and Local Texture; providing LL do not indicate they have a problem with this, it is likely that other TPVs will opt to do the same.
However, it might be worth noting that Temporary Textures do rely on using a feature in a manner in which it is not intended to be used, and which is specifically related to avatar baking. LL are currently looking into ways in which to make avatar baking more robust and less prone to problems such as bake fail (when your avatar fails to rez correctly). One of the options being considered in this regard is moving the bake process server-side.
If this does indeed happen in the future (and it is not a trivial change), then it may result in Temporary Texture uploads being “broken”; but again it is important to emphasise that no actually decision on how to deal with avatar bake issues has yet been taken.
In the meantime, expect to see Local Textures in your preferred Viewer in the near future!
With thanks to Innula Zenovka for raising my awareness that Local Textures had reached the Beta Viewer (forum post), and to Latif Khalifa and Trinity Dejavu for input to this piece)
ETA contributor’s detail, supplied by Mobius Ryba.
Last week Oz put out a call for help with testing the Mesh Parametric Deformer than Qarl Fizz has been developing, and which is now available in a Project Viewer (as well as some TPVs).
The response to that call has been somewhat slow, prompting Oz to pass a further comment on the JIRA related to the deformer (STORM-1716):
Perhaps this issue really isn’t all that important, or worth the trouble to integrate.
So far, only one designer has responded with one test garment.
Let me be clear – the lack of test material is a major blocker for testing, and therefore accepting, this proposed feature. If you want it, step up and do it soon.
The comment has been reported elsewhere (and remarked upon in the comments following my original piece on the call), and has caused some consternation.
Howeverbefore people start taking Oz’s comment to heart as a sign that he or LL want to “kill” or “drop” the deformer, I spoke to Oz directly on the matter after reading the comment and he wryly admitted that it was intended as an attention-grabber and that, indeed, several more mesh designers have come forward indicating that they wish to engage in the testing as a result. When I asked him about the shock value of the comment, he replied, “Yeah, it was certainly intentional, and I would not have actually dropped it. But it is true that it would have taken far, far longer (months maybe).”
So does this mean we should ignore the underlying call for help?
No – we just shouldn’t panic about the deformer being dropped. Help is still needed. So, if you are a mesh clothing designer, or know of a mesh clothing designer, then please consider getting involved in the work / asking them to get involved in the work.
[Posted 9:45am PDT, 8 May 2012] We will be performing scheduled maintenance today, Wednesday and Thursday of this week (May 8, May 9, May 10), beginning at 6:00pm PDT each day. Each maintenance is scheduled to last around 8 hours. Please save all builds and refrain from rezzing no copy objects, as some regions may be taken offline and remain offline for extended periods of time. Please follow this blog for any updated information. [emphasis mine]
So for today, Wednesday and Thursday, expect severe disruption to SL.
Whether or not this maintenance is related to recent service outages / issues, the most recent of which occurred some 24 hours ago, is unclear. However, the forewarning is appreciated.
While I have been prone to avoid personal opinion in “news” items, that there is upcoming maintenance does prompt me to ask Linden Lab as to whether they could also broadcast a reminder in-world prior to the work commencing, for the benefit of those who may not routinely read the Status Page or who are not engaged on Twitter?
Update: Latif Khalifa reports encountering the problem on Singularity, so the issue is likely to affect V1-style Viewers as well, and provides a potential workaround for those encountering the issue (see comments, below).
There have been a number of reports of mysterious Viewer crashes of late, specifically in relation to file operations (saving a texture or snapshot to disk, attempting to upload, setting your cache location, etc.).
The problem appears to be manifesting itself in V3-based Viewers, and the culprit appears to be Microsoft Skydrive.
A JIRA has been raised on the issue in general (VWR-28843), with reports that uninstalling Microsoft Skydrive eliminates the issue. This is obvious not the best solution for the situation, but those experiencing the issue may wish to check the JIRA and consider WATCHing it.
Active within Second Life since 2008, Kev was heavily involved in BURN2, the Department of Public Works and SL8B, serving as a core team lead in all three, as well as being an advisor to the LEA.
Inara Pey: Living in a Modemworld 