Re: [Flightgear-devel] Re: [OpenATC] Re: status
You might want to go to the TNL website (www.opentnl.org) and most of those questions are answered in the docs. There are error/fault recovery procedures to handle such things and its just a question of how robust we want to make the network. And that depends, in part, on the size and interest of the community to support on-going development and operations. Few users -- forget it!!! Lots of players, heavy net traffic -- we make it industrial strength!!! Regards John W. - Original Message - From: Ampere K. Hardraade [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Saturday, October 02, 2004 10:51 PM Subject: Re: [Flightgear-devel] Re: [OpenATC] Re: status Here are a few questions: What will happen if the ATC is disconnected? What sort of redundancies do you have in mind? Who will handle all the traffic when no one is the ATC? How does a client knows about the location of other clients? Will the ATC be the server in this case or will the clients be able to communicate with each other directly? What will happen if a pilot is disconneted due to a computer crashed or seg-fault? Should the aircraft be blinked out, or should the pilot be able to log into the network again to continue the flight? Assuming that each aircraft only has one crew, and that he/she can reconnect to the system to continue the flight after a disconnection, what will happen if the pilot gets disconnected during a take off/landing? Should the aircraft automatically abort the procedure or should a computer from somewhere handle the rest? Ampere On October 3, 2004 12:53 am, John Wojnaroski wrote: Well, there has been some progress on implementing an OpenATC protocol based on the tnl library. Putting together a package that will create applications for master server nodes, controller nodes, and pilot nodes. If your comfortable with the FG/SimGear directory structure and build process you should feel right at home with this package. ATM controller nodes announce their presence on the net to the master server which acknowledges their presence and logs them into the controller list. A pilot node request service from the master server by announcing a set of parameters( location, freqs, callsign, etc) and the master determines based on TBD criteria which controller node on the list has control. And establishes a two-way link for the pilot/controller pair, updates the log/connectivity/whatever tables. The master bows out and the pilot/controller pair now directly exchange data as required (for now, this is just a bunch of nonsense encrypted data, although the hooks are there to get FG data). There is nothing on the controller end that knows what to do with the data. We're still a long way from a functional system, but it looks like the underlying backbone network stuff will work. To that end I'm thinking of setting up a limited network test to watch the whole thing come crashing down ;-). Actually, I've brought up the network using a couple of IP addresses I control and several internal machines on a LAN. The protocols provide for a reasonably good level of security and will allow cooperating nodes to connect from behind firewalls and NATs in a secure manner. It needs a bit more work to make it look more ATC'ish, but it might be time for a proof-of-concept. So looking for a few good volunteers to act as pilots and controllers. Will need to work out the details of how, when, who, and what... Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenGL/SSG error with latest build
David Megginson wrote: I last built FlightGear successfully on 15 August (I hadn't realized it had been so long). I had to make one small change to get to to build today, which I've put in CVS, but now I'm having a problem with OpenGL initialization. My old binary (also built with SDL) still runs fine; the new one fails with the message FATAL: ssgInit called without a valid OpenGL context. Where exactly does the context get initialized in main.cxx and or renderer.cxx? Neither of the two. It is handled by the fg_os* files (in src/Main) now. I'm not familiar with the new code arrangement (it does look like an improvement), and would appreciate some pointers before I start hunting. I think that glutinit() used to set up OpenGL before we switched to SDL. fgOSInit() should do that now. The reason I had this error previously was because the renderer expects at least a 24-bit frame buffer. But that was SDL specific. Could it be you have one GLUT and one SDL binary now? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS and branch development
I am trying to save to JSBSim CVS some files I have modified for reading the new JSBSim XML format. These files should not be part of the main (HEAD) branch at the moment. I'm not sure I have done this correctly. Can a CVS expert inform me what the correct procedure is to tag a subset of files with a branch tag, store them in CVS, and then commit changes as they are made? Also, I would need to know how to merge or commit changes from the branch to the main HEAD line upon completion of development. Thanks! Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS and branch development
Hi Jon, On Sonntag 03 Oktober 2004 16:06, Jon Berndt wrote: I am trying to save to JSBSim CVS some files I have modified for reading the new JSBSim XML format. These files should not be part of the main (HEAD) branch at the moment. I'm not sure I have done this correctly. Can a CVS expert inform me what the correct procedure is to tag a subset of files with a branch tag, store them in CVS, and then commit changes as they are made? Also, I would need to know how to merge or commit changes from the branch to the main HEAD line upon completion of development. If I look at your last checkin, you already did that right. Just for the record: - Creating that new branch. - Checking out the new branch with cvs co -r BRANCHNAME - Work as usual within that newly checked out directory. Everything you do in that directory is done on that branch (branch tags are sticky). For merging changes from HEAD I use the following procedure: First I create a tag in the HEAD branch when I did the past changes. You can do that in a directory with the checked out HEAD with: cvs tag LAST-MERGE-TO-XML This is an initial procedure which should be done with the HEAD revision used to create the new branch. When I merge, I create a temporary tag on HEAD with cvs tag LAST-MERGE-TO-XML-TMP In your development directory for the XML branch you can then leave most work to cvs. It will incorporate the changes between the tags LAST-MERGE-TO-XML and LAST-MERGE-TO-XML-TMP by cvs up -jLAST-MERGE-TO-XML -jLAST-MERGE-TO-XML-TMP cvs even cares for cvs add's of new files ... Check for conflicts, resolve them and check that in. Then I move the LAST-MERGE-TO-XML tag to the LAST-MERGE-TO-XML-TMP to get that right for the next time I will merge changes. Again in the directory with the HEAD branch checked out: cvs tag -d LAST-MERGE-TO-XML # remove old tag. cvs tag -r LAST-MERGE-TO-XML-TMP LAST-MERGE-TO-XML # tag where tmp tag is cvs tag -d LAST-MERGE-TO-XML-TMP # remove tmp tag Thats it. If you want to merge changes from the branch to HEAD. You can do the same with changed roles of the branches. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS and branch development
Hi Jon, If I look at your last checkin, you already did that right. Just for the record: - Creating that new branch. - Checking out the new branch with cvs co -r BRANCHNAME - Work as usual within that newly checked out directory. Everything you do in that directory is done on that branch (branch tags are sticky). For merging changes from HEAD I use the following procedure: First I create a tag in the HEAD branch when I did the past changes. You can do that in a directory with the checked out HEAD with: cvs tag LAST-MERGE-TO-XML Thanks. I will refer to this as time goes on. Now here's another question: If a person wants to check on the HEAD version, but wants the changed versions now also in the branch JSB_New_XML? I guess one would check out the HEAD version, then update from the JSB_New_XML branch? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenGL/SSG error with latest build
On Sun, 03 Oct 2004 10:00:52 +0200, Erik Hofman [EMAIL PROTECTED] wrote: I'm not familiar with the new code arrangement (it does look like an improvement), and would appreciate some pointers before I start hunting. I think that glutinit() used to set up OpenGL before we switched to SDL. fgOSInit() should do that now. The reason I had this error previously was because the renderer expects at least a 24-bit frame buffer. But that was SDL specific. Could it be you have one GLUT and one SDL binary now? No, they're both SDL. I am running with a 16-bit display, but I haven't had trouble using SDL with that before the reorg. It could be that FlightGear was still calling glutInit back then. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
