OpenSim/OSGrid Roundup

LSL Scripted Vehicles on OSGrid

2009-10-23T11:34:00.001-07:00

To make a long story short:

The code is now part of the master branch of the opensim project.

Q: What does this mean?

A: It means that all of Kitto's work to-date is now a part of 'trunk'

Q: Does this mean that my vehicle scripts from SL will work now?

A: Not exactly. Kitto still has a few things to do before that can happen. That being said, good vehicle scripts -can- be written with whats finished if one is creative, and most vehicle scripts could probably be tweaked to work.

Q: So where does this leave us?
A: See my tutorial on the OSGrid forums at http://osgrid.org/forums/viewtopic.php?f=15&t=1861 to make your own boat :D

Cheers!
James/Hiro

Git, Network Protocol Versioning, and The Current State of the Code

2009-10-06T06:46:00.000-07:00

BUSYBUSYBUSY

A lot has been going on with opensim! This is why it's been a very long time since I have posted concerning any of my git adventures; between opensim software development dynamics and the new business concern, I've been just about buried with higher priority things than blogging.

That said, time to play a bit of catch up:

First, concerning my Git Tip of the Day

It isn't dead. I just had to do some agressive study and cognition on the topic, and then got very busy with the aforementioned other things. The short take: my efforts with respect to grokking git better have been very fruitful, but like just about everything else, I still dont know it all. Expect a post over the next few days with a great deal of detail compiled from my abundant notes.

Now, concerning network protocol versioning, and the recent osgrid bump in protocol version:

Late last week, thursday or friday depending on where you are in the world, osgrid updated their grid backend services and plazas to a ROBUST service paradigm (a project-local acronym, dont go pester google about it). As there are technically significant differences in the backend protocols implemented by the new server(s), an additional change was to increment the network protocol version number, forcing a cut-off of regions operating prior versions of the software. This has serious implications for region operators: they are forced to update to a version of the software from which they cannot roll back. If things go wrong, it's a rough ride until the kinks get ironed out. The bad news is, things went wrong this time. What went wrong? several things. A few fairly significant, a good many minor - no one thing contributed to the problems we've seen since the update. The good news is, a lot , and I mean a lot of good is to come of it. We're seeing memory footprints cut in half, really quick, really reliable on-the fly texture decoding (spells the end of blurry textures once and for all), and greatly increased capacity to endure loads in the release candidates - but issues remain and addressing them is an incremental, iterative process.

Which brings us to The Current State of the Code

There is a release on the website at OSGrid.org. It may, in fact, be a different revision from what is recommended. This state of affairs is no accident or oversight - it's a consequence of the dedication of the developement and testing teams to keeping the best possible code available at any given time. Many incremental improvements and hotfixes have been applied in the last 72 hours or so - if you need to download the binaries, you can have faith that what is there is the best code currently available.

You can expect that releases will be coming fast and furious in the days ahead. Work continues in the interest of producing some very dramatic improvements in opensim, in the broadest of senses. Refactoring projects that have been long under way are nearing completion, code has been cleaned up, new architectures implemented, and many optimizations of memory and other resource use are focused at delivering these benefits in the short term - so please bear with us as we labor to produce what will be nothing less than the most game-changing release of opensim we have ever produced.

And with that, I'll quit bending your ear, and get back to doing something productive.

Cheers!
James/Hiro

Maintaining an active local fork with Git

2009-09-09T08:09:00.000-07:00

[WARNING: this is not a tutorial - it is a workflow deconstruction. Failure to read the entire article before attempting this operation could conceivably result in lost work. Please make certain you understand the process, and remain aware that this is not a linear sequence of instructions, but rather a description of one of my personal experiences. Thanks! James]

Topical Introduction: Git Operations vs. GitHub.com

I have to say, before anything else is said, that I approached the task of maintaining a git fork with considerable trepidation. I've never really maintained a source tree before that I wasn't really the only one making commits - that was an SVN repo, and honestly, I was never very confident that it could handle more than a few users working on the same project in the absence of some considerable out-of-band cooperation and coordination between those users.

Yesterday I made my first such effort with Git, and though I'm by no means an expert overnight, the whole process went smoothly (including a graceful recovery from a significant mis-step!) and I am delighted to say that I have not only completed successfully the process of merging a changeset to our local fork, but I was also able to make that fork available to others as an upstream source for pulling the changeset for testing and potential incorporation to the project's master repository!

Needless to say, I am very excited about how much I was able to accomplish. Read on to see how I was able to get this done.

Git: Preparing a new (branch if necesary)

One of the first things you should do, typically speaking, is establish a working branch (if you havent already. If you have, skip ahead to 'Introducing new/modified source to the tree', below). This would tend to mean you are already logged into a command shell on the computer that hosts your local fork.

First things first: change your working directory to the top-level directory in the git repository. This allows git to find the repo you're working with, without you having to specify a bunch of location-designation parameters for git on the commandline.

Now, the branch: if you aren't reading this section because you appreciate my mad literary skillz, you're probably reading it because you want to know how to create a branch; and the answer is really simple: you use the 'branch' option to git as shown below:

git branch branch-name

This will create a new branch, containing the exact same source (initiallly) as the 'master' branch of head (whatever was in the repo at the time you made your local fork via a 'git clone url' command.

Simple, huh? Not so fast! now you have to check out that branch to actually work with it. This is done with the following command:

git checkout branchname

Executing this command makes the new branch the 'working' branch. Remember, git is a sort of object-database manager - it has a backstore in .git/ in the top-level directory in the repo, and inside it stores compressed representations of all your branches. This is not as heavy as it sounds - it stores changesets as a set of 'deltas' or changes to the main branch (master).

Now we are good to make changes to our new branch. What? you already incorporated your patched/new files into the 'master' branch (like I did)? Not to worry - putting the master branch back in it's original state is easy as pi:

git reset --hard #hashnum

#hashnum should be the hash value for the last commit in your repository before you cloned it - i.e., your local fork's original condition. The hash value can be obtained using the 'git log' command.

Having reset the repository to it's initial condition (assuming you made a similar mis-step), you are now ready to start over at the beginning of this section and make a proper branch to work in. This implies something:

you should not be editing code directly in the repository - you should be editing only the 'payload' - a working copy of the code extracted from the repository.

For a deconstruction of the simple process that accomplishes this, see my last blog entry :)

Introducing new/modified source to the tree

If you arrived here by skipping ahead, you probably already know that you need to be in a shell changed into the top-level directory of your repository. If not, you probably should go back and read what you skipped, just for the sake of getting some background info.

Adding source to the tree was accomplished with a very simple process; I copied any files from my working source tree that had been created anew or modified into the branch. How this was accomplished is an area I will be exploring in detail in the near future - for this operation, however, it was very simple. I simply copied the changed/added files from the working source into the repository, after having changed branches. I have a couple of questions about this methodology - I'll address them in a later post, but I'll go ahead and ask them now: 1. are there other (better) ways to go about this? and 2. under what conditions might this turn out to fail?

Copying the changed/added files into the repo is not enough, however - we need to invoke git in a couple of ways to prepare/preview the changes to be comitted. First, we need to add the files, as follows:

git add filespec

filespec is a pathspec that points at the new/changed files; if the files already existed in the repo, they are silently ignored - if the are new, they will be added to the repo. Next comes the preview:

git checkout

This will display a list of new and modified files. You should review them for completeness prior to the next command, which will acually make the commits.

Making the commit

git commit

and that will wrap up the commit of the changesets to the local repo.

Wow, was that easy or what!

GitHub.com: Pushing changes from your local fork to your GitHub.com account

GitHub is a relatively new and powerful website complimenting git by providing git users a social metaphor for 'organic' developement conducted on git repositories. It is feature-rich and targeted at both the opensource community and companies who employ opensource developement methodologies.

You will need to obtain an account and log in there, and then make the proper arrangements for authentication. This is done using ssh/rsa keypairs. Full instructions for establishing an account and configuring it for use are available on their website at http://github.com. I highly recommend it!

Exporting your GitHub-hosted repository: The pull request

The need to use GitHub implies certain things about your work and your repository: you will need it if, for instance, your local fork is used to develop code for a remote project you dont have the authorization to 'push' code to - that you want to make available to the maintainers of that remote project for evaluation and potential incorporation into the primary project.

Dont get me wrong, this can be accomplished without the use of GitHub - GitHub just makes it easy to be very communal in your approach. This is a good thing (tm), as git tends to be best used in a very organically organized project, as most opensource projects are.

The way to get your changes on GitHub is excrutiatingly simple: you push them. Your account at github will provide two types of interfaces (in the form of urls) to a fork you place there: one for public (anonymous) use, and one for private use. The former requires no authentication whatsoever; the latter employs a set of rsa keys, exactly as you would employ in the establishment of a secure shell connection. See the GitHub link 'Help with Keys' on the account settings page for details for creating and installing these credentials on your particular operating system platform. Having done so, and assuming you've created a target repository on the site, the push is accomplished as follows:

git push url

where url is the url of the GitHub repository, e.g., git@github.com:JamesStallings/opensim.git

Conclusion

If I have been clear at all, by now you should have a fair understanding of what I did to make this happen. It's not a perfect workflow, more of a discription of my first attempt to establish one with git. I am happy to report, that the operation seems to be a success. I'll continue asking and answering as many questions as I can about git and supporting technologies - if you have questions, use that comments button and I'll see if I can answer yours too.

In my next topic, a few days down the road, I hope to have some answers about the questions I asked wrt proper ways to import new code into the repository - and perhaps take a stab at a formal workflow tutorial.

Thanks for reading!
James

Welcome back to me!

2009-09-03T06:17:00.000-07:00

It has been a very long time since I made a post to this blog. The reasons are many and varied - among them, that I had little to post about that wasn't some sort of whining or bitching or other negativity. As most of the reasons for this state of affairs were more personal than related to OpenSim or OSGrid, I felt it better that I remain silent than reflect personal issues on either of these splendid efforts.

Indeed, I have been considering passing the blog off to someone else, in the interest of keeping the name in good, productive hands.

That said, I've changed my mind. I do have something to post about after all, that is positive, usefull, and perhaps even potentially usefull to others! YAY!

So, without further ado, I'll make this new post, and hopefully many more to come, on the topic of the Git source control management system.

First, a little bit about why this topic comes to light at this time.

Recently, much to the dismay of many users (and not a few developers), OpenSim transitioned from the Subversion SCM to the Git SCM. Without getting too deeply into history, Linus Torvalds, originator of the Linux Operating System project, wrote git in an effort to make a better source control system, flexible enough to accomodate the needs of the many thousands of people submitting patches to the linux kernel, and to make his (or others, as the case may be), lives easier with respect to managing these many patch submissions when merging these patches. As with just about everything Linus does, he pushed the tool to the limits of software technology, and produced entirely new functionalities not previously seen in any SCM, that specifically target organic software developement processes within volunteer communities of open source developers.

Whew! good thing I didn't get too deep into history!

So, essentially, until it's a non-issue, have a look here each or every other day or so, for a 'Git Trick of the Day'. And with that, here's todays Git Trick of the Day, presented as a problem coupled with a solution to that problem (I'll try to stick to that format as I accumulate posts):

Problem:

The local git repository, obtained via the 'git clone' operation, contains much more than just the source tree for the project. It also contains a good number of git SCM artifacts, which represent the entire revision history of the project to the time of the clone. This makes it less than optimal as an environment for building and testing the code that resides in the project.

While this might seem an incredible handicap, it is in fact one of the chief sources of power that comes with git.

I dont want to get too far from the problem space I'm addressing here today, so I wont get into a discussion of those intricasies at this point - rather, I will provide a command for extraction of the source tree into a working directory apropos the build+test operation.

Without further ado, here's that command:
git tar-tree HEAD opensimstaging | (cd ~ && tar xf -)

Now, lets disect that a bit. But first, a little warning is in order: Git is still very much in developement, and change is the order of the day - you will need the latest stable revision to use this command (1.6.0.2 at the time of this writing). Further, I'm a linux user primarily, and I have not yet vetted this procedure on windows - though I will, in the near future, and in the not-too-distant future I will advise in a comment to this post as to how to accomplish this on that 'other' platform ;)

One last warning with respect to the changing nature of git: this command, even on this late stable revision of the code, is already deprecated! Dont let that concern you though - git is pretty smart, and will 're-write' the command for you to produce one that is more current. I'll add that to comments as well, once I've puzzled it out.

Onward!

The git command above does the following things:

Firstly, it executes the git command:
git tar-tree HEAD opensimstaging

What this does is extract an archive ready copy of the repository 'payload' from the HEAD - also referred to as the 'master' branch. This is the default branch of the repository, chronologically current as of the time the git clone command was used to instantiate a local 'fork' or working copy of the repository. It bases this tree in the relative directory 'opensimstaging'. You can feel free to replace 'opensimstaging' in this command with a directory name more appropriate to your local needs.

As the output being produced is in 'tar' (tape archive) format, this is the directory the tree will be unpacked to (were it actually being written to a tar file. Tar files are an associated topic, but a bit out of scope for this post). Suffice it to say, that this tar format file will be written to a special unix file called 'stdout'. This is also known as 'the console' - in other words, where things get printed.

This is where the rest of the command comes into play:
| (cd ~ && tar xf -)

Note the first character, the pipe '|' symbol. In unix parlance, this is the command's 'plumbing'. It literally ties the output from one command to the input of another, in this case a tar command.

Note the presence of the parentheses, the 'cd' command, and the double ampersand (&&). This construct has the following effects - the parenthesis binds commands together, and enforces the order of execution within them - think of it as a sort of aggregation of the commands within the parentheses, causing the shell to interpret them as if they were a single command. The double ampersands concatenate the commands adjacent to it such that the latter does not execute unless the former is successful. It's a sort of error-condition control. If the path requested in the 'cd' command does not exist, causing an error condition and failure of that command as a result, the subsequent 'tar' command will not be launched.

Barring any trouble, the sequence is like this: the tar formatted output from the git command will be passed to the tar command joined on the line by the pipe, but only if the encapsulated cd command works. Tar then unpacks the tar archive on git's output stream into the directory specified. Nifty, huh! and the product produced in the target directory is without the git-related objects that make up the repository proper, leaving it 'clean' for purposes of building and testing.

A further benefit is that the 'git pull' command can be used on the original clone to update it, and the process described herein repeated to produce an up-to-date build+test environment, without the overhead of cloning the project a second time from 'origin'.

I've tried to be both brief and thorough here, and I hope I've not added to your confusion - if you have questions, feel free to ask them in comments, or catch me on FreeNode IRC on #osgrid - I'm Hiro_Protagonist both there and on OSGrid.

Thanks for reading, and I hope I have been able to help you feel more comfortable with git!

Cheers
James

Hello, world!

2009-07-27T14:59:00.001-07:00

I am on the intarweb!

TERAVUS OUSLEY FTW!!!!!!!!!11 uno

2008-12-08T06:27:00.000-08:00

Teravus Ousley, among many other things, is the Open Dynamics Engine physics engine guru for the OpenSim project. Teravus, who is a proficient and prolific c# programmer, committed work on the evening of Dec 6 (or thereabouts) that fixed physical linkset and linkset collision issues.

This is a matter of some significance, and the importance of this work from a simulation science standpoint cannot be overstated.

Thanks Teravus, and Kudos!

W00Tz!!!

Building Rexx Viewer on Linux

2008-12-04T06:39:00.000-08:00

First off, the source is BIG. Weighing in at 20MB, it's a hefty download.

Having just unzipped it, I am surprised to see no README or INSTALL in the archive root. This is not especially encouraging. What is there are four directories: avatargenerator, maxscriptexport, rexmeshtool, and rexviewer.

With the complete dearth of any sort of build instructions, I am left with no choices but educated guesses - I rather suspect that avatargenerator and maxscriptexporter are utilities, and so I will begin with what might be the one included dependency, rexmeshtool. Here goes Norton!

Ok, so the rexmeshtool directory would appear to contain some sort of microsoft project. My guess is, there is no nant build configuration in the .sln file. Let's go see :D

Well, that didnt go far LOL

No nant .build file - this is essentially a microsoft-only project, and without a bit more work from the it's devs, it simply isnt going anywhere on linux.

I'd love to yell long and loud about the many things I had to do to get this to build - but unfortunately, that isnt going to happen.

So what I will yell long and loud about is this: This project is in NO WAY ready for building on linux. It may be a few short steps from it - it may be light years from it.

But without at least a prebuild file to gen a nant config to bootstrap the build process, it just isnt going to happen.

I will be keeping my eye on this, and on the Rexx guys - but they have a bit more work to do if they truly want to see this run on a linux desktop. Keep an eye on this blog for news relating to progress along these lines.

Cheers for now :)
Hiro P
OSGrid

Physical Vehicles Update

2008-12-04T06:21:00.000-08:00

**** Physical Vehicles Update ****

The short story is, we have a few now :D

Thanks to one Owen Oyen of SecondLife and OSGrid :)

One day last month, Owen showed up at my deltazone region to discuss physical vehicles. Owen makes some rather specialized content in SL - he is the one who brought us the pitching of boats under sail, tidal currents based on an analysis of sailing grounds, and a host of other good things related to virtual sailing in SL.

Owen's concern that day we met was why exactly there were no physical vehicle functions implemented yet in opensim. After a brief bit of discussion, we came to the conclusion that the llVehicle class of functions in LSL are really a dramatically simplified approximation of a linear motor with some twists thrown in - literally - for rotating a vehicle about it's axis of travel.

As proof of our sound thinking, Owen produced in collaboration with myself, a very satisfying and functional virtual sailboat :) recently, Owen and Bri Hasp have extended this further, producing an iceboat as well :D

Both are available at or near the south edge of Bri's 'Baya' sim on OSGrid. Unfortunately, Owen has chosen not to make the scripts open - leaving it to me to apply what I learned with him in the production of such scripts.

While I have not yet produced these scritps (I got a job shortly after Owen released his freebie-but-no-copy boat), I will do so in the future - and, I will happily share with you the basics of the implementation.

First, llSetForce and llApplyImpulse are used as motors, depending on the need and circumstance. Owen, I think, finally settled on the use of llSetForce exclusively, but for reasons that were a bit obscure to me. Second, to prevent the vehicle from accumulating energy on an exponential curve, llGetMass is used to calculate a bit of friction, which takes the form of a force applied in a direction opposite to the direction of motion, in the same timer-driven calculation that applies the force which keeps the boat moving.

Finally, a wind source and sail position/forces are calculated and applied. Coupled with some stabilization and correction of movement through the periodic re-inititalization of axes outside that along which movement occurs with constants (usually zero), we have a boat that is readily pushed about the sim on Owen's 'wizard wind', which he has scripted into the boat as well.

Maybe that reads like greek to you - if so, go pick up one of Owen's freebies at Baya and just go have fun with it. Be sure to read the included notecards, because this vehicle has peculiarities and quirks uniquely associated with opensim. If not, I heartily ecourage you to take up this ground-breaking work and see what sorts of vehicles you can produce.

Off to attempt to build Rexx viewer source on linux :D

Cheers for now :D

WISH MEH LUCK!
and see the following post, wherein I describe my rexx-viewer-on-linux-viewer-building experiences.

Hiro
OSGrid

Scripted Physical Vehicles in OpenSim

2008-11-07T16:40:00.000-08:00

First, to establish a bit of context on this report, I am referring to any vehicle that moves under the influence of the physics simulation. This specifically excludes llSetPos and like techniques.

While my experiments did not involve e.g., llSetVehicleType, they are still physical vehicles too - and dont worry, we'll examine the status of llSetVehicleType and friends while we're at it.

The first trouble I encountered in attempting to make a physical vehicle in OpenSim, is that there are no llVehicle* style functions implemented in the script engine. Or are there? a casual glance at the source code (if there is such a thing) would lead one to believe so. A closer investigation, though, will show that while the 'Not Implemented' stubs have been replaced with meaningful code that passes values up to the wooly innards of OpenSim, the afore-mentioned innards don't actually pass it on to the physics engine. But just about everything is in place to do so.

Why hasn't this last step been done? The answer to that is a bit complicated.

The short story is, the wooly innards are about to get rearranged, hopefully into a somewhat less wooly form. And as this is where all that physical script plumbing empties out, it's arrangement has considerable bearing on how llSetVehicle and friends are implemented.

Hold that thought while we take a stress breaker :)

What I *have* had at least some moderate success with is making a flying prim that is a physical vehicle. I know, but it's a start. How can this be done? Why, with llApplyImpulse and llTargetOmega.

Ok, it's an utter kludge LOL but it works.

Why llTargetOmega? it's the only LSL function currently implemented that can physically rotate a prim. llApplyImpulse provides both the lift and the forward thrust. I use the standard vehicle 'control' event to obtain the users inputs via 'llTakeControls', and I use llTargetOmega to stop and start a rotation of the prim when the appropriate keys are pressed to turn left and right.

Why dont I post that script here and now? It's just too ugly. When I spend a bit more time with it, I *might* actually have a reasonably manueverable flying prim - but as it is now, it's just barely proof-of-concept.

Now, stressbreaker is over!

Basically, the work on the OpenSim 'wooly innards' I referred to above is highly complex, represents a huge change to the core codebase, and must be worked over and discussed by at minimum 10 different software engineers. It's going to take a bit of time, I'm afraid. Be patient, it'll be worth the wait.

In the interim, I hope to properly implement llSetRotaionalImpulse and llSetRotationalVelocity, both of which bear enough resemblance to llTargetOmega that I should be able use it as a reference in the source code; if I am successfull, this should give us sufficient tools to implement some very useable vehicles based on llSetForce and llApplyImpulse.

Crude, I know. But better than a foot-race :)

Cheers for now!

KUDOS!!

2008-09-08T07:59:00.000-07:00

Kudos to JHurliman of the libomv project and Teravus Ousley of the OpenSim project for their highly successful efforts this weekend!

JHurliman and friends have recently finished up some fairly major work on libomv, and Teravus worked closely with him on the one hand, and with the opensim/osgrid user community on the other, to bring this fresh new libomv into our OpenSim project.

The technical hurdles were numerous and sometimes quite high, but these fellows were definitely up to the task and it looks as if all the real show-stoppers and toe-stubbers have been addressed; things are cooking along quite nicely. :D

Cheers Guys! Great Job!

Concerning the future of the 'Grid' as a paradigm for VR

2008-08-22T06:17:00.000-07:00

The Death of the Grid is Nigh!

Two of the most interesting OpenSim-related blog posts I have seen in recent weeks were penned by none other than Adam Frisby (his post is at http://www.adamfrisby.com/blog/2008/08/the-world-wide-3d-web/), and Justin Clarke-Casey (who's post is at http://justincc.wordpress.com/2008/08/15/could-there-be-a-future-without-big-grids/), pose the question, "does the grid continue to have relevance in the future of OpenSim, long-term?"

Whoa! Heresy! Blasephemy! Chaos! teh barbarians are at the gates!
Or are they?

The History and Nature of The Grid

First, lets reflect a bit by what we mean when we say ''Grid'' in the context of VR. VR has it's technical beginnings in the code of MMORPGs. If you don't know what an MMORPG is, you may wish to crawl back under your rock ;) SRSLY though, OpenSim inherits many of it's metaphors through a direct line of inheritance going all the way back to the text-only muds of yesteryear, and even more remotely to games like Infocom's ''Zork''.

For our purposes, a ''Grid'' is a means for grafting little slices of geographical metaphor together to present them as a contiguous aggregation of ''Land'', or ''RealEstate'', with all of the connotations and overtones that come along with that as baggage (or value, depending on one's perspective). That perspective largely stems from one's interests in implementing a virtual space.

This is a fairly traditional paradigm, and is largely taken for granted even in the literature which initially inspired the developement of current VR models; to such a degree that a potential debate begins to take form centered on the notion that grid vs. not-grid is an assertion in need of evaluation.

For myself and others, this is a question which is largely evocative of swift reaction, we having invested a great deal of time and energy in developing, supporting, and using grid applications of OpenSim and supporting software and practices. Upon reflection, however, I have arrived at the position that the question is largely moot. And I'll gladly tell you why in subsequent paragraphs, as we leave off the discussion of canonical grid architecture and examine that of OpenSim.

OpenSim Architecture

OpenSim is designed to address not just one but a potentially infinite set of use cases. Great care has been taken both in the forward-looking design and the backward-glancing refactorings to implement feature sets as modules. To say that OpenSim is very configurable is a gross understatement. OpenSim is literally three different complete software systems; the simplest of which is the 'Standalone' codebase - it is really the other two combined, but 'lite'. The remaining two software systems are the 'Grid Services', and the 'Region Server'.

As an aside, our first clue to trouble appears here, that is, even if there is no duplication in code, there is certainly duplication of purpose - the two variations (grid and standalone) are distinct in the interest of addressing concerns of scale. While scale is definitely a matter of concern if one wishes to embrace a large body of users, it's pretty well acepted that two distinct but similar applications is not the ideal way to address this concern.

The reason grid mode scales better than standalone is that the grid provides a centralized backstore for assets, user authentication, and user-ownership of assets. Or so the story goes. The truth is, these services do not, of a necesity, need to be delivered from a single source; in fact, there is every reason to believe that spreading them around a bit will - you guessed it - scale better.

To elaborate a little further on standalone (hopefully without putting too fine a point on it), the standalone codebase implements a specific use-case: the 'Walled Garden'. This walled garden, as the name suggests, is a slice of geographical metaphor that is unaffiliated in any other explicitly virtual way with any other seperate but similar slice of geographical metaphor.

A Potential Pheonix in the Making

Note that the primary reason for the existence of these two distinct but similar applications is more profoundly technical than social. Some might beg to differ, but the ability to limit incidental visits by anonymous or other uninvited users is more by consequence than by design. This is evidenced in the relative ease with which standalone has been patched in early OGP/InterOp testing.

What may rise from the ashes, or, where I'm actually headed with all this

Essentially, what needs to happen (and therefore, what will most likely happen) is that the current state of affairs will slowly be displaced by one in which a much more thoroughly distributed model will be preferred. Think standalone mode on steroids: configurable to use local or remote backstores; to participate (or not) in some third party authentication and/or asset providers; to appear (or not to appear) on agglomerative geographical representations, with concommitant metaphorical participation in-situ (see into/from 'adjacent' regions, participate in object/script crossings, physics/water table/terrain cooperations, etc.)

This architecture pushes relevant responsibilities for authentication, hosting, and permissions/ownership back onto the region operator, where they really should be. Does this really eliminate the 'grid'? potentially, perhaps, in any oraganizational sense. Grid operators will likely become the first operators of the afore-mentioned service level organizations. Indeed, they already are ;)

The Nature of the (new) Beast

- This 'idealized' OpenSim will be simpler to support. There will only be one of them, as we will no longer make a distinction between gridmode and standalone.
- It will be more homogenous, as all instances will be potentially reachable from all others, even where no metaphorical geographical relationship exists
- It will be more socially satisfying as all spatial agglomeration will be voluntary, deliberate, and by design.

Long Live the Grid, all hail the Grid

To bring this all to a comfortable close, I think the death of the grid is a bit overstated. Sure, it'll pass (especially in it's current incarnation), but it will represent the progress of many sure steps forward, and produce a far more usefull operational paradigm; one in which politics will become less important in the developement of the software, promoting easier support, smoother developement and testing, and a better, more satisfying VR experience for Operator and User alike.

So for my part, I say bring it on!

Cheers,
James G. Stallings II
aka daTwitch/Hiro Protagonist/Lazarus Longstaff

But SRSLY

2008-08-15T14:09:00.000-07:00

I haz created a more or less traditional book in OpenSim using LSL scripting.

It runs in a single cube prim. For your own copy of my first effort, paste this into a script and drop it in a cube prim:

vector opensize=<0.064,0.5,0.35>;
vector closedsize=<0.04,0.265,0.35>;
string book="closed"; // b6258725-335d-4e47-9676-39361010f5cc 34270b40-68a2-4341-aeb3-10e3b2f45214
list pageUUIDs=["ce3f600b-0028-40f0-a77b-10426b8ff975","07a9e95b-ef73-47ef-80f1-b6c168529142","e39d7c07-aa29-4776-8083-b6a055427995","589e5863-b3a5-4441-a2c8-fd960cf1997e","32ae5dd8-582c-410a-afc9-fef75fc4a6b4","4152fba5-02ef-4f1a-a7d2-9d4ebc4a8be1","f4427be8-651d-47d5-ab06-5597443b92d2","aeb9162e-a2e3-4942-ba58-1ed0cbb250ab","98888e86-b1d4-412f-b275-a98d04038dad","1840ea8f-ba8e-47b0-8182-cf3abc56bb8d","a00dd649-f617-4f39-a4e0-6b110199d439","a063425d-b31a-4309-8d4d-1886f1cd8530","afb3f53e-9ca6-425e-874a-f9bba796d7cf","09c65ace-d015-4a6c-9467-421f9f728f42","bb976ea4-f423-4706-b7f8-33fd4d856029","8b7f7d9e-57f2-4c17-a010-30972be1982c","707e44d8-e432-47f7-9535-b42e032f485f","f860fb9b-d1fb-486c-948f-7131bade9662","b065b77a-6e6c-4cfd-9079-50df43455595","006e3243-9817-49e2-b975-1c1c8e5b5222","2e86574c-21a1-46ef-a6cb-e076c6e94d27","f4df80e8-2e47-4287-abc8-9422d299995c","5470da29-83f5-4cab-8ee1-c0cd80102450","19ef268b-03e5-4678-aff8-d7db5d3b1ccf","fef6f8ed-554f-44e5-88ec-93338196981b","b61d1655-044f-4332-aa1b-558b042f2ea1","dbdeb221-5eb7-461e-acd1-a57b0e733c4f", "bf5b0c57-2d57-4bb4-82f3-a22ce8e9a1ac", "ccee6b1d-7201-43c1-bf31-e664a6f4c808",
"b6258725-335d-4e47-9676-39361010f5cc", // right here gets a repeat
"34270b40-68a2-4341-aeb3-10e3b2f45214","209f134d-32ef-49cf-8760-478f2e356534","d0353b58-7513-4180-90f2-5b0cba0fda5d","3f61aaa4-3168-4605-bcd3-41a12f0cae69","1d4072de-b47d-43f9-acf6-2bd33a081313","a6bcd0c1-af54-4639-8e44-804038b30c73","96989e63-3697-4952-9921-7f950122c962","13ac21e6-54a9-41be-9bb3-42dee4cbad8d","9378acb0-187a-48c9-94b3-dc3fad2e02d1","6992ee7b-b1c9-4685-9437-742ad33b066b","51061eb8-a8e3-48c1-b969-83cda8496250","e7a86214-23f5-4840-8eb2-fae38dcd0ddf","9a993a2c-c6f2-430c-95de-10367879cf1e",
"b3bd7ec4-ad57-427f-9d9f-dc1457a30d1b","d5d5d201-dbad-4540-9559-a75c768b0e75","ec60869c-df31-43fe-a80f-400f49b3f3d8","2f180734-558a-4e8d-9131-317f93f9019c","fab8d130-6d23-4c25-bd7e-abf0c2c9674f","e91a5db7-ad57-4766-9bcd-1b54f39bfb78","c5a0438c-e86c-4e8c-a461-a14570e36242","4092de87-0b38-4fe1-be51-ab258bfe01cd","1251b2ca-0602-4a57-a5d2-5e19898bdbc7","c0f03827-7112-4124-af64-37f5dc624c4b","d01de6ae-f48c-4781-884e-d8ffd7c9ff15","044038a3-e2ce-42f7-bead-2ac491e1e7fd","9d355fe2-4e47-473c-b197-c14096d04fb1","047295f3-2fbe-4bc0-a20a-0c4ee45e9c0c","f31329b3-5a86-4bbd-a354-946047293896","b3b8e143-596c-4dcc-b343-a1d6e2259ace","f89e5cfc-34f8-496a-8502-797878860b73","5512e24a-7ba1-4c60-8b0e-82be455d0314","2881aad1-f9ae-4145-9eb7-9cfaab604f26","b8892fb5-df34-448c-9528-f807b6d0c6cd","876a6985-c37a-4510-b940-cd185621f4ff","611fdde9-6abd-4d48-b4e8-aeda55414258","a46dade4-5efd-4f5a-afb0-e44324606405","bb89eebb-9e8b-4718-8fee-d0676a77839d","87955458-f05b-445d-8721-b359fcb1a279","ece2b053-0245-4b08-bc6f-22755823f968","7101e397-4f8b-43ff-80fb-2ea6eb792373","55fd7df3-06c7-4c92-9701-a511f3838317","80b13e0f-8f66-495c-9af1-086606e052fb","3435ed56-7e8a-4b8b-abf2-58011ff91b15"];

integer pagesets=72;

integer pageset=0;

settexture()
{
string ID=llList2String(pageUUIDs,pageset);
key textureID=(key) ID;
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",0);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",1);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",3);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",4);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",2);
llSetPrimitiveParams([PRIM_TEXTURE, 5, textureID, <0.5,1,0>, <0.25,0,0>, 0.0]);
llSetPrimitiveParams([PRIM_TEXTURE, 6, textureID, <0.5,1,0>, <-0.25,0,0>, 0.0]);
// llSetTexture(textureID,5);
// llSetTexture(textureID,6);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",7);
}

closebook()
{
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,1,0>, 0.0, <0,0,0>, <1,1,1>, <0,0,0>]);
llSetPrimitiveParams([PRIM_SIZE, closedsize]);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",5);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",0);
llSetTexture("041d02c0-b2fa-4ddf-bafb-c438adf72fc4",1);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",3);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",2);
llSetTexture("63f5294b-6a33-4219-97cc-d3965b7106fb",4);
}

default
{
state_entry()
{
closebook();
book="closed";
pageset=0;
}

touch_start(integer num_times)
{
if(book=="closed")
{
book="open";
llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,0.725,0>, 0.0, <0,0,0>, <1,1,1>, <0,0,0>]);
llSetPrimitiveParams([PRIM_SIZE, opensize]);
settexture();
} else if(book=="open")
{
pageset=pageset + 1;
if(pageset>(pagesets-1))
{
closebook();
book="closed";
pageset=0;
} else {
settexture();
}
}
}
}

See if you can figure out why it repeats the 31st pageset, I cant - it may be a bug in OpenSim.

Oh, and a bit of an easter egg for those of you running linux that read this far:
get a debian pkg of qavimator binaries here:

http://www.byteme.org.uk/qavimator.html

Cheers!

In the Interim

2008-08-15T14:05:00.000-07:00

How should I put this - I'm at no particular loss for words, but have little to say that's topical.

Sounds like a good application for 'Stream of Consciousness' writing:

Elation Shifting like Gold Sand with sun SHINING only dimly lit light lighting lightening but not too much wind of water contention strife simplistic overtones of disarmonious old music getting stale for friends new and old politics makes stranger bedfellows and still it's a chinese world after all

Concerning Open Content, DRM, and Second Inventory

2008-07-07T18:24:00.001-07:00

Greetings.

This post is to address some concerns expressed by one of my colleagues with regard to my mention of Second Inventory in my last post.

Having come to grips with my reactionism in response to what felt a little bit like an attempt at censorship, I came also to a realization that to a degree he was right - I had made certain basic assumptions that not everyone is comfortable with.

As far as I am aware, Second Inventory does not allow it's users to copy content that doesn't belong to them; let me be perfectly clear for the record when I say I certainly hope it does not. I don't use it myself, being strictly a linux person.

I have every reason to believe that the tool was being used responsibly by the parties mentioned in this context in my prior post. As far as I know at the time of this writing, there are two viable ways for moving 3d content inter-grid - the copybot and Second Inventory. Both are tools; as such, they are meritorious only according to their usefulness. Like the hammer and the saw, they can be used in both constructive and destructive ways. The good or bad is in the hand that guides the tool.

I did not mean to either personally nor on behalf of anyone at OSGrid.org, OpenSimulator.org, or OMF.org endorse content theft, content theft techniques, or any other sort of encroachment on anyone's rights to the legal use of their property. Nor do I anticipate changing my stance on that in the future.

That being said, however, I will continue to promote increased knowledge of tools and technologies useful for the ethical use and reuse of content in the most effective and efficient methods possible, and decline to take responsibility for the actions of the disaffected and despised who surely earn their infamy through their deeds.

With Kindest Regards,
James G. Stallings II
aka Lazarus Longstaff/Hiro Protagonist/daTwitch

Dateline 2008-06-07: The Week in Review

2008-07-07T07:16:00.000-07:00

Sneakiepeek:
Qee Nishi Rocks the House at Shengri La

Greetings and Salutations Avies!
It's been a busy week, chock-full of fun and good times for all! so lets get the ball a-rollin' as we take a walk forward through time from this time last week...

Zaius Plaza Build
Zaius Plaza, currently under construction (of course, isnt everything?) is rapidly becoming freebie heaven for OSGrid. Contributions are coming in en-masse from Shenlei Winkler and Nebadon Izumi, both importing content via SecondInventory they have created over the years on the Linden Labs grid. Both have been content creators on the SL platform for three years or so. Shenlei's mall will contain her offerings, and Nebadon has set up the bottom three floors of OKC Tower as a freebie-zone and Art Gallery. Both creators are donating the body of their imported work to OSGrid users, if you seem 'em in world be sure to say thanks!

Additionally, OKC Tower is also a community freebie-zone, so if you have content you'd like to share, come on by Zaius Plaza and drop it off at OKC Tower.

Bade Plaza Build
Bade Plaza is a build I'm conducting pretty much solo, so it goes in fits and starts as I move around between evangelizing and supporting OpenSim and OSGrid, creating content, and otherwise taking care of business.

Having gotten a little tired of working on all these techie-looking projects in the midst of my more or less pastoral digs at Hoffman Sim, I decided to make use of a work plat I had established some time ago at 500m altitude; going to and from rapidly became a pain.

Bade Plaza Under Construction

So, on a whim, I decided to make a decent teleportation system (I know, this tale is supposed to be about Bade Plaza - bear with me a sec).

This actually came together quite nicely; I'd recently tested bulk upload with a ton of rich textures from Filter Forge, one of my favorite sources of free textures. Great software too from the look of it - but I dont do windows.

The scripting evolved quite naturally from a combination of a waterfall script, an alpha-adjusted tie-die texture, a posing stand script, and a couple of calls too llRezObject and llSetPos. Look for the system in a package (real soon now) over at OKC Tower in Zaius Plaza, or pop over to Bade Plaza and take a copy of one of the operating units.

Bade Plaza Teleportation Device

And with that feeble seguey I'll get back to Bade Plaza. Bade is an unusual build; it's a small city (tiny really) consisting of four approximately identical apartment buildings in each of the four corners; the region is layed out approximately symmetrically, and each of the buildings are joined to the others by walkways couched in gardens and aqueducts. The region is surrounded and bisected on north and south axis by waterways, with a central pool.

The apartment buildings provide ready dwelling spaces for region squatters/homesteaders. They also provide the-ground level support for a massive 200m+ skyscraper called Blade Tower that dominates the entire rest of the city. Tower space is available only by special arrangement (contact yours truly with your ideas if interested).

Oh, and you can see the teleporters in action there too.

AdamZaius comes to OSGrid and Brings His Regions With Him
Boy, Howdy!

Apparently, AdamZ doesn't believe in doing things small. So far, he's dropped a few tens of servers on the grid, practically doubling the number of regions attached. What's more, he isn't finished yet. By my reckoning, from the hints he's dropped on #osgrid at FreeNode IRC, he will own fully 4/5ths of OSGrid's regions by the time he's finished. What a freakin' load test for the UGMAI! Go AdamZ!

The InterOp Love Fest Continues
After week-before-last's Linden Lab powows, Which Linden's Office Hours were a little anticlimactic and highly technical. Only the AWG hardcores were in attendance; I think John Q. and Mrs. Public are growing weary of detail, as I note their attendance is beginning to slowly fall off. Probably such things go in bursts anyway.

Which's Office Hours were more a brainstorming session than not, though I think (s)he may have preferred it to be more of a presentation. I don't think (s)he got finished, and was perhaps a bit worn out from the difficulties of trying to communicate clearly and effectively one's ideas in cleartext. Of course, anyone who cares about the issue has their own ideas about how all this should work; not all of them are cluefull. 'Nuff Said. Here's a link to a transcript of Which's Office Hours.

And Finally....Party at Shenlei's Shengri La!
Ok, lets get a couple of things out of the way right off the bat, and then we'll get to the pix:
1. This was hands-down the best party I have ever attended in Second Life. No question about it. The Host (Rez Tone) and Hostess (Shenlei Winkler), were phenomenal, the people in attendance were notable and photogenic, as was the venue; and then there was ...
2. QEE NISHI. Qee spins the techno. Qee spins the rave. Qee spins the trance. Qee spins it all in a contiuous flowing stream of cosmic notification that she is rockin' the house. I just can't say enough about Qee. Her av is the picture of her sound. A total package - absolutely incredible.

And the last bit of party news before we get into the photojournalism:
Shenlei and Rez are planning to collaborate with Qee on OSGrid's first major event. Heavy iron is being donated to carry the load of 40+ highly decorated and animated avatars and scripts. It's gonna be a party to remember! Sometime in mid to late August. Keep your eyes glued to this blog for more details on this event as it unfolds.

So, here's the pics from Shenlei's Party this past weekend at Shengri La:

This is Shengri La on the night of the party:

Here's our beloved host and hostess in proper form. Rez veiled in particles on the left, and Shenlei on the right in the articulated wings.

Nebadon Izumi (one of my OSGrid Ops colleagues) and his good friend Coke Supply Get Down on the dancefloor:

The inimitable Qee Nishi!

Qee show's us what it is that's sexy about technology:

Qee against a backdrop of Rez's molecular construct. By any chance would that be a caffiene molecule Rez?

That's it for now, a fun and busy week!

Celebrate content! We sure did!

Cheers,
James
aka Laz/Hiro/daTwitch

Dateline 2008-Jul-01: A Day in the history of VR

2008-07-01T20:35:00.000-07:00

Greetings from the interwebs and farflung VR spaces!

Tonight I'll be relating a set of VR history-making events (at least *I* think they are history-making) that occurred over the course of a very busy day in cyberspace.

First, was the Architecture Working Group meeting on Linden Lab's grid, led by Zha Ewry of IBM. This was one of the best meetings I have yet attended on the Linden grid - the participants were passionate, reasonably polite, very focused, and very well spoken. It was almost completely devoid of backchatter and heckling, and no one showed up to fling poo prims. +1!

Next was OpenSim Office Hours, held each Tuesday at 12:00 noon PST. Most all of the OpenSim Principals were in attendance, in addition to several linden labs folk who made their first appearance on OSGrid. And, we broke our previous record for concurrent logins to a single region server! Read on to find out just how many folk attended.

Finally, winding up the afternoon, was Zero Linden's Office Hours, where he made a brave attempt to present his outline for a permissions system that would provide the necesary mechanisms for implementing DRM obligations in an open grid services environment. More on this later though. Let's get into the thick of it!

AWG Meeting re: Domain Membership and Trust, with Zha Ewry of IBM

This was an awesome meeting! The best LL-sponsored meeting I've yet attended. I dont know how much design work was actually done, but a lot of understanding was passed around. Link to the transcript here. The thing that made this meeting great was there was no real heckling; everyone there was focused on the issue before us; no one was really ill informed, or at least, no one was unwilling to expand their understanding. It was a fantastic meeting with an equally fantastic group. Great Job Zha, Saijani and AWG!

Linden Labs vs. OpenSim Office Hours on OSGrid, with a broken record!

That introductory blurb doesn't do proper justice to what happened - it makes it sound like a musical experiment gone way south! Here's what *actually* happened:

We set up for office hours, as per usual - except perhaps there was more of us in attendance than usual. I dunno, maybe everyone was just free at that time for once. In any case, we piled on in and had just begun to discuss our agenda, when the first Linden Labs representative showed up. Unless I am mistaken, this was one Hamilton Linden. Next came Infinity Linden, followed at some interval by Whump Linden (he came in a bit late, and unfortunately we did not get to chat with him at much length). Zha Ewry also made it by, to round out the party.

With so many special guests at Office Hours, we were behooved to some flexibility with respect to our agenda, finishing up quickly with our more routine discussion, and turning the floor over to our guests. Hamilton did most of the talking, desiring to confirm that we had some marginal level of interest in assisting with their interop testing; I wonder if he wasn't a little overtaken by the strength of our response. All expressed interest in assisting with testing in whatever way possible, and several of us made one or more of our regions available for R&D. Here's a phat link to a transcript, and an even tastier link to Nebadon Izumi's video of the occasion. High point of the meeting: when Hamilton Linden looks around at Wright Plaza and asks "Did you build this build in OpenSim?" Serious Chucklehead, that Hamilton!

What? I forgot something? a broken record? Oh, that was just the soundtrack for Zero's presentation on Permissions...just kidding!

The record that was broken, for the number of consecutive logins on an OSGrid region - was at Wright Plaza - we hit 25 main agents (the prior record was 22), with no significant lag or other issues, and the region never did crash, though JustinCC did mention his inventory was flailsome - but I think he was probably the only one diggin' in inventory, so hard to say if it was anomolous or not.

Zero Linden's Office Hours Permissions Presentation

Big, heaving, tired sigh....Poor Zero - I feel for him. Seems the asshats *always* show up and disrupt his meetings. I often wonder why he even bothers. He's clearly got the patience of Job.

Today Zero attempted to deliver a presentation on the plans for a permissions system, one that would ideally complement the things Zha and AWG are doing with Region Domains and Trust Protocols. Unfortunately, most of the folk in attendance at this meeting had neither bothered to attend Zha's meeting nor read the transcript beforehand. It was a chaosfest, and that was before the first griefers showed up.

Hardly anyone there had sufficient understanding to ask intelligent questions, and when Zero was able to address their talking points directly, they often didnt understand one or more of answer and implications. Many slipped into "this is fundamentally broken" trains of thought, or "just open it up like the web" mode. Most seemed to think we were discussing user interactions with an interface when in fact, in most cases, we were discussing transparent communications exchanges between client and server components.

Then there were the griefers. I'm not sure what it was they were slinging around; but eventually, the prims were cleaned up, and the offending parties removed.

Then came the second wave.

And the third. I'm not certain whether or no it was a PN attack, but it was certainly crafted to look like one. Particle rezzer spewing 'srs nigras' e.g., a black man with a large afro in a grey dress suit - basically, the PN logo. Personally, I think it was likely a 'false flag' attack, the PN are -much- more repugnant than this.

Zero handled all this with not inconsiderable grace, and extreme patience to boot - as numerous god-mode Lindens were zipping about cleaning up and banishing identified offenders to the seventh level of hell.

Hang in there Zero, some of us actually do benefit from your presentations!

Oh, and here's a link to a transcript from Zero's meeting.

All in all, it was a great and momentous day in VR - new ground was broken, bridges were built and plans for the future were laid. Thats my kind of day - where we can all get in the pit together and show a little love.

Cheers from Hoffman on OSGrid!
Hiro Protagonist aka Lazarus Longstaff aka daTwitch aka James G. Stallings II

News You can USE

2008-06-30T08:00:00.000-07:00

Greeetings!

Recently, Nebadon Izumi (another of the OSGrid admins) and I conducted a very interesting and productive test on OSGrid. We employed a light-weight patch against mono trunk that enables the use of large heaps on linux, and compared it against a similarly loaded windows region running .net.

This post is a general description of the test - a more detailed analysis will follow shortly.

The test was basically comprised of DMiles' (#opensim-dev, FreeNode IRC) patch (which can be found at http://opensimulator.org/wiki/GC_NO_EXPLICIT), and related instructions.

Our initial test involved enabling the Boehm garbage collector as per the instructions and testing against an empty sim which we then populated with multiple copies of the same scripted prim.

This reference prim contained a script which loads a radar map from intellicast.com on 15 minute intervals, then paints it on the prim face with the proper osFunction().

Using the patched mono I was able to load no less than 1024 of these prims into the region.

The region ran for some 12 hours without significant issue.

Memory consumption for the region was 1.3 GB

While this rendered the region unusable from a client running on the same box as the test region (my normal approach to things), it was still quite useable from a different box on the same lan, as were the other four regions running on the same hardware.

Speaking of hardware, my configuration is as follows. I'll include the software while I'm at it:

Hardware:
Pentium D dual core running at 3.0GHz
2 GB ram
SATA HD subsys
10/100 switched network
Tier II DSL (256 DN/96 UP)

Software:
Debian Linux unstable branch (sidux)
Mono svn (a recent revision - sorry, the best I got right now)
OpenSim r5189 (at the time of this test)
MySQL 5.2

Other sifgnificant facts about my installation:
It's my desktop machine, so typically runs an mp3 player spinning from the local disk; X.org; and the client.

My OpenSim configuration is OSGrid attached with a MySQL backstore for the regions' assets and grid inventory.

As for more general workaday useage, it goes something like this:

My home region on OSGrid, Hoffman, has around 1000 prims, and around 100 scripts (animated fires mostly). With a single avatar on the region, it typically consumed around 120-160 MB. Since the application of this patch to mono, the footprint has decreased by some 40 MB on average. This is consistent with the reduction in footprint when the sim is unoccupied, when I have seen memory usage drop to a low point of 35MB - typical useage under these conditions pre-patch was around 70MB.

Nebadon's findings on windows/.net reflected a similar memory usage profile. His installation is a Core2duo at 2.2GHz with 2GB ram running Windows 2003 Server and .net; everything else pretty similar except he has a much faster internet connection (the winserver in question is hosted at cari.net). He ran 500 or so of the same test scripts; his memory consumption bounced around a lot between 500MB and 1GB depending on whether or not he left his avatar idling. Mostly closer to 500MB.

All in all, at least anecdotally, every indication is that this is a Good Thing to do for your regions.

*** note: at the time of this writing, the patch is known to be broken due to a hand edit gone bad. A few plus signs are missing somewhere. It was trivial, however, to apply the code change with a manual insertion of the code to the mono source. Will attempt to get DMiles to polish this a bit Real Soon Now.

Hope this gets you more bang for your OpenSim buck!

Cheers!
James/Hiro/daTwitch