SineWave (with a little bit of help from DeepThink) is running a big Pub Quiz, this Friday on OSGrid.org. For those who are outside of Britan, read the wikipedia article for an overview on what this is, the rules and format.

The short

It’s on OSGrid.org, in the SineWave Region - 5PM GMT / 12PM EST / 9AM PST, Friday the 10th of October (this friday!). Total runtime is expected to be fourty minutes or so. You should register your avatar in advance on this page.

The rest

You should try test logging into SineWave sometime before the event, as we’ll be trying to start promptly. There’ll be other prizes including some hosting from DeepThink and maybe a little more. Performance will be a little slower than usual since the region will be operating under a performance profiler, but should still be acceptable.

As usual, we’ll publish the profiler results to help other developers - if you want to bring friends, feel free as the more avatars logged in, the better the quality of the results we get.

FAQ

Why are you running this, $500 is a lot to give away randomly? We’re doing this as a load test on OpenSim - we’re looking to get about 100 avatars or so and see where OpenSim stresses so we can optimise and fix those areas.

I need to get onto OSGrid - how do I connect? We recommend you grab the Hippo Viewer, it’s free and will connect by default to OSGrid (although it has support for any modern opensim grid)

I’ve been afflicted by this very problem myself lately, which is why this post has been sitting in my head (along with a slight hangover) for the last few days.

It should go without saying that a single developer can only achieve X number of features/fixes/improvements in Y time (and not every value of X is equal), but the moment you substitute “X” with specific feature names, it suddenly becomes urgent priority for everyone to stop work on it and get that done, to hell with everything else - although we want that too … and a pony.

The facts of life

The reality is - we’ve got a finite number amount of time, a finite number of developers, and a not-quite-so-finite list of features and improvements we have to spend time on, this means we prioritise stuff. We say “We think stability is a prerequisite before you go about implementing an example micropayments system.” - and with good cause, if the system didnt have that prerequisite stability, why the hell would you trust it to handle important or sensitive information?

This is not to say some of us havnt devoted time to thinking about it, it’s just that we each have our own ideas about what we think is important, and unless you are actively assisting in some capacity (food, booze, code, testing, etc), your personal wish list probably isn’t going to get any attention.

It’s harsh - but there it is. At the end of the day, each developer has a finite amount of time to work on projects, and when they are working on things - there is a strong chance that a specific goal is in mind and needed. If you want to change that goal, you either must have a convincing reason that that person is interested in and agrees with, or you need to provide an incentive to compensate for time that would otherwise be spent elsewhere. It’s also quite possible to just get in there, and do it yourself then submit those changes back.

Backseat Driving

There’s a lot of developers working on the OpenSim project - and each of them has their own ideas, goals and projects. Some of them are working on commercial projects that rely on OpenSim - and hence have some very specific feature and stability requirements that they work on. Others have more free reign by virtue of doing this in their spare time. There is a common misconception that the OpenSim team has an agenda - there’s somewhere around 200 developers on the project which means there’s 200 sets of agenda’s.

Right now, my personal agenda (which by proxy does carry a little across to what the DeepThink developers are working on) looks something like this:

• Abstract login and client initialisation to a more generalised interface to allow third party login and authentication routines to be fitted more easily as loadable DLLs.
• Find where we have remaining hard-coded references to LLClientView bits and bobs, and recode them in a more vendor neutral manner.
• Have a look at some of the terrain control issues reported on the mailing list recently.

It’s a pretty short list - this list gets revised, updated and changed pretty regularly based on what I need to do at the very moment, it’s the same for a lot of the other central developers - they are built on a task-by-task basis.

So - if you have a feature you really want to see happen, that you really think is important we tackle and address, your options include:

• Do it yourself - the code is there and we dont bite when it comes to new contributions. (Just as long as the code matches our other guidelines about quality, modularity, etc.)
• Convince someone to do it for you - this it the hardest of the options since we’re already very busy as a group, but it’s certainly possible. Make a convincing argument - it helps if you can research it and break it down into specific tasks. (”Improve stability” is not a task - “Fix crashes when/while XYZ happens” is.)
• Hire someone to do it for you - it’s an option on the table too. There’s a lot of developers familiar with the codebase now, lots of them are looking for beer money and can implement your pet project or ideas for a fee.

So in conclusion - if you have something you really think is important, really want to see - think it through, ask yourself “Is this more important than what people are working on already”, “Is this something that OpenSim is ready to support”, “Is this important enough that I am willing to work to see it done?”, and finally “If no-one thinks it’s that important, ready or <insert reason here>, am I willing to pay to see it happen?”. Because at the end of the day, features take time, and time is a non-renewable resource - people like to see it invested wisely.

The deadline for the screenshot competition is now over - I have a few hours to get the designs incorporated into our materials and get them off to the printers. We’ve had a couple of folks interested in helping man the booth - at this stage it looks like we’ll have between 5 and 7 people there at all times which is a great turnout. Look forward to seeing everyone then!

I’ve got a whole bunch of screen shots so far (if you haven’t got a reply from  me yet - please wait until Tuesday when I do the selections). I will be closing submissions on Tuesday, if you haven’t got your submissions in, I need them by Tuesday, 12PM Lunchtime GMT, however I’d really appreciate them all in by Monday evening.

Your screenshots will be featured on some of the posters we’re designing at the Virtual Worlds conference, we’re including an image credit and URL on them. Some may also be used in the information booklet we’re preparing to have printed for visitors to our booth.

We’ve got a couple of tickets available for people who can help us explain OpenSim to conference attendees in our very-spacious booth being sponsored by DeepThink, Genkii, RealXtend, SineWave and ISID.

If you want to get a free pass to attend in return for helping us out:

• You must know your stuff - you must be a regular user of OpenSim and/or RealXtend, ideally hanging on the IRC channels or reading the mailing lists too.
• Be prepared to spend at least a couple of hours in our booth (you don’t have to stay for the whole time)

If you are interested - send me an email or leave a comment where I can contact you. We’ve got a number of free passes so the more the merrier.

Here’s three screen shots from a OpenSim demo that DeepThink is working on to exhibit at Virtual World Expo in LA. If you want to see more, you will just have to come show up at the OpenSim booth and play around with it in real time. (We’ll also put it up online somewhere after the conference is over).

If you are very familiar with the operation of OpenSim (actual developers will be prioritized here) I have a couple of free tickets available for people to man the booths with. Contact me for details.

This one comes up a lot - I hear it in quite a few places “Well, shame it’s in C#.”, it’s usually followed by some nebulous statement about Microsoft, followed by patent threats, embrace extend extinguish, etc etc.

So let’s start with the basics -

• C# is a ECMA and ISO standardized language. It went through the review procedures of ECMA and ISO in a standard fashion (unlike OOXML). Download the ECMA Spec here and the ISO Spec here.
• Yes, the base library is included in that standardization. The primary exceptions are, ADO.NET, ASP.NET, Web Services and Win Forms. Many of these exceptions are however separately covered via Microsoft’s Open Standards Patent program, although we’ve moved to avoiding them entirely in the standard release. (Extensions which use them are however available on the third-party utilities forge)
• The ECMA standard also includes the CIL byte code format.
• If Microsoft decide to add new extensions onto .NET (which they have done with every major release), the OpenSim developers are content to wait until those extensions are available under Mono (which moves fast enough that it isn’t a major problem).
• Microsoft is not known for breaking backwards compatibility to “extinguish” things - the mere fact you can still run Win3.1 applications on Windows Vista should give some assurances there. Microsoft is yet to make any kind of retroactive change to the .NET standard - all .NET 1.1 applications should still run under .NET 3.5 without changes. (and the cost to them of making a change like that would be significant in terms of people using applications under Windows)
• There are two completely F/OSS implementations of C#/.NET and the standard library. Mono (Licensing Concerns Addressed Here) and the FSF’s DotGNU PNET. OpenSim is regularly tested for compatibility under Mono (in fact our automated testing environment uses it). DotGNU is significantly less popular and has not been properly tested with due to not being feature complete yet. There is also a third source-availible implementation from Microsoft called Rotor, however it is not under a OSI-approved license.
• Microsoft maintains a reasonably healthy relationship with the Mono developers and has been known to collaborate in the past (such as for the development of the specialised Moonlight runtime).

The next question usually is “Well, why not write it in Java then?” the answer is multi pronged and highly likely to generate a flame war on the subject - the biggest reason is that coding the same thing in Java would probably take significantly longer to do.

Java is a beast of a language that has had layers of gunk added in every revision resulting in a hodge-podge of inconsistently named items in the standard library that may, or may not address what you want. The second major reason is that the C# standard library is both larger and more functional - the amount of time and effort the Base Class Library has saved is astonishing. Wikipedia has a nice article detailing the differences between the two languages.

However, since both Java and C# share a very similar byte code language - it is possible to do a machine driven cross-compilation so you could run OpenSim under the JVM runtime if you so wish. Source translation between the languages is also reasonably possible however requires a degree of manual work.

Some concluding facts which may actually surprise some people

• One of the largest contributors and users of the project is IBM. One of the first groups inside of IBM to get involved was IBM’s Linux Technology Center. All[?] of the IBM developers are using Linux, Emacs and Mono to develop and test.
• Approximately half the developers working on OpenSim are running under Linux/BSD. As a user base, Linux users represent approximately 80-90% of the casual testers and operators. (Windows is however much better represented in people running commercial operations)
• Our compatibility targets are Mono 1.2.5 (latest is 1.9) and .NET 2.0 - we dont use features which supercede these (although we may raise that to Mono 2.0 once it is out of beta).

What this competition is about

For the upcoming Virtual Worlds 2008 conference in LA, myself and some of the other OpenSim contributors and developers have decided to sponsor a large booth, and we’d like to cover it with screen shots of the best and most innovative uses of OpenSim out there today.

What we need

We need high resolution screen shots from your builds, ideally these should be captured at a minimum of 1600×1200 pixels (if you are using the Second Life™ viewer, the “High Resolution Screen shots” option works well). All settings should be set to maximum, ideally with anti aliasing, screen shots should have a minimal amount of adjustment (limited to cropping, brightness) and originals should be provided.

The Specifics

• High Resolution - We’re printing onto a 300 DPI surface, this means we absolutely need the highest possible resolution when printing to make sure we have crisp clean non-blurry images. While there isnt a definition of what is or isnt high resolution - try submit screenshots at least 1600×1200, higher is preferred.
• Submit in a lossless format - We need images provided in either 24-bit PNG, TIFF or BMP. As these files tend to be rather large, please zip or rar them with maximum compression.
• If you are submitting a manipulated image, the original is required as well. There is no guarantee that the manipulated version will be used. (We are trying to provide accurate but nifty portrayals of what OpenSim can do.)
• Deadline - submit your images before Wednesday, 27th August 2008. Sooner is appreciated as we will begin incorporating images into the layout as soon as they are received.
• How to submit images - Please use a service such as yousendit.com to transfer the archived files, send your message to “adam@deepthink.com.au”. My inbox will reject files larger than 10mb, so please do not send these directly.
• Judging will be done by myself in conjunction with the other people sponsoring the booth. Decisions whether to utilize an image will be based on constraints such as whether or not we can work them into the larger montage and do so in a way which highlights OpenSim in a positive way.
• Some tips - People/avatars always look good. Eye candy is always a plus. Showing scenes where this is in production and potentially useful for people interested in using it are also going to be in demand.

What you get?

Accepted and utilized images will get 6 months free standard-class region hosting from DeepThink to a grid of your choice. The Judges may provide hosting for images of excellent quality which are unable to be used, however this is soley at the discretion of the judges.

Every now and then, this hits me. I fire up OpenSim (or RealXtend), and it crashes instantly with a “BadImageFormatException” - when you see this, you know you have a compatibility problem with an embedded C/C++ binary. In english, 90% of the time this means you are running under a 64-bit environment with a mix of 64 and 32bit code trying to run together.

OpenSim is 64-bit aware

The reason for this happening is that OpenSim by virtue of the .NET platform is quite 64-bit aware, this means natively it can address 16TB of memory just fine if run on a 64-bit operating system. (nb, under Mono you need to make sure Mono is 64bit to get the same benefits).

However unfortunately, some of the libraries we link against have to be compiled ‘one way’ or the ‘other way’ and not both.  When running a 64-bit application, things such as memory pointer lengths are difference, so there is no way to cleanly pass data between a 32-bit and 64bit application - everything must be one or the other.

So how do you fix this?

There’s two routes, the easy route, and the proper route. The easy route is good for 90% of our users - if you dont need to access more than 4GB of memory and dont mind about the slight slowdown when handling double precision numbers, then just run 32-bit.

How? Instead of launching OpenSim.exe launch OpenSim.32BitLaunch.exe instead - this forces OpenSim to run under a 32bit environment (under windows provided by WoW32).

The more detailed fix

The next option is to strip out the sections that are causing problems. OpenSim is modular - so you can swap bits and pieces with their alternatives. The following are components that are not 64-bit compatible by default (however it is possible to fix this, something I will get to in a moment.)

Incompatible Components List

Physics - most problems come from our Physics Engines, since these tend to be written in high performance C/C++ with ASM littered. The following list of physics engines by default are NOT 64-bit compatible.

• OpenDynamicsEngine - The ODE DLL we provide is compiled for a 32bit operating system, however you can fetch the sources for our custom ODE DLL from (SVN) http://opensimulator.org/svn/opensim-libs/ and build it yourself on your native environment.
• AGEIA PhysX - The AGEIA PhysX support (now Nvidia PhysX) relies on a natively compiled 32-bit DLL. At present there is no fix here.

Compatible Engines

• BasicPhysics - This is purely managed but very simple in operation. Collisions are provided only between the avatar and the ground here. This runs without problems regardless of environment
• POSPhysics - POS physics is a more complicated BasicPhysics engine with bounding box collisions between objects. For some tasks this is sufficient.
• BulletX - Our own custom BulletX library is derived from the BulletXNA project, this is a properly developed fully managed physics engine that does proper collisions (however the friction coefficient can be a little low for some users).

Storage Engines - At least one of our storage engines relies on some hard coded components, it’s listed below

• SQLite - Whaaa? SQLite is broken on 64-bit environments? Afraid it’s true. Unfortunately on Windows systems the only solution is to recompile the entire of Mono (including Mono.SQLite.dll) yourself under a 64-bit flag.

Compatible Engines

• MySQL - The DotNetConnector provided by MySQL is 100% compatible and probably the recommended adapter for production installs.
• MSSQL - Windows-only however MSSQL is also free and the adapter is built into .NET itself so is pretty much guarunteed compatible.

Other incompatible components

Perenially we have problems with the following components in addition to the above, this includes libsecondlife’s OpenJPEG version - this can be fixed by compiling libsecondlife and OpenJpeg (using make) on the target system. This may have been fixed recently however as complaints about this DLL have lessened sharply.

Running

Once you have swapped incompatible components out, or recompiled them appropriately, OpenSim should run under a 64-bit environment natively on Windows. As mentioned above, under Linux/Mono you will need to make sure that Mono has been compiled as a 64bit application for this to take effect.

The differences between the two are mostly marginal, however there are some definitve improvements in certain mathematical loops and stability when using large amounts of memory. In production environments, running 64-bit mode can be an attractive option, however will require constant maintainence to compile the above libraries as new releases occur.

I’ve noticed that there are a lot of resources out there for how to run your own OpenSim instance, but they are so disparate that finding them all can be a challenge, especially as each tends to have it’s own self contained target use case.

So in order to make life easier for people, I have compiled a list as follows

For Windows Users (Desktop and Server)

• Maxx Monde has written an excellent set of tutorials, you can read them as follows.
  • Part One: Compiling and Installing
  • Part Two: Commandline Usage
  • Part Three: MySQL Databases
• Virtual White has also a set of tutorials which cover mostly the same things as Maxx’s.
  • Part One
  • Part Two
  • Part Three
  • Part Four
  • Part Five
• OpenLife have a ‘ready to run’ standalone launcher which while lagging a few months behind the latest release, tends to be stable and easy to use.
• The “Semi-Official” Instructions from the OpenSimulator wiki
• How to connect to your OpenSim from the OpenSimulator wiki
• Tool: OSTray - OpenSim Tray Launcher
• Tool: DeepServers - ASP.NET GridServers (written by DeepThink)

For Linux Users (Server Oriented)

These links usually also work for MacOSX as long as you are familiar with a commandline.

• Official OpenSim Instructions
• Getting OpenSim Running on a VPS connected to OSGrid for $15/month written by myself. (Start to finish tutorial)
• Tool: Moo Console Launcher and Configurator
• Tool-ish: WiXTD - Based on the popular OpenSim Web Interface
• Tool-ish: OpenSim Web Interface (redux)
• Tool: OpenUGAI - Cgi-bin Perl GridServers (written by 3Di)

Pages worth bookmarking

• OpenSim Forge - Tools and Utilities for OpenSim and peripheral software.
• OpenSim Related Software Page - ditto.
• OpenSim User Documentation Page - User documentation from OpenSim developers
• Planet OpenSim - Blogs, news and other commentary on OpenSim
• OSGrid - Nonprofit free to use grid built by members, lead tester of the OpenSim software. (See also how to attach a region)
• RealXtend - OpenSim derivative with some cool features (Windows-only)
• SLUniverse’s Other Grids Forum
• OSGrid’s Forum

Enjoy. I will try to periodically refresh this when new useful resources appear.