[Flightgear-devel] Re: TerraGear Help
OK, Seams that I'm on my way ! Now for the easy part, importing the DTED ;-) Thanks for your help Erez __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim in-air starts
On Sat, 2003-03-01 at 18:02, David Megginson wrote: > I've done a little more work on YASim initial velocities, and the --vc > and --mach options should now work more-or-less correctly (except that > --vc doesn't take compressibility effects into consideration). Hmm .. compressiblity becomes important at around Mach 0.3 or so and it looks like the YASim routines only leave out the supersonic stuff. > That > means that you can start YASim models in the air the same way as > you start JSBSim and UIUC models: > > fgfs --aircraft=747 --mach=0.7 --altitude=3 > > fgfs --aircraft=dc3 --vc=130 --altitude=12000 > > fgfs --aircraft=j3cub --vc=60 --altitude=500 --offset-distance=1 > > The main difference is that YASim does not yet have a trimming > routine, so you need to get right on the controls (things are not too > bad if you choose a normal cruising speed and the controls start near > neutral). > > > All the best, > > > David -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim in-air starts
I've done a little more work on YASim initial velocities, and the --vc and --mach options should now work more-or-less correctly (except that --vc doesn't take compressibility effects into consideration). That means that you can start YASim models in the air the same way as you start JSBSim and UIUC models: fgfs --aircraft=747 --mach=0.7 --altitude=3 fgfs --aircraft=dc3 --vc=130 --altitude=12000 fgfs --aircraft=j3cub --vc=60 --altitude=500 --offset-distance=1 The main difference is that YASim does not yet have a trimming routine, so you need to get right on the controls (things are not too bad if you choose a normal cruising speed and the controls start near neutral). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cycling w/ right mouse button && pause
On Sat, Mar 01, 2003 at 04:31:30PM -0500, David Megginson wrote: > So it is. I've just checked in some changes, so that all a subsystem > has to do is override FGSubsystem::is_suspended() to return false, and > it will keep running during a pause. I've made the change to the > input module, and the mouse now cycles again during pause. Thanks David. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cycling w/ right mouse button && pause
Curtis L. Olson writes: > Manuel Bessler writes: > > > I've noticed that cycling (right clicking) between mouse > > > pointer mode, yoke mode, and view mode has no effect while > > > paused. If you right click while paused it does not change mode > > > until I hit 'p' again to unpause. It seems that it 'records' at > > > most one right click in paused mode. > > Yes, I observe this problem. Also a related problem is that incoming > network packets are not read. What's going on is that when the sim is > paused, the subsystems are not executed, but some of these things > should be executed even when the sim is paused ... I haven't had time > to look into it yet. David Megginson is the architect of the > flightgear subsystem system so it's all his fault. :-) So it is. I've just checked in some changes, so that all a subsystem has to do is override FGSubsystem::is_suspended() to return false, and it will keep running during a pause. I've made the change to the input module, and the mouse now cycles again during pause. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Multiplayer
Duncan McCreanor writes: > My name is Duncan McCreanor. I am employed as a Software Engineer > for an Australian company where we have been looking at the > possibility of using Flightgear as the basis for an Air Traffic > Control visual simulator. That sounds excellent. > When coding/testing is completed, how do we go about getting the > changes reviewed and added to Flightgear? You can send the code to Curt or me. I'd recommend Curt ([EMAIL PROTECTED]), since I have an enormous backlog right now, but I'll try to get to it quickly if it comes to me. If the code is working, even marginally, then you should consider sending it ASAP -- you'll have many more people to help you with the testing and debugging. The nice thing about Open Source is that you don't have to wait until code is fully polished before you throw it out into the world. The other advantage to sending code in now is that if people feel you are going the wrong direction with anything, we can catch it earlier. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer
Hi, My name is Duncan McCreanor. I am employed as a Software Engineer for an Australian company where we have been looking at the possibility of using Flightgear as the basis for an Air Traffic Control visual simulator. We are in the process of putting together a demonstration of the possibilities that Flightgear provides. As part of the demonstration a colleague and I have been working on the multiplayer aspects of Flightgear. We have produced a working multiplayer version under Linux. The multiplayer code has been created from scratch without using any of the existing multiplayer code. It was felt that the existing multiplayer code was too platform (Unix/Linux) specific and appeared to slow down the frame rate. The multiplayer code we have added uses existing Simgear and plib classes so should be platform independent, although we have not tested it on other platforms and have not allowed for endian issues. The design we have implemented allows players to interact without the need for a server. If the transmit and receive addresses are set to broadcast, it is possible to play multiplayer games on a local network. Point-to-point for two players is also possible across the internet. The ability to send text chat messages to a designated player has been allowed for but not implemented. Although we have not used a server, the design does not need to be changed for use with a server. Command line parameters have been added to set up the multiplayer code. The commands are of the form: --multiplay=in | out,Hz,destination address,destination port --callsign=a_unique_name The code has only just been completed. We plan to further test and enhance it over the next few weeks. When coding/testing is completed, how do we go about getting the changes reviewed and added to Flightgear? Below are some examples of startup commands that demonstrate the use of the multiplayer facilities. For two players on a local network or across the internet: -- Player1: --multiplay=out,10,192.168.0.3,5500 --multiplay=in,10,192.168.0.2,5501 --callsign=player1 Player2: --multiplay=out,10,192.168.0.2,5501 --multiplay=in,10,192.168.0.3,5500 --callsign=player2 For multiple players on a local network: Player1: --multiplay=out,10,255.255.255.255,5500 --multiplay=in,10,255.255.255.255,5500 --callsign=player1 Playern: --multiplay=out,10,255.255.255.255,5500 --multiplay=in,10,255.255.255.255,5500 --callsign=playern Note that the callsign is used to identify each player in a multiplayer game so the callsigns must be unique. The multiplayer code ignores packets that are sent back to itself, as would occur with broadcasting when the rx and tx ports are the same. Multiple players sending to a single player: Player1: --multiplay=out,10,192.168.0.2,5500 --callsign=player1 Player2: --multiplay=out,10,192.168.0.2,5500 --callsign=player2 Player3: --multiplay=out,10,192.168.0.2,5500 --callsign=player3 Player4 (rx only): --multiplay=in,10,192.168.0.2,5500 --callsign=player4 This demonstrates that it is possible to have multiple instances of Flightgear that send to a single instance that displays all the traffic. This is the sort of implementation that we are considering for use as a tower visual simulator. For use with a server (when one is created): Player1: --multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 --callsign=player1 Player2: --multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5501 --callsign=player2 Playern: --multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5502 --callsign=playern The server would simply act as a packet forwarding mechanism. When it receives a packet, it sends it to all other active players. Regards, Duncan. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: TerraGear Help
Erez Boym wrote: Hi, Curtis and all OK, Upgrading automake to v1.6 as you have recommended did solve the autogen.sh script problem, TerraGear did start to compile. Now it seams that it has another issue, this time in the TerraGear code itself. In both the CVS code and the 0.0.5 code the build process brakes down with the following error: /usr/bin/ld: cannot find -lgenpolyclip In the root of the TerraGear source directory is a file called README.gpc. This file is related to this question. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
