Fundraiser! Let's bribe LL for an option to disable automatic camera movement!

My frustration is passing a milestone.

This feature has been requested for longer than I've been in SL (and that's approaching a year soon).

It's time to get serious.

It's time to put money down on the table to get this done.

I'm asking people to pledge an amount of US DOLLARS (or food / alcoholic beverages / etc) to be put toward development of an *option* in preferences to disable *all* automatic camera movements.

Please pledge your support by specifying how many US dollars (or pizzas or beers, etc) you'd be willing to send to LL to keep a developer around late one night (or whatever it takes) to get this implemented.

Keep in mind, upon implementation, you should keep your promise to transfer the amount you specify directly to LL to be given to whoever gets this implemented.

I'm starting this off with a pledge of US$50.

Please feel free to pledge even as little as US$1. Any amount is good, so long as you demonstrate your frustration by participating.

I'll pledge $25 for this. Way to go Kex. ^^

A bottle of 15 year old Laphroaig scotch (aprox. value $75)

I sympathize. There are times I just can't take anymore camera nonsense and pack it in for the day. It's diabolical, in an otherwise modern graphics system.

However, the problem isn't the raising of a large-enough bribe to tempt LL to get this attrocious thing fixed, because after all, thousands of people are suffering this hundreds of times a day so there is bound to be huge support for it.

No, the problem is attracting LL's attention to the issue in the first place. There is no way that they've not spotted the huge outpouring of customer irritation about it since launch, so they must be avoiding the topic on purpose. The question is, why?

What we really need is someone to drop in on them at their SF offices, and demand 10 minutes of their time on behalf of the long-suffering SL players. We don't deserve a Second Rate camera system.

Oh, everybody has their price. I pledge $25 as well.

Well, once I get a response back from my bug report on the issue, I might just start making a bug report for every object I edit.

I'll put in my $75.00

I've thought about it many a time, since it matches my interests, but I'm averse to reinventing wheels that already exist commercially.

To qualify as "a better SL", it would have to be more than just an open project. It would have to:

1. have a better architecture with distributed content and distributed processing (even Philip Linden said as much),
   
2. be built on ultra-modular incremental foundations (because monolithic offline software updates don't scale),
   
3. be founded on a paradigm of total distrust between all communicating entities, in addition to basic network protection,
   
4. be language-agnostic not only for user scripting of object behaviours but also for incremental core developments, and
   
5. be client platform-agnostic since a community metaverse doesn't have the limited horizons of a commercial product.

That's a very tall order, I know, but a worthwhile one.

The two aren't mutually exclusive though. I dare say that many people would like to help LL improve their current product and work on the community metaverse/multiverse of the future at the same time.

Heh! People are going to accuse you of being our alt, Morgaine

Basically, everything youve listed, we've pretty much set as guiding principles for OSMP, and I think we're doing a fair job.

Going through your requirements:

> have a better architecture with distributed content and distributed processing

Anyone can host a sim. You can hyperlink between sims. Each sim has its own asset server.

There is an authentication server available to make hyperlinking between sims completely transparent. Authentication servers will form trust relationships using Kerberos.

> be built on ultra-modular incremental foundations (because monolithic offline software updates don't scale),

OSMP currently contains roughly five separate executables on the server, and three or four on the client + a Physics dll.

The executables communicate between each other using XML over sockets IPC.

It's totally possible to rip one executable out (eg physics dll, or file transmission exe) and replace it with another.

> be founded on a paradigm of total distrust between all communicating entities, in addition to basic network protection,

I guess I touched on this in the distributed architecture section above.

Anyone can create a sim. You assign a sim to an authentication server. When users connect to your sim directly, they are redirected to authenticate with the authentication server. Once the auth server gives the greenlight you're in.

Multiple sims can connect to a single authentication server. Once you're authenticated with the authserver, you can hyperlink transparently between all sims connected to that server.

You can authenticate with multiple authservers - as can a sim - to be able to transparently hyperlink through multiple authserver webs. You obviously will have to log in once to each authserver, but after that it's transparent.

In the future, authservers will be able to trust each other, eg using Kerberos, forming webs of authservers and extending the extent to which hyperlinking stays transparent, no need to authenticate with each individual web.

> be language-agnostic not only for user scripting of object behaviours but also for incremental core developments, and

Each executable within the system, and as we have said there are a few, can be written in any language you choose.

Currently, we are using C++ for most things and Python for the GUI, but that could change at any time.

Forking is encouraged. It'd be great to see two renderers for example: one in OpenGL, one in DirectX; or two physics engines, one based on ODE, one based on... something else. And this is all consistent with the architecture.

As far as the actual scripting engines, a scripting engine is simply a client to the system like any other, with certain privileges, locked to its IP address. The client communicates with the server infrastructure via normal XML over sockets IPC. You can have multiple scripting engines and they can operate absolutely in parallel with each other.

Currently, we have a demo that uses C++, because there's no reason why sim-global logic cant be implemented in C++, and a Lua engine, which executes scripts assigned to objects within the sim, analogous to LSL. But better.

> be client platform-agnostic since a community metaverse doesn't have the limited horizons of a commercial product.

OSMP runs over platform-independent toolkits so is generally portable. We are using:

- ODE Physics Engine
- Lua Scripting Engine
- SDL
- TinyXML
- pthreads
- MySQL database engine
- OpenGL graphics engine

Theres a detailed architecture description here:

http://metaverse.sourceforge.net/architecture.html

(or go to http://metaverse.sourceforge.net and click on "OSMP Architecture"

For examples of things you can do in OSMP which are difficult to achieve in LSL, please see my signature.

If you could be interested in contributing, please dont hesitate to get in touch.

Azelda

Very impressive, Azelda!

I read your article through a couple of times and it was very encouraging. The only part that I thought missed the mark a little was:

That's a rather coarse level of granularity, and only a developer that's acquainted with the entire unit could be expected to do a good job safely modifying such a monolithic process. Furthermore, the special local change couldn't be offered to anyone else without them replacing their entire executable too. It's not very flexible nor upgrade-friendly.

What I had in mind was a much more finely granular approach, where virtually every factored-out piece of functionality is implemented within a dynamically reloadable segment in which the coding of that functionality can be in any language that has been bound into the framework. I call it micromodularity, and it's not hard to do. The benefits of micromodularity in distributed projects are enormous:

1. every project member is using the language in which they are most competent, so code quality is better;
   
2. all coding is performed in the highest level language that can deliver the required performance in that particular unit, so progress is faster because high-level abstractions require less coding;
   
3. each language is good at some things and bad at others, so this allows projects to use the best features of each --- horses for courses, and no whacking in screws with a hammer;
   
4. optimization is trivial, because only the magic few percent of performance-critical micromodules need to be replaced (one at a time) by evil speed demon versions and nothing else is affected;
   
5. all the language implementation types work together for best effect, ie. from native code (even assembler where appropriate), through static compiled bytecode and the dynamic bytecode of modern scripting languages;
   
6. "rapid development" is, for a change, actually rapid, because micromodules stand alone and only a trivial API definition needs to be scanned by compilers; and finally
   
7. with a bit of ingenuity, you can perform all upgrades live, completely transparently --- OFFLINE UPGRADING DOES NOT SCALE to a community metaverse.
   

As you see, I regard micromodularity as pretty important. Furthermore, it's not an optional extra, because unless you write the system with that in mind, it pretty much cannot be repartitioned to adopt such a structure later on.

That said, OSMP does seem to have gathered a very large number of the key principles under its project belt. Excellent!

Morgaine, it's open source, if you wanna work on a micromodularity architecture for us, we would love to integrate it with the main code tree

I'll post $1 to see this working.

On a related note, I wonder if anyone has scanned the SL client for linked-in GPL code or similar? It would certainly make things "interesting" if LL became legally obliged to release client source and some Windoze developer could then fix the problems that LL refuses to fix for us ... the lousy camera handling being the first under the scalpel of course!

OK, I'm in for US$100.

What we need to do is deal directly with a developer to do the fix on their own time. After all there have been over 50 posts requesting this and LL ignores them all so appealing directly to Philip Linden will not work. QED.

Yeah, it could be dangerous for the developer, I'm sure LL would fire him or at least give him a good keel-hauling for fixing this precious bug they have been cultivatiing for so long. For LL it will be like loosing a close friend. But he could add the toggle in a debug menu item, that way we could get the benifit and LL would never know.

P.S. pease consiider this post non-gender specific EOE.

If things get nasty like that, we talk to Mitch Kapor. There is no way in hell he'd allow a top developer to be fired for fixing a very long-standing bug. Silicon Valley would screw him into the ground if that ever got out and he supported it. But he wouldn't support it. He didn't get to where he is by ignoring customer needs.

The metaverse project sounds interesting; but will it stand the test of time? As an open source project it's still a baby; not even reached 6 months old. If it's still going strong at 18 months then you will have captured my interested.

Q: So far how many dedicated pulbic servers do you have running it?