Project Orbiter Master/Slave renderer

[ao7g]

Hi all,

I find this add-on very interesting and promiseful.

I'm building my simpit, and I plan to have 3 screens :

- Orbiter master on the main front screen
- 1st orbiter slave on right screen showing the view through the right window
- 2nd orbiter slave on left screen ( the left window )

I tested this with the following assembly :

A main spacecraft with 2 dummy spacecrafts attached to it, one facing right, the other facing left ( using Vinka's spacecraft3 ).

So it would be easy to launch one orbiter master on the front screen, and 2 orbiter slaves, each one one on the side screens, showing the cockpit view from the 2 dummy spacecraft.

Here it is :

The main spacecraft is "ACME", found at orbithangar :

http://www.orbithangar.com/search_quick.php?text=acme&submit.x=0&submit.y=0

The 2 dummy spacecrafts, "cam-right" and "cam-left", are Vinka's modified "maqusats" with new meshes, visibles for showing orientation, should be invisible later...

Now in a single orbiter running :

"ACME" cockpit view :

F3 :

"cam-right" cockpit view :

"cam-left" cockpit view :

All is ok !

Alas, when launching a master orbiter, and 2 slave orbiters ( all on the same screen, for now ), I get this :

I have the same view on the 2 slaves as the main orbiter, even selecting repeatedly the dummy spacecrafts with F3.

Orbiter slave doesn't permit to select another ship than the master's !

I understand the "philosophical" reason ( maybe ) : an interdiction to the slave to mess the simulation ?

How can this be solved ?

Maybe the limitation could be overrun by changing a parameter in the orbslave.cfg file, for the adventurous ones ?

Any Idea ?

 

[Donamy]

I've asked 2 questions on this thread, and recieved no response since Nov. of last year. I think it is a dead addon.

 

[ao7g]

Oops, problem solved !

I had eyes but didn't see...

In OrbSlave.cfg the right value is :

; Follow focus change on master? 1=yes, 0=no
switchFocus = 0

Now all is working :

By the way there is some jerkyness in the attached spacecrafts, only in atmosphric flight it seems...

Maybe too much drag ?

 

[kamaz]

My apologies, I have forgotten about this thread. Please feel free to PM me next time.

Regarding the jerkyness issue, there could be 2 causes:

(a) it is related to MJD synchronization between master and slave. This is turned off once you are above 10km altitude. So, check if there is any difference in behavior below and above 10km. Also, try setting

disableMJDSync = 1

in OrbSlave.cfg.

(b) check the framerate you are getting on master. The slave waits up to 100ms for an update, so if master runs at less than 10 frames per second, the slave will time out, forcing a resync with the next frame.

Also, try running the slave with debug mode on by setting

debug = 1

in OrbSlave.cfg. It will print packet statistics on the screen which can point to the source of the problem.

 

[kamaz]

New version of the master/slave renderer!

Changes:

* Reworked synchronization protocol: Rendering is now fully asynchronous, each instance renders at full speed! (Synchronous rendering can be turned on in the config file). This should also fix tearing on the slave renderer caused by network jitter.

* Transmission of keyboard events: Keyboard events directed to the vessel (i.e. handled by VESSEL2::ConsumeBufferedKey) are now transmitted from master to slave (or vice-versa)

* Built-in camera positioning: Set your cockpit camera position in the config file!

* Text-based synchronization: For vessels which have functionality which is not accessible via VESSELSTATUS interface, a new synchronization mode has been added, based on (ab)using scenario save and reload functionality.

The new version of the add-on (rev25) is attached to the top post.

 

[ao7g]

New functionnalities... :banana:...Mmmh !

Thanks for this very useful tool !

 

[flightline]

Wow! Tried it and works great. You can now network multiple computers for different views and they are solid. No jitters. kamaz really did a great thing for us home cockpit builders!! Many thanks.

 

[vdrorb]

more configuration options, status line/debug

1. Great work... all thumbs up :thumbup:

2. is there a way of getting rid of the debug/ status line at the bottom of screen?

greetings,
Stefan

 

[AssemblyLanguage]

Trouble with WaitForClients

I've been using Master/Slave (rev14)with the stock Atlantis Final Approach scenario. Thank you for the update (rev25) that included some animations. However, now I am having trouble with the WaitForClients option.

With WaitForClients=1, when the slave activates, the Atlantis rotates wildly and crashes within a few seconds. "in orbit" scenarios work OK. I've tested this on a fresh install of Orbiter 2010-P1 with only AllowMultipleInstances added.

With WaitForClients=0, it works but then you have to get back to the master very quickly for a good approach.

Here is the debug output (OrbSlave.log)

2014-01-16 10:48:34.605 Thread 4784       OrbSlave.cpp:  64:Config: debug=1
2014-01-16 10:48:34.605 Thread 4784       OrbSlave.cpp:  70:Config: masterIP=127.0.0.1
2014-01-16 10:48:34.605 Thread 4784       OrbSlave.cpp:  76:Config: masterPort=40000
2014-01-16 10:48:34.605 Thread 4784       OrbSlave.cpp:  81:Config: switchFocus=1
2014-01-16 10:48:34.605 Thread 4784       OrbSlave.cpp:  86:Config: waitForMaster=0
2014-01-16 10:48:34.605 Thread 4784       OrbSlave.cpp:  91:Config: sendKeys=0
2014-01-16 10:48:34.606 Thread 4784       OrbSlave.cpp:  96:Config: elevation=0
2014-01-16 10:48:34.606 Thread 4784       OrbSlave.cpp: 101:Config: azimuth=0
2014-01-16 10:48:34.608 Thread 4784       OrbSlave.cpp: 155:Bound to 0.0.0.0:54990
2014-01-16 10:48:46.755 Thread 4784       OrbSlave.cpp: 211:MJD sync delta=32.9968 s
2014-01-16 10:48:47.775 Thread 4784       OrbSlave.cpp: 326:Pkts: 18 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 1 upd/sec mean_delay=32996.8 ms jitter= 1.$ ms rms
2014-01-16 10:48:47.808 Thread 4784       OrbSlave.cpp: 211:MJD sync delta=0.144669 s
2014-01-16 10:48:48.794 Thread 4784       OrbSlave.cpp: 326:Pkts: 360 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 19 upd/sec mean_delay=-0.1 ms jitter= 8.7 ms rms
2014-01-16 10:48:49.794 Thread 4784       OrbSlave.cpp: 326:Pkts: 360 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 19 upd/sec mean_delay=-8.0 ms jitter= 3.5 ms rms
2014-01-16 10:48:50.826 Thread 4784       OrbSlave.cpp: 326:Pkts: 360 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 19 upd/sec mean_delay=-5.2 ms jitter= 2.5 ms rms
2014-01-16 10:48:51.838 Thread 4784       OrbSlave.cpp: 326:Pkts: 322 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 17 upd/sec mean_delay=-6.0 ms jitter= 3.0 ms rms
2014-01-16 10:48:52.869 Thread 4784       OrbSlave.cpp: 326:Pkts: 360 lost: 19 ( 5.3 %) dropped: 19 ( 5.3 %) 18 upd/sec mean_delay=-3.3 ms jitter= 1.5 ms rms
2014-01-16 10:48:53.889 Thread 4784       OrbSlave.cpp: 326:Pkts: 341 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 18 upd/sec mean_delay=-5.6 ms jitter= 2.4 ms rms
2014-01-16 10:48:54.920 Thread 4784       OrbSlave.cpp: 326:Pkts: 379 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 20 upd/sec mean_delay=-12.2 ms jitter= 3.9 ms rms
2014-01-16 10:48:55.919 Thread 4784       OrbSlave.cpp: 326:Pkts: 341 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 18 upd/sec mean_delay=-7.4 ms jitter= 2.3 ms rms
2014-01-16 10:48:56.924 Thread 4784       OrbSlave.cpp: 326:Pkts: 341 lost: 0 ( 0.0 %) dropped: 0 ( 0.0 %) 18 upd/sec mean_delay=-11.2 ms jitter= 3.6 ms rms
2014-01-16 10:48:59.062 Thread 4784       OrbSlave.cpp: 326:Pkts: 284 lost: 0 ( 0.0 %) dropped: 567 (199.6 %) 15 upd/sec mean_delay=-4.4 ms jitter= 1.8 ms rms
2014-01-16 10:49:00.069 Thread 4784       OrbSlave.cpp: 326:Pkts: 363 lost: 19 ( 5.2 %) dropped: 19 ( 5.2 %) 19 upd/sec mean_delay=-14.6 ms jitter= 5.0 ms rms

Thanks

 

[kamaz]

1. Great work... all thumbs up :thumbup:

2. is there a way of getting rid of the debug/ status line at the bottom of screen?

greetings,
Stefan

In master or in slave?

---------- Post added at 11:56 PM ---------- Previous post was at 11:47 PM ----------

With WaitForClients=1, when the slave activates, the Atlantis rotates wildly and crashes within a few seconds. "in orbit" scenarios work OK. I've tested this on a fresh install of Orbiter 2010-P1 with only AllowMultipleInstances added.

With WaitForClients=0, it works but then you have to get back to the master very quickly for a good approach.

Issue reproduced and confirmed. I will have a look.

Thanks for the description of your use case, because I wanted to remove the WaitForClients feature

 

[Spacethingy]

A quick solution to getting rid of annoying debug lines:

http://orbiter-forum.com/showthread.php?p=228732&postcount=11

 

[vdrorb]

re: more configuration options, status line/debug

@Spacethingy: mentioned DisableDebugString dont work in this case but thanks

@kamaz
i would like to disable the bottom line message(s) in both (master and slave)
(just to clarify, i am talking about the messages at the bootom e.g. "NO CLIENTS" or ".. THREAD ..." and so on

cheers,
Stefan

 

[kamaz]

Thanks for feedback, a new version (rev28) is attached to the top post. Changes:

- make debug/status messages in master optional (see "debug" option in the config file)
- copy RCS status (rot/lin/off), navmodes (prograde/retrograde/etc.), navchannels and manual input mode for aerodynamic control surfaces (i.e. VESSEL::SetADCtrlMode() )
- if waitForClients is set on master, do not hang, pause simulation instead (you must press Ctrl+P to unpause after starting clients)
- slaves can be now started before master, just make sure you load the same scenario

---------- Post added at 11:09 PM ---------- Previous post was at 11:07 PM ----------

@kamaz
i would like to disable the bottom line message(s) in both (master and slave)
(just to clarify, i am talking about the messages at the bootom e.g. "NO CLIENTS" or ".. THREAD ..." and so on

Set debug = 0 in both OrbMaster.cfg and OrbSlave.cfg (as of rev 27, this is now the default anyway).

---------- Post added at 11:16 PM ---------- Previous post was at 11:09 PM ----------

With WaitForClients=1, when the slave activates, the Atlantis rotates wildly and crashes within a few seconds.

I've fixed this by pausing the simulation if there is no client (you must unpause manually), instead of hanging in clbkPostStep().

Also, you can now start clients before master which may be more convenient in some situations

---------- Post added 01-19-14 at 12:23 AM ---------- Previous post was 01-18-14 at 11:16 PM ----------

The new code also exhibits the following behavior: if waitForClients is set, and all clients disconnect, then the master will pause.

Not sure if this is a bug or a feature

 

[koss]

Hello! Thanks to Kamaz for very useful addon!

Using this addon I simulate Space Shuttle CCTV (as two montors in the right of aft workstation). It makes controlling arm easier and more close to real (as I think).

[ame="http://www.youtube.com/watch?v=xr2z6n4s-mY"]SSU RMS Cam test - YouTube[/ame]

Good luck with development!

 

[shmeg]

Hi Kamaz,
Sent you a private message on this as well but thought I would add it to the development forum too in case someone else has come across this.

Fault: When running 2 systems (no other addons enabled) OrbMaster system after about 15 minutes develops the following fault and CTD's. Or slave is unaffected and continues reconnects after restarting Orb Master. If I disable Orbmaster : orbiter continues to run indefinitely.

Environment: Orbiter 2010 on fresh install of WIN7 with all MS updates installed.
No other applications are on the machine.

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x4c7b0fbb
Faulting module name: MSVCR80.dll, version: 8.0.50727.4940, time stamp: 0x4ca2b271
Exception code: 0x40000015
Fault offset: 0x000046b4
Faulting process id: 0x874
Faulting application start time: 0x01cf976457882505
Faulting application path: C:\Orbiter2010\modules\server\orbiter.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_d08cc06a442b34fc\MSVCR80.dll
Report Id: b5baa204-0362-11e4-90f1-74d435e4bb18

Any suggestions or help greatly appreciated. I am also doing a lot of stuff with Arduino in my orbiter simpit so happy to answer any questions re: those in return

Regards
Shmeg (Ben)

 

[kamaz]

Bug fixed.