[Flightgear-devel] Fw: GAS-L: Eclipse Combustion Engineering Guide - Free PDF
..may be of use modelling combustion, fans and some thermodynamics. Begin forwarded message: Date: Wed, 2 Oct 2002 00:14:37 EDT From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: GAS-L: Eclipse Combustion Engineering Guide - Free PDF Thought some of you might find this useful. http://www.burnerparts.com/peconet/efe825tn.pdf ..warning, ca 1 MB. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ 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
[Flightgear-devel] Problem with panel initialization
Hi, I've been observing a problem with panel initialization for a couple of week or so now. When I start the program I get the graphics screen with scenery and stuff, but no panel. Moreover, I am unable to switch it on via Shift+P. Only after I do a Reset does the panel appear and can be switched on/and off via Shift+P. This is a CVS build from today under Cygwin/WinXP. This may have started around the time the 3D clouds were added, but not sure if it's related. Any idea, what's broken here? Anyone else having this problem or is it only me? Regards Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Internal compiler error
Hi all... I hope this is not a repetitive question (I tried looking through some of the archives and found a similar question, but the answer didn't help me). When I try compiling either plib, simgear, metakit, or flightgear I keep getting "Internal compiler error" at seemingly random points. If I re-run the make, sometimes it successfully compiles the file it failed on and then fails again on a different file. Occassionally it takes up to 10 reties before a file will compile. On one occassion I managed to build everything using this tedious approach but flightgear would not run, it kept generating segmentation faults. When I download the pre-built binaries for flightgear it runs without any problems. The strange thing is I get the "Internal compiler error" when compiling under Windows 2000/Cygwin and under Red Hat Linux 7.3! Does this mean it is a hardware-related problem? I have no problems running any other software. My setup is Pentium III 600EB 512MB PC133 SDRAM 60GB HDD, Leadtek GeForce 2 64MB, SBLive. Here is a sample run in plib which generates the "Internal compiler error" SAMPLE RUN START Administrator@ZELIOS-PENTIUM3 /usr/local/plib-1.4.2$ makeMaking all in srcmake[1]: Entering directory `/usr/local/plib-1.4.2/src'Making all in utilmake[2]: Entering directory `/usr/local/plib-1.4.2/src/util'make[2]: Nothing to be done for `all'.make[2]: Leaving directory `/usr/local/plib-1.4.2/src/util'Making all in jsmake[2]: Entering directory `/usr/local/plib-1.4.2/src/js'make[2]: Nothing to be done for `all'.make[2]: Leaving directory `/usr/local/plib-1.4.2/src/js'Making all in slmake[2]: Entering directory `/usr/local/plib-1.4.2/src/sl'make[2]: Nothing to be done for `all'.make[2]: Leaving directory `/usr/local/plib-1.4.2/src/sl'Making all in puimake[2]: Entering directory `/usr/local/plib-1.4.2/src/pui'make[2]: Nothing to be done for `all'.make[2]: Leaving directory `/usr/local/plib-1.4.2/src/pui'Making all in sgmake[2]: Entering directory `/usr/local/plib-1.4.2/src/sg'make[2]: Nothing to be done for `all'.make[2]: Leaving directory `/usr/local/plib-1.4.2/src/sg'Making all in ssgmake[2]: Entering directory `/usr/local/plib-1.4.2/src/ssg'c++ -DPACKAGE=\"plib\" -DVERSION=\"1.4.2\" -DWIN32=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DWIN32=1 -DGLUT_IS_PRESENT=1 -I. -I. -I../../src/sg-I../../src/util -I/usr/local/include -g -O2 -O6 -Wall -malign-double -I/usr/local/include -L/usr/local/lib -c ssgSimpleState.cxxssgSimpleState.cxx: In method `void ssgSimpleState::setTexture(char *, int = 1,int = 1, int = 1)':ssgSimpleState.cxx:632: Internal compiler error.ssgSimpleState.cxx:632: Please submit a full bug report.ssgSimpleState.cxx:632: See URL:http://www.gnu.org/software/gcc/bugs.html forinstructions.make[2]: *** [ssgSimpleState.o] Error 1make[2]: Leaving directory `/usr/local/plib-1.4.2/src/ssg'make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/usr/local/plib-1.4.2/src'make: *** [all-recursive] Error 1 Administrator@ZELIOS-PENTIUM3 /usr/local/plib-1.4.2$ SAMPLE RUN END I have tried several things to get this error to go away, including: * Removing the -O optimisation flags * Removing the -g debug option * Using -O3 -fomit-frame-pointer -DNDEBUG for CXXFLAGS as suggested in an old post Sometimes even ./configure abort and generates "Signal 11". The code versions I am using are: plib-1.4.2 SimGear-0.0.18 FlightGear-0.7.10 Any help would be greatly appreciated as I am trying to make some small modifications to FlightGear for a university project. I have been trying to compile flightgear on and off for a few weeks now. I have managed to get it to compile on Windows 2000/Cygwin on my PC at work without any problems, it's just my home PC which has this problem. Regards, Clarence.
RE: [Flightgear-devel] Internal compiler error
Sig 11 errors during large compiles are often symptomatic of RAM problems (http://www.bitwizard.nl/sig11/). I don't know whether this applies to Cygwin as well as Linux, but it might. I doubt that this is a problem with the source as many people have built all the source you mention without problem, myself included on W2K/Cygwin. As mentioned in the Sig11 FAQ (link above), ensure that all the hardware in the PC is the correct spec, and that nothing is overclocked. Try underclocking as a possible workaround. If your RAM is on more than one stick, try removing different parts of it. As an aside, you may want to switch to plib 1.6.0, simgear 0.2.0 and FlightGear 0.8.0/0.9.0 when you get things working. Richard -Original Message- From: Clarence Bakirtzidis [mailto:[EMAIL PROTECTED]] Sent: 02 October 2002 2:41 pm To: flightgear-devel Subject: [Flightgear-devel] Internal compiler error Hi all... I hope this is not a repetitive question (I tried looking through some of the archives and found a similar question, but the answer didn't help me). snip ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internal compiler error
In the past I've seen these sorts of errors and behavior caused by both memory problems and CPU overheating. I would be surprised if it wasn't some sort of hardware problem. Curt. Clarence Bakirtzidis writes: Hi all... I hope this is not a repetitive question (I tried looking through some of the archives and found a similar question, but the answer didn't help me). When I try compiling either plib, simgear, metakit, or flightgear I keep getting Internal compiler error at seemingly random points. If I re-run the make, sometimes it successfully compiles the file it failed on and then fails again on a different file. Occassionally it takes up to 10 reties before a file will compile. On one occassion I managed to build everything using this tedious approach but flightgear would not run, it kept generating segmentation faults. When I download the pre-built binaries for flightgear it runs without any problems. The strange thing is I get the Internal compiler error when compiling under Windows 2000/Cygwin and under Red Hat Linux 7.3! Does this mean it is a hardware-related problem? I have no problems running any other software. My setup is Pentium III 600EB 512MB PC133 SDRAM 60GB HDD, Leadtek GeForce 2 64MB, SBLive. Here is a sample run in plib which generates the Internal compiler error SAMPLE RUN START Administrator@ZELIOS-PENTIUM3 /usr/local/plib-1.4.2 $ make Making all in src make[1]: Entering directory `/usr/local/plib-1.4.2/src' Making all in util make[2]: Entering directory `/usr/local/plib-1.4.2/src/util' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/plib-1.4.2/src/util' Making all in js make[2]: Entering directory `/usr/local/plib-1.4.2/src/js' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/plib-1.4.2/src/js' Making all in sl make[2]: Entering directory `/usr/local/plib-1.4.2/src/sl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/plib-1.4.2/src/sl' Making all in pui make[2]: Entering directory `/usr/local/plib-1.4.2/src/pui' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/plib-1.4.2/src/pui' Making all in sg make[2]: Entering directory `/usr/local/plib-1.4.2/src/sg' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/plib-1.4.2/src/sg' Making all in ssg make[2]: Entering directory `/usr/local/plib-1.4.2/src/ssg' c++ -DPACKAGE=\plib\ -DVERSION=\1.4.2\ -DWIN32=1 -DSTDC_HEADERS=1 -DHAVE_GL_ GL_H=1 -DHAVE_GL_GLU_H=1 -DWIN32=1 -DGLUT_IS_PRESENT=1 -I. -I. -I../../src/sg -I../../src/util -I/usr/local/include -g -O2 -O6 -Wall -malign-double -I/usr/ local/include -L/usr/local/lib -c ssgSimpleState.cxx ssgSimpleState.cxx: In method `void ssgSimpleState::setTexture(char *, int = 1, int = 1, int = 1)': ssgSimpleState.cxx:632: Internal compiler error. ssgSimpleState.cxx:632: Please submit a full bug report. ssgSimpleState.cxx:632: See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make[2]: *** [ssgSimpleState.o] Error 1 make[2]: Leaving directory `/usr/local/plib-1.4.2/src/ssg' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/plib-1.4.2/src' make: *** [all-recursive] Error 1 Administrator@ZELIOS-PENTIUM3 /usr/local/plib-1.4.2 $ SAMPLE RUN END I have tried several things to get this error to go away, including: * Removing the -O optimisation flags * Removing the -g debug option * Using -O3 -fomit-frame-pointer -DNDEBUG for CXXFLAGS as suggested in an old post Sometimes even ./configure abort and generates Signal 11. The code versions I am using are: plib-1.4.2 SimGear-0.0.18 FlightGear-0.7.10 Any help would be greatly appreciated as I am trying to make some small modifications to FlightGear for a university project. I have been trying to compile flightgear on and off for a few weeks now. I have managed to get it to compile on Windows 2000/Cygwin on my PC at work without any problems, it's just my home PC which has this problem. Regards, Clarence. !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META content=text/html; charset=iso-8859-1 http-equiv=Content-Type META content=MSHTML 5.00.3315.2870 name=GENERATOR STYLE/STYLE /HEAD BODY bgColor=#ff DIVFONT face=Arial size=2Hi all.../FONT/DIV DIVnbsp;/DIV DIVFONT face=Arial size=2I hope this is not a repetitive question (I tried looking through some/FONT/DIV DIVFONT face=Arial size=2of the archives and found a similar question, but the answer didn't help/FONT/DIV DIVFONT face=Arial size=2me)./FONT/DIV DIVnbsp;/DIV DIVFONT face=Arial size=2When I try compiling either plib, simgear, metakit, or flightgear I/FONT/DIV DIVFONT face=Arial size=2keep getting Internal compiler error at seemingly random points./FONT/DIV DIVFONT face=Arial size=2If I re-run the make, sometimes it successfully
[Flightgear-devel] ANN: AI traffic from Dave Luff
I have just committed Dave Luff's preliminary AI traffic support, with a few cleanups for non-Windows systems (such as filename case). The AI traffic is disabled by default for reasons Dave explained in an earlier message: This isn't in Flightgear at the moment (the current AIEntity/AILocalTraffic has a nasty bug and puts multiple planes on top of each other until Flightgear crashes which is why its not called) It does work OK for at least part of a circuit, though. To try it out, you have to set the property /sim/ai-traffic/enabled to true. You *also* need to start at KEMT (El Monte airport, in the w120n30 scenery) with a heading of 30, and if you want to hear the other plane, you need to tune your comm radio to 121.2MHz. This command-line should work once you've installed the w120n30 scenery: fgfs --airport-id=KEMT --heading=30 \ --prop:/sim/ai-traffic-enabled=true \ --prop:/radios/comm/frequencies/selected=121.2 I'm sure Dave would appreciate extra eyes trying to find the bugs. Eventually, we'll want to actually fly the other planes using an FDM/autopilot combination so that they respond realistically to wind, temperature, and so on. 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] Internal compiler error
Richard Bytheway wrote:a As mentioned in the Sig11 FAQ (link above), ensure that all the hardware in the PC is the correct spec, and that nothing is overclocked. Try underclocking as a possible workaround. If your RAM is on more than one stick, try removing different parts of it. Oddly, that FAQ fails to mention the single best tool for detecting these problems: http://www.memtest86.com/ Get this and run it. It's a boot image, so if you don't have a Linux installation (LILO and GRUB can run it just like a kernel) or a floppy, you may have to do some gymnastics. Leave it running overnight and see what you find. You'd be amazed at the number of working machines in the world have slightly bad RAM. One of my boxes, which seems perfectly stable, gets about 1 error every 10 hours. If you see any more than that, consider replacing your memory or motherboard. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
DCL writes: I personally think that fdm/autopilot is overkill given that they're dots in the sky unless you're illegally close. Not always -- for example, watching another plane land or take-off while holding short is the best way to tell what the wind is doing (is the plane in a major slip on short final? is it crabbed way to the right on climbout to hold runway heading? is it bouncing around like a mechanical bull from gusts and turbulence?). In a busy circuit, it's not uncommon to be following only 0.5mi behind another plane, and depending on screen resolution, you can probably tell again whether it's crabbed, what its pitch angle is, etc. I agree that you should not normally be close enough to see control surfaces move unless you're practicing formation flying. Temperature and air pressure are important because they affect density altitude -- the plane should climb very lethargically on a hot day at a mountain airport and quite vigorously on a cold day at sea level -- again, these are things you watch while holding short of the runway. Furthermore, above FL180 (and north of about 60deg latitude at all altitudes) altimeters are set to pressure altitude, so you'll have to take air pressure into account eventually. Even in the circuit, circuit altitude is based on the altimeter reading, which (even when corrected for pressure) can be off a bit due to temperature and humidity. That's not a problem as long as everyone's altimeter is off the same amount. You can go through and try to support all of this, but in the end, it will probably be easier just to create a new instance of an FDM and autopilot and let them fly the plane. Note that I'm not suggesting that you do this now -- what you've done already is quite impressive. However, be careful that you don't end up unintentionally creating your own new FDM in its stead. 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
[Flightgear-devel] dumb CVS question
Hi, I made a lot of local modifications to FlightGear 0.7, and now I want to put them into my copy of 0.8. I tried to do a cvs diff (on my version of 0.7) to get the changes to put into 0.8, but I get the following complaint from CVS: $ cvs diff main.cxx /var/cvs/FlightGear-0.7: no such repository cvs diff: authorization failed: server cvs.flightgear.org rejected access to /var/cvs/FlightGear-0.7 for user cvs I tried to login again and got the following: $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7 login (Logging in to [EMAIL PROTECTED]) CVS password: /var/cvs/FlightGear-0.7: no such repository cvs login: authorization failed: server cvs.flightgear.org rejected access to /var/cvs/FlightGear-0.7 for user cvs I'm sure I'm making this harder than it should be. Any help would be appreciated. Mark ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb CVS question
You can do that. Just change the user in all the Root files to cvsguest in your 0.7 tree. Then do your diff command. Best, Jim Boslough, Mark B [EMAIL PROTECTED] said: Thanks Eric. I have both cvs branches of FlightGear 0.8. What I am wanting to do is to reach back and get the changes I put into my local version of 0.7, so I need to do the cvs diff on FlightGear 0.7. I can do this manually, but I was hoping that FlightGear 0.7 would still be in a repository somewhere so I could get CVS to tell me what I did, instead of digging back into the code manually. Thanks, Mark -Original Message- From: Erik Hofman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] dumb CVS question Boslough, Mark B wrote: Hi, I made a lot of local modifications to FlightGear 0.7, and now I want to put them into my copy of 0.8. I tried to do a cvs diff (on my version of 0.7) to get the changes to put into 0.8, but I get the following complaint from CVS: $ cvs diff main.cxx /var/cvs/FlightGear-0.7: no such repository cvs diff: authorization failed: server cvs.flightgear.org rejected access to /var/cvs/FlightGear-0.7 for user cvs I'm sure I'm making this harder than it should be. Any help would be appreciated. Things have changed since the release of 0.8.0, see: http://www.flightgear.org/cvsResources/anoncvs.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Subsystem Manager
I'm working on testing and integrating a couple of new classes,
FGSubsystemGroup and FGSubsystemMgr. FGSubsystem is the interface
that each module of the program should implement (most do now, but
there is still a bit of legacy code). The FGSubsystem interface looks
basically like this:
class FGSubsystem
{
public:
virtual void init () = 0;
virtual void bind () = 0;
virtual void unbind () = 0;
virtual void update (double delta_time_sec) = 0;
virtual void suspend (bool suspended);
virtual void resume ();
virtual bool is_suspended () const;
};
There's a little more, but that's the essential stuff.
The first new class, FGSubsystemGroup, is simply a subsystem that
contains a list of other subsystems:
class FGSubsystemGroup : public FGSubsystem
{
public:
virtual void set_subsystem (const string name,
FGSubsystem * subsystem,
double min_step_sec = 0);
virtual FGSubsystem * get_subsystem (const string name);
virtual void remove_subsystem (const string name);
virtual bool has_subsystem (const string name) const;
};
Each member of the group can have a minimum step time -- it won't be
updated more frequently than that time, no matter what the framerate
is. For example, if I wanted to add a controls subsystem that should
be updated every frame, a logging subsystem that should be updated
every half second, GPS subsystem that should be updated only every two
seconds, I could do something like this:
group-set_subsystem(logger, new FGLogger);
group-set_subsystem(controls, new FGControls, 0.5);
group-set_subsystem(gps, new FGGPS, 2.0);
group-init();
group-bind();
Now, every frame, I call
group-update(delta_time_sec);
and all of the subsystems will either be updated or have their
elapsed-time counters tick down towards an update. If I call
group-suspend(true);
all of the subsystems in the group will stop updating as long as the
suspension is in force.
We could use FGSubsystemGroup as our primary mechanism for managing
subsystems, but since there are some dependencies (we have to ensure
that some systems are updated before or after others), I decided to
make a top-level FGSubsystemMgr class to maintain a series of groups,
or run-levels -- everything in a lower level is guaranteed to be
initialized, bound, unbound, and updated before anything in a higher
level. Right now, my levels are just
INIT
GENERAL
but we should be able to get much more clever. The subsystem manager
maintains a separate FGSubsystemGroup for each level, and can init,
bind, unbind, or update them all with a single call. Going through
the top-level manager, adding subsystems looks like this:
globals-get_subsystem_mgr()-add(FGSubsystemMgr::INIT,
logger, new FGLogger);
globals-get_subsystem_mgr()-add(FGSubsystemMgr::GENERAL,
controls, new FGControls, 0.5);
globals-get_subsystem_mgr()-add(FGSubsystemMgr::GENERAL,
gps, new FGGPS, 2.0);
globals-get_subsystem_mgr()-init();
globals-get_subsystem_mgr()-bind();
and then, in main.cxx
globals-get_subsystem_mgr()-update(delta_time_sec);
This arrangement should give us much more flexibility and should make
the top-level code in src/Main/ about an order-of-magnitude more
readable and maintainable once everything's converted over. I plan to
go slowly with the conversion, starting with the easy stuff and making
sure I don't break anything along the way.
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] dumb CVS question
Maybe I misunderstood. Sorry to be such a dope. Mark -Original Message- From: Boslough, Mark B [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 3:31 PM To: '[EMAIL PROTECTED]' Subject: RE: [Flightgear-devel] dumb CVS question Jim, thanks. I already tried that. Here's what I got: $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7 login (Logging in to [EMAIL PROTECTED]) CVS password: Fatal error, aborting. cvsguest: no such user cvs login: authorization failed: server cvs.flightgear.org rejected access to /v ar/cvs/FlightGear-0.7 for user cvsguest -Original Message- From: Jim Wilson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 3:02 PM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] dumb CVS question You can do that. Just change the user in all the Root files to cvsguest in your 0.7 tree. Then do your diff command. Best, Jim Boslough, Mark B [EMAIL PROTECTED] said: Thanks Eric. I have both cvs branches of FlightGear 0.8. What I am wanting to do is to reach back and get the changes I put into my local version of 0.7, so I need to do the cvs diff on FlightGear 0.7. I can do this manually, but I was hoping that FlightGear 0.7 would still be in a repository somewhere so I could get CVS to tell me what I did, instead of digging back into the code manually. Thanks, Mark -Original Message- From: Erik Hofman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] dumb CVS question Boslough, Mark B wrote: Hi, I made a lot of local modifications to FlightGear 0.7, and now I want to put them into my copy of 0.8. I tried to do a cvs diff (on my version of 0.7) to get the changes to put into 0.8, but I get the following complaint from CVS: $ cvs diff main.cxx /var/cvs/FlightGear-0.7: no such repository cvs diff: authorization failed: server cvs.flightgear.org rejected access to /var/cvs/FlightGear-0.7 for user cvs I'm sure I'm making this harder than it should be. Any help would be appreciated. Things have changed since the release of 0.8.0, see: http://www.flightgear.org/cvsResources/anoncvs.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Okay, I made a German version of strings-en.xml which I called strings-de.xml. I just submitted it to John asking him to install it under /Translations in the base package. Questing: Is the lates CVS version of FlightGear able to use it and how should this be done? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Michael Basler writes: Okay, I made a German version of strings-en.xml which I called strings-de.xml. I just submitted it to John asking him to install it under /Translations in the base package. Questing: Is the lates CVS version of FlightGear able to use it and how should this be done? More work needs to be done, but you should be able to go into your prefernces.xml file and specify the strings-de.xml file instead of the strings-default.xml. It would be nice to develop this further and also be able to do default keyboard bindings. Eric H. sent me a proposal so perhaps he'll get a chance to impliment it at some point. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb CVS question
Oops...guess I was wrong. The user for that path is still cvs. I just checked and it worked fine for that path. In each directory of your version 7 you'll find a CVS/Root file that should contain the text: :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7 If they do then just typing cvs diff should work. If it doesn't try cvs login (password is guest) and then cvs diff. If they don't contain that exact text, you will probably need to checkout to a fresh tree and move just the source files (important) from your version 7 tree into the new tree. Then run the diff command. Best, Jim Boslough, Mark B [EMAIL PROTECTED] said: Jim, thanks. I already tried that. Here's what I got: $ cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7 login (Logging in to [EMAIL PROTECTED]) CVS password: Fatal error, aborting. cvsguest: no such user cvs login: authorization failed: server cvs.flightgear.org rejected access to /v ar/cvs/FlightGear-0.7 for user cvsguest ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb CVS question
Jim, thanks. That worked. No wonder I couldn't figure it out. It was too easy :-) -Original Message- From: Jim Wilson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 4:06 PM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] dumb CVS question Oops...guess I was wrong. The user for that path is still cvs. I just checked and it worked fine for that path. In each directory of your version 7 you'll find a CVS/Root file that should contain the text: :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7 If they do then just typing cvs diff should work. If it doesn't try cvs login (password is guest) and then cvs diff. If they don't contain that exact text, you will probably need to checkout to a fresh tree and move just the source files (important) from your version 7 tree into the new tree. Then run the diff command. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Curt, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson More work needs to be done, but you should be able to go into your prefernces.xml file and specify the strings-de.xml file instead of the strings-default.xml. Thanks, this works, while it's not quite logical. The line above it states !-- this should not be touched, it defines the default translations strings -- so I'd never touch it ;-) Why not modify the next line to strings include=Translations/strings-de.xml/ which seems more logical to me but, unfortunately, does not dp the job. Anyway, it's a good start. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3dClouds
Finally found a little time to play with the clouds. Curtis has a set of updated files that (hopefully) will align/orient the clouds for your local lat/lon at an elevation of about 3500 feet (~1100 meters) MSL. It has not been tested except on the west coast of the US. We think we have an explanation of why some clouds flash white now and then or turn white when you get close or enter them, but need to run a solution to ground. Stay tuned... Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
