From experience with OMP when we had a server going, it -is- fun to fly around with other people. The operative term here, of course, is -fly-.
Once you get into orbit, it gets horribly boring, and don't even think of doing interplanetary stuff - time acceleration doesn't work in a multiplayer environment. Formation flying isn't all that great either, since there's a limit to how precise the server can be in positioning ships.
All in all, if you want a multiplayer scenario, you're better off doing something like FSX.
Hello:
Long time listener, first time caller.
*picks up the "beat the dead horse" bat from the table*
I believe the issue of multiplayer being "individual ships" is a miss from the intent of what I know myself, and the few folks I use orbiter with.
Our thoughts are more towards the idea of multi-CREW, rather than multi-player, as such.
Meaning, I am not going to worry if I don't see manned ship float by; as you've pointed out, you aren't likely to.
Back in the late 80's-early 90's, there was a UNIX (yes, /the/ AT&T ver 3.1) "Star Trek"-ish game where everyone was logged into a central server that was the "ship". Each "player" was a console on the bridge of the same ship.
I'd like to see Orbiter become the graphical version of that concept. Timing, and relative/absolute placement of a vessel in space would only need to ever be dictated by the "server" vessel, and everyone else would take information from that, then if any updates put the server, and client out of sync by more than 10K, ignore the data, and continue along the previously known/established line/trajectory information.
This is the simplest way to get orbiter in it's current form to a reasonable multiplayer scenario to start with. Once the mechanics are in place, then apply it in scale, and as stated many times over, just ignore ships >= 100K, and any ships within that distance, ignore data that is an adjustment of previous state more than Xk over previously known speed. In other words, if the ship is traveling at 18k p/s breaking away towards where ever, and you get an update that says they moved 200k in a second, you can safely ignore that packet, and normalize the data to "they moved only 18k" and trust the next packet or two will have correct data in it. Obviously these are bogus numbers, as the potential for a person to move 200k in 5 dropped packets is not unrealistic, but, you get the idea.
But, the real thought I wanted to bring out is that Multi-Crew is not the same mechanical nightmare as muti-vessel. You know where the ship should be, and the clients should be told to ignore data that is unrealistic to the last known good data.
In fact, it almost seems like with the graphics engine, and orbiter_ng, you could just have multiple systems attach to represent different views, and focus of the same ship, and the "server", or "ship" be the atomic choice maker.
Don't get me wrong, I would love to see a persistent "real world" application of orbiter, and have folks be able to move about in a larger environment where "Trade Wars 2000" is graphically made. But, to be realistic to the current iteration of the engine, and limitations thereof (which aren't really limitations, as such, only when viewed against the multiplayer concept), then multi-crew maybe what needs to be the first settled-for step in pushing orbiter into this design concept.
At that point, the simplest thing is as some say...avoid the whole time warp feature, and just force people into proximity-activated jump gates. Not a pretty solution, but, allows those of us that want to run our computer for 7 months to mars the option, or, if I want to go eat dinner with my wife, and kids, I can spend a day or so setting into position for a gate that gets me within a days maneuvers for mars.
*sets the "beat the dead horse" bat back down on the table*
