I was drawn back to Banana Island, Bowie Zeplin’s homestead region, which I last visited in March, due to a post from Honour which indicated Bowie’s new build is now close to completion. As her work is always stunning to see, as anyone who saw Pangloss will know only too well, I knew I’d have to hop over and see for myself as soon as the opportunity presented itself.
As with her previous pieces, Beeswing is beautifully composed, striking to the eye and with a “natural” surrealism which makes it truly unique.
The first thing you’ll notice on arrival is the region is darkly atmospheric – I’ve taken the liberty of either toning-up my images or of using a slightly different windlight to the default. The landscape is largely given over to water surrounded by hills, and features raised wooden walkways which wind through the region and under the thick roots of trees which float serenely overhead.
Wander the walkways, and you’ll come across vignettes, large and small, many of which appear to be memories of childhood or of events from childhood. Some may be happy: an innocent game of hopscotch or a favourite book. Others appear less happy: the tiny apartment house, ripped open by an upthrust tree, perhaps an echo of a parental divorce, the shattering of a home, the tiny figure within the broken building representing a daughter standing isolated and alone as her parents go their separate ways.
Elsewhere, the images appear to be all that remains of dreams and hopes once held, or the memories of roads not taken: the dancer under a single spotlight; the naked figure rising from water displaying ever-changing images, her hand extended towards a star above her, as if reaching for her future. Mixed with these are other little vignettes I’ll leave to you to interpret.
Toward one side of the region sits a gilded cage, doors flung wide, within which sits an idyllic image: a house sitting in a beautiful landscape, smoke rising from its chimney as water tumbles from a waterfall nearby to feed a crystal blue lake before passing under a quaint stone bridge. The kind of thing society tells us is the ideal lifestyle we all should strive to attain; yet still those gilded cage doors sit, both inviting us in and perhaps warning us of the price we may yet face should we do so …
To determine a meaning here, if one is indeed intended, is not easy. Nor, frankly, is it required, given the captivating beauty apparent in each of these scenes. To me, if there is a theme here, then perhaps it echoes the meaning behind Richard Thompson’s song Beeswing, a refrain from which can be found in the region; that the installation is about the choices we make in life, or which are thrust upon us, and the price they carry.
If that sounds dark, then don’t be put off: Beeswing is an evocative place, stunning in composition and with a beauty as fine as a bee’s wing. More than worth the time taken to visit it.
One of the staples of Fantasy Faire is the Silent Auction, which sees a wide range of exclusive items auctioned quietly to bidders. This year is no exception; bidding opened on Tuesday May 6th and remains open through until 17:00 SLT on Saturday May 10th.
Some 39 items have been donated to the auction, including avatar skins, outfits, accessories, buildings, avatars, and much more. You can see the items on offer at the Fantasy Faire silent auction web page.
To bid for any item, hop over to Fairelands Junction. You’ll find all the items hanging on red ribbons strung between the trees there. most of the images of the items on offer have the required information about them. However, clicking on any of them will deliver a note card containing all the information you’re likely to need.
Bidding is triggered by clicking on the blue ribbon alongside an item. These display the minimum bid required. Note that no money is changing hands as a result of a bid, only the winning bidder will be charged at the conclusion of the auction. Remember as well that this is a silent auction. so you’ll need to keep track of those items you’re bidding on!
Short Story / Poetry Competition
Are you inspired by one or more of this year’s Fantasy Faire builds? Are you moved to express your inspiration in words or a poem? If so, then the Fantasy Faire Short Story and Poetry competition may be for you!
All you have to do is write a story (500-3000 words) or poem (10-50 lines) on one or more of this year’s Fantasy Faire regions. It can be on any subject you like, so long as it reflects the setting(s) of the Faire. You can include as many of the regions as you wish, and even the inland sea. You don’t have to give long descriptions of the region(s) you feature, or even name them, but the settings should be obvious to the reader – if someone has to stop and think, “wait! Is this Medhir Woods or Mourningvale Thicket?”, then it won’t work for the judges. Your entry can, however, be sad or happy, witty or wise, evoke laughter or tears – or any and all of these. The choice is yours.
The ten winners, as selected by the judges, will be published in the September issue of Prim Perfect Magazine. Entries should be submitted in TXT, DOC or RTF format to: firstname.lastname@example.org, and should arrive no later than Saturday May 31st, 2014.
As noted in part one of this report, the group chat updates were deployed to the back-end chat servers on Monday May 5th. The changes to group chat should be subtle, and may not be observable to many. Additional analytics are included in the code, which should provide further pointers on what else may need addressing going forward.
Group Ban Lists
Baker Linden’s work on adding the ability to ban troublemakers / spammers, etc., from groups with open enrollment is now getting relatively close to becoming available.
Baker has recently closed what is believed to be the last of the server-side issues, BUG-5929. This meant that if the name of the group owner was accidentally added to a list of people to be banned from a group, the ban process would fail, with no-one in the list either being added to the ban list or banned from the group (although other than the group owner, anyone selected for banning would be ejected from the group).
The expected behaviour would be for all those named (other than the group owner) to be added to the ban list, with those who were already members of the group also being ejected and banned. Baker’s fix is to ensure this is now the case, and it should be available shortly on Aditi for testing (channel DRTSIM-234 14.05.05.289712 – which includes the Morris region where the Server Beta meeting is held).
Viewer-wise, a project viewer with the new code is expected to appear very shortly (it was running through the build process during the Server Beta meeting on Thursday May 8th). This should be added to the Alternative Viewers wiki page when available. The repository for the code has now been made public, so TPVs can start looking at it – but again, given the status of the viewer as a project release, don’t expect the code to immediately start popping-up in TPVs.
HOWEVER, it may be a while before the new group ban functionality can be used on the main grid, as there is an initial back-end host code update required prior to anything being deployed to any simulator channel. According to Maestro Linden, the Lab will likely want to run those updates for a week to check for any unexpected regressions prior to putting any simulators on a group ban RC.
In the meantime, the group ban capabilities can be tested on Aditi either using the project viewer (when available) or the existing test viewer.
“Welcome to the Hotel California” – BUG-5961
An old issue recently came to light once more with BUG-5961 (originally entitled “I cannot leave a group that I joined”, but with the description subsequently updated by Maestro to “Viewer attempts full fetch of member list before allowing user to leave group” in order to better reflect his findings following investigation).
It’s not actually clear if this is a one-off situation, or possibly more widespread, as the bug report is specific to the group “Akeyo”.
However, Maestro’s thinking is that the problem is linked to the download of the membership list, which even with the Group Services fixes introduced in late 2012, can still take time to complete with some larger groups.
Essentially, you cannot leave a group until the membership list has been loaded, as the viewer must check to ensure that when leaving, you’re not the last owner of the group. Should the membership list take time to download, this can lead to a temptation to click the Leave button again, causing the download to start-over, resulting in the list not loading, thus preventing you from leaving it (hence the Hotel California quip, which I admit I stole from Maestro!).
The Lab is looking into this issue further, although it may be a while before any resolution is found. One workaround in the meantime is to run a client such as Radegast, which handles groups slightly differently to the viewer, and use that to leave the offending group.
Restore to Last Position
Restore to Last position was a popular feature which allowed anyone to take content to inventory and then re-rez it later at the same position. While there were issues with the capability (such as using it to rez an object in a different region, with a different topology to the one where it was originally taken back to inventory resutling in an object to “vanish”, as it rezzed underground or something), it was broadly seen as beneficial.
However, it was also subject to exploitation, which is why the server-side behaviour for it was changed by the Lab some time ago such that the function will only work if you have rezzing rights at 0,0,0 in a region. If you do not, any attempt to use Restore to Last Position will fail with a notification that you don’t have the required rezzing permissions. The viewer-side code for the capability was also removed from the SL viewer, although TPVs have retained it.
A further issue with the capability has been with No Copy objects. If Restore to Last Position is used on these when the user doesn’t have rezzing rights at 0.0.0 in a region, they not only fail to rez – they also vanish from inventory, requiring a relog in order to get them listed again.
However, BUG-5955 “Restore to Last Position (used only by TPVs) causes content loss” highlights a problem where at least one type of No Copy object can be permanently lost from inventory if Restore to Last Position is used even in a region where the user has rezzing permissions at 0,0,0. Not even a subsequent re-log sees the item reappear in inventory.
Given the unpredictable nature of Restore to Last Position, the Lab is considering removing or blocking all support for it viewer-side until such time as a fix for issues can be found / it can be made to work more predictably in all cases.
As an alternative, and given the function’s popularity, it has been suggested a restriction preventing its use on No Copy objects should be implemented. The Lab may be taking this under consideration. This is the option Firestorm have indicated that they intend to implement with their upcoming release (which may as a result be delayed until the code is implemented and tested).