Tech Talk
llLookAt and llMoveTo fixed for OpenSim
While OpenSim to a large extent has full compatibility with the Linden Scripting Language (lsl), not all functions are implemented or works as expected – expectation being they behave the same as in SecondLife.
One of the functions that is used a lot for implementing followers is the llLookAt() function, and the OpenSim implementation had a number of shortcomings to it, so Talla Adam took the initiative to crowdsource funding to fix the function.
A total of $2000 was pledged by the following people
- Talla Adam, Kitely Grid: $200
- Shin Ingen, Ingen Lab Grid: $200
- Fred Beckhusen, Outworldz Grid: $500
- Selby Evans, Virtualoutworlding blog: $500
- Geir Nøklebye, XMIR Grid: $50
- Butch Arnold, 3rd Rock Grid: $100
- Michael Sietz, Digital Worlds Group LLC: $350
- Alex Ferraris, AviWorlds Grid: $100
After a couple weeks of coding Dahlia Trimble submitted code to fix the issues, and this was accepted by the pledgers in a meeting held on February 26, where also the compensation to the developer was agreed on.
The result of the code fix will be published in the upcoming OpenSim 0.8.1 release and the resulting functionality can be seen illustrated in a video of birds following an avatar. For OpenSim users out there wanting to be on the bleeding edge of the 0.8.1 release the code can be downloaded from the development branch of OpenSim.
The llMoveTo function was found to work as expected after a minor code tweak.
For the general status of lsl functions and their OpenSim implementation status check out this overview.
BulletSim physics plugin for OS X updated
The BulletSim physics plugin for OS X as been updated to be at the same revision level as the Linux and Windows versions. The latest version lowers CPU load, and fixes bugs and issues. It can be found in the bin/lib32 folder of the OpenSim git repository as libBulletSim.dylib.
To update, shut down your OpenSim instance, replace the library in your installation and start your OpenSim instance again.
Microsoft adds iCloud support to Office for iOS
In an update to Office for iOS, Microsoft has added the ability for users to save their Excel, PowerPoint and Word documents to iCloud where they can be shared between iOS, OS X and Windows devices subscribing to iCloud. The updated 1.6 version requires iOS 8.
Updated: iWork available to anyone on the web with iCloud
Updated Feb 27:
Apple has now removed the beta tag so anyone can create an account and use iWork by going to iCloud.
It used to be that to use iWork on the web you had to have an AppleID that was tied to Apple hardware. Not so any more, as Apple has started accepting AppleID accounts created by anyone, thus giving access to iWork for people who don’t have purchased a Mac or an iOS device.
In order to register an Apple ID, users must visit beta.icloud.com and click the link below the sign-in area that allows users to create an account. Users can then create a login with any email address, on any modern browser, including Microsoft's Internet Explorer for Windows.
After creating an Apple ID, users will be able to log in to iCloud.com and access Pages, Numbers and Keynote, the apps that make up Apple's iWork, in addition to Settings. You will also get a gigabyte of free storage for your documents in iCloud.
For the full description of iWork for iCloud, check out Apple’s iWork for iCloud beta pages.
iWork for iCloud works with Safari 6.0.3 or later, Chrome 27.0.1 or later, and Internet Explorer 9.0.8 or later. Now if I only could get it to work in MoaP without the SSL handshake failed message…
Apples gives Swift a noteworthy update with Xcode 6.3 beta
Apple has released Xcode 6.3 beta to developers including a noteworthy update to the Swift language, incrementing the version to 1.2
The language update includes compiler improvements and new language features such as incremental builds, faster executables both for debug and release builds, better compiler diagnostics and elimination of compiler crashes.
New language features included are improved interaction between Swift and Objective-C and refinements to ensure safe and predictable behavior.
Since the 1.2 release includes some source-incompatible changes compared to previous versions, Xcode 6.3 includes a migrator to help automate the conversion process.
Xcode 6.3 can be used with Xcode’s Continuous Integration service on OS X Server 4.x and Git Source Code management in OS X Server.
More details of Swift 1.2 can be found in the Swift Blog and the full details in the release notes (requires developer account logon).
Maybe the language is now sufficiently mature to build a Swift viewer for OpenSim!
A tale about viewers and http requests
Working on search and testing it on viewers, it turned out a combination of settings in the sim would create a very unfavorable condition in which the viewer would flood the simulator with requests akin to a DDOS attack grinding the sim almost to a halt processing packages.
There are actually two parts to the unprocessed packages issue, one that has to do with code changes in the 0.8.1 branch and one that has to do with Linden Lab code for their latest viewers.
When LL switched to a CDN (content delivery network) for serving up inventory via http they eventually removed or disabled code in the viewer that fetch inventory via UDP resulting in viewer-builds based on the new LL code, such as the Kokua viewer to simply crash when the code encounters an opensim grid/standalone that does not serve inventory via http (most don't.)
In order to figure out what was exactly causing the crash, we found that setting the two parameters below in OpenSim.ini to a wellformed URL would keep the viewer from crashing but it would also leave the inventory blank (if there was not anything actually serving up the inventory from the URL.) Turning off http for inventory would load the avatar and attachments to the extent it could navigate a region and actually cross a region, but the moment it tried to access inventory the viewer would crash.
Cap_FetchInventoryDescendents2 = "localhost"
Cap_FetchInventory2 = "localhost"
So yesterday I deployed these two params to the prod grid with a wellformed url rather than localhost just to prevent bad crashes in case someone bumped in with a viewer that required these to be set not to crash.
Enter adaptive trottles…
In the effort to speed up avatar logins and increase the number of concurrent avatars in a sim, the code developed before the conference last fall introduced throttles seeking to reduce the impact on the sim of unprocessed requests from multiple avatars when the sim got a bit crowded.
It seemed this caused more problems than it fixed so when the code from the conference code brand was merged into the 0.8.1 development branch people started seeing more "slow synchronous request" messages on the console and it acted like the throttles throttled the entire sim and not only the avatar causing the slowdown. Therefore I was running the prod grid with throttles turned off for best performance.
Now, with the above caps set and throttles off it turned out viewers based on late LL code brewed up a shit-storm of requests to the url set in the caps which went unanswered so it flooded the (TCP/IP) packet handling queue of the sim. It also seems the same viewers also to a certain extent do the same for search, and the combination was such that the sim almost kneeled.
Turning the throttles on (which was fixed around new year so they worked as intended) effectively curbed the flood of requests from the viewer to a level that had minimal impact on the sim. I have also reverted the cap settings back to the default as it obviously was of no benefit.
Since opensim search only serves up profile search to these generation viewers, other search options also generates a lot of requests, but I have to research the effect of this a bit more. It is not anywhere close to the level that the http inventory requests described above does.
Making a DIY Fusion drive on a Mac mini with Yosemite
It was time to give a Mac mini 2012 a boost and these machines are often shipped with rather sluggish 5400 rpm mobile drives, so doing something about the drive speed seemed like a good candidate for speeding the system up a bit.
Apple’s Fusion drives can only be had when getting a new system and are not available for installation in systems “after the fact.”
Even with the limited housing of the Mac mini, there is space inside for a second drive, so with a drive installation kit from IFIXIT and about an hour of careful disassembly and reassembly of the mini a 160 GB SSD drive had been installed in the second drive slot.
Starting up the machine from a USB installation drive with OS X 10.10 (Yosemite) (pressing the alt key during startup), it was a little victory to see the machine recognizing both the new SSD and the old harddrive. Rather than starting a new operating system installation, but starting Disk Utility from the installer drive, Disk Utility reported a broken Fusion drive and offered to fix it. Confirming the operation, it repartitioned the drives, including adding a recovery partition, and combined them to a 660 Gb Fusion drive ready to install the system on.
On a Fusion drive the operating system automatically manages the contents of the drive so the most frequently accessed files, applications, documents, photos and other data are stored on the faster flash storage, while infrequently used items move to or stay on the hard drive.
The SSD and hard disk drive is presented as a single Core Storage managed logical volume with the space of both drives combined, where data movement is based on runtime access patterns. During idle periods, data is adaptively migrated to the most suitable devices to provide sustained data processing performance for users.
It will be interesting to see to what extent a Fusion drive will speed up OpenSim as both database operations, but also the flotsamcache should be able to take advantage of the SSD portion of the drive.