Re: [Flightgear-devel] Re: CVS: data/Aircraft/T38
Innis Cunningham wrote: Ok Eric Have you separated the A/C bits and named them ready for animation and have you redone the texturing. No. The only reason I created an ac3d file was to animate the heat-cones behind it. The model does have separate aero surfaces and such, but without a name attached to it. If not I have already converted the A/C and named the gear ready for animation.Or I could download the CVS one and work on it. I don't mind, you just will lose the heat-cone animation. If you got something ready, you can sent it to me and I'll put it in CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT Satelite Images
Norman Vine wrote: Awesome view of Hurricane Isabel just touching the East Coast of the US http://rapidfire.sci.gsfc.nasa.gov/gallery/ This evening the outer fringes of the storm were overhead here on Cape Cod 42.3N 71.7W and was as spectacular a sunset as I have ever seen. note center of storm was at 31.1N 73.3W You didn't by any chance take any pictures? Thank goodness that the top was blown off of this storm and it is no where as powerful as it once was. Let's pray this baby isn't going to create the mess she wants us to believe she's going to make. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: data/Aircraft/T38
Erik Hofman writes I don't mind, you just will lose the heat-cone animation. If you got something ready, you can sent it to me and I'll put it in CVS. Erik Ok I will download the animation xml and add the other animations to it might be a few days. By the way what is the difference between the T-38 and the T-5. Cheers Innis _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: data/Aircraft/T38
Innis Cunningham wrote: By the way what is the difference between the T-38 and the T-5. I think you mean the F-5? The T-38 is the trainer version of the F-5. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Joining
I am a programmer living in Sao Paulo (Brazil) and dont have (yet) large experience with OpenGL, now I am reading the *Red Book* and trying to understand the SimGear and FG code. My only experience (indirect) with OpenGL comes from my work with the team of the new Blender Python API. You're not the only Brazilian guy around... welcome! (eu também sou brasileiro, se bem que de Belo Horizonte - MG) As a first topic, I'm starting to work in models for my home airport, *Aeroporto de Congonhas - Sao Paulo - Brazil (SBSP)* (Fly to Brazil! (tm) :-) Cool... who knows, I live very close to Pampulha's airport in Belo Horizonte, I may be inspired by your efforts to do the same... :-) I hope that i can help with something. Sure you can! Welcome aboard! | English isn't my first language, so.. if you couldn't understand something... please ask me | Conte comigo se precisar. Um abraço, Roberto ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: data/Aircraft/T38
On Thu, 18 Sep 2003 11:57:44 +0200, Erik Hofman [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Innis Cunningham wrote: By the way what is the difference between the T-38 and the T-5. I think you mean the F-5? The T-38 is the trainer version of the F-5. ..and the F-5B? ;-) ..the F-5 lights its tail pipes when in a hurry and poos a chute when no longer in a hurry, and carry 2 x 20mm guns in the snout, and missiles, bombs, tanks etc from its hardpoints. -- ..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
[Flightgear-devel] Recent patches
Hi all
Several recent patches that were checked in with the following
log entry
This patch is there to correct a problem that prevent to load static objects when
specifying
a relative fg-root or a different, relative, fg-scenery.
It appears that there is a mix between fg-root, fg-scenery and PLIB's model-dir.
It has been reported on the list that users are not able to see the buildings,
especially those running the win32 builds because they run 'runfgfs.bat' that set
FG_ROOT=./DATA.
appear to break FGFS when running from a different directory
then FG_ROOT.
We operated for a long time without this and I do not understand
what suddenly required this change
i.e. IMHO we do *not* wnat to do this
void FGTileMgr::update_queues()
{
ssgEntity *obj_model =
globals-get_model_lib()-load_model( .,
dm-get_model_path(),
globals-get_props(),
globals-get_sim_time_sec() );
...
}
Can we please back out these changes so as to have a more
flexible system again. If there is a problem with how FGFS is
launched under Windows we can fix it in a better way.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent patches
Norman Vine wrote:
Several recent patches that were checked in with the following
log entry
This patch is there to correct a problem that prevent to load static objects when
specifying
a relative fg-root or a different, relative, fg-scenery.
It appears that there is a mix between fg-root, fg-scenery and PLIB's model-dir.
It has been reported on the list that users are not able to see the buildings,
especially those running the win32 builds because they run 'runfgfs.bat' that set
FG_ROOT=./DATA.
appear to break FGFS when running from a different directory
then FG_ROOT.
We operated for a long time without this and I do not understand
what suddenly required this change
i.e. IMHO we do *not* wnat to do this
void FGTileMgr::update_queues()
{
ssgEntity *obj_model =
globals-get_model_lib()-load_model( .,
dm-get_model_path(),
globals-get_props(),
globals-get_sim_time_sec() );
...
}
Can we please back out these changes so as to have a more
flexible system again. If there is a problem with how FGFS is
launched under Windows we can fix it in a better way.
I am responsible for this patch. I realize now that I did all of my
testing with the current directory set to fg-root.
But the old behaviour was not satisfactory because all that is
said in the log is true.
So give me some hours to check if it can be done correctly
instead of trading a wrong behaviour for another one.
Cheers,
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] sun angle bug fix
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes
Well I'm not sure exactly what the problem is.
Hi Jim.
You just need to add the call to fgUpdateLocalTime()
as below
Cheers
Norman
// $FG_SRC / Time / tmp.cxx
// update sky and lighting parameters
void fgUpdateSkyAndLightingParams() {
fgUpdateLocalTime();
fgUpdateSunPos();
fgUpdateMoonPos();
cur_light_params.Update();
}
Gadds!...ok...then what currently triggers that update so that the values
happen to be correct by the second frame?
BTW can we do something with tmp.cxx? Either create a class for the functions
or move them to main.cxx?
// tmp.cxx -- stuff I don't know what to do with at the moment
//
// Written by Curtis Olson, started July 2000.
//
According to the comment, it is three years old now :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent patches
Frederic BOUVIER wrote:
Norman Vine wrote:
Several recent patches that were checked in with the following
log entry
This patch is there to correct a problem that prevent to load static objects when
specifying
a relative fg-root or a different, relative, fg-scenery.
It appears that there is a mix between fg-root, fg-scenery and PLIB's model-dir.
It has been reported on the list that users are not able to see the buildings,
especially those running the win32 builds because they run 'runfgfs.bat' that set
FG_ROOT=./DATA.
appear to break FGFS when running from a different directory
then FG_ROOT.
We operated for a long time without this and I do not understand
what suddenly required this change
i.e. IMHO we do *not* wnat to do this
void FGTileMgr::update_queues()
{
ssgEntity *obj_model =
globals-get_model_lib()-load_model( .,
dm-get_model_path(),
globals-get_props(),
globals-get_sim_time_sec() );
...
}
Can we please back out these changes so as to have a more
flexible system again. If there is a problem with how FGFS is
launched under Windows we can fix it in a better way.
I am responsible for this patch. I realize now that I did all of my
testing with the current directory set to fg-root.
But the old behaviour was not satisfactory because all that is
said in the log is true.
So give me some hours to check if it can be done correctly
instead of trading a wrong behaviour for another one.
Hmmm. I just redid some testing with a different current directory (c:/)
and an absolute FG_ROOT (d:/flightgear/cvs/fgfsbase) and I don't
see any problem.
Can you tell me what is your exact test case ?
And a dumb question : have you updated and recompiled SimGear ?
Cheers,
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Recent patches
Frederic BOUVIER writes: Hmmm. I just redid some testing with a different current directory (c:/) and an absolute FG_ROOT (d:/flightgear/cvs/fgfsbase) and I don't see any problem. Hmmm how are you launching FGFS Can you tell me what is your exact test case ? Sure - Here are pertinent snippets from the log $ src/Main/fgfs 21 | tee log FlightGear: Version unknown version Built with GNU C++ version 3.3 Scanning command line for: --fg-root= Scanning D:\home\nhv/.fgfsrc for: --fg-root= fg_root = d:/home/nhv/FlightGear Reading global preferences Finished Reading global preferences Unable to detect the language Selecting language: C Reading localized strings from d:/home/nhv/FlightGear/Translations/strings-default.xml Scanning command line for: --aircraft= Scanning D:\home\nhv/.fgfsrc for: --aircraft= No user specified aircraft, using default Reading default aircraft: c172 from d:/home/nhv/FlightGear/Aircraft/c172-set.xml Processing config file: d:/home/nhv/FlightGear/system.fgfsrc Processing config file: D:\home\nhv/.fgfsrc .. load() base search path = d:/home/nhv/FlightGear/Scenery Loading tile d:/home/nhv/FlightGear/Scenery/w130n30/w122n37/958456 Refreshing timestamps for -122.375 37.5625 scheduling needed tiles for -122.358 37.6137 token = OBJECT_BASE name = 958456.btg WARNING: ssgLoadAC: Failed to open './Models/Buildings/cube-apartment.ac' for reading Assertion failed: status == 0, file D:/usr/mingw/include/simgear/threads/SGThread.hxx, line 233 And a dumb question : have you updated and recompiled SimGear ? I hope that 17-Sep-2003 7:11:50p is recent enough GMT +5 AFAICT crash due to not finding cube-apartment.ac because it is an absolute path. note it is there $ ls -l d:/home/nhv/FlightGear/Models/Buildings/cube-apartment.ac -rwxr-xr-x+ 1 admins None 1347 Jul 13 07:04 d:/home/nhv/FlightGear/Models/Buildings/cube-apartment.ac Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Recent patches
Norman Vine wrotes: Frederic BOUVIER writes: And a dumb question : have you updated and recompiled SimGear ? I hope that 17-Sep-2003 7:11:50p is recent enough GMT +5 Hmm.. Checking simgear / scene / model / model.cxx I see a minor differance then what is in the CVS recompiling now with a fresh copy - will post results ASAP Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Recent patches
Norman Vine wrote: Norman Vine writes: Frederic BOUVIER writes: And a dumb question : have you updated and recompiled SimGear ? I hope that 17-Sep-2003 7:11:50p is recent enough GMT +5 Hmm.. Checking simgear / scene / model / model.cxx I see a minor difference then what is in the CVS recompiling now with a fresh copy - will post results ASAP That was it, Don't know why my file was different, as I updated SimGear last night ? Anyway apologies for all the noise things seems fine as they are. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent patches
Norman Vine wrote: Norman Vine wrotes: Frederic BOUVIER writes: And a dumb question : have you updated and recompiled SimGear ? I hope that 17-Sep-2003 7:11:50p is recent enough GMT +5 Hmm.. Checking simgear / scene / model / model.cxx I see a minor differance then what is in the CVS recompiling now with a fresh copy - will post results ASAP It is older than 17-Sep-2003 ( I think model.cxx was modified 13-Sep-2003 ) because, when I rename cube-apartment.ac so that FG can't find it, an absolute path is printed, not a relative one. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linux Hardware
Hi,
Over the course of the last year I've been trying
to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would
support open source programs like FlightGear and OpenGC. All I could find was
Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of
interest in developing stuff for open source software under Linux.
Well, I never followed the herd and was not about
to move over to Windows or FS.
So I sat down and designed an interface board for
the MCP and EFIS as starters.Turns out, the board is somewhat generic in
that it takes rotary enconder data and key scan circuits and along with the
Linux driver stuffs the data into a small file that the application can
read/write.Using the board goeslike this:
The board has a standard parallel port interface (I
wanted to use IEEE1284 EPP but opted for the most common, simplest for the
moment). It will run either on your printer port or any additional parallel port
board (ISA or PCI) you care to install or I've got a custom ISA board with three
programmable ports I used for development and testing.
Installing/using the board is standard
Linux.
Compile the module driver -- source and makefiles
will be provided
Create the device - mknod /dev/mcp u 254
0
Install the modules - insmod mcp.o
Create you application - something like
this
/**
main()
{
:
fd = open( "/dev/mcp", O_RDWR);
int result = read(fd, mesg, sizeof
mcp_data);
// Convert from char string to data
types
memcpy( char * mcp_data, char * mesg,
sizeof mcp_data );
// Now do your application stuff
whatever
::
close(fd);
}
***/
So if you were running a MCP panel the data would
be airspeed, mach, heading, vvi, and altitude. Plus the state of the pushbutton
switches onthe panel which would go to the FMC for the appropriate action
and control of the system autopilot(s) and such. Or you could configure it as a
NAV/RADIO panel and process the data as frequencies. Or
whatever.
The board and driver run in kernel space and use an
interrupt to process changes in the state of the connected panel
I'm still testing the board but getting close to a
decision on moving from a breadboard to a PCB layout. Best guesstimate on cost
is between $100 and $200. ( I have no idea on what the manufacturing costs
beyond the production of the bare PCB look like, as always very dependent on
size of the lot and quantity discounts for parts and amortization of start-up
costs,etc,etc)
Trying to gauge the interest in such an item and
welcome any feedback, questions, etc.
For a look at some of the hardware panelsI
plan to use check out http://www.a-g-t.com
Regards
John W.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] sun angle bug fix
Jim Wilson wrote: Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes Well I'm not sure exactly what the problem is. Hi Jim. You just need to add the call to fgUpdateLocalTime() as below Gadds!...ok...then what currently triggers that update so that the values happen to be correct by the second frame? Both solutions didn't work for me. This might be because I'm running FlightGear at 2-3 fps upon startup. It might be it actually takes quite a number of frames to settle, which obviously takes longer for me. BTW can we do something with tmp.cxx? Either create a class for the functions or move them to main.cxx? // tmp.cxx -- stuff I don't know what to do with at the moment // // Written by Curtis Olson, started July 2000. // According to the comment, it is three years old now :-) For the records, I have rewritten the fgTIME class to force it into a FGSubSystem jacket. I might even go crazy and make it a container class for fgSun and fgMoon functions. After that I hope some stuff has settled down and is starting to behave in a more sane manner. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ssgLoadAC error on KEMT + patch
On Wed, Sep 17, 2003 at 11:45:14AM +0200, Erik Hofman wrote: Thomas Arendsen Hein wrote: When trying to start fgfs --airport=KEMT I get: WARNING: ssgLoadAC: Failed to open '/fg_root/Aircraft/c172/Models/c172-dpm.ac/Aircraft/c172/Models/c172-dpm.ac' for reading with current SimGear/FlightGear CVS. The attached patch fixes the problem, since sgLoad3DModel expects fg_root as the first parameter, not the full path to the model. Thanks for the catch. I've put a fix in CVS. When updating from CVS I got a conflict in AILocalTraffic.cxx, because I removed two obsolete lines in my patch which still are in CVS. The problem is, I forgot to attach my patch! So here is another one which removes these two lines. Thomas -- Email: [EMAIL PROTECTED] (at work: [EMAIL PROTECTED]) http://jtah.de/ Index: src/ATC/AILocalTraffic.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/ATC/AILocalTraffic.cxx,v retrieving revision 1.21 diff -u -r1.21 AILocalTraffic.cxx --- src/ATC/AILocalTraffic.cxx 17 Sep 2003 09:44:37 - 1.21 +++ src/ATC/AILocalTraffic.cxx 18 Sep 2003 21:20:49 - @@ -154,8 +154,6 @@ //cout FGAILocalTraffic.Init(...) called endl; // Hack alert - Hardwired path!! string planepath = Aircraft/c172/Models/c172-dpm.ac; - SGPath path = globals-get_fg_root(); - path.append(planepath); ssgBranch *model = sgLoad3DModel( globals-get_fg_root(), planepath.c_str(), globals-get_props(), ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] sun angle bug fix
Erik Hofman writes: Jim Wilson wrote: Norman Vine [EMAIL PROTECTED] said: Well I'm not sure exactly what the problem is. You just need to add the call to fgUpdateLocalTime() as below Gadds!...ok...then what currently triggers that update so that the values happen to be correct by the second frame? Both solutions didn't work for me. This might be because I'm running FlightGear at 2-3 fps upon startup. It might be it actually takes quite a number of frames to settle, which obviously takes longer for me. You still need to call fgUpdateSkyAndLightingParams() at the end of fgIdleFunction() FYI This is a 'chicken and egg' type situation that fgUpdateSkyAndLightingParms() was introduced to solve years ago by just directly calling all the contributors to the Sky Lighting. Curt's new TOD option just added an extra wrinkle. There shouldn't need to be any 'cach-up' required if all the contributors are forced to update themselves. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Linux Hardware
Title: Message
You
might want to take a look at www.microchip.com who do the PIC
microcontroller. They will usually send free samples. They provide a
great IDE. Also they do a USB chip. I do a bit of PIC development
myself - mostly LCD, MIDI and keyboard interfaces. I've been meaning to
look at the USB chip to see what is envolved in bespoke keyboard on USB
interfaces. I've also been toying with the idea of building my own panels
- probably will end up using a serial bus with IDs for units and then do the
interfacing to the PC using a PIC and USB. We have develop our own boards,
software and housings in house. We have a variety of PIC blowers, CNC and
machining equipment. If you are interested please feel free to email
me. We are based in the SW of the United Kingdom.
Cheers,
Al
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
WojnaroskiSent: 18 September 2003 18:50To:
[EMAIL PROTECTED]; FlightGear developers
discussionsCc: John FingerSubject: [Flightgear-devel]
Linux Hardware
Hi,
Over the course of the last year I've been trying
to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and
would support open source programs like FlightGear and OpenGC. All I could
find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a
lot of interest in developing stuff for open source software under
Linux.
Well, I never followed the herd and was not about
to move over to Windows or FS.
So I sat down and designed an interface board for
the MCP and EFIS as starters.Turns out, the board is somewhat generic in
that it takes rotary enconder data and key scan circuits and along with the
Linux driver stuffs the data into a small file that the application can
read/write.Using the board goeslike this:
The board has a standard parallel port interface
(I wanted to use IEEE1284 EPP but opted for the most common, simplest for the
moment). It will run either on your printer port or any additional parallel
port board (ISA or PCI) you care to install or I've got a custom ISA board
with three programmable ports I used for development and testing.
Installing/using the board is standard
Linux.
Compile the module driver -- source and makefiles
will be provided
Create the device - mknod /dev/mcp u 254
0
Install the modules - insmod
mcp.o
Create you application - something like
this
/**
main()
{
:
fd = open( "/dev/mcp",
O_RDWR);
int result = read(fd, mesg, sizeof
mcp_data);
// Convert from char string to data
types
memcpy( char * mcp_data, char * mesg,
sizeof mcp_data );
// Now do your application stuff
whatever
::
close(fd);
}
***/
So if you were running a MCP panel the data would
be airspeed, mach, heading, vvi, and altitude. Plus the state of the
pushbutton switches onthe panel which would go to the FMC for the
appropriate action and control of the system autopilot(s) and such. Or you
could configure it as a NAV/RADIO panel and process the data as frequencies.
Or whatever.
The board and driver run in kernel space and use
an interrupt to process changes in the state of the connected
panel
I'm still testing the board but getting close to
a decision on moving from a breadboard to a PCB layout. Best guesstimate on
cost is between $100 and $200. ( I have no idea on what the manufacturing
costs beyond the production of the bare PCB look like, as always very
dependent on size of the lot and quantity discounts for parts and amortization
of start-up costs,etc,etc)
Trying to gauge the interest in such an item and
welcome any feedback, questions, etc.
For a look at some of the hardware panelsI
plan to use check out http://www.a-g-t.com
Regards
John W.
---Incoming mail is certified Virus Free.Checked by
AVG anti-virus system (http://www.grisoft.com).Version: 6.0.518 / Virus
Database: 316 - Release Date: 11/09/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/09/2003
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
