Re: [Flightgear-devel] Cygwin build problem with sprintf
Norman Vine wote: ! #ifdef _WIN32 #define snprintf _snprintf #endif --- 66,72 ! #if defined(_WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif To Norman: Good fix. To Curt (etc.): Shouldn't this go in simgear/compiler.h instead of in every source file that uses it? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
David Megginson wrote:
Julian Foad writes:
No - we have that in some places, but I was thinking recently that it's
not the right way to go. I think the only practical purpose is to
reduce clutter in the browser; but the property browser could and should
do this for us if we want it to.
It also makes life easier for programmers, since we can pass around
one node containing engine settings and nothing else.
Hmm ... I was about to agree with that ... but why is that useful? Think about how
you then use that node controls/engines that you are passing around: you assume that
it contains sub-nodes called engine[n], and you access them. If instead you pass
around the node controls, the exact same functions can access the engine[n]
children in the same way. They won't be confused or hampered by the fact that that
node also has other sub-nodes that it isn't interested in ... will they? (OK, they
must access the children as 'children(engine)' rather than as 'children()'.)
Also, consider the generality of the way the property manager implicitly allows every
node to be indexed. This allows us to add each new feature in the singular:
/instruments/altimeter/{datum,serviceable,altitude-ft,...}
and then later to add more of them without changing the existing one:
/instruments/altimeter/{datum,serviceable,altitude-ft,...}
/instruments/altimeter[1]/{datum,serviceable,altitude-ft,...}
This is a really nice feature of the property manager. If there is a policy of
putting plural properties under a singular parent node, it doesn't accord with this
convenient practice. As you are considering moving the engine controls to a new place
in the tree anyway, you have the freedom to arrange them any way you like. That is,
it is not going to be backward-compatible anyway, and we already handle more than one
engine, so this particular case won't suffer additionally from a switch from singular
to plural. But consider that very many of the existing singular properties will
probably be pluralised at some time in the future.
I think I don't like mixing both ways. If we want each node to contain EITHER a list
of differently-name sub-nodes OR an indexed array (but not a mixture of both), then it
would make sense to make the property manager support this syntax directly - like
perhaps engine/n or engine/[n].
To me, in the existing property manager the notation engine[n] is the correct
syntax to describe the n'th engine and duplication of the name engine seems
logically wrong.
- Julian
[Flightgear-devel] Bad link on Downloads page
Oops - the link to Bleeding-edge CVS snapshot on the Flight Gear Downloads web page points to repository version 0.7! - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 pannel lights
Andy Ross wrote: John Check wrote: What it is is that when electrical system modeling was added it affected planes for which no electrical system was added. Shouldn't the sane choice for the defaults be the opposite? The instruments work unless the electrical system tells them that they are disabled? Agreed. Instruments that test whether they are powered should default to powered if the aircraft does not provide a suitable electrical system. This could translate to if the required power bus property is not present. A simple default electrical system that provides just a main bus would only satisfy instruments that connect _directly_ to the main bus. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis Olson wrote:
The big thing that would need to be looked at is if we can include
based on the contents of a property name, rather than just include
some hard coded file name.
Like:
int main() {
char *sFile = getenv(FGFS_LANG);
char *LangStrings[] = {
#include sFile
}
...
}
:-)
Just trying to say that properties are intended to be dynamically variable, whereas
the include mechanism is processed at initial loading time, and I suspect it would
not be a good idea to hack it so that it can get the name from a property.
Still, a feature could (presumably) be implemented which dynamically loads in a file
of properties according to the current value of a filename property. This would be
over-kill for language selection, but would do the job and might be useful elsewhere.
For language selection, isn't there a way of specifying meta-variables in XML, which
might be the right thing to use?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Motion Maths
Jon Berndt wrote: The motion hardware has 2 degrees of freedom. Last night we had a discussion on what data to use from the sim (angular accelerations, velocities, pitch, roll etc.) and how to apply it to the motion hardware. Also, if I recall correctly, the space shuttle motion base uses the second derivative of velocities (i.e. the time derivative of accelerations) to drive the motion base. Er ... to drive the motion base's position, or its velocity, or its acceleration ... ? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failures and Instrumentation
David Megginson wrote: /instrumentation/altimeter/ /instrumentation/airspeed-indicator/ /instrumentation/vor-gauge/ /instrumentation/transponder/ etc., with indexes as appropriate. Inside each branch, we have a collection of properties, some common to many (or all) instruments, Yes, good. In particular, I have been wanting to modularise the instrument steam code to handle multiple copies of each instrument. e.g. It is common for an aircraft to have two altimeters which are (often) identical apart from having their pressure-datum knobs set to different values. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
Jonathan Polley wrote: Along the lines of adding the -pedantic option, I would like to add an ability (probably at ./configure time) to specify additional compile options. Since one of my platforms is a Mac, I would like to be able to add -wno_long_double, as it keeps telling me that their size is non-portable. You have this ability already. You just need to set the CFLAGS and CXXFLAGS environment variables while running configure. Have a look at the make files first to see what the default value is. For GCC it is -g -O2 for both, so you could do: [In Bash] GCCFLAGS=-g -O2 -wno_long_double CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS ./configure [In csh? (I'm not sure about this)] env CFLAGS=-g -O2 -wno_long_double CXXFLAGS=-g -O2 -wno_long_double ./configure - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS log browser broken
The result of trying to view viewmgr.cxx (web page http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/Main/viewmgr.cxx?rev=1.18cvsroot=FlightGear-0.7content-type=text/vnd.viewcvs-markup) is the following error: Failure during use of an external program: enscript --color -W html -Ecpp -o - - Python Exception Occurred Traceback (most recent call last): File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 2620, in run_cgi main() File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 2586, in main view_checkout(request) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 1914, in view_checkout markup_stream(request, fp, revision, request.mime_type) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 662, in markup_stream markup_stream_enscript(lang, fp) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 493, in markup_stream_enscript enscript.write(chunk) IOError: [Errno 32] Broken pipe - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS log browser broken
Curtis L. Olson wrote: It looks like enscript is breaking on viewmgr.cxx Is it enscript that is breaking, or the other end of its pipe? The error message says Broken pipe in enscript.write(chunk). Maybe just that the disk is full? Does this happen with any other source files or is it just viewmgr.cxx? That was the only file I had tried. Just now I tried fg_commands.cxx and got the same, so it's probably every file. - Julian [EMAIL PROTECTED] writes: The result of trying to view viewmgr.cxx (web page http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/Main/viewmgr.cxx?rev=1.18cvsroot=FlightGear-0.7content-type=text/vnd.viewcvs-markup) is the following error: Failure during use of an external program: enscript --color -W html -Ecpp -o - - Python Exception Occurred Traceback (most recent call last): File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 2620, in run_cgi main() File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 2586, in main view_checkout(request) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 1914, in view_checkout markup_stream(request, fp, revision, request.mime_type) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 662, in markup_stream markup_stream_enscript(lang, fp) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 493, in markup_stream_enscript enscript.write(chunk) IOError: [Errno 32] Broken pipe ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
Curtis L. Olson wrote: David Luff writes: Unfortunately, when ./configure gets run automatically after typing make, the configure switches after ./configure get remembered, but the flags in front of ./configure don't (this is using Cygwin Bash). Is there any way round this? I've been catching this situation manually and rerunning autogen.sh and configure my self. Me too. I have a script that runs: (optionally) autogen and configure (with variable assignments prefixed) make make install (for plib and SimGear only) in each of plib, SimGear, Atlas, FlightGear in turn. I tend to run this after each CVS update. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS log browser broken
Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Is it enscript that is breaking, or the other end of its pipe? The error message says Broken pipe in enscript.write(chunk). Maybe just that the disk is full? By my reading of the error message, python is reporting that enscript died unexpectedly. I agree, but I think that Broken pipe is the reason why enscript died, rather than just the result of it dying. What is it piping its output into? There is plenty of disk space, and the view command seems to work fine on other files OK, these display (but are not coloured - isn't enscript -color supposed to do syntax highlighting?): f*.hxx (5 files) README runfgfs.bat.in These fail: f*.cxx (5 files) Makefile.am 3dfx.sh ../FDM/JSBSim/FGAerodynamics.cpp ../FDM/JSBSim/FGAerodynamics.h Sometimes the error is different: there is no mention of enscript and it says: Python Exception Occurred Traceback (most recent call last): File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 2620, in run_cgi main() File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 2586, in main view_checkout(request) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 1914, in view_checkout markup_stream(request, fp, revision, request.mime_type) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 662, in markup_stream markup_stream_enscript(lang, fp) File /usr/local/viewcvs-0.9.1/lib/viewcvs.py, line 501, in markup_stream_enscript enscript.close() File /usr/local/viewcvs-0.9.1/lib/popen.py, line 180, in close self.file.close() IOError: [Errno 32] Broken pipe For now you could try (as text) rather than (view). Yes. I don't need to use it at all actually; I was just having a quick look, so you needn't spend time on this problem for my sake. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson wrote: Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. No it would not. The scenery is too far away. Further pixels require bigger values to shift. Distance makes a huge difference. The c172 cockpit doesn't appear to jitter much until you turn to the right and look at the headrest on the co-pilot's seat. The A-4 cockpit is much tighter and the panel is that much closer to the camera. Well, _position_ jitter would hardly affect the scenery, but orientation jitter (if it is orientation about the eye-point) would show up in equal amounts on everything that is affected by it. It's not something silly like the /sim/panel/jitter property being non-zero, is it? Nah... that would be too silly. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Remove .cvsignore?
I don't mind either way. I have found it generally useful to have them provided, and have wished the plib would do the same (for .deps directories, in particular). However, I have only ever worked on small patches, never adding files, so I have never needed to take note of the ? and unknown file messages that CVS prints. Even with the .cvsignore files, I still get a whole bunch of these messages, many of which are from local back-up files etc., but some of which I think should be added to the checked-in .cvsignore files (I can't check at the moment). I now always filter out lines starting with a question mark from the output of cvs update and cvs diff. If I was adding files I probably would want correct and complete .cvsignore lists. (I could add one in my home directory to describe most of my local back-up files.) While these files are in CVS people must occasionally update them. Not a very big deal, but in general the fewer files the better. About 22 of the 32 Flight Gear .cvsignore files contain just Makefile, Makefile.in and .deps. These could perhaps be replaced with a per-repository list in `$CVSROOT/CVSROOT/cvsignore'. - Julian David Megginson wrote: A while ago, I added .cvsignore files to the FlightGear, SimGear, and TerraGear CVS repositories to let CVS know to ignore generated files like executables and scripts, and cut down on the noise in CVS sessions. I now think that was a mistake, since people probably want their own, local, customized .cvsignore files if they want any at all. Would anyone object to my removing them from the repositories? Does anyone else care? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Remove .cvsignore?
FYI the FlightGear 'configure' is designed to be able to be run in a directory other then then the CVS source tree. That sounds well worth a try. Thanks. This has several advantages amongst them keeping the source tree MUCH cleaner :-) And being able to keep a debug build and a release build without doing a make clean every time. - Julian To use this feature: 1) run autogen.sh inside the CVS tree 2) create a new directory outside of the CVS tree 3) cd to the new directory 4) execute $PATH_TO_CVS_SOURCE_TREE/configure; make All of the compiler produced files should now be in your new directory .o .deps ect and the CVS tree should be 'clean' except for the files that autogen.sh created ie aclocal automake and autoconf created files IMHO these autogen.sh created files should be reflected in the .cvsignore(s) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Landing hints (was re: [Flightgear-devel] New A-4/jet panel instruments)
There are two aspects to being on the glide slope. First, are you on _any_ path that ends up at the beginning of the runway? Second, are you on the _intended_ glide slope? For the first, I was taught to look at the intended landing spot and, being aware of the windscreen, see whether that spot is stationary relative to the windscreen. If so, you are on track toward that spot. Try to see and feel this before worrying about _which_ glide slope you're on. It seems to work quite well. (Or perhaps you've already got this part OK; I wasn't sure from you're description.) For the second aspect, as David (I think) said, I was taught to recognise the on-screen geometry of the runway, mainly the angle of its edges. That works well in getting used to your home airfield, and after gaining experience there, you will be comfortable enough to adjust for unknown runways by picking up more than one cue at a time. (I remember thinking runway looking good ... looking good ... oh, airspeed! quick! ... that's better ... that's better ... oh, where's the runway gone?. Maybe not literally, but that's what it felt like. I stopped flying after getting a PPL, and never really reached the comfortable stage. So please don't trust my tips and advice too much.) - Julian from:Andy Ross [EMAIL PROTECTED] David Megginson wrote: Andy Ross wrote: Judging glide slope is still difficult, and will remain so until we get some kind of approach slope lighting (VASI/PAPI/FLOLS, whatever) implementation working. Speaking as someone who has just learned this stuff, I'll assert that estimating a glide path and extended centerline is not that tricky in good VFR conditions when the runway is level (sloping runways cause all kinds of misery). Heh, I hear what you're saying, but can't quite *do* it. This is one of those techniques that I understand in my head, but just can't get right in practice. In the cessna, I can sort of get by because the throttle is much more responsive. But in the jet, the engine spools more slowly and there's just too much going on. By the time I force myself to decide whether I'm too low, I've either gotten way too slow and am about to die, or have overcorrected on the throttle and am balooning way above the glide slope. Practice, practice, practice. The velocity vector in the HUD has been a crutch, I think. Gimme a week or so, and maybe a set of AoA indexers, and I'll probably be OK. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multi-vehicle issues (Was: static variables)
from:David Megginson [EMAIL PROTECTED] date:Tue, 18 Jun 2002 14:53:00 to: [EMAIL PROTECTED] subject: Re: [Flightgear-devel] static variables Curt and I have discussed this before (either online or offline). We could certainly have per-vehicle subtrees, i.e. ... and so on, and that would let us share some common, sim-wide information at the top level, and would make all program-wide information available at a single glance. The alternative is to use the multi-process model rather than a multi-thread model, and to swap entire property trees in and out like memory pages; we'll certainly avoid a lot of bugs that way (because the wrong properties simply won't be available). What does everyone else think? I think it will become clear straight away that the vehicle-specific properties will have to be organizationally separated from the base simulator properties. The initial profusion of bugs will be due to treating a property as global when it should really be vehicle-specific, and vice versa. I don't think there that one vehicle will accidentally access another vehicle's properties. You can't swap multiple copies of the _whole_ property tree, because base properties would get in a complete mess. You could swap the major branch that represents the vehicle, but you still have to re-organise so that all (and only) relevant properties are in that branch. At that point, the difference between swapping among copies of a branch and indexing that branch is fundamentally very little. The indexing could and should be made almost transparent within a given module, say the FDM, by having FDM property accessor functions that automatically supply the appropriate index or node pointer for that instance of the FDM. E.g. fdmGetInt(/rudder-pedal-pos) calls fgGetInt(/vehicle[n]/fdm/rudder-pedal-pos) [that is just an example of the concept, not a suggestion of actual names or style]. Although the reorganisation will be a lot of work, it will improve the modularity and clarity of the program design even when it is only running one vehicle. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compile/make/build flags?
Keith, unfortunately Eric's instructions weren't quite right :( Erik Hofman wrote: Just do ./configure this will give a full list of the possibilities. He meant ./configure --help of course :) Yours is: --disable-logging Actually, it is --without-logging: ./configure --without-logging (Unfortunately, configure silently ignores unknown options beginning with --with/without/enable/disable.) You would want to do this in both FlightGear and SimGear. But I always build with logging enabled, and then redirect to null at run time: src/Main/fgfs /dev/null 21 or to a file (because it's often useful to see what went wrong): src/Main/fgfs ~/fgfs.out 21 Both of these (to null or to a file) are fast under CygWin, whereas output to the console is slow. This is probably the main cause of your low frame rate, as long as you have enough free RAM to hold the 56MB executable. However, you can build a smaller one by omitting debugging information. There are several ways to do this. The easiest way is to strip the debugging info from the exe after it has been built: strip src/Main/fgfs.exe - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Report on my Scenery Investigation
Well I am happy to report that I got the Photo scenery to work perfectly. Unfortunately it is with the latest windows binaries under XP. Although the photo scenery works fine none of the other scenery seems to be installable as it doesnt seem to be uncompressable under windows. Do you mean that Windows XP's built-in ZIP handling doesn't know about Tar files, or something? I would expect it not to; you need to use CygWin or WinZip or similar. But thats OK if you have a dual boot system because you can load all of the scenery under linux except for the photo scenery of course Uh, why not the photo-scenery? (at least on my linux system the world scenery files gunzip) but the photo scenery gove the vertical lines stuff. Does anyone think the developers are aware of this? Do you mean rectangular holes in the ground at various joints in the scenery, like around airports? I still get this problem (CygWin, non-photo scenery) which appeared a few weeks ago. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
