Hello, I am trying to use mulitple monitors (2) to run flightgear using one for a forward view and one for a side view. I have followed all the written documentation i could find to do so, however when launching Flight gear from the "master" instance i get an I/O Error and it crashes. Can someone give me a step by step on how to get this working?Once again i have a single GFX card with multi monitor support, i am going to be running 2 seperate instances of FG on the same workstation. Hardware requirements are not an issue as this PC is a beast.any help would be much appreciated thanks,Blake

> I am trying to use mulitple monitors (2) to run>flightgear using one for a forward view and one for a side>view. I have followed all the written documentation i could>find to do so,what documentation specifically?> however when launching Flight gear from the>"master" instance i get an I/O Error and it crashes. what exactly is the error message saying?does the error happen to be related to the multiplayer system?If so, have you ensured to provide DIFFERENT default startup ports for each instance of FlightGear?> Can someone give me a step by step on how to get this working?what you are trying is not necessarily possible for every platform that FlightGear supports.So, we need to know more about your setup and the startup parameters you are using for each individual instance of FlightGear. Also, some additional background information (platform, hardware, OS/version etc.) is usually considered to be helpful (check out the troubleshooting section at http://wiki.flightgear.org to get an impression of what type of data is usually required to provide basic support)

sorry about the lack of details.here is the setup.the system is an 2.8 ghz AMD Opteron Dual Core Station with 12gigs of rama Geforce 7900 GTX video cardthe instance setup to be the slave has the following parameters in the system.fgfsrc--native-fdm=socket,in,60,,5505,udp--native-ctrls=socket,in,60,,5506,udp--fdm=null--fov=35--prop:/sim/view/config/heading-offset-deg=-35--prop:/sim/view/config/pitch-offset=3the master has the following--native-fdm=socket,out,60,,5505,udp--native-ctrls=socket,out,60,,5506,udpthe error i receive when launching the master instance is as followsError: connect() failed in make_client_socket()SG_IO_OUT socket creation failedError opening channel communication layer.I/O Channel config failedany help would be great,thanks again,Blake

sorry about the lack of details.here is the setup.the system is an 2.8 ghz AMD Opteron Dual Core Station with 12gigs of rama Geforce 7900 GTX video cardthe instance setup to be the slave has the following parameters in the system.fgfsrc--native-fdm=socket,in,60,,5505,udp--native-ctrls=socket,in,60,,5506,udp--fdm=null--fov=35--prop:/sim/view/config/heading-offset-deg=-35--prop:/sim/view/config/pitch-offset=3the master has the following--native-fdm=socket,out,60,,5505,udp--native-ctrls=socket,out,60,,5506,udpthe error i receive when launching the master instance is as followsError: connect() failed in make_client_socket()SG_IO_OUT socket creation failedError opening channel communication layer.I/O Channel config failedany help would be great,thanks again,Blake

Well, what OS are you running?And the error message itself isn't as helpful as running FlightGear with an increased log level (i.e. --log-level=bulk) this would show where EXACTLY the problem occurs. However, given that you don't seem to pass any other parameters, I do assume that you are AT LEAST also running into the problem of two FlightGear instances trying to use identical port numbers for the multiplayer subsystem, so you may want to check out the following thread: http://forums.avsim.net/dcboard.php?az=sho...=1446&mode=full

I am Runnin WinXP X64 Pro.i tried running with the increased log level, however it seems to go through a loop of parameter regarding the position fo the sun at various times of day (i know that might sound weird so ill get some direct verbage)ill also try the multiplay porting problem and see if that helpsthanks,Blake

>i tried running with the increased log level, however it seems>to go through a loop of parameter regarding the position fo>the sun at various times of day (i know that might sound>weird so ill get some direct verbage)that's actually quite normal, as you'll see very verbose debugging information for all subsystems-regardless of which one is actually failing.That's also why you can expect the startup to take significantly longer due to the limited outport speed of the console, however when the startup actually does fail, the recent output should be much more informative. In general, you might also want to consider redirecting the output to a file for closer inspection if the problem cannot be located easily.

after looking at the debug this is the only place i can see any errorsParse I/O channel request: native-fdm,socket,out,60,,5505,udp protocol = native-fdm medium = socket direction = out hertz = 60 hostname = port = 5505 style = udpError: connect() failed in make_client_socket()SG_IO_OUT socket creation failedError opening channel communication layer.I/O Channel config failed.and then it diesany ideas??thanks,Blake

Just to make sure: What instance (main/slave) is failing here? Are any other instances running at this point already?Do you happen to be connected to any type of dhcpd-enabled router (i.e. wlan) or are you running an application firewall?Just to make debugging easier, I would suggest to follow exactly the guidelines under $FG_ROOT/Docs/README.IO (once everything works properly you can still play with the exact settings):----Socket Communication: --native=socket,dir,hz,machine,port,style machine = machine name or ip address if client (leave empty if server) port = port, leave empty to let system choose style = tcp or udp example to slave one copy of fgfs to another fgfs1: --native=socket,out,30,fgfs2,5500,udp fgfs2: --native=socket,in,30,,5500,udp --fdm=external This instructs the first copy of fgfs to send UDP packets in the native format to a machine called fgfs2 on port 5500. The second copy of fgfs will accept UDP packets (from anywhere) on port 5500. Note the additional --fdm=external option. This tells the second copy of fgfs to not run the normal flight model, but instead set the FDM values based on an external source (the network in this case.)----

The Slave instance runs fine, it is the Main instance that keeps failingI have tried it with and without the slave instance already running, and it failed both times.Yes i am behind a DHCP enabled router, however since it is all on the same system (not over the network) would this matter?

The document at http://www.inkdrop.net/dave/multimon.pdf suggests something only slightly different from what you are using. Add an IP address in the native-fdm option on the host side. If host and slave are the same machine, you might have to use e.g. 127.0.0.1 if "localhost" doesn't work.

>The document at http://www.inkdrop.net/dave/multimon.pdf>suggests something only slightly different from what you are>using.Hi, you appear to be the author of this highly useful file?While I may be wrong, it seems to me that this file hasn't yet made it into the official FlightGear distribution?If that's indeed the case, you may want to consider submitting the file itself (or rather a link to it) to the FlightGear Devel mailing list in order to ensure that it will become a permanent part of the FlightGear base package's Doc folder for future reference by other users and developers.Looking more closely at the file, it appears that you used OpenOffice to create the PDF?This is indeed excellent as people would usually appreciate it even more if contributors of such documentation could make the *source code* of the corresponding file (for instance, Tex, LaTex or OpenOffice/XML in this case) available, in order to enable other community members to easily make modifications/updates without requiring a certain proprietary tool (i.e. Adobe stuff).Also please note that there's in fact an official manual (also PDF, but maintained in LaTex) for FlightGear, for which its maintainers are usually seeking updated and additional contents such as the one that you have contributed in the form of a separate file. So, while contributing actual new stuff is always warmly perceived, the maintainers of the regular documentation would obviously appreciate it even more if such contributions could be come a part of one comprehensive manual, rather than being widely spread over the internet, across all sorts of different places-as this is the only way to ensure that your contribution will actually turn out to be a long-term contribution because it will become an official part of the distribution.Alternatively, you may want to consider migrating your document over to the wiki at http://wiki.flightgear.org which would ultimately enable even more contributors to easily update your instructions, without having to rely on any external tools whatsoever.Thanks again for your contribution.