Re: [Flightgear-devel] startup time option
Jim Wilson [EMAIL PROTECTED] wrote: Starting with --start-date-lat=2002:07:01:20:00:00 (default airport), I'm seeing a sudden change in lighting after about a minute or so, This is exactly the behaviour I encounter when for example starting at dusk (in the c310u3a-3d at KHAF this time). When FG starts, the panel is a bit dark (because it's already pretty dark outside) but it still shows a clear gray. After some ten seconds a slightly yellow coloured veil falls over everyting and it remains that way, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: data/Aircraft/T38
To do it I would need to convert it to AC3D and probably change the textures. Cheers Innis David Culp writes If anyone would like to spruce-up the T-38 3D model, he'll be a hero. (wink, wink :) Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Chat via SMS. Simply send 'CHAT' to 1889918. More info at http://ninemsn.com.au/mobilemania/MoChat.asp?blipid=6800 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Manuel Bessler wrote: Could someone with that or a similar book please help out. If you can help with better numbers for the 717-200 flightmodel that would be highly appreciated. Did you see these pages: http://www.bh.com/companions/034074152X/appendices/data-a/table-2/table.htm http://www.bh.com/companions/034074152X/appendices/data-b/table-6/default.htm Erik ___ 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: To do it I would need to convert it to AC3D and probably change the textures. I've already converted it to AC3d format. This version is in CVS now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup time option
Martin Spott wrote: Jim Wilson [EMAIL PROTECTED] wrote: Starting with --start-date-lat=2002:07:01:20:00:00 (default airport), I'm seeing a sudden change in lighting after about a minute or so, This is exactly the behaviour I encounter when for example starting at dusk (in the c310u3a-3d at KHAF this time). When FG starts, the panel is a bit dark (because it's already pretty dark outside) but it still shows a clear gray. After some ten seconds a slightly yellow coloured veil falls over everyting and it remains that way, Just for the record, this behavior was already present before Curt's changes ... Could it be it isn't using the lighting tables until the sun gets repositioned? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup time option
Erik Hofman [EMAIL PROTECTED] wrote: Martin Spott wrote: This is exactly the behaviour I encounter when for example starting at dusk (in the c310u3a-3d at KHAF this time). When FG starts, the panel is a bit dark (because it's already pretty dark outside) but it still shows a clear gray. After some ten seconds a slightly yellow coloured veil falls over everyting and it remains that way, Just for the record, this behavior was already present before Curt's changes ... Could it be it isn't using the lighting tables until the sun gets repositioned? This should be a good explanation. I'll see if it depends on the airport - that should have influence on the intensity of the yellow veil because the sun position is different, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ssgLoadAC error on KEMT + patch
Thomas Arendsen Hein wrote: Hallo! 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. Now I can enjoy hunting Trainer-two-five-charlie again :) Thanks for the catch. I've put a fix in CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] startup time option
Jim Wilson writes: Starting with --start-date-lat=2002:07:01:20:00:00 (default airport), I'm seeing a sudden change in lighting after about a minute or so, attached is the log output. I'm not sure if this is significant, but the actually sky location of the sun graphic doesn't seem to move. Try adding fgUpdateSkyAndLightingParams(); as the last thing before passing control to fgMainLoop() in fgIdleFunction() Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
Martin Spott writes: Norman Vine [EMAIL PROTECTED] wrote: Martin Spott writes: I wonder how long it takes until someone imports the world's SRTM data into GRASS (with a networked database backend like PostGIS). AFAIK lots of people are doing this Do you suggest we should do so too ? Not sure about using GRASS but using a DataBase yes Why don't people share their development work ? Probably because this is a *tough* problem to get right and is very labor intensive even with the best of tools therefore most of the work to date has been commercially driven We would need a database where everyone around the world could be granted write access to a dataset that is kept at one central point (later we might talk about replication or a distributed database), I think we want to start at the other end i.e. several smaller localized databases with local access control Initial decomposition of the World should probably be by Continents since there wouldn't be any edge matching problems. However since edge problems are confined to neighboring tiles a finer grain decomposition should be possible with some coordination Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: help]
Fwd. for list non-member, please include in any replies. Original Message Subject:help Date: Tue, 16 Sep 2003 13:49:30 -0400 From: Dai, Chengbi [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Hi I have the following questions about FlightGear-0.9.2. Could you please help me to post the following information to the development group? The questions are as follows: In FlightGear-0.9.2, the file size of fgfs.exe I download from website is 2,656 KB, but the size of the same file became 46,414 KB when I compiled the source code with the Cygwin compiler under Windows 2000. Could someone tell me how to optimize the compiling process? Could someone tell how to compile the FlightGear source code to the MS Windows binary version with the Cygwin compiler? Thanks for help Chengbi Dai Chengbi Dai E-Mail: [EMAIL PROTECTED] Institute for Aerospace Research National Research Council U-61, 1200 Montreal Road, Ottawa, ON K1A 0R6 Government of Canada -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
Norman Vine [EMAIL PROTECTED] wrote: Martin Spott writes: We would need a database where everyone around the world could be granted write access to a dataset that is kept at one central point (later we might talk about replication or a distributed database), I think we want to start at the other end i.e. several smaller localized databases with local access control Initial decomposition of the World should probably be by Continents since there wouldn't be any edge matching problems. Oh, we already have the tools to do that: Take a copy of the scenery you want to improve and use FGSD to work on it. Copy the stuff to a central repository after tweaking This won't be a long term goal. I was thinking about some mechanism that lets multiple developers (scenery editors) work on one chunk of scenery _without_ re-inventing synchronization mechanisms, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] startup time option
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
Starting with --start-date-lat=2002:07:01:20:00:00 (default airport), I'm
seeing a sudden change in lighting after about a minute or so, attached is the
log output. I'm not sure if this is significant, but the actually sky
location of the sun graphic doesn't seem to move.
Try adding fgUpdateSkyAndLightingParams(); as the last thing before
passing control to fgMainLoop() in fgIdleFunction()
That didn't work. If I add this bit of code right before the fgRenderFrame()
call in the main loop it works.
// PLEASE! This is NOT a patch. Don't add to CVS.
static bool first_time_2=true;
static int countfromstart = 0;
if (first_time_2) {
fgUpdateSkyAndLightingParams();
countfromstart ++;
if (countfromstart 1) first_time_2 = false;
}
This isn't a fix, it is just a clue as to what the problem is. Apparently
looking at the code, if the function is called the _second_ pass through the
main loop then it works.
I'd follow this through myself but I've got to go see a client this morning.
Just want to post this in case it rang a bell for someone.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: help]
Hi I have the following questions about FlightGear-0.9.2. Could you please help me to post the following information to the development group? The questions are as follows: In FlightGear-0.9.2, the file size of fgfs.exe I download from website is 2,656 KB, but the size of the same file became 46,414 KB when I compiled the source code with the Cygwin compiler under Windows 2000. Could someone tell me how to optimize the compiling process? Could someone tell how to compile the FlightGear source code to the MS Windows binary version with the Cygwin compiler? This looks like it is bloated with debug info, and maybe a case of including static libraries where dynamic libraries are available. Try running: strip -s fgfs and could you provide the output of: ldd fgfs Regards, Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ssgLoadAC error on KEMT + patch
On 9/16/03 at 9:47 PM Thomas Arendsen Hein wrote: Hallo! 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. Hi Thomas, Thanks very much for the patch. That fixes the pink plane problem I've been seeing with the AI plane recently. Now I can enjoy hunting Trainer-two-five-charlie again :) Glad someone's using it :-) However, that callsign raises an issue. Firstly, the reg on c172-dpm is N301DP, so I guess it ought to be Trainer-one-delta-papa! Secondly, what happens when we get more than one airport in the base package with AI support (hopefully within a few months), and possibly more than one AI plane per busy GA airport (probably a bit longer - algorithms to stop them taxiing on the same bit of tarmac are non-trivial!!!). They can't all use the same callsign! It should be easy to assign different pseudo-random callsigns in the AI code, but what about the visual model? Is it feasable to have a range of letters and numerals to stick on for the reg as per the runways, or should I forget about this right now? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup time option
Jim Wilson wrote: That didn't work. If I add this bit of code right before the fgRenderFrame() call in the main loop it works. // PLEASE! This is NOT a patch. Don't add to CVS. Pfew, Lucky I read far enough into your message ... :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
Norman Vine [EMAIL PROTECTED] wrote: And I am worried about security issues when we have thousands of users all wanting to update their little piece of the earth :-) I didn't mean that _everyone_ should be able to write to the scenery database (or however we'd call it _if_ it really should happen to be born). I'm thinking about a limited number of scenery editors (?) with write access - similar to people with write access to the CVS repository. Maybe there would be maintainers for certain regions or continents - if necessary. Also as the scenery gets more populated the problem will eventually become intractable with out some division, and not everyone will want or need high res scenery for the entire planet. I would not use highly detailed scenery as a default. I'm thinking of a scenery database as a repository which serves as a data source for the usual terrain build process (not to serve as the run-time scenery itself!). So if people are really interested in using highres scenery they still could build certain parts themselves (and allow further distribution) My idea was evolving from the necessity to manually place handmade objects into the scenery on every rebuild. The same applies to hand crafted terrain optimizations. My approach to standardize the generation of hand optimized scenery would incarnate in a database holding the relevant stuff. While there's always the possibility for someone to submit terrain improvements based on a let's say 1:50.000 map by simply editing the scenery in FGSD and dropping this into his own copy of the relating region I wish to create the ability for a second person to further improve the terrain in a way that it automagically gets included into later scenery builds. Perhaps there will a way to define the resolution of the scenery you'd build from the database. There still should be some discussion wether we would place the whole world into that database and use a 'real' GIS tool or if we simply place a set of parameters into the database reproducing the manual editing on automatic scenery build. Holding the whole world could make things more flexible and we would be defining some standard mechanism for editing. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
Martin Spott writes: I would not use highly detailed scenery as a default. I'm thinking of a scenery database as a repository which serves as a data source for the usual terrain build process (not to serve as the run-time scenery itself!). So if people are really interested in using highres scenery they still could build certain parts themselves (and allow further distribution) Going a slightly different direction with this, the latest scenery build consumes almost 7Gb (up from the previous 4.5Gb) which means it takes me about 11 cd's to fully contain it. It might be interesting to have a low res scenery build with the goal of putting the entire world on a single cd ??? Would there be any interest in something like this? Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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
[Flightgear-devel] Time of day dialog box
I just added a time of day dialog box go the gui under the top level Weather menu. This allows you to set several convenient symbolic times of day such as dusk, dawn, noon, real-clock-time, etc This is handier than I expected it to be ... check out Erik's sky coloring and lighting while you are at it. We may be a bit to dark still at dusk/dawn because currently I can barely see any ground illumination, but maybe other people should take a look and comment as well. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Re: [Terragear-devel] VMAP0 resolution
Curtis L. Olson [EMAIL PROTECTED] wrote: Going a slightly different direction with this, the latest scenery build consumes almost 7Gb (up from the previous 4.5Gb) which means it takes me about 11 cd's to fully contain it. Is the new rebuild already complete ? I'm wondering: bash-2.03$ for i in Scenery-*; do ls $i | wc -l; done 471 485 Are there any files missing ? [...] It might be interesting to have a low res scenery build with the goal of putting the entire world on a single cd ??? Would there be any interest in something like this? Not on my end, but I consider it useful in any way to be able to set the resolution for a scenery build, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Manuel Bessler wrote: Now, if we could use the blender built-in animation tools for creating the fgfs model/animation .xml files, that would be very cool. ;-) Yeah, that would be cool (although I never actually worked with Blender animation tools...). However, many things can change in future in .xml animation/wrapper FG model file and not all the users use Blender for modeling, so the work on such a script could become worthless in a few years. Thanks. But there are a lot of things not right yet. I'll probably redo the fuselage and the esp. the wings. I've started off with a lot of detail, so my model has probably serveral times as much vertices than the 747. I very doubt that. However, if you do encounter large vertex count, try to reduce them somehow. (I have less than 3000 faces in my J-22 and I don't think it look so terrible). How did you do the movable surfaces, eg ailerons or elevators. I made the whole wing as one mesh and plan to try to use boolean ops to split/cut out the movable parts. I'm interested how you did it. Well, I moved that red circled cursor (left click mouse button) in Blender to a desired center of roration position and found out its coordinates. Now you can fit this cursor to vertices also etc. (and personally, I found out the coordinates of this cursor by creating a box and editing her coords then:)). After that, I needed some brain time, to figure out how the objects move (in which direction and how much). That's it. For the gears, I did use 2 hours to calculate mathematilcy the axis around which the strut and tyres will close, but that just didn't work (obviously I mistaked somewhere;(), so I just modeled that on eye (that's why there are slight offsets still visible, like tyre looking through the gear door just when it closes/opens). Oh yes, and I used Kate and vi as text editors in Linux. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Tue, Sep 16, 2003 at 10:02:56PM -0400, David Megginson wrote: Manuel Bessler writes: Sure, if a model flies 'by the numbers' is a good start, but there are other properties that need to be simulated well for a good model, esp. outside of cruise (cruise is probably the simplest part). It's all numbers, of course: it's just that the numbers for the moments, etc., are not as easily available. Yes, exactly. How are these usually derived/calculated/guessed ? All I've found was a formula for approximation in a pdf document on MSFS SDK. I'm not even sure if it was an MS official document. I've reproduced this formula in my 717.xml jsbsim config. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Tue, Sep 16, 2003 at 09:53:50PM -0400, Nick wrote: Manuel, If you find errors in the MSFS let me know. I have a friend who is a developer there, on CFS but he talks to the MSFS guys too. Just for information he is a fully-trained (Kansas Univ.) engineer who used to do aero model development for Boeing. Also a great guy. I used to go to lunch with him once a month before I moved from Seattle to WV. Well, I really don't use MSFS. (and neither do I use Windows). Last time I had MSFS running myself was in the FS 4 days. On a 286 with hercules monochrome graphics :-) But I could never fly/land well back in those days. I was just comparing non-official 717-200 config files for MSFS. Even the best Aero engineer is limited by the simulation engine (MSFS). I myself don't know much about aero stuff, and all I know I've learned while doing the 717-200 for fgfs. learning-by-doing :-) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Wed, Sep 17, 2003 at 10:19:15AM +0200, Erik Hofman wrote: Manuel Bessler wrote: Could someone with that or a similar book please help out. If you can help with better numbers for the 717-200 flightmodel that would be highly appreciated. Did you see these pages: http://www.bh.com/companions/034074152X/appendices/data-a/table-2/table.htm http://www.bh.com/companions/034074152X/appendices/data-b/table-6/default.htm Yep. This is one of my sources for the model. But there are a lot of numbers where I * don't know if/how I could use them * or don't know what they are, eg. Sv/S, 1/4 Chord Sweep Also concerning the thrust issue, I don't know what to use. There's takeoff thrust, climb thrust,... what goes into the jsbsim config ? Or do I need to mess around w/ these numbers to get the right value ? Thanks for helping the blind and clueless :-), Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ssgLoadAC error on KEMT + patch
On Wed, 17 Sep 2003 13:28:56 +0100, David Luff [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On 9/16/03 at 9:47 PM Thomas Arendsen Hein wrote: Thanks very much for the patch. That fixes the pink plane problem I've been seeing with the AI plane recently. Now I can enjoy hunting Trainer-two-five-charlie again :) Glad someone's using it :-) However, that callsign raises an issue. Firstly, the reg on c172-dpm is N301DP, so I guess it ought to be Trainer-one-delta-papa! Secondly, what happens when we get more than one airport in the base package with AI support (hopefully within a few months), and possibly more than one AI plane per busy GA airport (probably a bit longer - algorithms to stop them taxiing on the same bit of tarmac are non-trivial!!!). They can't all use the same callsign! It should be easy to assign different pseudo-random callsigns in the AI code, but what about the visual model? Is it feasable to have a range of letters and numerals to stick on for the reg as per the runways, or should I forget about this right now? ..2 parts: Adding serial/reg/etc number textures to the 3d graphics? ..and _assigning_ these numbers from FG to all, here is all kindsa schemes possible, for one-off like the Spirit of St.Louis and the EAA replica of the same, this is trivial, they have 1 N-number each. ..for the future lot of several 54 plane combat box formations of B-17's, we might wanna generate serial numbers off ip's or somesuch. -- ..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] Re: CVS: data/Aircraft/T38
Ok Eric Have you separated the A/C bits and named them ready for animation and have you redone the texturing. 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. Cheers Innis Erik Hofman writes Innis Cunningham wrote: To do it I would need to convert it to AC3D and probably change the textures. I've already converted it to AC3d format. This version is in CVS now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ 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
[Flightgear-devel] sun angle bug fix
Well I'm not sure exactly what the problem is. To say the least getting into
some of this code isn't very easy.
Here's a patch that forces a single update after the FDM initializes.
Actually I think what this does is just delay the lighting update until the
second frame, since as far as I can tell the FDM isn't updated on the first
pass through MainLoop. It does appear that the FDM update is critical to
getting a good result from fgUpdateSkyAndLightingParams().
If anyone is interested below the patch is a log for two successive calls to
the lighting update one each of during processing of frames 1 and 2. Note
that there is a huge jump in the Sun position between the first and second frame.
Best,
Jim
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.129
diff -u -r1.129 main.cxx
--- main.cxx17 Sep 2003 10:02:36 - 1.129
+++ main.cxx18 Sep 2003 01:23:50 -
@@ -928,6 +928,11 @@
if ( !inited ) {
inited = true;
+
+// following run once after fdm is inited...
+fgUpdateSkyAndLightingParams();
+// above run once after fdm inits
+
}
if ( ! replay_master-getBoolValue() ) {
@@ -1392,7 +1397,6 @@
fgReshape( fgGetInt(/sim/startup/xsize),
fgGetInt(/sim/startup/ysize) );
-fgUpdateSkyAndLightingParams();
}
if ( idle_state == 1000 ) {
Loading tile /usr/src/games/fgfs/Scenery-0.9.2/w010n00/w001n00/2938503
Updating Sun position
Gst = 17.5722
t-cur_time = 1025564412
Sun Geodetic lat = 0.031 Geocentric lat = 0.0364209
sun angle relative to current location = 0.824245
Updating Moon position
t-cur_time = 1025564412
Moon Geodetic lat = 0.433565 Geocentric lat = 0.43101
moon angle relative to current location = 0.996144
Updating light parameters.
Sun angle = 47.2258
ambient = 0.2 diffuse = 0.999277 specular = 0.5 sky = 0.997832
$GPRMC,230013,A,.000,N,0.000,E,000.0,000.0,0107102,0.000,E*40
$GPGGA,230013,.000,N,0.000,E,1,,,00,F*19
$PATLA,115.80,280.0,115.80,280.0,379*59
Error writing to socket: 5500
Error writing data.
load() base search path = /usr/src/games/fgfs/Scenery-0.9.2
Loading tile /usr/src/games/fgfs/Scenery-0.9.2/w010n00/w001n00/2938511
Updating Sun position
Gst = 17.5724
t-cur_time = 1025564413
Sun Geodetic lat = 0.402627 Geocentric lat = 0.400212
sun angle relative to current location = 0.654801
Updating Moon position
t-cur_time = 1025564413
Moon Geodetic lat = -0.0710015 Geocentric lat = -0.0705277
moon angle relative to current location = 2.24961
Updating light parameters.
Sun angle = 37.5174
ambient = 0.2 diffuse = 1 specular = 0.5 sky = 1
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT Satelite Images
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 Thank goodness that the top was blown off of this storm and it is no where as powerful as it once was. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] sun angle bug fix
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();
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
