# OMP Support

Status
Not open for further replies.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Okay, I flown with RacerX and I foumd out what the problem was. This will help others, too. The thing is,.animations on omp are not shared...

Maybe this post will help others, but I doubt that will last over one thread page. I have already noted the lack of animation support in the manual's FAQ section (p. 20): http://omp.ddns.net/hg/omp/raw-file/0.7.1/Doc/OMP/OMP.pdf .

What I'm wondering about is this:
P.s , yes our nosecones were open and we were all set for docking.
As it is relatively easy to see if the docking partner's nosecone is open in the local simulation, I'm confused now.

Are you really sure that what caused your "bad temper" post was actually the lack of animation support?

Don't get me wrong here, but this is why I prefer clear bug-reports written in a calm manner. If people get upset about OMP (and I can totally understand this!), they tend to overlook important details. That's why I always suggest to step back a little from OMP if it is getting annoying. I do it myself to maintain sanity.

Last edited:

##### Member
Maybe this post will help others, but I doubt that will last over one thread page. I have already noted the lack of animation support in the manual's FAQ section (p. 20): http://bitbucket.org/face/orl-online/src/0.7.1/Doc/OMP/OMP.pdf .

What I'm wondering about is this:

As it is relatively easy to see if the docking partner's nosecone is open in the local simulation, I'm confused now.

Are you really sure that what caused your "bad temper" post was actually the lack of animation support?

Don't get me wrong here, but this is why I prefer clear bug-reports written in a calm manner. If people get upset about OMP (and I can totally understand this!), they tend to overlook important details. That's why I always suggest to step back a little from OMP if it is getting annoying. I do it myself to maintain sanity.

All I know is that I couldn't dock to either Racer nor the 'new guy' until I opened both mine and their nosecones, while they did the same. I'm really unsure if the reason it the lack of animation on OMP, but on OMP Orbiter still treats every Ship around you as your own, and when you'd be playing offline, you'd have to open both your and the nosecone of the ship you want to dock to, and I do think that's the reason.

#### RacerX

##### Donator
Donator
face what vlad is saying is there are times for unknown reasons that sometimes the docking don't "stick". What vlad is saying is a type of in-game "fix" to the docking
problem.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
face what vlad is saying is there are times for unknown reasons that sometimes the docking don't "stick". What vlad is saying is a type of in-game "fix" to the docking
problem.

Well, I kind of guessed so, but still his first post is suggesting a different reason for the described situation:
P.s , yes our nosecones were open and we were all set for docking.

This would mean that his first post was NOT about the following:

• User A and B meet in orbiter, coming closer.
• User A opens docking port, tells User B to do so, too.
• User B confirms, but tells A that his docking port is not open.
• User A disagrees, he tells B that his own port is NOT open, but A's port certainly is open.
• Both disagree, going "Huh?"

This is what animation support is about: reflecting animated parts in the counter-part simulation. This is not supported, so you will always have this difference in vessel-state.

Vladimir explicitly denied this scenario to be the case in the quote above. That's why I've got confused by his posts.

The "not sticking" effect is explainable: some vessels use the state of the animation to actively deny Orbiter's default port docking by means of undocking vessels immediately. OMP is detecting this and propagates the result: undocking of vessels. So what happens is the following:

• User A and B meet in orbit, getting closer
• User A opens his nosecone, and also B's remote-vessel nosecone by means of F3 focus switch.
• User A docks to B's remote-vessel. His session detects this and plays the docking sounds.
• In User B's simulation, though, the cones are not open, so the appropriate vessel implementations immediately undock the supposedly accidental docking, thereby triggering the OMP propagation of the undocking event.
• User A receives this event and gets the vessel undocked again, playing the undock sounds.
• User A perceives it as "not sticking together", although the real reason is the lack of animation support together with simulation of docking port status in the involved vessel implementations.

So if this is what you are talking about, then what we have is not a docking problem, but a state representation problem.

There are "real" docking problems too, that's why I'd like to keep it precise in this regards.

regards,
Face

#### jangofett287

##### Heat shield 'tester'
I know this is probably too obvious, but could the problems be caused by Client A and B docking at the same time, then sending these events to each other, causing each client to both send and receive a docking event, the result of which can vary depending on the synchronization of the two clients?

#### RacerX

##### Donator
Donator
Well, I kind of guessed so, but still his first post is suggesting a different reason for the described situation:

This would mean that his first post was NOT about the following:

• User A and B meet in orbiter, coming closer.
• User A opens docking port, tells User B to do so, too.
• User B confirms, but tells A that his docking port is not open.
• User A disagrees, he tells B that his own port is NOT open, but A's port certainly is open.
• Both disagree, going "Huh?"

This is what animation support is about: reflecting animated parts in the counter-part simulation. This is not supported, so you will always have this difference in vessel-state.

Vladimir explicitly denied this scenario to be the case in the quote above. That's why I've got confused by his posts.

The "not sticking" effect is explainable: some vessels use the state of the animation to actively deny Orbiter's default port docking by means of undocking vessels immediately. OMP is detecting this and propagates the result: undocking of vessels. So what happens is the following:

• User A and B meet in orbit, getting closer
• User A opens his nosecone, and also B's remote-vessel nosecone by means of F3 focus switch.
• User A docks to B's remote-vessel. His session detects this and plays the docking sounds.
• In User B's simulation, though, the cones are not open, so the appropriate vessel implementations immediately undock the supposedly accidental docking, thereby triggering the OMP propagation of the undocking event.
• User A receives this event and gets the vessel undocked again, playing the undock sounds.
• User A perceives it as "not sticking together", although the real reason is the lack of animation support together with simulation of docking port status in the involved vessel implementations.

So if this is what you are talking about, then what we have is not a docking problem, but a state representation problem.

There are "real" docking problems too, that's why I'd like to keep it precise in this regards.

regards,
Face
user A and B have the nosecones open. The docking does not stick. So user A hits F3 and opens user B nosecone. user B does the same with User A . docking is now achieved. vessels used was user A XR-2. User B was XR-1

Last edited:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
I know this is probably too obvious, but could the problems be caused by Client A and B docking at the same time, then sending these events to each other, causing each client to both send and receive a docking event, the result of which can vary depending on the synchronization of the two clients?

I doubt this, because although there is a docking event propagation happening, the receiving clients don't do anything with it yet. Only on receiving the undocking event the clients actually undock. Relevant code locations:

user A and B have the nosecones open. The docking does not stick. So user A hits F3 and opens user B nosecone. user B does the same with User A . docking is now achieved. vessels used was user A XR-2. User B was XR-1

This is where I've got confused... Vladimir said essentially the same thing: "both have the nosecones open, but the docking does not stick". Yet in the next sentence, there is the statement that "switching to the other user to open the nosecone fixed it". Is it only me that sees the contradiction in the sentences here? First the assertion is that both are open, then the statement is that you have to open it in order to work. This way of explaining it quickly leads to communication problems.

So if we can all agree on this description now, I can finally understand what happened to you there:

• From User A's point of view (POV-A), only the own vessel's nose cone was observed as open. No info about the nose cone of User B's vessel from POV-A. I suspect it is NOT observed as open from POV-A.
• From User B's point of view (POV-B), the observation is mirrored. In POV-B, User B's vessel is open, but not User A's.
• Only if all vessels have the cones open from all view points, docking can be established.
• If only one POV is seeing all cones open, but the other is still not having the same observation, it will still fail with the "not sticking" effect.
I know it sounds like nitpicking, but it is really important to get this right. As I already said, I know the effect to happen in the above described way. But never when you see all cones open in all POVs.

I also guess this is the last info I'm missing: in the not sticking case, does anybody of the docking partners see the other cone still closed? If so, how did the assertion that "all cones were open and we were clear for docking" came to be? Simple misreport from that new user on the other side, maybe?

regards,
Face

Last edited:

#### RacerX

##### Donator
Donator
I doubt this, because although there is a docking event propagation happening, the receiving clients don't do anything with it yet. Only on receiving the undocking event the clients actually undock. Relevant code locations:

This is where I've got confused... Vladimir said essentially the same thing: "both have the nosecones open, but the docking does not stick". Yet in the next sentence, there is the statement that "switching to the other user to open the nosecone fixed it". Is it only me that sees the contradiction in the sentences here? First the assertion is that both are open, then the statement is that you have to open it in order to work. This way of explaining it quickly leads to communication problems.

So if we can all agree on this description now, I can finally understand what happened to you there:

• From User A's point of view (POV-A), only the own vessel's nose cone was observed as open. No info about the nose cone of User B's vessel from POV-A. I suspect it is NOT observed as open from POV-A.
• From User B's point of view (POV-B), the observation is mirrored. In POV-B, User B's vessel is open, but not User A's.
• Only if all vessels have the cones open from all view points, docking can be established.
• If only one POV is seeing all cones open, but the other is still not having the same observation, it will still fail with the "not sticking" effect.
I know it sounds like nitpicking, but it is really important to get this right. As I already said, I know the effect to happen in the above described way. But never when you see all cones open in all POVs.

I also guess this is the last info I'm missing: in the not sticking case, does anybody of the docking partners see the other cone still closed? If so, how did the assertion that "all cones were open and we were clear for docking" came to be? Simple misreport from that new user on the other side, maybe?

regards,
Face
hey face I am confused. when you say "see the other persons nosecones open" do you mean animation ? that would be no because you disabled them correct? verbal communication in Teamspeak3 is how we know that the other persons nosecone is open. it is the first thing you ask when docking does not "stick"

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
hey face I am confused. when you say "see the other persons nosecones open" do you mean animation ? that would be no because you disabled them correct? verbal communication in Teamspeak3 is how we know that the other persons nosecone is open. it is the first thing you ask when docking does not "stick"

Ok, we are getting closer...

When I say "see the other persons nosecone open", I actually mean "see the other vessel's nosecone open". If you do not see this in your own simulation, the not sticking effect is almost certainly appearing.

I did NOT disable animations. They are just not supported by the propagation system by default. This is why an animation event on one user's computer is not propagated to the other person's computer, thus not causing a local cone-opening to happen on the remote machine, too.

You see, it is very simple: what you see on your machine is what your simulation is doing. If you do not see your docking partner's cone open in your simulation, of course docking will not work properly with vessels that take this into account. No matter what he tells you what he is seeing on his end. This is also true for the docking partner.

The confusing part is when only one partner is realizing this and thinks it is enough to open the opposite cone himself. Because in this case what I described already is happening.

OMP is not changing vessels and their behaviour, it tries to synchronize the states of the local vessel with the remote counter-part in order to create a distributed simulation network. Unfortunately, the already implemented recorder event propagation (that would cover a large part of the animation support) is not working properly due to some Orbiter core limitations. I've deactivated this animation SUPPORT, not the animations themselves.

My suggestion for such sessions would be like so: if you want to dock, you're first question should not be "is your cone open?", but "do you see our cones open?" . If the answer is no, give advice to direct the docking partner to open both cones in his simulation. Of course you should do the same thing.
This suggestion holds not only for docking. If you have other means of coorporation - like e.g. attachments - both parts have to do them on all vessels to see the expected result everywhere.
So basically, if other users report a status that is not the same as the status you see on your machine for that user's vessel, do not expect things to work perfectly.

Example: crash the XR2, so that wings/gears are destroyed. Due to the flight operation, this will happen on both machines, the owner and the viewer. Now repair your XR2 on your side. This operation is changing the status of your vessel on your machine, but not the vessel on the viewer's machine. Now fly around with this repaired vessel again. The viewer will see this vessel flying around, too, but behaving strangely with a kind of hick-ups. This is due to the changed aerodynamic profile implemented in the vessel for the status "damaged". This status "damaged" is still active on the viewer machine, but not on the owner machine. There you are back to status "normal".

All those bugs fall into the same category: incomplete state transfer.

regards,
Face

#### RacerX

##### Donator
Donator
ok so basically the problem is incomplete state transfer. And this is due to limitations in the orbiter core itself? And if so why does the docking errors happen only some of the time? Why the intermittent error? Seems to me like the lag/latency may have something to do with it. Another question. users A,B,C are all docked to ISS. B,C sees A docked. A sees B docked but C is not and a small distance away. B reports no issues all is well. Same thing? Incomplete state transfer?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
ok so basically the problem is incomplete state transfer. And this is due to limitations in the orbiter core itself?

No. The incomplete state transfer is of course OMP's fault. The reason why an attempted approach to implement state transfer - recorder events - did fail is a limitation in Orbiter's core.

And if so why does the docking errors happen only some of the time? Why the intermittent error? Seems to me like the lag/latency may have something to do with it.

This is what I can't really see in your descriptions. To me it looks like simple misunderstandings while coordinating the all-must-see-open situation. Latency plays no part in this. Please define what you mean with docking error. The not-sticking effect we have discussed at length now.

Another question. users A,B,C are all docked to ISS. B,C sees A docked. A sees B docked but C is not and a small distance away. B reports no issues all is well. Same thing? Incomplete state transfer?

No. This is almost certainly due to a missing master setting on one of the cluster members, just as noted in the FAQ (OMP.pdf, p. 21, right on top). I'm planning to do this automatically, but ad-hoc networking with auto-master detection is not exactly trivial .

#### Yankee

##### Donator
Donator
Hello.

I am having a problem getting the Linux OMP server to run. The solution, while probably very simple, is being elusive :idk:

Basically, it seems like a path issue. For example, when I issue
Code:
mono ServerConsole.exe
from within the /Server/Linux/ directory, it throws an exception:

Code:
Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path "/home/orbitersrv/orl-online/Server/Linux/..\../Config/Sol.cfg".
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at System.IO.File.OpenRead (System.String path) [0x00000] in <filename unknown>:0
at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize) [0x00000] in <filename unknown>:0
at System.IO.StreamReader..ctor (System.String path) [0x00000] in <filename unknown>:0
at System.IO.File.OpenText (System.String path) [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Map.DecodeSystemConfiguration (System.String file, System.String system) [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Map.InitGlobals () [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Map.Reconfigure () [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Server.Start () [0x00000] in <filename unknown>:0
at Orbiter.ServerConsole.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.DirectoryNotFoundException: Could not find a part of the path "/home/orbitersrv/orl-online/Server/Linux/..\../Config/Sol.cfg".
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at System.IO.File.OpenRead (System.String path) [0x00000] in <filename unknown>:0
at System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize) [0x00000] in <filename unknown>:0
at System.IO.StreamReader..ctor (System.String path) [0x00000] in <filename unknown>:0
at System.IO.File.OpenText (System.String path) [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Map.DecodeSystemConfiguration (System.String file, System.String system) [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Map.InitGlobals () [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Map.Reconfigure () [0x00000] in <filename unknown>:0
at Orbiter.Multiplayer.Server.Start () [0x00000] in <filename unknown>:0
at Orbiter.ServerConsole.Main (System.String[] args) [0x00000] in <filename unknown>:0

Now, I'm a little out of my league when it comes to running Microsoft applications on Linux; I've hardly ever had reason to use Wine, let alone Mono. But the problem seems to come from "Could not find a part of the path "/home/orbitersrv/orl-online/Server/Linux/..\../Config/Sol.cfg"."

As I'm sure the reader knows, directory delimiters in Linux are denoted by the forward-slash "/". Conversely, Windows generally uses the back-slash "\". My take on this error is that it's mixing Linux and Windows syntax for some reason when trying to locate and parse /Config/Sol.cfg.

Perhaps another thing to note is that the error looks a bit different depending on which directory I'm in when I issue "mono ServerConsole.exe" In the example above, I issued the command from /home/orbitersrv/orbiterroot/Server/Linux/ . In other words, I tried to start the server with the prompt inside the ServerConsole.exe working directory. This is reflected in the error message. For example, if I attempt to start the server from directory x, Mono will report it was unable to find a part of the path at "x..\../Config/Sol.cfg"

Note: identical error occurs regardless of which of the seemingly myriad versions of OMP I try to use :lol:

If someone could point me in the right direction, I'd greatly appreciate it.

Output of "uname -a"
Code:
Linux archsrv 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 09:14:51 CEST 2012 x86_64 GNU/Linux

Thanks,
Yankee

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Do you have an Orbiter installation at "/home/orbitersrv/orl-online"? Because if there is no "/home/orbitersrv/orl-online/Config/Sol.cfg" file, it won't work.

The path separator differences between Linux and Windows should be no problem if you use the appropriate .NET classes like System.IO.Path and associated static methods like Path.Combine, just as OMP is doing. That this is working fine shows my own experience with my private OMP server that is running since the beginning of the .NET development: Linux UML with Mono 1.2.6 (a really old beast).

Please keep in mind that the ORL-online packages are not stand-alone. They are meant as addons to the Orbiter installation, just as every other addon. Without an Orbiter installation's "Config" directory, the server will not work. This prerequisite is also mentioned in the manual at page 3, chapter 4 (Installation), last paragraph.

For the reasons WHY the server uses this "..\..\Config\Sol.cfg" part at all, please re-read the manual and the appropriate chapters about server configuration.

regards,
Face

P.S.: Mono and Wine are different concepts. Mono is a native Linux .NET runtime, while Wine is emulating the Windows OS APIs for executables. If you run OMP on Mono on Linux, you do NOT emulate Windows in the process. If you are more familiar with it: it is just like running Python programs.

Last edited:

#### Yankee

##### Donator
Donator
Ah, thanks for the speedy reply. Sorry it took me so long to get back.

And yes, I do have an orbiter installation in that dir, and the Sol.cfg is where it should be.

The path separator differences between Linux and Windows should be no problem if you use the appropriate .NET classes like System.IO.Path and associated static methods like Path.Combine, just as OMP is doing.

I think my problem is due largely to not understanding the second half of that sentence, AT ALL haha. I'm going to re-read the entire manual, maybe I'll find something this time. If not, I'll try running all of the several different orbiter multiplayer packages I've found around the net, again. Maybe I should also downgrade my version of Mono to 1.2.6? Currently, I am running this:

https://www.archlinux.org/packages/extra/i686/mono/

Thanks again,
Yankee

#### Ren Dhark

##### Member
Mono version

Maybe I should also downgrade my version of Mono to 1.2.6?

I'm running OMP on Mono version 2.10.8.1 just fine for a long time.
On Ubuntu Server I need to install some extra mono library like:
libmono-posix2.0-cil
libgdiplus
libmono-winforms2.0-cil

Did you change the path in server.xml and what version OMP are you using?

Currently rebuilding your problem with Arch Linux 3.5.3 inside Virtualbox.

Edit:
OMP version 0.7.1 running without any error on a basic ArchLinux (3.5.3-1) installation with mono version 2.10.8.1.
Sorry, I couldn't reproduce your problem.

Last edited:

#### Yankee

##### Donator
Donator
Wow, you really didn't have to go so far to help! But I really do appreciate it. Thank you.

I'll start from scratch, detailing my actions one at a time to see if it might shed some light on the problem.

1. Reformatted the box, fresh copy of latest Arch Linux and fully updated.
2.
Code:
pacman -S mono p7zip mercurial
3. Created new account "orbitersrv" with home dir at /home/orbitersrv/. Added user to group "users" and nothing else.
4.
Code:
wget [url]http://orbithangar.com/orbDownload.php?file=orbiter100830.zip[/url]
5.
Code:
mv orbDownload.php?file=orbiter100830.zip orbiter100830.zip
so filename is less obnoxious
6. unzip orbiter100830.zip
7.
Code:
hg clone [url]https://bitbucket.org/face/omp[/url]
folder "omp" now holds OMP client and server content
8. cd omp/ && cp -r * ..

Now, if I haven't screwed up, everything should be in it's right place for a working vanilla OMP server. I'll try running.

Code:
[[email protected] Linux]$mono ServerConsole.exe Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Orbiter.Multiplayer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Orbiter.Multiplayer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'Orbiter.Multiplayer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Orbiter.Multiplayer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' This is good. The error isn't as huge and severe looking as my earlier attempts. I see it's unable to load "a file or assembly" named "Orbiter.Multiplayer". I'll try grabbing those extra mono lib dependencies Ren Dhark mentioned. libgdiplus is already installed Spent a few minutes on google and couldn't find the posix or winform libs in either the arch official or user repos. I'll look harder once I have more time. But now, off to study a bit for my Java exam on Monday! Once again, thank you so much for the time you've invested in assisting me, Yankee Edit: Did you change the path in server.xml... To which path are you referring? Last edited: #### Face ##### Well-known member Orbiter Contributor Addon Developer Beta Tester Yankee, try the ORL online distribution of OMP, it is the only "official" release of OMP ATM: http://omp.ddns.net/hg/omp/archive/0.7.1.zip The OMP repository is a plain project that is currently not fully functional, as it represents an evolutionary step in development (full migration of client to .NET instead of native C++). The ORL online repository is what most understand OMP is. In order to have a broader audience, a content beyond the pure multiplayer framework was needed. So I decided to join WHAP and other developers in creating the Orbiter Racing League Online add-on. And this is where all the current (functional) development happens. In the ORL project, there is also a different OMP.pdf than in the OMP project. There you should be able to read about server.xml and the various configuration files. regards, Face Last edited: #### Yankee ##### Donator Donator That version of ORL did the trick! Code: [[email protected] Linux]$ mono ServerConsole.exe
[COLOR="Green"]      Added star 1 'Sun' as 0
Added planet 1 'Mercury' as 1
Added planet 2 'Venus' as 2
Added planet 3 'Earth' as 3
Added moon 1 'Moon' with parent planet 'Earth' as 4[/COLOR]
etc...

Thank you, Face and Ren Dhark! I'm sorry I didn't realize I was supposed to use that particular version. That was the whole problem.

Thanks again,
Yankee

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
That version of ORL did the trick!

Code:
[[email protected] Linux]\$ mono ServerConsole.exe
[COLOR=Green]      Added star 1 'Sun' as 0
Added planet 1 'Mercury' as 1
Added planet 2 'Venus' as 2
Added planet 3 'Earth' as 3
Added moon 1 'Moon' with parent planet 'Earth' as 4[/COLOR]
etc...
Thank you, Face and Ren Dhark! I'm sorry I didn't realize I was supposed to use that particular version. That was the whole problem.

Hooray!

Well, I guess it is also my fault to not immediately ask for the version used. I assumed that you came here due to the OHM package, but as you can see, the word-play on "assume" is again spot-on...

regards,
Face

#### Ren Dhark

##### Member
Server running on

Face's Orbiter MultiPlayer version 0.8 (Server only) has been successfully though unofficial tested on:
• Ubuntu Server 14.04 LTS with mono 3.2.8 (current OMP host)
• Ubuntu Server 10.04 LTS & 12.04 LTS with mono 2.10.8.1
• CentOS 6.2 with mono 2.10.2 (for icedown)
• ArchLinux 3.5.3-1 with mono 2.10.8.1 (for Yankee)
• Mac OS X 10.7.3 with mono 2.10.9_11 (for my curiosity)
• Windows XP SP3 with DotNet 3.5 SP1 (for spaceexplorersuk)
After mono and OMP are installed you need to change at least the [FONT=Courier New, monospace]OrbiterRoot[/FONT] and [FONT=Courier New, monospace]Network IP[/FONT] value inside the server.xml located at /Orbiter/Server/Linux.

Ren

Last edited:
Status
Not open for further replies.

Replies
27
Views
2K
Replies
117
Views
9K
Replies
2
Views
490
Replies
6
Views
410
Replies
1
Views
232