This week has seen a number of TPVs updated. Rather than dwell interminably on each of them, here’s a rapid rundown, based on the individual blog entries for the three Viewers.
Restrained Love Viewer
Release 2.8.3 brings with it many bug fixes and:
Added
New keyboard shortcuts for builders (they are also added to the Build > Options sub-menu):
– Alt+W to edit linked parts
– Alt+T to set to stretch textures
– Alt+B to set to stretch both sides
– Alt+R to set to set grid mode to World
– Alt+F to set to set grid mode to Local
– Alt+V to set to set grid mode to Reference
– Alt+G to set to set current selected object as Reference and set grid mode to Reference
Debug setting “RenderMeshDeformed” to switch Qarl’s parametric alpha mesh deformer on and off (it is off by default
LL’s patch for the new inventory features (i.e. no accidental nudity)
Allow to click in-world while in Mouselook mode, even when your controls are taken, but only while pressing Alt
Fixed
Inventory offers were unreadable (the Show button used to overwrite the URL), same for teleport offers
Shift+Right-click on an object in world failed to open it
In Mouselook mode, we could only click on something or fire with a gun once
RLV_50: Fix to the alignment tool in the Build floater is broken (thanks given to Lance Corrimal and Jonathan Yap)
RLV_52: another avatar sitting down while in ML resets my camera (with thanks to Lance Corrimal)
The main inventory tab can now show or hide links, or show only links (the recent and worn tabs always hide links). Switch it on via the Inventory gear icon
The use of private memory pools has been switched off. If you notice more crashes than before, switch it back on with the Debug setting “MemoryPrivatePoolEnabled” and let Lance know (via a post on the forum)
This version of the Dolphin Viewer 3 does not send “LookAt” data anymore, if you switch on “Do not point at objects” (Preferences->Dolphin Viewer 3->Miscellaneous). Lance notes that, “The options to have the LookAt / PointAt crosshairs on-screen will be gone in the next release, unless someone points out good use cases for having them that are not based on drama or paranoia.”
The inventory patch recommended by Oz Linden has been implemented – no “accidental nudity” for Dolphin Viewer 3 users
Updated to RLV 2.8.2.1
When you take a Snapshot to disk using the keyboard shortcut CTRL-SHIFT-D, it uses the file format that you selected for your last “snapshot to disk” from the snapshot floater
The check boxes for switching AutoCloseOOC and AllowMUpose are back in Preferences->Dolphin Viewer 3->Miscellaneous
The linux version of the Dolphin Viewer 3 now uses dbus calls in the secondlife: handler script to send SLurl to whichever viewer is running at the time. Lance comments, “This is not available on 64-bit Windows, so please vote for VWR-28073 and VWR-28074. Thanks.”
The Windows installer should not use the term “Second Life” anymore anywhere in any language. It should read “The Dolphin Viewer 3″
Some Windows build issues have been addressed.
Fixes:
The tips of the handles of the Align tool in the Build toolbox point in the right directions
Sharing inventory items with more than one inventory window is open is now working correctly
The hovertip on the local chat bar mentions whispering as well
Previews of textures show the checkerboard pattern again under transparent areas. Lance notes: “This version still does this with the old deprecated OpenGL calls. The next version of Dolphin Viewer 3 will do it “right”, thanks to Shyotl from Singularity”
Fixed: the “Preview As” dropdown in the texture upload preview is not covered by the texture anymore.
Ability to select the use of your right arm when selecting / pointing / building
Revised pie menu
Ability to see UI when in Mouselook
Shining updates.
Niran’s: UI visible in Mouselook (note ML crosshairs in the centre of the image)
The UI-in-Mouselook is interesting – NiranV mentions it as coming via Dolphin, but I’ve failed to notice it in that Viewer (or any other V3-based TPV) – not that I’m a major user of ML at the best of times and so may well have missed it if it is a debug setting (or I managed to skip the option in Preferences). It’s an interesting addition to direct 1st person use of the Viewer, especially given UI options can be accessed using the Alt key. For those who prefer a more traditional Mouselook view, the UI can currently be hidden using a debug command: AllowUIHidingInML.
As a semi-regular user of Niran’s Viewer, I have to say, I’m not totally convinced with the build floater changes (which need a small amount of tidying-up) on two counts. Firstly, because Niran’s is one of three Viewers I routinely use, and so the layout cuts against the other two – this is admittedly more *my* problem than the Viewer’s.
Secondly – and more importantly – while the “traditional” builder floater is getting increasingly crowded (and one could argue it does need a bit of a re-think), it does have a certain logical flow in the way information is presented – and scanned by the user. This is something that appears to have been lost in this initial presentation within Niran’s Viewer.
Update January 27th, 2013: The Zen viewer has been discontinued by its creator.
Note: January 17th, 2012: I’ve received a number of complaints from the Firestorm team relating to elements included in the Zen Viewer. One in particular relates to the client-side AO, which in its current formI’d previously been given to understand had its roots in another Viewer & enhanced in Firestorm. However, I’m more than happy to correct this and give due credit to the Firestorm team.
No, I’m not going all metaphysical on you. Yet.
Zen is the name of the latest Second Life Viewer to cross my path, coming to me by way of a Twitter-poke from Cinder Roxley. Being developed by Zena Juran, this is a rather nice take on the LL Viewer, not altering too much, while adding some very nice touches.
Core Data
Currently available for the Windows platform, Zen is based on the latest 3.2.7 code from Linden Lab. This means it has the very latest in the Shining fixes, mesh upload, the updated snapshot floater, etc. In addition, it also includes:
The alpha parametric deformer
Client-side AO and particle editor
Temporary texture & sculpt uploads and local sculpt and texture browsing
Area search
Pie menus
Toggle notifications between top / bottom right of the screen
LSL pre-processor and save / load scripts locally
Copy/Paste Object/Texture Parameters
Qarl’s prim alignment tool
Texture Refresh
Derendering option
Fetch inventory at log-in
Move orphaned system folders for deletion
Copy UUID on right-click
Resized View/Camera floater
Adjustable region restart timer.
In addition, the Viewer also has some useful defaults pre-set from the get-go which are liable to save most people using it time in getting things initially set-up.
The version I review here is version 3.2.7 (1), released 15th January, 2012, although version 3.2.7 (2) is available as of the 16th January, incorporating various tweaks and fixes.
Installation and First Looks
The installation EXE is 26.9Mb in size, pretty much par for the course nowadays, and installs Zen directly into its own directory without any hitch. On starting-up, Zen reveals the familiar 3.2 UI with a couple of interesting alterations from the norm: the Destination Guide doesn’t open by default, and the Mini-location Bar is displayed in preference to the Navigation/Favourites bars.
Zen default UI presentation
Transparent Buttons
Another, perhaps more obvious difference, is that the buttons – all positioned along the bottom of the window – are semi-transparent. Some may find them harder to see as a result, but I have to say I quite like it, although an option to adjust the level of transparency (if possible) would be welcome.
The buttons that are active by default are, it’s probably fair to say, the ones most people will prefer to see active from the get-go: Chat, People, Snapshot, Profile, MiniMap, View, World Map, Search, Build, Inventory and the AO buttons (on/off & settings). Other than the AO buttons, there are currently no additional buttons included in Zen’s Button Toolbar.
Menus
Menu-wise, Zen offers something of an eclectic mix, with a couple of the menus somewhat altered from the V3.2 offerings, others largely unchanged. Of particular note in a couple of the menus is the absence of many of the options that have corresponding buttons; there are no menu options for Choose an Avatar, Picks, Places and Camera Controls in the ME menu, for example, and World lacks a Destinations option.
Button access only: the ME menu from Zen (l) and from V 3.2.7 (r)
On the one hand, this appears to make sense – if the functions have buttons, why have duplicate menu option to access them? Where a function is in frequent use, then it is likely it will be accessed through the button far more than through the menus. There is also the argument that experienced users (and Zen is aimed at those more familiar with SL, as are most TPVs) are unlikely to require access to some options (such as Choose an Avatar) while others will be more routinely accessed via Search (such as Destinations).
However, in some cases the menu options do offer a convenient means of accessing options that may not otherwise be used frequently enough to warrant having the button active at all times. As such, I’m not totally convinced removing some of the menu options (such as Picks and Places) is perhaps the right way to go.
Also missing from the ME menu, given it is built from the official 3.2.7 code, is the Merchant Outbox. However, this actually makes sense, as Direct Delivery isn’t yet available on the Main grid, so it’s hardly something people are going to miss at this point in time.
Zen menu options
Like many TPVs, Zen has its own dedicated menu called, appropriately, ZEN. This provides quick access to a number of functions not found in the official Viewer: the ability to turn off / on Pie menus, disable / enable the mesh parametric deformer alpha, etc.
There may not be a lot of options here – but that’s intentional; Zen isn’t meant to be a feature-heavy Viewer, and to compare it with those that are would be a mistake. Zen is aimed at a very specific niche: building, as Zena explained to me, “I prefer to use the official Linden Lab Viewer It has the best performance, but it does lack features found in other TPVs that I find very useful for content creation on the grid”. Full marks to her for defining the goal of the Viewer so clearly.
Preferences
This approach is also reflected in PREFERENCES, which currently sees little deviation from the official Viewer in terms of tabs and options. The only easily spotted differences are the inclusion of a LSL Pre-processor tab for scripters and a UI tab for skinning the Viewer.
LSL pre-processing options
The skin options are currently limited – you essentially get a choice of a blue highlighting for things like menu selections, etc., or the more traditional LL teal effect (complete with options to change other aspects of the UI). However, this is something Zena is again working on, so more options are liable to be available with future releases.
UI Skinning
Defaults
However, just because there aren’t a lot of extra menus options and Preferences, doesn’t mean there aren’t a lot of “under the hood” tweaks to the Viewer that may not at first be obvious. Zen actually differs itself from the herd in that several common defaults are pre-set to how many experienced users prefer them. For example:
Limit select distance is OFF
Camera constraints are DISABLED
Inventory is pre-set to SORT BY NAME and SYSTEM FOLDERS TO TOP is OFF
Inventory hover tips are disabled by default
Default cache size set to 1Gb rather than 512Mb
Network bandwidth is set to 1500Kbps (see this article on bandwidth settings) rather than the usual 500Kbps.
All of these tend to make getting started on Zen a lot less fussy, although it might be fair to say that many users would also like to see Chat and IM pre-set to use the “old style” non-header layout as well – Zen currently uses the LL default with headers active.
Camera Floater
The Camera floater in Zen has been nicely resized, and includes an option to quickly reset Draw Distance. The resizing is welcome – the camera floater on the official Viewer is somewhat supersized. However, in achieving the resizing, the more familiar zoom slider and viewing angle buttons have been removed. Again, I have very mixed feelings towards this approach.
Take the Mouselook button for example. While it is true that press the M key will drop you into Mouselook – it is equally true that this only works if you have your WASD keys set to move your avatar. For those that don’t, and who prefer to have WASD set to starting local chat (rather than having to tap ENTER first), the lack of a Mouselook button on the camera floater might cause a frown or two.
Animation Overrider
This is the “standard” client-side AO first seen in Firestorm and now found in most recent TPVs, which includes the ability to run multiple AO configurations, “build” AO sets “on the fly”, etc. In keeping with Dolphin, Zen currently uses the two-button configuration as mentioned above (one for accessing the AO floater, the other for turning the selected AO on / off), rather than the single-button approach used within Exodus.
Build Options
Zen offers all of the most frequently used build options found in the TPV “market” today. The build menu accepts four digits after the decimal point, there is Qarl’s alignment tool, the ability to copy / paste parameters, temporary uploads, sculpt and texture browsing, additional scripting tools, and for those working with mesh clothing, the parametric deformer alpha. Add to this the choice of using either the context menu or the Pie menu, and creators are supplied with a good range of options.
For me, there is only one item I’d like to see added, which is currently in Exodus, and that’s the ability to save / load position and rotation information of an object into /from it’s description field; when working on a number of builds and having limited space on my build platform, I find this a real boon for my work over copying / pasting co-ords manually.
What’s Not There
Again, it’s important to remember that this is focused Viewer aimed at delivering an improved building experience based more closely on the “vanilla” official Viewer when compared to other TPVs and that Zen is also something of a new development. As such, the Viewer doesn’t currently include options such as radar or things like RLV and the media filters. This doesn’t mean these options won’t appear in time, but it would be unfair for people to dismiss the Viewer on the basis of their absence.
Viewer Status
Zen is TPV Policy compliant, and Zena informs me that, “I have an application submitted to be listed on the TPV directory and have been in contact with Oz Linden. As soon as Oz reviews the Zen Viewer it should (hopefully) be listed on the TPV directory.” The source code is available on Bitbucket, as is a fledgling wiki for documenting the Viewer and an issue tracker, which Zena requests is used for support issues / requests, rather than contacting her in-world.
Performance and Opinion
As Zen is based on the official 3.2.7 release I was expecting it to perform well on my usual system given my recent experiences with 3.2.5 and 3.2.6. So far, I’ve not been disappointed. Performance has largely matched my experiences with 3.2.5 (different environmental variables accepted, and remembering this is not intended as precise benchmark test), and frequently improved upon them (having shadows enabled at altitude, for example had the viewer running at around 15-16fps, slightly faster than 3.2.5, while on the ground, the rates were around those of 3.2.5 (about 11-12fps).
Overall, and in running Zen for a couple of days, I’ve found it to be a pleasant, crash-free experience (other than one issue which Zena fixed in the 3.2.7 (2) release). When building, the Viewer is easily as capable as my “default” Viewer choices (and I’ve given it a good run in this respect, given I’m (again) rebuilding my house…). Certainly, the additional build options made getting the work done a breeze, and it was nice to have a Viewer in which I can both build and have shadows running without suffering refresh stutter every time someone enters or leaves the sim.
Overall, the Viewer offers some nice build enhancements over the official Viewer, and those who prefer to use the LL-supplied Viewer, but would like to have some of the additional build options at their disposal without necessarily swapping to a TPV for general use should find Zen offers a very solid alternative.
Update 16th January:Charlar has added a comment to the JIRA that clarifies LL’s position on the alignment tool and puts concerns into perspective. The comment further makes it clear that from LL’s position, the opportunity to see the tool included in the official Viewer is far from closed, and Oz indicated in his comment from yesterday.
Update 15th January: The JIRA mentioned below has been re-opened, and Oz has requested any developers willing to take the alignment tool further to contact him directly. This clearly shows that the Lab is aware of feelings on the matter and are trying to meet people half-way, and full kudos to them on this. Qarl (Karl) has declined to update the code, but has stated it’s in the public domain, and others are welcome to do so.
Earlier in the month, Karl Stiefvater (do I still need to introduce him as the creator of the parametric deformer?) submitted an earlier piece of code he’d created – the prim alignment tool – to Linden Lab under a code contribution agreement.
I didn’t cover the contribution at the time, as Tateru had it very well covered. However to recap: Karl, formerly Qarl Linden, now Qarl Fizz, submitted the code to LL by way of a “Thank you” for a generous donation someone made towards the deformer project, as you can read on his website as well as Tateru’s blog (Tateru having steered the donation in the right direction).
The alignment tool does precisely what it says on the box: it aligns prims, as Karl’s own video demonstrates:
No fuss, no bother. It’s not a one-size-fits-all solution that is designed to fit every possible situation where prims (or linksets or objects) may need to be aligned, and it is not intended to be. However, it does provides a major benefit for builders in dealing with a specific set of issues that can otherwise be time-consuming to overcome. As such, it has been adopted by a number of TPVs, where it has proven to be highly popular.
But it has been rejected by Linden Lab under the original JIRA raised on it some 2 years ago by Nalates Urriah. As Lance Corrimal (himself the developer of the Dolphin TPV which uses the tool) and Tateru on her blog point out, the reason for the rejection appears to be primarily because the tool doesn’t perform tasks it was not designed to do and is thus “incomplete”.
The rejection notice as posted on the JIRA reads:
Thanks for making this effort. Alignment and snapping are an area where there are useful enhancements to be made.
However, we are not able to accept this contribution as it is.
These are the primary issues we found which resulted in that decision:
The feature should support the same modes as the other manipulation modes.
It does not work for non-mod permission objects. This functionality should work for all objects that the user can manipulate in-world.
It only supports World snap mode, not Reference and Local modes, unlike all our other manipulation modes
It packs and aligns to the face of the object bounding box. If objects are not cubes and do not share the same alignment, or aren’t aligned with the world coordinates (see above), the result of the operation is unexpected. Ideally the operations would use the actual shape of the object for aligning and packing.
There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.
In it’s current form, this is usable for purely prim-based builders under specific circumstances. It’s less useful for building with non-cube prims, mesh, sculpties. It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West). It’s not usable by non-building residents who need to place and organize purchased items.
LL obviously have the right to reject code that they feel is not in their best interests, or in the interests of the Viewer or their users. That’s a given and is fair enough. As such, and being of a generous nature, I have to say that there might be some mileage in some of the reasons given for the rejection (Jonathan Yap actually raises a couple of points within the JIRA). But, and again being fair to all, the rejection equally comes across as little more than nit-picking.
Take, for example, the remark that, “It’s minimally useful for building when the structure is not facing a global direction (ex: North, South, East, West).” On the surface, this might appear reasonable – until one remembers that the same is pretty much true for building as a whole in the Viewer at present – as anyone who has encountered prim drift can ably testify.
Then there is the comment, “There are also some coding implementation style issues that would need to be addressed. These can be covered in more depth after the functionality is dealt with.” This reads as not only nit-picking, but also to be putting the cart before the horse.
If Karl is in fact committing some basic errors in his approach to coding for the official Viewer, surely these should be addressed before embarking on any major functionality changes (were they to be agreed upon), in order to circumvent the risk that such “style issues” don’t lead to yet another rejection down the road?
Some have commented that the entire rejection smacks of a “not invented here” mentality. That may be the case, equally, there may be issues within the code as submitted we’re not privy to and which the note in the JIRA isn’t really helping to make clear. Even so, seeing this rejection I have to confess to being left with an uneasy feeling as to how the deformer tool is to be judged by the wider audience within LL. Time will tell on that, however.
As far as the alignment tool is concerned, I’m with Tateru on the matter and calling “time” on any hope of seeing it incorporated into the official Viewer, for precisely the reasons she states.
Update:version 1.11 with an out-of-memory crash fix is now available. If you have downloaded 1.10 and are experiencing crash issues (memory use exceeding 1.25Gb), you might want to download this version.
Niran’s Viewer is one of the two most capable graphics Viewers in current development – easily standing shoulder-to-shoulder with Exodus (which has in some respects gained far more attention of late).
Niran’s hasn’t been without problems – simply because it is so advanced (possibly too advanced for some people’s tastes). While NiranV Dean has worked hard to present a range of graphics controls that are more intuitive (using settings such as “low”, “medium” and “high”, rather than numeric sliders, etc.), it is possible that people have been so used to the slider mechanisms may find his newer approach a little more confusing.
I’ve tried to follow Niran’s development from Beta onwards because, well, I like it. Rather a lot. Things for me went a bit squiffy with release 1.02, which simply refused to work with my PC (or my PC with it, not sure which way around it was), and some of those issues carried over into 1.03.
Release 1.10 redresses all of that with a nice set of nips, tucks and updates that have so far given me a very pleasant ride and which again point to why those with a bent for photography, etc., in SL should take Niran’s Viewer for a spin. It is based on the very latest LL 3.2.7 (Project) code base, and includes all the latest Shining fixes to boot!
Graphics and Rendering
On the graphics / rendering front, Niran has re-worked the original sky glow defaults from V3 into the Windlight preset for the Viewer for those that find the Niran’s Viewer glow defaults a little too bright. You can find them under the Sky settings, with names such as “Realistic” should you wish to swap over to them in preference to the Viewer’s own glow defaults.
Niran’s Viewer glow default……and using the “Realistic” preset (V3 sky default)
Within the Graphics panel itself, NiranV has been fixing various bits and pieces – adding tooltips, etc., and also, God bless him, adding default (*) indicators alongside options so that it’s relatively easy to get back to a starting point when making adjustments. This I’ll treasure him for, as I’m no graphics expert, and have confused myself once or twice playing with settings on a number of Viewers.
UI
Clean UI
The most obvious difference in the UI for those who are familiar with Niran’s Viewer & who do a clean install), is that there are only 7 buttons on-screen by default, and these are both icons-only and moved to the left / right sides, potentially maximising the in-world view.
Visiting PREFERENCES->VIEWER->UI reveals the alpha / beta options have been expanded, with the ability to enable / disable the mesh parametric deformer alpha being added to the other options.
Alpha Beta options expanded
On the parametric deformer, NiranV notes, “For all you that wanted to disable it, you will now find the option to do so … untick it and re-wear any mesh or the whole mesh AV to make it update and look normal, the reason why it doesn’t auto update like in Exodus is easy, Qarl’s code adds an update to mesh nearly every second or less , this results in flickering mesh shadows and totally freaking Meshes on other people , i took that one out , contra is that you have to “refresh” it then , but it definitely works better :)”
Received Items and Merchant’s Outbox both in Inventory
I took a quick plunge into the Beta grid to give the Direct Delivery options a go, now that the public Beta is underway.
Enabling the Received Items and the Merchant’s Outbox will add both to your Inventory panel (in difference to the official Project Viewer, which has the Merchant’s Outbox as a separate panel).
In testing the options, I found the Received Items side of things worked as expected. However, I was unable to test uploading goods, as the Merchant Outbox section refused to let me drop anything into it, which I’ve reported to NiranV.
This issue aside, I find NiranV’s approach to Direct Delivery more intuitive than LL’s – having the Merchant Outbox included in the Inventory panel means one doesn’t need to have yet another panel open and floating around, and dragging-and-dropping will be much easier. Other TPV developers, take note.
As a slight aside, don’t be confused if you see “Niran’s Viewer” popping up in place of “Second Life” (such as in the Merchant’s Outbox, which refers to “Niran’s Viewer Marketplace” rather than “Second Life Marketplace”) – this is the result of an accidental global replace of “Second Life” with “Niran’s Viewer” by one of NiranV’s colleagues on the project…
Opinion
Small, from an end-user perspective, but very welcome and tidy changes to the Viewer that do much to encourage its more widespread use. Performance-wise on my usual machine, and on my usual sims (the usual caveats in place), it ran well – better than 1.02, giving me performance on a par with Exodus with or without shadows enabled, and a very smooth run. There are still some things I feel are missing from the Viewer – but these are personal choices, and they won’t stop me from using this Viewer alongside Exodus in my fledgling attempts at SL photography.
If you’re into photography and / or machinima, then Niran’s is definitely a Viewer to take a look at.
Direct Delivery (DD) – the mechanism that will replace Magic Boxes for merchants using the SL Marketplace and which should bring improvements to the overall delivery of items purchased on the Marketplace – is in open beta for people to try on the Beta (Aditi) grid.
Direct Delivery has been subject to many ups and down over the last twelve months, but this beta should bring it a step closer to reality. Given LL’s overall track record on the delivery of new Marketplace services, this is something that has merchants understandably nervous and concerned.
Documentation relating to the new system has also been updated, including the release notes and a set of getting started instructions – both of which are worth a read, although the latter are somewhat irritating (see below), and will be rationalised and clarified prior to DD going live.
For those (merchants especially – although it would seem those curious as to how purchasing goods using the new system can also have a bit of a go) wishing to try-out the system:
You’ll need to have the Direct Delivery Project Viewer (version 3.2.7.247349/dated 10th Jan or later), complete with its funky blur-tinted UI elements (new to this Project Viewer, or sign of another change coming to the UI?)
You’ll need to have an active account on Aditi and should log into that first if you’ve not done so in a while (indeed, you might want to change your password as per the linked instructions & force an account update if you haven’t)
You’ll need to be able to log-in to the Aditi Marketplace (this may throw up a security certificate warning, depending upon your web browser settings).
Testing Purchases
For those simply curious as to how they’ll be affected when purchasing goods, it’s very straightforward:
When logged into the Beta Marketplace, simply purchase any item commencing with “DD”.
Open your Inventory panel and click on the RECEIVED ITEMS tab at the bottom of the Inventory panel to expand it – and your purchased items should be in a folder, ready to be moved into the location of your choice in your Inventory.
Note: Items purchased on the Beta grid will only be available in your Beta grid inventory and purchasing them will not impact your Main grid L$ account balance. If your Beta grid account does not have a L$ balance, you can raise a support ticket. Funds cannot be transferred between the Beta and Main grids.
Direct Delivery: from the Marketplace to you (some Marketplace steps omitted) – click to enlarge
Testing Uploads (Merchants)
Items using Direct Delivery no longer need to be boxed-up – part of the idea being that people receiving goods will no longer need to rez a package in-world and unpack it (although if you wish to box items still (and some of the limitations of the system actually mean you may still need to), you can.). Nor do they require a Magic Box; instead they use a new addition to the Viewer – the Merchant Outbox – to upload goods to the Marketplace.
You can organise your items either in your inventory itself, or within the new Merchant Outbox panel (located in the ME menu on the Project Viewer) prior to uploading. Of the two options, the former is probably the preferred, given that anything organised solely in the Merchant Outbox will vanish as soon as it has been uploaded.
The basic steps are:
Open your Inventory and the Merchant Outbox (ME->MERCHANT OUTBOX).
Drag the items from your Inventory panel to the Merchant Outbox panel.
If required, organise items by folders in the Merchant Outbox (individual items dropped into the Merchant Outbox will automatically be placed in their own folders).
Click the SEND TO MARKETPLACE button.
You should get an on-screen confirmation when all items have been sent.
Click on My Marketplace (top right) and select MERCHANT HOME.
On the MERCHANT HOME page, click on MANAGE LISTINGS on the left (or click on INVENTORY at the top and then select MANAGE LISTINGS from the drop-down).
Your listings are displayed, with unassociated items at the top.
Use the ACTIONS option to the right of each item to create a new Marketplace listing in the usual way.
Obviously, multiple items can be uploaded via the Merchant Outbox, I’m using a single item purely for demo purposes.
From you to your Marketplace store & ready to be listed: Direct Delivery (click to enlarge)
Irritating
The tests themselves are easy to carry out. What is irritating is the lack of attention paid to the “getting started” instructions. Vis:
The instructions wibble on about downloading a Magic Box (this is testing Direct Delivery, right?) – a Magic box isn’t required for a basic test of the DD functions – either when purchasing goods or uploading them
They direct you to place the Magic box at one of two locations on the Beta grid – one of which is – or was during my testing – (wait for it) NO REZ (virtuatrade Campus S).
If mention of Magic Boxes is included for those who wish to carry out more involved testing (such as comparing what happens on uploading, how the system handles / differentiates items uploaded via either mechanism, etc.), then this should really be made clear in the instructions. Also, and as a minor quibble, why isn’t the Magic Box itself set-up as a DD item? That would kill two birds with one stone (get a Magic Box for more involved testing and test the receipt of DD items in a single pass).
There is also an error in the Selling in the Marketplace instructions which might lead some to get a little confused. These direct people to their MERCHANT HOME page, and then to click on MANAGE INVENTORY, when in actual fact the required link is MANAGE LISTINGS, which is located under the INVENTORY heading.
Feedback
I’m not entirely sure why this level of testing is now required, as it all seems very basic. But then, I wasn’t involved in the closed beta testing and I haven’t been keeping up with discussions on DD via the Merchant’s forum. As it stands – and leaving aside the inevitable amount of work required to shunt stuff from Magic boxes to the DD system, this process seems straightforward and easy to understand for merchants and consumers alike (“getting started” instructions for the Beta notwithstanding).
My tests here are, of course, pretty basic. It’ll be worth keeping an eye on the Merchants’ forum and the Beta thread to see if any major issues come out of the beta process, as well taking a read through the documentation listed below.
Oz Linden has announced that due to a change to the inventory transfer protocol, a new inventory patch has been issued by LL.
Commenting on the patch, Oz states: ““We’re going to be deploying changes to the inventory backend soon that improve robustness and performance, but in testing those changes we found that existing viewers relied on certain things being strictly ordered. With the new backend, that assumption does not always hold true.
“Changeset d327dcc8ae51 from viewer-development implements the viewer change needed to avoid race conditions. It should be straightforward to apply to any viewer, and is safe to release before the changes are deployed (it is compatible with the services as they are now).”
The exact deployment date for the actual change to the inventory transfer protocol is unclear – longer than days, but less than a month. However, TPV developers are being encouraged to implement the patch sooner rather than later.
Commenting on the impact of not implementing the patch, Oz says, “I believe that there is no known risk of inventory loss or damage without the patch, but it is true that some operations can result in accidental nudity, which some users might be unhappy about.”
One side effect of this is that the patch will not be applied to the official 1.23.5 Viewer code by LL, and so that Viewer has been removed from the Viewer download page of the wiki. However, developers supplying Viewers based on the V1 code base will be able to port and apply the patch to their own code.
Secondly – and more importantly – while the “traditional” builder floater is getting increasingly crowded (and one could argue it does need a bit of a re-think), it does have a certain logical flow in the way information is presented – and scanned by the user. This is something that appears to have been lost in this initial presentation within Niran’s Viewer.
Inara Pey: Living in a Modemworld 