Re: [Flightgear-devel] Re: CVS error msg
John Wojnaroski a écrit : Curtis L. Olson wrote: John Wojnaroski wrote: Hi Curtis, When you have a moment. I may have sent this to you yesterday from one of my other machines, but can't find a copy. If a dup, my apologies. In file included from ../../src/Cockpit/panel.hxx:50, from ../../src/Cockpit/cockpit.hxx:36, from main.cxx:61: ../../src/Input/input.hxx: In method `const class SGPropertyNode * FGBinding::getArg()': ../../src/Input/input.hxx:123: warning: choosing `SGPropertyNode_ptr::operator SGPropertyNode *()' over `SGPropertyNode_ptr::operator const SGPropertyNode *() const' ../../src/Input/input.hxx:123: warning: for conversion from `SGPropertyNode_ptr' to `const SGPropertyNode *' ../../src/Input/input.hxx:123: warning: because conversion sequence for the argument is better main.cxx: In function `bool fgMainInit(int, char **)': main.cxx:759: assuming on overloaded member function make[2]: *** [main.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Kind of lost on this one... Kind of lost on this one too ... I think this might be Andy Ross's code so he might be a good one to ask. What compiler version are you using? Curt. Running 2.95.4... Andy, if you're listening, any ideas. If this is due to using an older compiler, should there be a test in to check for that? I tried the patch below with MSVC and it also compiles without any problem, so if it works with gcc 3.x and other compilers, I am to apply it. -Fred RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.190 diff -u -r1.190 main.cxx --- main.cxx16 Dec 2004 13:19:01 -1.190 +++ main.cxx20 Dec 2004 07:55:10 - @@ -754,9 +754,9 @@ _bootstrap_OSInit++; #endif -fgRegisterWindowResizeHandler( FGRenderer::resize ); -fgRegisterIdleHandler( fgIdleFunction ); -fgRegisterDrawHandler( FGRenderer::update ); +fgRegisterWindowResizeHandler( FGRenderer::resize ); +fgRegisterIdleHandler( fgIdleFunction ); +fgRegisterDrawHandler( FGRenderer::update ); #ifdef FG_ENABLE_MULTIPASS_CLOUDS bool get_stencil_buffer = true; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS error msg
Frederic Bouvier wrote: I tried the patch below with MSVC and it also compiles without any problem, so if it works with gcc 3.x and other compilers, I am to apply it. It works for the MIPSpro compiler, so I've committed this patch. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Here are a few ideas: - we could extend fgrun (to add such features as flight planning, AI objects editing), - we could create another app, which would be meant to communicate with FlightGear in realtime (probably via the telnet interface), something more elaborate than the http interface, in the same way that fgrun does for command-line options I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) - in any case, it would be best to make sure that FG is able to change aircraft (FDM, 3D model, systems) on the fly, because that is probably the only start-up-time setting that can't be changed so far once FlightGear is running. That would be a great improvement. Having spend most of the weekend trying to install CVS versions of all the FG dependencies I only spent a few hours designing a new order/labeling in the menu (using QT Designer just because it's a graphical UI Designer). From that I think easy improvements can be made just by renaming things. For example the difference between 'Adjust view distance' and 'Adjust LOD ranges' is not obvious. It's only after you click one you notice it was the wrong :-) Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] My 172P work for appraisal
Dave Martin wrote: Here we are: (screenshots) Well, after looking at the first shot: http://www.cyfinity.com/fgfs/c172p1.jpg I thought: Oh, how nice, someone added a C150 to the hangar, but after looking at the last one: http://www.cyfinity.com/fgfs/c172p7.jpg I am pretty much pleased ;-) Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Jon Stockill wrote: Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well. The only issue is that for single PC, home users who aren't immensely computer savey, starting up multiple apps concurrently can be a bit tricky ... especially in a multiplatform / portable context. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Curtis L. Olson wrote: Jon Stockill wrote: Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well. Agreed - the internal GUI we have at the moment, while not the prettiest available certainly gets the job done, and can be configured without having to resort to coding - it's perfectly adequate for the job. What I was against was multiple GUIs util different toolkits, as that would significantly increase the bloat, and make packaging flightgear an awful lot more complicated. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
The only issue is that for single PC, home users who aren't immensely computer savey, starting up multiple apps concurrently can be a bit tricky ... especially in a multiplatform / portable context. Wrap that in a script/launcher app/... KDE starts some 10-15 apps/demons on initialization, the whole Gnome desktop is based on networked components (CORBA). Yet both aren't normally counted as apps that aren't friendly to the end user. Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Am Montag 20 Dezember 2004 13:08 schrieb Curtis L. Olson: Jon Stockill wrote: Thomas Förster wrote: ... For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well. Is there documentation on this (writing external UI's) somewhere? Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Software Patents.
Dave Martin wrote: Many of you are probably aware that the EU Council is trying to press through a draconian directive on EU software patents on Tuesday during a meeting of the Agriculture and Fisheries commision of all things. It's good to mention this topic - fortunately we still have yet another chance when the directive has to pass the European parliament in the second reading, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Software Patents.
I am led to understand that the EU Parliament can only vote down elements of the proposal at the second hearing if this is allowed at the Fisheries commission meeting - is this correct. It is pleasing to see that there are already over 1,700 signatories to the support wiki. When I signed late last night there were only 31. On Monday 20 Dec 2004 15:18, Martin Spott wrote: Dave Martin wrote: Many of you are probably aware that the EU Council is trying to press through a draconian directive on EU software patents on Tuesday during a meeting of the Agriculture and Fisheries commision of all things. It's good to mention this topic - fortunately we still have yet another chance when the directive has to pass the European parliament in the second reading, Martin. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Software Patents.
Dave Martin wrote: I am led to understand that the EU Parliament can only vote down elements of the proposal at the second hearing if this is allowed at the Fisheries commission meeting - is this correct. Hmmm, I wouldn't bet on this but my understanding is that parliament can vote against the directive as a whole, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] My 172P work for appraisal
On Monday 20 Dec 2004 09:58, Martin Spott wrote: Dave Martin wrote: Here we are: (screenshots) Well, after looking at the first shot: http://www.cyfinity.com/fgfs/c172p1.jpg I thought: Oh, how nice, someone added a C150 to the hangar, but after looking at the last one: http://www.cyfinity.com/fgfs/c172p7.jpg I am pretty much pleased ;-) Thanks, Martin. As it happens I'd quite like to make a 150/152 model from scratch as a fairly high-poly example which would be 'comfortably' realistic. However, I'm watching the development of the PA28-161 for now so I can get some tips on setting up 3d panels etc. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Ann: blender source for aircraft models
Since there are so many talented 3D modellers around the project now, I've put online the Blender source for the mostly crude 3D models I've developed. Note that this is not, yet, a permanent location; I'll think of a better URL later, or better yet, we'll set up a directory on the main FlightGear site for 3D model source files. http://www.megginson.com/Private/Models/ All of these models are hereby released into the Public Domain. Note that these are undocumented, raw directory dumps, not nicely packaged distributions. You'll almost certainly have to fix the texture paths, if nothing else. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
From: Curtis L. Olson [EMAIL PROTECTED] Reply-To: FlightGear developers discussions [EMAIL PROTECTED] Date: Mon, 20 Dec 2004 06:08:51 -0600 To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45 Jon Stockill wrote: Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well. The only issue is that for single PC, home users who aren't immensely computer savey, starting up multiple apps concurrently can be a bit tricky ... especially in a multiplatform / portable context. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d But cross platform support gets more difficult. This is somewhat demonstrated by the issues that someone is having right now getting fgrun to compile and build. By keeping a single application there is a bunch of support, and a bunch of drive to keep the code base working across platforms. If the code splits into a bunch of different applications then people are needed to build/test/support each separate app. on each platform. In theory that should not be that hard, but in reality, I believe, no one has yet built fgrun for the Mac... --Adam ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Thomas Förster wrote: Is there documentation on this (writing external UI's) somewhere? Thomas, There's no specific documentation, but what I did was leverage the telnet interface which gives you a convenient way to interact with the FG property system. It's relatively low bandwith but that's generally fine for a gui. The telnet interface also provides some higher level commands which are convenient for remotely controlling the app. It's an approach that works quite well (at least on linux.) I have control over the machine so I can set all the various apps to startup the way I like and can have complete control. I'd shudder to try to roll multiple concurrent apps into a user release though because it's a fragile house of cards. I can get it setup on my own system, but any little change or difference can bring the whole thing crashing down, and for users that don't understand how it all goes together, they may not be able to easily modify the scripts to make it all work. But if we can work through the management/distribution/platform/usability issues, I think it would be a great thing to have. You can do so much more, so much more easily with a real gui tool kit than you can do in pui. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Monday, 20 December 2004 14:08, Curtis L. Olson wrote: For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui It still needs a bit of work though. One cannot change the aircraft or location at the moment through an external app. I also noticed that connections have a direction associated (in/out). To have a bi-directional connection does one have to use two seperate connections? Also is the hz parameter required? Isn't it event driven? Polling is evil! ;-) The only issue is that for single PC, home users who aren't immensely computer savey, starting up multiple apps concurrently can be a bit tricky ... especially in a multiplatform / portable context. The way I see it is we can have a GUI that the user launches that in turn loads FG in the background. Similar to fgrun but with a live connection like the flight instructor type setup. When the user is done configuring aircraft, weather, etc they press a SYNC or FLY button and the changes are sent to FG and FG is told to pop up (brought to the foreground). Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Not safe let loose with ac3d :-)
Just had a go at my first building. Its a (not too accurate) rendition of the tower at Wellesbourne Mountford (EGBW) The tower consists of 2 container units stacked on top of each other and a glass house. My go: http://www.cyfinity.com/fgfs/welltower.jpg http://www.cyfinity.com/fgfs/welltower2.jpg The real thing: http://www.wellesbourneairfield.com/tower001.jpg Yes, I know its on a runway in America right now (I loaded it the 'quick' way) and yes, I did take it for a little flight ;-) While being a commercial package, ac3d should make it quite easy to produce reasonably good building for specific locations en-mass. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiling with Visual Studio 2003.net
Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external symbol errors. Are the Microsoft build files in there legit, or is this just someone's wishful thinking? Thanks, Drew ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Paul Surgeon wrote: It still needs a bit of work though. One cannot change the aircraft or location at the moment through an external app. You can't change aircraft through the internal or external gui right now. You can change position just fine, as well as setup things like 7 mile final, on a 3 deg. glideslope, at 90 kts. I also noticed that connections have a direction associated (in/out). To have a bi-directional connection does one have to use two seperate connections? No, not with the telnet interface. Also is the hz parameter required? Isn't it event driven? Polling is evil! ;-) I've seen some event driven gui/socket code that was (of all things) written in MSVC. There are plenty of messes already in FG so that's one direction I'd really rather not go. The way I see it is we can have a GUI that the user launches that in turn loads FG in the background. Similar to fgrun but with a live connection like the flight instructor type setup. When the user is done configuring aircraft, weather, etc they press a SYNC or FLY button and the changes are sent to FG and FG is told to pop up (brought to the foreground). That certainly sounds doable, although the particular details of how to launch, and kill, and detect if the child process is running will probably vary wildly from platform to platform. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Andy messier wrote : Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external symbol errors. Are the Microsoft build files in there legit, or is this just someone's wishful thinking? It has been discussed very recently : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Frederic Bouvier a écrit : Andy messier wrote : Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external symbol errors. Are the Microsoft build files in there legit, or is this just someone's wishful thinking? It has been discussed very recently : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470 see also : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32556 http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32570 http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32600 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1). Now, when I download the FlightGear source, should I REPLACE the FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the source, or put the source inside this directory? Same with SimGear and plib? I can't find any instructions among those project files. Also, which file should I open in VisualStudio to build the source? Sorry for the basic questions...I'm new to Visual Studio. Thanks, Drew On Mon, 20 Dec 2004 20:17:40 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Frederic Bouvier a écrit : Andy messier wrote : Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external symbol errors. Are the Microsoft build files in there legit, or is this just someone's wishful thinking? It has been discussed very recently : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470 see also : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32556 http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32570 http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32600 -Fred ___ 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] Compiling with Visual Studio 2003.net
Andy messier wrote : Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1). Now, when I download the FlightGear source, should I REPLACE the FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the source, or put the source inside this directory? Same with SimGear and plib? I can't find any instructions among those project files. I would be you, I wouldn't overwrite the files I've just downloaded, but I guess you would not find the project files in the official distribution, so it is really up to you. Also, which file should I open in VisualStudio to build the source? Sorry for the basic questions...I'm new to Visual Studio. You should read this one : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032478.html -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
I haven't overwritten any files...I'm just trying to understand what goes where. I have a directory structure called FG-ProjectFiles-msvc71, which does not contain the FlightGear source. I have another directory, which I downloaded separately, called Flightgear-0.9.6. Where do I put it? Should I have a directory as follows? FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6 Or do I need to do something different? There are no instructions. FlightGear/cvs/FlightGear = FlightGear isn't explicit to me. Thanks, Drew On Mon, 20 Dec 2004 21:15:44 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Andy messier wrote : Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1). Now, when I download the FlightGear source, should I REPLACE the FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the source, or put the source inside this directory? Same with SimGear and plib? I can't find any instructions among those project files. I would be you, I wouldn't overwrite the files I've just downloaded, but I guess you would not find the project files in the official distribution, so it is really up to you. Also, which file should I open in VisualStudio to build the source? Sorry for the basic questions...I'm new to Visual Studio. You should read this one : http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032478.html -Fred ___ 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] Re: Flightgear-devel Digest, Vol 20, Issue 45
Adam Dershowitz wrote: But cross platform support gets more difficult. This is somewhat demonstrated by the issues that someone is having right now getting fgrun to compile and build. Well, David Luff has proven that cross-platform-portability is not a miracle, his TaxiDraw compiles at least on Windows and five different Unices just with some small Makefile changes allthough he didn't tell us how much effort he had to spend in order to achieve this portability ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] UI (was no subject)
I think the existing external telnet access is an excellent feature. It would be nice to put some effort into making the underlying code more efficient so that the simulator doesn't mind it being used a lot. On a separate note, I propose the following feature (if not present): 1. A command on the telnet interface for adding menu items to the PUI. 2. When the associated telnet session closes, the menu items disappear. 3. A telnet command to put up a PUI dialog and return the results. We could create a python class that uses the existing telnet module and makes the menu item addition and PUI dialog invocation accessible. A separate class can offer the same services but use a GTK backend. That would let us all write nice features as python scripts which, for single user, attach to the main FlightGear PUI interface or, for training use, interact directly with the instructor's console. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
I realize that. I just meant that the more the source code forks into different applications the harder it will be to keep it all working across platforms. Each person who is working on their own particular app. Will make sure that it works on their own platform. While if there is one FlightGear app. Then there is a joint effort, with each change in source, to get it to work across many platforms. -- Adam From: Martin Spott [EMAIL PROTECTED] Organization: home Reply-To: FlightGear developers discussions [EMAIL PROTECTED] Newsgroups: list.flightgear-devel Date: Mon, 20 Dec 2004 20:34:15 + (UTC) To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45 Adam Dershowitz wrote: But cross platform support gets more difficult. This is somewhat demonstrated by the issues that someone is having right now getting fgrun to compile and build. Well, David Luff has proven that cross-platform-portability is not a miracle, his TaxiDraw compiles at least on Windows and five different Unices just with some small Makefile changes allthough he didn't tell us how much effort he had to spend in order to achieve this portability ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Mon, 20 Dec 2004 13:04:47 -0600 Curtis L. Olson wrote: That certainly sounds doable, although the particular details of how to launch, and kill, and detect if the child process is running will probably vary wildly from platform to platform. The only OS where I could do it would be Linux (I have done some programming on Windows in the past, but not enough to be able to do that). I thought that the way to do this would be the same on UNIX-like systems, and that it would differ only on Windows... Here are the ways of launching the simulator and the FlightGear Control app I can think of: 1- the Control app launches and communicates with FlightGear, the latter being for instance a child process (or fgrun could be extended to communicate with FlightGear in this way) 2- FlightGear is launched at the same time as the Control app 3- FlightGear and the Control app can be run independently With option 1, there are issues such as how to ensure that when FlightGear exits, the Control app reverts to a launcher app. Does option 2 mean that they have to be launched at the same time ? Could we benefit from this ? What is already clear is that FlightGear should not depend on this Control app. It must be possible to run FlightGear from the command-line without anything else. That is why I would be in favor of option 3. Here is what is already possible with what we presently have. The FlightGear telnet protocol allows an external program to get and set properties. This already allows for environment / position / time / radio / gps / view settings, to name a few. The current gui (menubar) can do more than that, and in the future it would probably a good thing to use the same API, in order for instance to be able to launch a nasal command from the Control app. As we said before, the main problem would be to change aircraft (and therefore reinit FDM, 3D model, systems) without restarting FG. I'll try and have a look at the initialization code as soon as I find some time. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Drew a écrit : I haven't overwritten any files...I'm just trying to understand what goes where. I have a directory structure called FG-ProjectFiles-msvc71, which does not contain the FlightGear source. I have another directory, which I downloaded separately, called Flightgear-0.9.6. Where do I put it? Should I have a directory as follows? FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6 my layout is (I have a drive named I: ) : I:\FlightGear\cvs\FlightGear I:\FlightGear\cvs\FlightGear\src I:\FlightGear\cvs\FlightGear\src\Main ... The path of the files located in the project files should have helped you. Or do I need to do something different? There are no instructions. FlightGear/cvs/FlightGear = FlightGear isn't explicit to me. the directory 'cvs' could imply that the projects are for the cvs version. If you want to use them for the 0.9.6 version, you would have to adapt it because few files were added, other removed and some moved. The file to load is the solution file, named FlightGear-2.sln, .vcproj files are the project files and hold path to source files and compile options. They are xml files. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
I'm getting the following errors (most of them several times) Cannot open include files: FL/Fl.h FL/Fl_File_Chooser.h GL/glut.h plib/ssg.h sg.h Cannot open source files: .\majik_demo.cxx .\simgear\scene\sky\clouds3d\camdisplay.cpp .\src\AIModel\AICarrier.cxx .\src\AIModel\submodel.cxx .\src\Cockpit\hud_rwy.cxx .\src\Fdm\groundcache.cxx .\src\fdm\sp\ACMS.cxx .\src\fdm\sp\ADA.cxx .\src\Instrumentation\encoder.cxx .\src\Instrumentation\kr_87.cxx .\src\Instrumentation\kt_70.cxx .\src\Instrumentation\marker_beacon.cxx .\src\Instrumentation\navradio.cxx .\src\Instrumentation\transponder.cxx .\src\Network\ATC-Inputs.cxx .\ssgLoadASC.cxx .\ssgSaveIV.cxx .\tux_example.cxx There are a bunch of warnings as well, but I won't worry about them yet. Drew On Mon, 20 Dec 2004 23:02:58 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Drew a écrit : I haven't overwritten any files...I'm just trying to understand what goes where. I have a directory structure called FG-ProjectFiles-msvc71, which does not contain the FlightGear source. I have another directory, which I downloaded separately, called Flightgear-0.9.6. Where do I put it? Should I have a directory as follows? FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6 my layout is (I have a drive named I: ) : I:\FlightGear\cvs\FlightGear I:\FlightGear\cvs\FlightGear\src I:\FlightGear\cvs\FlightGear\src\Main ... The path of the files located in the project files should have helped you. Or do I need to do something different? There are no instructions. FlightGear/cvs/FlightGear = FlightGear isn't explicit to me. the directory 'cvs' could imply that the projects are for the cvs version. If you want to use them for the 0.9.6 version, you would have to adapt it because few files were added, other removed and some moved. The file to load is the solution file, named FlightGear-2.sln, .vcproj files are the project files and hold path to source files and compile options. They are xml files. -Fred ___ 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] C172P Model Year?
On 12/18/04 at 7:15 PM Dave Martin wrote: While you're there, is there any chance of a magneto-related performance loss? ie: when you run left mags only you get a power loss. Cheers :) Hmm, I thought I already had, but it seems I'm mistaken. It's in the LaRCsim code (IO360.cxx), but never made it over to JSBSim's FGPiston.cpp. I believe I was gunning for about 25 rpm drop on one vs. two magnetos in the original code. I'll port it over... Of course, oversights like this would get picked up more easily if an adept 3D modeller added a magneto switch to the 3d C172 and pa28-161 :-) A master-on switch would be great as well :-)) Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Reasonable vertex count for ground static?
I've just had a crown fitted to my tooth and I'm a bit off-song so I decided to make a 'rip-down' version of the C172P that I was working on for ground-static (pure scenery display). I've made the model look near to the normal model in quality unless you go right up and look closely (interior textures, controls etc are gone) The seats are still in but I've cropped a lot of vertices from the fusealage and wings and re-orientated the model nose-up to simulate an empty cabin. (I made some 'line' tie-downs too just for show. The vertex count is down from near 1800 to 1200 and the number of 512x512 textures is halved. Is this low enough to be reasonable as a ground-static aircraft? (I have a behemoth of a gpu that loves vertices so I'm not much use as a tester). Can anyone up to speed which scenery placement who could have a go with placing a few duplicates of the model and then taxying past a few times to gauge whether the frame-rate takes a big hit? Thanks Dave Martin ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On 12/20/04 at 11:41 PM David Luff wrote: Of course, oversights like this would get picked up more easily if an adept 3D modeller added a magneto switch to the 3d C172 Oops, found it, bottom left! and pa28-161 :-) It is missing from that though. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] C172P Model Year?
Hmm, I thought I already had, but it seems I'm mistaken. It's in the LaRCsim code (IO360.cxx), but never made it over to JSBSim's FGPiston.cpp. I believe I was gunning for about 25 rpm drop on one vs. two magnetos in the original code. I'll port it over... Dave: There are two active branches, now: the main branch and JSBSim_NEW_XML (IIRC). If the changes are small, let me know what they are and I can copy it to the new XML branch unless you want to do that, too. The engine execution code has not changed much, if at all. Only the loading code. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Drew wrote : I'm getting the following errors (most of them several times) Cannot open include files: FL/Fl.h FL/Fl_File_Chooser.h FLTK 1.1.x, only needed to build fgadmin. Remove the project from the solution if you don't want to build it GL/glut.h GLUT, mandatory plib/ssg.h sg.h PLIB, mandatory Cannot open source files: .\majik_demo.cxx PLIB demo, optional .\simgear\scene\sky\clouds3d\camdisplay.cpp .\src\AIModel\AICarrier.cxx .\src\AIModel\submodel.cxx .\src\Cockpit\hud_rwy.cxx .\src\Fdm\groundcache.cxx .\src\fdm\sp\ACMS.cxx .\src\fdm\sp\ADA.cxx .\src\Instrumentation\encoder.cxx .\src\Instrumentation\kr_87.cxx .\src\Instrumentation\kt_70.cxx .\src\Instrumentation\marker_beacon.cxx .\src\Instrumentation\navradio.cxx .\src\Instrumentation\transponder.cxx .\src\Network\ATC-Inputs.cxx New, CVS only, ( or wait 0.9.8 ), files - remove them from the solution if you really want to compile 0.9.6 .\ssgLoadASC.cxx .\ssgSaveIV.cxx CVS plib files. same as above .\tux_example.cxx Plib demo, optional There are a bunch of warnings as well, but I won't worry about them yet. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Reasonable vertex count for ground static?
Hi Dave Dave Martin writes I've made the model look near to the normal model in quality unless you go right up and look closely (interior textures, controls etc are gone) The seats are still in but I've cropped a lot of vertices from the fusealage and wings and re-orientated the model nose-up to simulate an empty cabin. (I made some 'line' tie-downs too just for show. The vertex count is down from near 1800 to 1200 and the number of 512x512 textures is halved. The static 747 and 737 at KSFO are 1100 and 400 vertices respectivley.So that may give you an idea how complex you think the 172 should be. Dave Martin Cheers Innis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
