Re: [Flightgear-devel] Issues regarding the texture-path tags inXML.
Innis Cunningham wrote: Hi Guys Just wondering why if it is possible in the AI to use one model with one or more liveries why it is not possible in the main aircraft folder. Every livery available for AI could be made accessible for normal use (if it isn't already done). It's just that one needs to take into account some (possible) problems when creating a new livery. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ASCII interface
Gerhard Wesp wrote: Hi, do we already have ASCII realtime I/O for data like position, orientation, controls, configuration etc.? Yes, it's the generic protocol (see Docs/README.IO and data/Protocol/README.Protocol for more information). There is no proper protocol configuration file specified though. I did start one which is called playback.xml in the Protocols directory. If you want to extend it, be my guest. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags inXML.
Hi Erik Erik Hofman writes Innis Cunningham wrote: Hi Guys Just wondering why if it is possible in the AI to use one model with one or more liveries why it is not possible in the main aircraft folder. Every livery available for AI could be made accessible for normal use (if it isn't already done). It's just that one needs to take into account some (possible) problems when creating a new livery. I am not sure I understand. As far as I can see with my limited knoweldge the AI system uses a slightly different way of doing things than the main aircraft folder.From what I can see of the main aircraft folder each aircraft has its own set file and inside the specific aircraft folder I can not see how you can have different liveries for the one model.If you can could you point me to a FG aircraft that currently does this. With reference to problems with new liveries as long as the repainters use the original texture map for the model what problems arrise?.I fully realise that they can change the size of the texture with remapping which I understand someone has done with the 737. There is a Lufthansa texture that is 2048x2048 that has been mapped to the 737.If anyone has used this livery could they make a comment to any change in frame rate when using this larger texture they may have noticed.Would be interesred thats all. Erik Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Automated builds on Linux
I am trying to move my main PC over from Windows to Linux (FC3 to be precise). I have a nice tidy script to build and install all of plib, SimGear, FlightGear and Atlas, which works beautifully on Cygwin, but it fails on Linux because it, understandably, needs root privs for the make install sections. How does everyone else here manage this problem? I can't believe everyone rebuilds everything manually, and I know that you don't _have_ to install the packages, but I would like to. I am not a Linux newbie (used it in various forms since 1992), but I am trying to improve my habits. Once I would just have done the entire build as root, but I feel that that is asking for trouble now. Any suggestions? Richard Bytheway This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Automated builds on Linux
Richard Bytheway wrote: I have a nice tidy script to build and install all of plib, SimGear, FlightGear and Atlas, which works beautifully on Cygwin, but it fails on Linux because it, understandably, needs root privs for the make install sections. This depends on your preferences. I have a directory /opt/FlightGear/ which I am owner of, so I can easily set the install prefix to this directory and build the whole stuff from a script. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Automated builds on Linux
On Tuesday 13 September 2005 11:35, Richard Bytheway wrote: I have a nice tidy script to build and install all of plib, SimGear, FlightGear and Atlas, which works beautifully on Cygwin, but it fails on Linux because it, understandably, needs root privs for the make install sections. How does everyone else here manage this problem? I can't believe everyone rebuilds everything manually, and I know that you don't _have_ to install the packages, but I would like to. I rebuild everything manually, but more importantly, for my CVS builds of FGSG I build and install both under my home directory. This allows me to also keep, system-wide, the latest release for testing/comparison purposes. Considering that I use the latest _release_ for plib, and that most FG code changes occur in FG rather than SG, and also that these changes mostly only require a very quick partial rebuild of FG, you can see that it's not really very much work at all. No more than checking out the latest code and doing the usual makemake install in fact... If you are just building the latest _releases_ of Flightgear et al, I'd suggest a distro like Gentoo might be better suited than FC - the portage system handles the entire process; a simple emerge flightgear grabs, compiles and installs all the dependencies and FlightGear itself. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Automated builds on Linux
On Tuesday 13 September 2005 12:35, Richard Bytheway wrote: I am trying to move my main PC over from Windows to Linux (FC3 to be precise). I have a nice tidy script to build and install all of plib, SimGear, FlightGear and Atlas, which works beautifully on Cygwin, but it fails on Linux because it, understandably, needs root privs for the make install sections. How does everyone else here manage this problem? I can't believe everyone rebuilds everything manually, and I know that you don't _have_ to install the packages, but I would like to. I am not a Linux newbie (used it in various forms since 1992), but I am trying to improve my habits. Once I would just have done the entire build as root, but I feel that that is asking for trouble now. Any suggestions? I don't want to wait for releases, so I use CVS. However I never run make install with any flightgear related stuff... I only symlinked the created binaries to /usr/local/bin and this symlink of course still works when I recompile... off course neither run make clean nor delete the sources afterwards :-) Another method is to configure everything with --prefix=$HOME. you just want to but $HOME/bin $HOME/lib and so on into your PATH. Haven't tried that though, but should work, shouldn't it? I don't know if this comes close to your idea of Automated builds but I think my approach is pretty user friendly... cheers Thorben ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 29, Issue 17
[EMAIL PROTECTED] wrote: Send Flightgear-devel mailing list submissions to flightgear-devel@flightgear.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.flightgear.org/mailman/listinfo/flightgear-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Flightgear-devel digest... Today's Topics: 1. Re: Flightgear-devel Digest, Vol 29, Issue 16 (Steve Knoblock) 2. Re: Lufthansa liveries (Gabor Toth) 3. Re: [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.6, (Martin Spott) 4. EasyXML.cxx (Richard Harrison) 5. Re: Issues regarding the texture-path tags inXML. (Innis Cunningham) 6. ASCII interface (Gerhard Wesp) 7. Re: EasyXML.cxx (Erik Hofman) 8. Re: Issues regarding the texture-path tags inXML. (Erik Hofman) 9. Re: ASCII interface (Erik Hofman) 10. Re: Issues regarding the texture-path tags inXML. (Innis Cunningham) 11. Automated builds on Linux (Richard Bytheway) -- Message: 1 Date: Mon, 12 Sep 2005 14:07:51 -0400 From: Steve Knoblock [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 29, Issue 16 To: flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii works fine, however, I notice some differences in the numbers reported by the heading and track properties. Are you sure that the Digitrack actually knows the roll angle of the airplane? I am not sure I have the technical background to understand how the Digitrak actually works. It does not use a turn coordinator as a source of roll information. There is an explanation on the website http://www.trutrakflightsystems.com/overview.html which may be new, I do not remember having it when I made the model for MSFS. In the FG generic autopilot, the second stage of the heading bug hold, inputs /orientation/roll-deg into the controller and uses the target roll as the reference. I copied this to get it working. I looked at the KAP140, but it depends on the turn indicator for input to the wing leveler (roll mode). The Digitrak docs clearly state that it does not employ a turn coordinator, so I cannot take this approach. The overview claims it can sense motion about the three axes, apparently through the directional gyro. I assume it uses that to obtain roll angle. The orientation/roll-angle would be a good place to start, being closest to getting the roll information from the digital gyro. Is it possible to use the directional gyro as a source? It seems that I would need to create my own gyro model to do this. The DG/heading indicator only outputs heading. I can only assume from the documents (the PDF manual particularly) that the gyro is periodically corrected for drift using the magnetometer or the GPS. I have not decided how to simulate this. Heading and track are _not_ the same thing. Heading is the direction that the nose of the aircraft is pointing. Track is the direction that the aircraft is You're right. I forgot about wind effects. I have studied this in instructional texts on navigation, but I have become lazy flying PC flight sims by GPS route most of the time. Thanks for clearing that up, Steve -- Message: 2 Date: Mon, 12 Sep 2005 20:11:57 +0200 From: Gabor Toth [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Lufthansa liveries To: FlightGear developers discussions flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Thanx. :) I'm glad you like it. About the mini howto, I have no idea what to write in it. I've just took the original file, and repainted it in Gimp. For source I used airliners.net and some of my own photos. Then, as the resolution was too low for the 737, I decided to double the resolution. That's all. Regards, Gabor On Sunday 11 September 2005 15:45, mat churchill wrote: Gabor these look great. How about a mini howto on the texture creation for the livery, you seem to have got the balance just right between the look and the resolution of the texture. Another screenshot: http://projects.34sp.com/Flightgear/luthansa.jpg Clouds seem to have come a long way recently as well. Mat -- Message: 3 Date: Mon, 12 Sep 2005 19:48:39 + (UTC) From: Martin Spott [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.6, To: flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/b1900d In directory baron:/tmp/cvs-serv4749 Modified Files: b1900d-set.xml
[Flightgear-devel] FGNav vs. FGNavRecord
There seem to be two very similar navaid classes currently existing in the src/Navaids directory - FGNav in nav.hxx and FGNavRecord in navrecord.hxx. Is any one of these preferred / due to be depreciated? (So I don't use the wrong one). Is there any reason for the duplication / change? (Just out of interest). Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ASCII interface
On Tue, Sep 13, 2005 at 09:51:52AM +0200, Erik Hofman wrote: Yes, it's the generic protocol (see Docs/README.IO and data/Protocol/README.Protocol for more information). Sounds good! Actually, I need to feed my data to FG, so it's input. Is this bidirectional in the current CVS? In 0.9.8 it's output only. Thanks, -Gerhard -- o o Gerhard Wesp| http://www.cosy.sbg.ac.at/~gwesp/ \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Automated builds on Linux
From: Richard Bytheway [EMAIL PROTECTED] needs root privs for the make install sections. Look at the command sudo. Also, you may want to over-ride the default install command to add the -p option, so that incremental rebuilds work properly. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ASCII interface
Gerhard Wesp wrote: Sounds good! Actually, I need to feed my data to FG, so it's input. Is this bidirectional in the current CVS? In 0.9.8 it's output only. Yes, at least I think so. I've added input recently but didn't test bidirectional data transfers. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MSVC problems with 0.9.8 tarball
I pulled the FlightGear 0.9.8 tarball from the website, SimGear 0.3.8 tarball, plib 1.8.4, OpenAL (not sure of the version, I pulled it from CVS around June/July) and compiled fgfs in MSVC .NET. It compiled fine, but running the executable is a little strange as you can see from the screenshot: http://www.cs.unc.edu/~quirk/blankscreen.bmp Though the hud/panel can be displayed, and any airplane flies fine according to the instruments, there's just no scenery. I downloaded and ran the pre-built binary and that runs/looks normal, so there's something wonky when I compile my own version. I've redownloaded all the libraries and started over, but got the same result. Has anyone seen this before or know how to fix it? Thanks, Patrick ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags inXML.
Hi Innis, I've done a quick measure, and I got no difference in FPS. My config is 900MHz P3, 384MB RAM, GeForce FX5500. Gabor There is a Lufthansa texture that is 2048x2048 that has been mapped to the 737.If anyone has used this livery could they make a comment to any change in frame rate when using this larger texture they may have noticed.Would be interesred thats all. Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML.cxx
I don't have the original post in front of me but if I remember rightly, just a couple of values from the object are needed for the throw. Why not copy them to local vars, do the XML_ParserFree and then the throw using the local vars? Richard On Tue September 13 2005 00:45, Erik Hofman wrote: Richard Harrison wrote: Surely the XML_ParserFree should be after the throw? (I appreciate this is 99% safe, but it probably isn't the way that things should be done). The problem is that the program doesn't return to the function after throwing an exception. I assume it's best to add the XML_ParserFree() function to atexit() somewhere. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML.cxx
Richard Harke wrote: I don't have the original post in front of me but if I remember rightly, just a couple of values from the object are needed for the throw. Why not copy them to local vars, do the XML_ParserFree and then the throw using the local vars? Richard Now that you talk about that, this is not a jsbsim problem only, there is the same sequence in easyxml, and that explain why there is nearly allways a crash when an xml file is malformed. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML.cxx
I'm not surprised it breaks with malformed XML files. A suggested fix is
below.
if (!input.good()) {
sg_io_exception ex(Problem reading file,
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
SimGear XML Parser);
XML_ParserFree(parser);
throw ex;
}
--Richard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
Jim A wrote: I have noticed there are many instances in the data directory where developers have left explicit paths to textures, particularly in .ac files. These paths are specific to the developer's machines, and so will not be useful to others. This is benign. The plib loader strips off the leading directories on the texture file name for you and uses its own path for texture lookup. I would presume that most of these things are added not by the model authors, but by the software they are using. Other than the potentially embarassing information leakage (it exposes the author's file hierarchy), this isn't really a problem. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags inXML.
Hi Gabor Thanks for that and keep up the good work.The more repaints the better. Your computer specs are nearly the same as mine 850 duron 256meg ram and GF MX 440 graphics Cheers Innis Gabor Toth writes Hi Innis, I've done a quick measure, and I got no difference in FPS. My config is 900MHz P3, 384MB RAM, GeForce FX5500. Gabor ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
Thanks, Andy. I didn't know that. (just one _more_ thing I don't know) ;-) Does it first try the explicit path, if valid? Got into this issue when I tried to use someone else's scenery (not from CVS), but an rgb was missing. The person had put an explicit path in the ac to another location, and had not provided me the rgb. Later, I added the rgb locally, and removed the explicit path. Did both at once, so I didn't get a chance to observe any path stripping. Sorry about my providing even more exposure to the author file hierarchies! Jim Jim A wrote: I have noticed there are many instances in the data directory where developers have left explicit paths to textures, particularly in .ac files. These paths are specific to the developer's machines, and so will not be useful to others. This is benign. The plib loader strips off the leading directories on the texture file name for you and uses its own path for texture lookup. I would presume that most of these things are added not by the model authors, but by the software they are using. Other than the potentially embarassing information leakage (it exposes the author's file hierarchy), this isn't really a problem. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
On Tue, 2005-09-13 at 16:40 -0700, Andy Ross wrote: This is benign. The plib loader strips off the leading directories on the texture file name for you and uses its own path for texture lookup. I would presume that most of these things are added not by the model authors, but by the software they are using. Other than the potentially embarassing information leakage (it exposes the author's file hierarchy), this isn't really a problem. Yes, but it's sloppy. It's information that doesn't belong there. Anyone wanting to import or process that data will have to add this path stripping to their code. Better to remove it. Didn't your mother ever make you clean your room? :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags inXML.
On September 13, 2005 02:52 pm, Gabor Toth wrote: Hi Innis, I've done a quick measure, and I got no difference in FPS. My config is 900MHz P3, 384MB RAM, GeForce FX5500. Gabor It should be tested across the network. The MD-11, a resource sucker, has decent framerate offline as well. However, those who see it online have their framerate dropped below 1 fps. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
