Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Cub/Models/Effects exhaustsmoke.png, NONE, 1.1 exhaustsmoke.xml, NONE, 1.1 tyre-smoke-port.xml, NONE, 1.1 tyre-smoke-stbd.xml, NONE, 1.1

[James Turner]

On 12 Apr 2010, at 13:07, Erik Hofman wrote:

 Log Message:
 Replace Devid Megginsons version of the j3cub with the excellent work of 
 karla from the forum. Signed off by David.

Woo-hoo!

This is an awesome model, about to fire it up and take it for a spin.

Thanks to all involved for their hard work, the results speak for themselves 
I'd say.

James

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Cub/Models/Effects exhaustsmoke.png, NONE, 1.1 exhaustsmoke.xml, NONE, 1.1 tyre-smoke-port.xml, NONE, 1.1 tyre-smoke-stbd.xml, NONE, 1.1

[Heiko Schulz]

Hi,
 
 Woo-hoo!
 
 This is an awesome model, about to fire it up and take it
 for a spin.
 
 Thanks to all involved for their hard work, the results
 speak for themselves I'd say.
 
 James

Yes, great little aircraft, very accurate modelled! Now only a PA18 Super Cub 
with the same qualitity missing!
It is fun to fly with!

I'm thinking about to apply our new graphical stuff like a slight reflection 
effect to the glas material and bumpspec to the other parts if I get the 
authors permission.

Would be great we had the versions with floats, skis and tundra-wheels as 
well... 

What I wonder- if David Megginson gave permission- why we have now the same 
aircraft with two different models in CVS? One named j3cub and one named 
Cub.

Do wee need still the old one?

Heiko





__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com 

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p/Models/Liveries

[Martin Spott]

Hi Stuart,

Stuart Buchanan wrote:

 Update of /var/cvs/FlightGear-0.9/data/Aircraft/c172p/Models/Liveries
 In directory baron.flightgear.org:/tmp/cvs-serv9716/Models/Liveries
 
 Modified Files:
fuselage-normal.png tail-normal.png wing-normal.png 
 Log Message:
 Updated normal mapping with better riveting.

The riveting looks quite promising - but in real life it's noticeably
less dominant (please excuse the stupid face on the photo):

  http://foxtrot.mgras.net/bitmap/FGFS/DEEQA-Oelklappe.jpg

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Airport B-1200.ac, 1.2,

[Erik Hofman]

Martin Spott wrote:
 Erik
 
 Erik Hofman wrote:
 Update of /var/cvs/FlightGear-0.9/data/Models/Airport
 In directory baron.flightgear.org:/tmp/cvs-serv32368

 Modified Files:
B-1200.ac BAK-12-0.ac Schopf_F110.ac TowBear_TT.ac 
default01.rgb eddf_lamp_t2.xml radar.ac tacan.ac 
 Log Message:
 fix line endings and remove unneeded translucency
 
 In order to save your changes from getting lost with the next update,
 would you mind sending me a packaged version of the affected models
 (everything including XML and textures in a TAR or ZIP) ?

Ok, I'll try to do so if I get some time.

Erik

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Airport B-1200.ac, 1.2,

[Martin Spott]

Erik

Erik Hofman wrote:
 Update of /var/cvs/FlightGear-0.9/data/Models/Airport
 In directory baron.flightgear.org:/tmp/cvs-serv32368
 
 Modified Files:
B-1200.ac BAK-12-0.ac Schopf_F110.ac TowBear_TT.ac 
default01.rgb eddf_lamp_t2.xml radar.ac tacan.ac 
 Log Message:
 fix line endings and remove unneeded translucency

In order to save your changes from getting lost with the next update,
would you mind sending me a packaged version of the affected models
(everything including XML and textures in a TAR or ZIP) ?

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Autopilot xmlauto.cxx, 1.51, 1.52 xmlauto.hxx, 1.31, 1.32

[James Turner]

On 24 Feb 2010, at 22:15, Torsten Dreyer wrote:

 logic filters use well known conditions to drive output properties. Example 
 for bax = baz  (foo | bar). 

Nice!

Regards,
James


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Autopilot xmlauto.cxx, 1.51, 1.52 xmlauto.hxx, 1.31, 1.32

[leee]

On Thursday 25 Feb 2010, James Turner wrote:
 On 24 Feb 2010, at 22:15, Torsten Dreyer wrote:
  logic filters use well known conditions to drive output
  properties. Example for bax = baz  (foo | bar).

 Nice!

 Regards,
 James

Yes, a very useful addition.

LeeE


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source configure.ac, 1.162, 1.163

[Alan Teeder]

Frederic

Thanks for today's updates to the Windows build.

Flightgear now builds out of the box -  well almost.

The start point was your 3rd party zip file at 
ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/

I had to make an SVN  build of Openscenegraph to get rid of CLEAR_MASK not 
a member of osg.CullSettings errors in CameraGroup.cxx  During this build I 
overwrote the 3rd party file that they supply over yours, and installed the 
new Openscenegraph in your install directory.

My OpenAl and alut have been updated from the Creative site. Because of 
differences in OpenAl and Simgear calling conventions all of the alut and 
Openal includes are repeated in 3rdParty/include and 3rdParty/incude.h

Also I built my own plib, but this was just to eliminate all the missing 
pdb file warnings at Flightgear link time. It was not really necessary.

This is a summary of the changes that I can remember that made to your 3rd 
party distribution. Hopefully these notes cover all of the important steps.

Finally I made up my own file simgear/version.h

The good news is at last we have up-to-date build files in the CVS. It will 
be interesting to hear how others get on.

Good to have you back.

Alan


--
From: Heiko Schulz aeitsch...@yahoo.de
Sent: Sunday, January 17, 2010 3:15 PM
To: FlightGear developers discussions 
flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] [Flightgear-cvslogs] CVS: source 
configure.ac,1.162, 1.163

 Welcome back, Frederic!

 Where have you been so long? :-)


 still in work: http://www.hoerbird.net/galerie.html
 But already done: http://www.hoerbird.net/reisen.html

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz 
 gegen Massenmails.
 http://mail.yahoo.com

 --
 Throughout its 18-year history, RSA Conference consistently attracts the
 world's best and brightest in the field, creating opportunities for 
 Conference
 attendees to learn about information security's most important issues 
 through
 interactions with peers, luminaries and emerging and established 
 companies.
 http://p.sf.net/sfu/rsaconf-dev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel 


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/santa/Models/Effects stardust.xml, NONE, 1.1

[Curtis Olson]

Erik, we may need to discuss Santa theology on the developers list here.
 Are you just making this stuff up?

:-)

Curt.


On Sat, Jan 16, 2010 at 8:37 AM, Erik Hofman
ehof...@baron.flightgear.orgwrote:

 Update of /var/cvs/FlightGear-0.9/data/Aircraft/santa/Models/Effects
 In directory baron.flightgear.org:/tmp/cvs-serv28936/santa/Models/Effects

 Added Files:
stardust.xml
 Log Message:
 add effects

 --- NEW FILE stardust.xml ---
 ?xml version=1.0?
 PropertyList

 particlesystem
  namestardust/name
  texturestar.png/texture
  emissivetrue/emissive
  lightingfalse/lighting

  offsets
   x-m0/x-m
   y-m0/y-m
   z-m0/z-m
  /offsets

  condition
   greater-than-equals
propertyvelocities/airspeed-kt/property
value10/value
   /greater-than-equals
  /condition

  attachworld/attach

  placer
   typepoint/type
  /placer

  shooter
   theta-min-deg-5/theta-min-deg
   theta-max-deg5/theta-max-deg
   phi-min-deg-5/phi-min-deg
   phi-max-deg5/phi-max-deg
   speed-mps
value0/value
spread0/spread
   /speed-mps
   rotation-speed
x-min-deg-sec5/x-min-deg-sec
y-min-deg-sec5/y-min-deg-sec
z-min-deg-sec5/z-min-deg-sec
x-max-deg-sec10/x-max-deg-sec
y-max-deg-sec10/y-max-deg-sec
z-max-deg-sec10/z-max-deg-sec
   /rotation-speed
  /shooter

  counter
   particles-per-sec
propertyvelocities/airspeed-kt/property
factor0.1/factor
spread1/spread
   /particles-per-sec
  /counter

  alignbillboard/align

  particle
   start
color
 red
  value0.6/value
 /red
 green
  value0.8/value
 /green
 blue
  value1/value
 /blue
 alpha
  value0.12/value
 /alpha
/color
size
 value0.8/value
/size
   /start
   end
color
 red
  value0.6/value
 /red
 green
  value0.8/value
 /green
 blue
  value1/value
 /blue
 alpha
  value0.008/value
 /alpha
/color
size
 value8/value
/size
   /end
   life-sec
value5.0/value
   /life-sec
   mass-kg0.1/mass-kg
   radius-m0.015/radius-m
  /particle

  program
   fluidair/fluid
   gravity type=boolfalse/gravity
   wind type=booltrue/wind
  /program

 /particlesystem

 /PropertyList




 --
 Throughout its 18-year history, RSA Conference consistently attracts the
 world's best and brightest in the field, creating opportunities for
 Conference
 attendees to learn about information security's most important issues
 through
 interactions with peers, luminaries and emerging and established companies.
 http://p.sf.net/sfu/rsaconf-dev2dev
 ___
 Flightgear-cvslogs mailing list
 flightgear-cvsl...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-cvslogs




-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/santa/Models/Effects stardust.xml, NONE, 1.1

[Erik Hofman]

Curtis Olson wrote:
 Erik, we may need to discuss Santa theology on the developers list 
 here.  Are you just making this stuff up?
It's true, it's really true! I saw it myself ... once.
I think.

Erik


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_props.cxx, 1.42, 1.43 / Possible cause of crashing FG at exit

[Tatsuhiro Nishioka]

Hi,

I'd always got the crash when SGProp trying to delete /sim/logging/classes. 
So this must be the root cause of the crash (sound manager code is innocent).
Now it quits without weird crash or malloc errors.

Thanks!!

Tat

On Jan 1, 2010, at 2:32 AM, Martin Spott wrote:

 Tim Moore wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv17684/src/Main

 Modified Files:
   fg_props.cxx 
 Log Message:
 Move getLoggingClasses() result buffer to file level.

 Getting it out of the function fixes some corruption problems at program 
 exit.

 Based on a pretty rough check I'd say this fixes the segfault on exit
 for me (Debian Lenny/AMD64),

   Martin.
 -- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
 --

 --
 This SF.Net email is sponsored by the Verizon Developer Community
 Take advantage of Verizon's best-in-class app development support
 A streamlined, 14 day to market process makes app distribution fast and easy
 Join now and get one step closer to millions of Verizon customers
 http://p.sf.net/sfu/verizon-dev2dev 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/HM-14 - New directory

[Martin Spott]

Emmanuel Baranger wrote:

 Update of /var/cvs/FlightGear-0.9/data/Aircraft/HM-14
 In directory baron.flightgear.org:/tmp/cvs-serv28022/HM-14
 
 Log Message:
 Directory /var/cvs/FlightGear-0.9/data/Aircraft/HM-14 added to the repository

Oh yes, _that_ is a nice one !
Folks, forget everything you've learned about STOL capabilities  ;-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_props.cxx, 1.42, 1.43

[Martin Spott]

Tim Moore wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv17684/src/Main
 
 Modified Files:
fg_props.cxx 
 Log Message:
 Move getLoggingClasses() result buffer to file level.
 
 Getting it out of the function fixes some corruption problems at program exit.

Based on a pretty rough check I'd say this fixes the segfault on exit
for me (Debian Lenny/AMD64),

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Navaids navdb.cxx, 1.34,

[Martin Spott]

James Turner wrote:

 Update of /var/cvs/FlightGear-0.9/source/src/Navaids
 In directory baron.flightgear.org:/tmp/cvs-serv28367/src/Navaids
 
 Modified Files:
navdb.cxx navrecord.cxx 
 Log Message:
 Fix for Martin: tolerate runway-associated navaids with a bogus ICAO/runway 
 ident.

Thanks a lot, works as advertized,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Instruments-3d/zkv500 MainScreens.nas, 1.7, 1.8 TaskScreens.nas, 1.3, 1.4 TurnpointScreens.nas, 1.5, 1.6

[James Turner]

On 9 Dec 2009, at 00:25, Sébastien MARQUE wrote:

 I've got an suggestion for the gps code: a command nearest-coord (or 
 better name) which would give nearest navaid for arbitrary coordinates, 
 given by scratch/longitude-deg and scratch/latitude-deg. It will allow 
 to implement a simple navaid-to-navaid flight-plan in a FG session. I 
 tried already months ago, but I can't get it to work properly.

This doesn't even need a new command - I shall just update the code so that if 
you optionally set a valid lat/lon when executing 'nearest', it uses that 
position instead of the current GPS position. I will hopefully get this into 
CVS today.

If it's useful, there's several commands that could be updated to have this 
behaviour.

Regards,
James
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Instruments-3d/zkv500 MainScreens.nas, 1.7, 1.8 TaskScreens.nas, 1.3, 1.4 TurnpointScreens.nas, 1.5, 1.6

[James Turner]

On 8 Dec 2009, at 20:18, Alexis Bory wrote:

 - Sebastien Marque: Turnpoint is managed using OBS mode, the route is still 
 managed by zkv500's Nasal, only obs mode is available 
 (seehttp://wiki.flightgear.org/index.php/GPS_internals). It should be leg 
 mode but I can't get it to work as I expect to.

Sebastien: You could try asking me, instead of working around problems that I 
can (and will!) fix.

James


--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Instruments-3d/zkv500 MainScreens.nas, 1.7, 1.8 TaskScreens.nas, 1.3, 1.4 TurnpointScreens.nas, 1.5, 1.6

[Sébastien MARQUE]

Hi James,

I'm sure this is not a problem with the gps code but only with the 
zkv500 code, because it manages itself the route (it has its own route 
manager), so the gps code just can't use leg as it doesn't know the 
entry point of the leg.

I'm working on it, transferring the route management to the gps code. I 
hope to get a full working zkv500 gps in the next week.

I've got an suggestion for the gps code: a command nearest-coord (or 
better name) which would give nearest navaid for arbitrary coordinates, 
given by scratch/longitude-deg and scratch/latitude-deg. It will allow 
to implement a simple navaid-to-navaid flight-plan in a FG session. I 
tried already months ago, but I can't get it to work properly.

best regards
seb

ps: thanks to Alexis to have committed this patch.

James Turner a écrit :
 On 8 Dec 2009, at 20:18, Alexis Bory wrote:
 
 - Sebastien Marque: Turnpoint is managed using OBS mode, the route is 
 still managed by zkv500's Nasal, only obs mode is available 
 (seehttp://wiki.flightgear.org/index.php/GPS_internals). It should be leg 
 mode but I can't get it to work as I expect to.
 
 Sebastien: You could try asking me, instead of working around problems that I 
 can (and will!) fix.
 
 James
 
 
 --
 Return on Information:
 Google Enterprise Search pays you back
 Get the facts.
 http://p.sf.net/sfu/google-dev2dev
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports runways.cxx, 1.43,

[Martin Spott]

Alex Romosan wrote:
 James Turner j...@baron.flightgear.org writes:
 
 Log Message:
 Fix displaced threshold handling when using in-scenery definitions of 
 runways.
[...]
 i submitted a patch for this a while ago. if you actually add
 _displ_thresh then the aircraft gets positioned at the beginning of the
 runway proper not the threshold. so i think the offset should be:
 
  double offsetFt = (0.5 * _length) + _displ_thresh;

The displaced threshold is relevant for landing, in the sense of don't
touch ground before this line, maybe due to noise abatement measures,
safety or some other reasons.
The take-off run, in contrast, defaults to start at the runway end, no
matter if there is a displaced threshold or not. Note, this is
different from stopways/blastways, which are typically not supposed to
be used neither for startup nor for landing.

Things _might_ be a little bit different in real life. When airliners
are queueing up at the runway end of a large field and you're in a
C172, the contoller might save you from taxiing the entire way and,
instead, request you to enter the runway somewhere beforehand. But as a
default, the displaced threshold does not matter for takeoff.

Cheers,
Martin.
BTW, as I understand, user postings don't belong to the -cvslogs
 mailing list.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Scenery/Objects/w130n30/w123n37

[Martin Spott]

Vivian Meazza wrote:
 Update of /var/cvs/FlightGear-0.9/data/Scenery/Objects/w130n30/w123n37
 In directory baron.flightgear.org:/tmp/cvs-serv13878
 
 Modified Files:
942050.stg 
 Added Files:
KSFO_AirTrain.ac KSFO_DomesticGarage.ac KSFO_GarageA.ac 
KSFO_InternationalTerminal.ac KSFO_InternationalTerminal_1.png 
ksfoairtrain1.png 
 Log Message:
 Add KSFO Airtrain by Gijs de Rooy 

Please note that the 1x2 degree Base Package Scenery chunk is once in a
while going to get ovberwritten by a copy from the Scenemodels
repository. Therefore please submit your changes there.

Thanks,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports runways.cxx, 1.43,

[John Denker]

On 12/05/2009 01:35 PM, Martin Spott wrote:

 The displaced threshold is relevant for landing, in the sense of don't
 touch ground before this line, maybe due to noise abatement measures,
 safety or some other reasons.

Exactly so.

 The take-off run, in contrast, defaults to start at the runway end, no
 matter if there is a displaced threshold or not. 

Agreed.  You are not required to use the full length
of the runway for takeoff, but it is safer to do so.

 Note, this is
 different from stopways/blastways, which are typically not supposed to
 be used neither for startup nor for landing.

Yes.

 Things _might_ be a little bit different in real life. When airliners
 are queueing up at the runway end of a large field and you're in a
 C172, the contoller might save you from taxiing the entire way and,
 instead, request you to enter the runway somewhere beforehand. But as a
 default, the displaced threshold does not matter for takeoff.

The displaced threshold is never relevant for takeoff.
The displaced threshold is the _landing_ threshold.

If you decide to take off using less than full length, 
it would be pure coincidence if the starting point 
coincided with the displaced threshold point.

Any code that computes takeoff position based on the
displaced threshold must be considered a bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main main.cxx, 1.306, 1.307 options.cxx, 1.128, 1.129

[James Turner]

On 30 Nov 2009, at 14:24, Erik Hofman wrote:

 Modified Files:
   main.cxx options.cxx 
 Log Message:
 update to allow selection of a new sound device


Nice work! And the preference / settings changes too - I know this is painful 
work, but it's long overdue and will really help make using FG more pleasant 
for lots of people. 

Incidentally, I am currently cursing Apple's OpenAL implementation, it only 
supports the default input and output devices - despite 'supporting' the 
enumeration extension. I have a patch to iaxclient (as used by fgcom) to allow 
input and output device selection for the openAL backend, but it's completely 
pointless on Mac, without patches to OpenAL itself :(

James


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: docs/getstart/source features.tex, 1.21,

[Martin Spott]

Stuart Buchanan wrote:
 Update of /var/cvs/FlightGear-0.9/docs/getstart/source
 In directory baron.flightgear.org:/tmp/cvs-serv25730
 
 Modified Files:
features.tex 
 Log Message:
 Update Features list:
 - Re-ordering to put MP at the top
 - Updated desrcription of AAR making use of dynamic AAR option.

PDF version at the usual place:

  http://mapserver.flightgear.org/getstart.pdf

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: docs/getstart/source features.tex, 1.21,

[Stuart Buchanan]

Martin Spott wrote:
 Stuart Buchanan wrote:
  Update of /var/cvs/FlightGear-0.9/docs/getstart/source
  In directory baron.flightgear.org:/tmp/cvs-serv25730
  
  Modified Files:
 features.tex 
  Log Message:
  Update Features list:
  - Re-ordering to put MP at the top
  - Updated desrcription of AAR making use of dynamic AAR option.
 
 PDF version at the usual place:
 
   http://mapserver.flightgear.org/getstart.pdf
 
 Martin.

Thanks for generating a new PDF Martin.

I still have a number of other updates to make - including the current menu 
items, so 
there's not much point in checking a new PDF into the data/ tree yet.

-Stuart



  

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p/Nasal action-sim.nas, 1.1, 1.2

[Ron Jensen]

On Sun, 2009-11-22 at 16:06 -0600, James Turner wrote:
 Update of /var/cvs/FlightGear-0.9/data/Aircraft/c172p/Nasal
 In directory baron.flightgear.org:/tmp/cvs-serv24918/Nasal
 
 Modified Files:
   action-sim.nas 
 Log Message:
 Dave Perry: 
 
 This patch adds main gear rotations about the fuselage attach points
 that keep the wheels in contact with the ground as the compression
 increases and decreases.  I also rotated the main fairings and wheels
 4 degrees so the wheel axles are horizontal sitting on the ground.
 The left and right main gear struts, wheels, and fairings were
 adjusted to be mirrored (symetric) in the c172p.ac.  I also increased
 the rpm boundary between the Propeller and Propeller.slow selects. 
 
 
 Index: action-sim.nas
 ===
 RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c172p/Nasal/action-sim.nas,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -u -r1.1 -r1.2
 --- action-sim.nas18 Nov 2009 20:36:13 -  1.1
 +++ action-sim.nas22 Nov 2009 22:06:31 -  1.2
 @@ -43,6 +49,25 @@
  
  var update_actions = func {
  
 +#  Compute compression induced main gear rotations
 +#
 +#  constants
 +   var R_m = 0.919679;
 +   var h0 = 0.63872;
 +   var theta0_rad = 0.803068;
 +   var radTOdeg = 57.295779;
 +
 +#  Right main
 +   var delta_h = dhR_ft.getValue()*12/39.4;
 +   var right_alpha_deg = ( math.acos( (h0 - delta_h)/R_m ) - theta0_rad 
 )*57.295779;
 +
 +#  Left main
 +   var delta_h = dhL_ft.getValue()*12/39.4;
 +   var left_alpha_deg = ( math.acos( (h0 - delta_h)/R_m ) - theta0_rad 
 )*57.295779;
 +   
 +
 +
 +  # outputs
  if ( navLights.getValue() ) {
 instrumentLightFactor.setDoubleValue(1.0);
 #  Used double in case one wants to later add the ability to dim the 
 instrument lights

The relationship between feet and meters is exactly 0.3048 feet per
meter.  Your conversion value of 12/39.4 is approximately 0.30456...  It
would be better to do:

 #  constants
...
   var radTOdeg = 57.295779;
   var ftTOmeter = 0.3048;
...
#  Right main
   var delta_h = dhR_ft.getValue()*ftTOmeter;
   var right_alpha_deg = ( math.acos( (h0 - delta_h)/R_m ) - theta0_rad 
)*radTOdeg;

#  Left main
   var delta_h = dhL_ft.getValue()*ftTOmeter;
   var left_alpha_deg = ( math.acos( (h0 - delta_h)/R_m ) - theta0_rad 
)*radTOdeg;

This is more exact and also avoids two divisions per frame.

Thanks,
Ron



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p/Nasal action-sim.nas, 1.1, 1.2

[Csaba Halász]

On Tue, Nov 24, 2009 at 5:28 PM, Ron Jensen w...@jentronics.com wrote:

 The relationship between feet and meters is exactly 0.3048 feet per
 meter.  Your conversion value of 12/39.4 is approximately 0.30456...  It
 would be better to do:

  #  constants
 ...
   var radTOdeg = 57.295779;
   var ftTOmeter = 0.3048;

Or even better, use the constants already in global.nas, namely R2D and FT2M

-- 
Csaba/Jester

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p/Nasal action-sim.nas, 1.1, 1.2

[dave perry]

Ron Jensen wrote:
 The relationship between feet and meters is exactly 0.3048 feet per
 meter.  Your conversion value of 12/39.4 is approximately 0.30456...  It
 would be better to do:

  #  constants
 ...
var radTOdeg = 57.295779;
var ftTOmeter = 0.3048;
 ...
 #  Right main
var delta_h = dhR_ft.getValue()*ftTOmeter;
var right_alpha_deg = ( math.acos( (h0 - delta_h)/R_m ) - theta0_rad 
 )*radTOdeg;

 #  Left main
var delta_h = dhL_ft.getValue()*ftTOmeter;
var left_alpha_deg = ( math.acos( (h0 - delta_h)/R_m ) - theta0_rad 
 )*radTOdeg;

 This is more exact and also avoids two divisions per frame.

   
Thanks Ron,

All but the exact ftTOmeter value is already in cvs.  I used ooCalc to 
compute 1/.0254 and did not format the cell.  Good catch.  Would someone 
with commit privilege apply this patch?

? Nasal.diff
Index: action-sim.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c172p/Nasal/action-sim.nas,v
retrieving revision 1.4
diff -u -p -r1.4 action-sim.nas
--- action-sim.nas  24 Nov 2009 16:51:47 -  1.4
+++ action-sim.nas  24 Nov 2009 17:20:30 -
@@ -56,7 +56,7 @@ var update_actions = func {
var h0 = 0.63872;
var theta0_rad = 0.803068;
var radTOdeg = 57.295779;
-   var ftTOm = 0.304569;
+   var ftTOm = 0.3048;
 
 #  Right main
var delta_h = dhR_ft.getValue()*ftTOm;


Dave P.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p

[Alex D-HUND]

On Thu, 19 Nov 2009 16:55:42 + (GMT)
Heiko Schulz aeitsch...@yahoo.de wrote:

  One other issue I see with the 3d model and the
  textures.  The way the 
  cuts in the textures is done, one has nearly vertical
  surfaces on each 
  side near the bottom edge of the windshield.  This
  results in severe 
  stretching of the textures on each side below the
  windshield.  This is 
  fairly obvious and needs to be corrected.  This again
  involves a lot of 
  work.  Does the team think we need to fix this for the
  liveries before 
  the next release as this is the default ac?
 
 That would mean a complete new mapping of this part and that the textures and 
 liveries. 
 You woulden't notice it, if there woulden't be ambient shadow- it could be 
 maybe done with simple edtiting the liveries.

Ahoy guys,

I am still working sometimes on the D-ECJB livery and also recognised this 
glitch. And it is possible to make it 'invisible' by editing the livery. See 
screenshot, picture [1].

However, I am not sure if this is the right way to solve this issue. I am 
planning to draw details like the sheeding below the windshield, like the one 
on picture [2], and I am not sure if this will be easy with the current 
mapping. To look at the future, I am not sure if there is any c172p painting 
out there which will make the way into FG *and* uses this part of the aircraft, 
but if so, drawing this would be quite hard. OTHO, redoing all the existing 
liveries will take some effort.

Well, this was 'just to say' and if the decision is just editing the liveries 
I'll adapt this to the other liveries and send them to Heiko(?).

[1] http://fgfs.beggabaur.de/daten/c172p_mapping.jpg
[2] http://ntxac.inside.net/ntxac/N55299/N55299_17.JPG

ciao

PS: replace [some|all] of the I am not sure by a better phrase on your own. 
;-)
-- 
Alex D-HUND f...@beggabaur.de

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p c172p.xml, 1.22, 1.23

[Stuart Buchanan]

James Turner wrote:
 Update of /var/cvs/FlightGear-0.9/data/Aircraft/c172p
 In directory baron.flightgear.org:/tmp/cvs-serv24918
 
 Modified Files:
 c172p.xml 
 Log Message:
 Dave Perry: 
 
 This patch adds main gear rotations about the fuselage attach points that 
 keep 
 the wheels in contact with the ground as the compression increases and 
 decreases.  I also rotated the main fairings and wheels 4 degrees so the 
 wheel 
 axles are horizontal sitting on the ground.  The left and right main gear 
 struts, wheels, and fairings were adjusted to be mirrored (symetric) in the 
 c172p.ac.  I also increased the rpm boundary between the Propeller and 
 Propeller.slow selects. 

Thanks Dave (and James).

Dave, Heiko (and anyone else modifying the 172 right now):

I'm making some minor changes to the XML animations in the cockpit 
right now to add support for mouse scroll wheel to rune instruments, plus some
more detailed in-sim help.

BTW - I added some additional in-sim tutorials for the c172p. If anyone has the 
time to 
run through them and provide feedback, that would be very useful.

-Stuart



  

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p

[dave perry]

Heiko Schulz wrote:
 Hello.

 First thanks for comitting the changes to the c172p.

 For all, I don't see me as main author, just as another one beside the 
 already known, just made a new 3d-model and 3d-panel.

 So thanks for Dave Perry as another contributer for the instruments-lights! 

 I see still issues and this regards still to the alignement of the 3d-modell. 
 It looks o.k. in the air, but on the ground it is not o.k.

 Martin is right, when he says that the real aircraft is tilted standing on 
 the ground at exactly 5 degrees to the back.

 A c172N POH found on the web, say this too, as my drawings I got as well.
 Manual: 
 http://www.redskyventures.org/doc/cessna-poh/C172N-1978-POH-S1to7-scanned.pdf 
  Page 5 for the drawing.

 So the prop is also tilted 5 degrees to the back. 

 The mistake is that I modelled the aircraft standing on the ground, instead 
 in cruising level.
 So the maingear struts has to be compressed when the aircraft is one the 
 ground, which is actually not the case- the mainstruts doesn't compress yet.

 Problem: just changing the pitch in Models/c172p.xml doesnt't made this 
 right. You can easily see that, when you compare the locations of the gears 
 in the fdm with the one in Blender. 

 The most right answer would be to change the orientation of the model in 
 Blender, but this means also to edit the animations and the positions of the 
 instrumentsA lot of work, but then it would be right ( and the ambient 
 colors could be corrected as well)

 I would begin with the work today, but may need help with the mainstruts 
 compression, as this means maybe a bit math...

 Anything against, or maybe even someone who wants to do the whole job? ;-)

 Kind Regards
 Heiko


   
Hello Heiko,

I have another patch ready to submit with xml indents and tabs fixed and 
consolidation of redundant sections as well as alignment of the 
propeller spin axis with the spinner axis.

I believe that the position on the ground should be totally determined 
by the gear compression forces and the mass and cg.  I.e. it will 
correct itself once we implement correct gear compressions.  So don't 
mess with rotating the 3d model.  At least let me try to get it right 
with gear compressions.

One other issue I see with the 3d model and the textures.  The way the 
cuts in the textures is done, one has nearly vertical surfaces on each 
side near the bottom edge of the windshield.  This results in severe 
stretching of the textures on each side below the windshield.  This is 
fairly obvious and needs to be corrected.  This again involves a lot of 
work.  Does the team think we need to fix this for the liveries before 
the next release as this is the default ac?

Regards,
Dave P.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p

[Heiko Schulz]

Hello,

  
 Hello Heiko,
 
 I have another patch ready to submit with xml indents and
 tabs fixed and 
 consolidation of redundant sections as well as alignment of
 the 
 propeller spin axis with the spinner axis.
 
 I believe that the position on the ground should be totally
 determined 
 by the gear compression forces and the mass and cg. 
 I.e. it will 
 correct itself once we implement correct gear
 compressions.  So don't 
 mess with rotating the 3d model.  At least let me try
 to get it right 
 with gear compressions.

O.k. as long this solves this issue completly. 
 
 One other issue I see with the 3d model and the
 textures.  The way the 
 cuts in the textures is done, one has nearly vertical
 surfaces on each 
 side near the bottom edge of the windshield.  This
 results in severe 
 stretching of the textures on each side below the
 windshield.  This is 
 fairly obvious and needs to be corrected.  This again
 involves a lot of 
 work.  Does the team think we need to fix this for the
 liveries before 
 the next release as this is the default ac?

That would mean a complete new mapping of this part and that the textures and 
liveries. 
You woulden't notice it, if there woulden't be ambient shadow- it could be 
maybe done with simple edtiting the liveries.

Regards
Heiko


__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com 

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p

[Ron Jensen]

On Thu, 2009-11-19 at 09:37 -0700, dave perry wrote:

 I believe that the position on the ground should be totally determined 
 by the gear compression forces and the mass and cg.  I.e. it will 
 correct itself once we implement correct gear compressions.  So don't 
 mess with rotating the 3d model.  At least let me try to get it right 
 with gear compressions.

A quick look using JSBSim  standalone shows a pitch (theta) angle of 0.6
degrees using the default loading of a single 180 lb pilot.  

Lowering the nose gear three inches, to z=-23, gives a theta angle of
3.9 degrees.

Adding a 180 lb copilot, two 180 lb passengers and 30 lbs luggage gives
a theta angle of 5.0.

Thanks,
Ron

--- Aircraft/c172p/c172p.xml2009-11-19 11:30:00.0 -0700
+++ Aircraft/c172p/c172p.xml2008-12-14 14:33:47.0 -0700

@@ -96,7 +96,7 @@
 location unit=IN
 x -6.8 /x
 y 0 /y
-z -23 /z
+z -20 /z
 /location
 static_friction 0.8 /static_friction
 dynamic_friction 0.5 /dynamic_friction



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.42, 1.43 viewmgr.hxx, 1.19, 1.20

[Erik Hofman]

Csaba Halász wrote:
 On 5 Nov 2009, at 09:18, Erik Hofman wrote:
 
 John Denker:
 Add a view debugging functions and represent the viewer quats in the
 property tree for debugging.
 
 Unfortunately the debug code is broken and causes segfaults. It is
 tieing temporary char pointers to property nodes. In its current
 incarnation this happens in the function format_rotor in viewmgr.cxx.
 If we wish to have these debug properties I suggest they be published
 as numeric components.

Ok they are now placed as doubles under /sim/current-view/debug instead.

Erik

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.45, 1.46

[Martin Spott]

Hi Erik,

Erik Hofman wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv10148
 
 Modified Files:
viewmgr.cxx 
 Log Message:
 put the debugging quat strings as doubles under /sim/current-view/debug 
 instead.

I suspect that something's missing in this patch:

g++ -O3 -march=opteron -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. 
-I../../src -I../../src/FDM/JSBSim -I/opt/CERTI/include  -I/opt/gnu/include 
-I/usr/local/include -I/opt/FlightGear/include 
-DPKGLIBDIR=\/opt/FlightGear/share/FlightGear\ -g -O2 -I/opt/FlightGear 
-D_REENTRANT -c -o viewmgr.o viewmgr.cxx
viewmgr.cxx: In member function 'virtual void FGViewMgr::bind()':
viewmgr.cxx:224: error: 'getCurrentViewOrientation_w' is not a member of 
'FGViewMgr'
viewmgr.cxx:226: error: 'getCurrentViewOrientation_x' is not a member of 
'FGViewMgr'
viewmgr.cxx:228: error: 'getCurrentViewOrientation_y' is not a member of 
'FGViewMgr'
viewmgr.cxx:230: error: 'getCurrentViewOrientation_z' is not a member of 
'FGViewMgr'
viewmgr.cxx:233: error: 'getCurrentViewOrOffset_w' is not a member of 
'FGViewMgr'
viewmgr.cxx:235: error: 'getCurrentViewOrOffset_x' is not a member of 
'FGViewMgr'
viewmgr.cxx:237: error: 'getCurrentViewOrOffset_y' is not a member of 
'FGViewMgr'
viewmgr.cxx:239: error: 'getCurrentViewOrOffset_z' is not a member of 
'FGViewMgr'
viewmgr.cxx:242: error: 'getCurrentViewFrame_w' is not a member of 'FGViewMgr'
viewmgr.cxx:244: error: 'getCurrentViewFrame_x' is not a member of 'FGViewMgr'
viewmgr.cxx:246: error: 'getCurrentViewFrame_y' is not a member of 'FGViewMgr'
viewmgr.cxx:248: error: 'getCurrentViewFrame_z' is not a member of 'FGViewMgr'
viewmgr.cxx: At global scope:
viewmgr.cxx:811: error: no 'double FGViewMgr::getCurrentViewFrame_w() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:814: error: no 'double FGViewMgr::getCurrentViewFrame_x() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:817: error: no 'double FGViewMgr::getCurrentViewFrame_y() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:820: error: no 'double FGViewMgr::getCurrentViewFrame_z() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:833: error: no 'double FGViewMgr::getCurrentViewOrOffset_w() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:836: error: no 'double FGViewMgr::getCurrentViewOrOffset_x() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:839: error: no 'double FGViewMgr::getCurrentViewOrOffset_y() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:842: error: no 'double FGViewMgr::getCurrentViewOrOffset_z() const' 
member function declared in class 'FGViewMgr'
viewmgr.cxx:873: error: no 'double FGViewMgr::getCurrentViewOrientation_w() 
const' member function declared in class 'FGViewMgr'
viewmgr.cxx:876: error: no 'double FGViewMgr::getCurrentViewOrientation_x() 
const' member function declared in class 'FGViewMgr'
viewmgr.cxx:879: error: no 'double FGViewMgr::getCurrentViewOrientation_y() 
const' member function declared in class 'FGViewMgr'
viewmgr.cxx:882: error: no 'double FGViewMgr::getCurrentViewOrientation_z() 
const' member function declared in class 'FGViewMgr'
make: *** [viewmgr.o] Fehler 1


Regards,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.45, 1.46

[Erik Hofman]

Martin Spott wrote:
 Hi Erik,
 
 Erik Hofman wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv10148

 Modified Files:
viewmgr.cxx 
 Log Message:
 put the debugging quat strings as doubles under /sim/current-view/debug 
 instead.
 
 I suspect that something's missing in this patch:
 
 g++ -O3 -march=opteron -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. 
 -I../../src -I../../src/FDM/JSBSim -I/opt/CERTI/include  -I/opt/gnu/include 
 -I/usr/local/include -I/opt/FlightGear/include 
 -DPKGLIBDIR=\/opt/FlightGear/share/FlightGear\ -g -O2 -I/opt/FlightGear 
 -D_REENTRANT -c -o viewmgr.o viewmgr.cxx
 viewmgr.cxx: In member function 'virtual void FGViewMgr::bind()':
 viewmgr.cxx:224: error: 'getCurrentViewOrientation_w' is not a member of 
 'FGViewMgr'

Indeed. the header file never got committed.
I've fixed that. Thanks.

Erik

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.42, 1.43 viewmgr.hxx, 1.19, 1.20

[John Denker]

On 11/10/2009 06:36 PM, Csaba Halász wrote:
 On 5 Nov 2009, at 09:18, Erik Hofman wrote:
 
 John Denker:
 Add a view debugging functions and represent the viewer quats in the
 property tree for debugging.
 
 Unfortunately the debug code is broken and causes segfaults. It is
 tieing temporary char pointers to property nodes. In its current
 incarnation this happens in the function format_rotor in viewmgr.cxx.
 If we wish to have these debug properties I suggest they be published
 as numeric components.

That's interesting.  

In an earlier version, I did exactly that:  putting the quats
into the property tree as four separate numerical entries.

Before switching to the string representation, I read the
code for the tie functions.  I got the impression the code
was making a clone, i.e. a deep copy.  Apparently this
impression was incorrect.  Sorry.

Having used the feature both ways, I remain of the opinion
that the string representation is easier for the user to
interpret.  Doing this safely via a few static char*s is
easy to do.  Let me work on it.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.42, 1.43 viewmgr.hxx, 1.19, 1.20

[Csaba Halász]

On Wed, Nov 11, 2009 at 2:43 PM, John Denker j...@av8n.com wrote:

 Before switching to the string representation, I read the
 code for the tie functions.  I got the impression the code
 was making a clone, i.e. a deep copy.  Apparently this
 impression was incorrect.  Sorry.

No, the problem isn't with the property tree. You were returning the
c_str() from a string that goes out of scope when the format_rotor
function exits. Thus, the returned pointer will already be invalid
when it gets passed to the tie.

-- 
Csaba/Jester

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.42, 1.43 viewmgr.hxx, 1.19, 1.20

[Erik Hofman]

John Denker wrote:
 Having used the feature both ways, I remain of the opinion
 that the string representation is easier for the user to
 interpret.  Doing this safely via a few static char*s is
 easy to do.  Let me work on it.

To be honest I don't think it's worth the effort, but I wont hold you back.

Erik

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main

[Martin Spott]

Erik Hofman wrote:
 Martin Spott wrote:
 Hi Erik,
 
 Erik Hofman wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv10148

 Modified Files:
viewmgr.cxx 
 Log Message:
 put the debugging quat strings as doubles under /sim/current-view/debug 
 instead.
 
 I suspect that something's missing in this patch:
 
 g++ -O3 -march=opteron -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. 
 -I../../src -I../../src/FDM/JSBSim -I/opt/CERTI/include  -I/opt/gnu/include 
 -I/usr/local/include -I/opt/FlightGear/include 
 -DPKGLIBDIR=\/opt/FlightGear/share/FlightGear\ -g -O2 -I/opt/FlightGear 
 -D_REENTRANT -c -o viewmgr.o viewmgr.cxx
 viewmgr.cxx: In member function 'virtual void FGViewMgr::bind()':
 viewmgr.cxx:224: error: 'getCurrentViewOrientation_w' is not a member of 
 'FGViewMgr'
 
 Indeed. the header file never got committed.
 I've fixed that. Thanks.

Excellent, works as promised,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.42, 1.43 viewmgr.hxx, 1.19, 1.20

[John Denker]

On 11/11/2009 07:10 AM, Erik Hofman wrote:
 John Denker wrote:
 Having used the feature both ways, I remain of the opinion
 that the string representation is easier for the user to
 interpret.  Doing this safely via a few static char*s is
 easy to do.  Let me work on it.
 
 To be honest I don't think it's worth the effort, but I wont hold you back.

Done already:
  http://www.av8n.com/fly/fgfs/quat-no-stack.patch


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main viewmgr.cxx, 1.42, 1.43 viewmgr.hxx, 1.19, 1.20

[Csaba Halász]

On 5 Nov 2009, at 09:18, Erik Hofman wrote:

 John Denker:
 Add a view debugging functions and represent the viewer quats in the
 property tree for debugging.

Unfortunately the debug code is broken and causes segfaults. It is
tieing temporary char pointers to property nodes. In its current
incarnation this happens in the function format_rotor in viewmgr.cxx.
If we wish to have these debug properties I suggest they be published
as numeric components.

-- 
Csaba/Jester

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Sound fg_fx.cxx, 1.43, 1.44 fg_fx.hxx, 1.23, 1.24

[James Turner]

On 9 Nov 2009, at 10:29, Erik Hofman wrote:

 allow sound effects in the configuration file to be added to the  
 'avionics' sample group by setting 'typeavionics/type'.

Awesome stuff, this is such a good step towards better sound handling.

James

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Maritime/Military

[Tom P]

Hi Martin, Vivian  team

This is an honest question, trying to understand the direction where we can
evolve FG.

Currently the models in data/Models seem to serve two purposes, and I'm
wondering if they can be divided (kept in different repositories) based on
the purpose?

1) static objects populating the scenery, are bound to a fixed location
(buildings, structures, ...).
  Samples are contained in these directories:
  - Agriculture
  - Airport
  - Boundaries
  - Bridges
  - Buildings
  ...

2) Models for vehicles, ships, *crafts and anything movable:
  - Aircraft
  - Maritime/Civilian  (with a few exceptions)
  - Maritime/Military
  - Transport (with a few exceptions)

The fact that this last group is placed statically is, forgive my
simplification, an accident of history.
Any of these could be under AI or user control, and could be added
dynamically to the scenery (any scenery, within certain constraints).

So, in other words, would it make sense to split the location where we keep
the models based on the criteria whether the model is:
- truly static (buildings / structures / ...),
  http://scenemodels.flightgear.org/modelbrowser.php
- or movable (vehicles / crafts / ships)
  http://cvs.flightgear.org/viewvc/data/Models/

The dream is to have all the movable ones under AI or user control one day.

Thanks,

  Tom


On Fri, Oct 30, 2009 at 9:07 AM, Martin Spott martin.sp...@mgras.netwrote:

 Vivian Meazza wrote:
  Update of /var/cvs/FlightGear-0.9/data/Models/Maritime/Military
  In directory baron.flightgear.org:/tmp/cvs-serv17265
 
  Modified Files:
 OliverPerryFFG.ac
  Log Message:
  Rotate to standard FG orientation

 Please see 'data/Models/00README.CONTRIBUTE':

 The following classes of static geometries and therefore the corresponding
 subdirectories are being maintained via the FlightGear Scenery Model
 Repository (http://scenemodels.flightgear.org/models.php) [...]

 It's getting obvious to me, that friendly reminders are silently being
 ignored. Why do you think did we put this README file there 
 In consequence, it seems like we have to be a bit more verbose:

 If you commit directly to CVS, then you're putting your change at risk
 of getting overwritten the next time we're syncing the Scenemodels
 repository to CVS.

 Thanks for listening,

Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --


 --
 Come build with us! The BlackBerry(R) Developer Conference in SF, CA
 is the only developer event you need to attend this year. Jumpstart your
 developing skills, take BlackBerry mobile applications to market and stay
 ahead of the curve. Join us from November 9 - 12, 2009. Register now!
 http://p.sf.net/sfu/devconference
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Maritime/Military

[Curtis Olson]

On Thu, Nov 5, 2009 at 6:52 PM, Tom P wrote:

 Hi Martin, Vivian  team

 This is an honest question, trying to understand the direction where we can
 evolve FG.

 Currently the models in data/Models seem to serve two purposes, and I'm
 wondering if they can be divided (kept in different repositories) based on
 the purpose?

 1) static objects populating the scenery, are bound to a fixed location
 (buildings, structures, ...).
   Samples are contained in these directories:
   - Agriculture
   - Airport
   - Boundaries
   - Bridges
   - Buildings
   ...

 2) Models for vehicles, ships, *crafts and anything movable:
   - Aircraft
   - Maritime/Civilian  (with a few exceptions)
   - Maritime/Military
   - Transport (with a few exceptions)

 The fact that this last group is placed statically is, forgive my
 simplification, an accident of history.
 Any of these could be under AI or user control, and could be added
 dynamically to the scenery (any scenery, within certain constraints).

 So, in other words, would it make sense to split the location where we keep
 the models based on the criteria whether the model is:
 - truly static (buildings / structures / ...),
   http://scenemodels.flightgear.org/modelbrowser.php
 - or movable (vehicles / crafts / ships)
   http://cvs.flightgear.org/viewvc/data/Models/

 The dream is to have all the movable ones under AI or user control one day.


This may sound a little strange, but there's really nothing different about
'static' models such as buildings or radio towers or smoke stacks that would
prevent them from moving around ... other than it doesn't make a lot of
conceptual sense to do that.  But there's nothing in how a model is created,
represented, etc. that limits it to non-movable versus movable.

Also in either case (movable vs. non-movable) an object could have animation
components.  For instance a wind turbine with blades that spin and turn into
the wind, a lift bridge, an airport beacon with light beams that spin at
night, a smoke stack that emits smoke, etc.

So it may be worth discussion an organizational structure that separates
object into likely function or usage, but as far as I know, there's nothing
inherent in how the model is defined and represented that would force it
into one category or the other ... other than if I see buildings chasing
each other around I'd probably think that was a little weird.

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/ZLT-NT/Engines

[Anders Gidenstam]

On Mon, 2 Nov 2009, Martin Spott wrote:

 Vivian Meazza wrote:
 [-- text/plain, Encoding 7bit, Zeichensatz: ISO-8859-1, 254 Zeilen --]

 Update of /var/cvs/FlightGear-0.9/data/Aircraft/ZLT-NT/Engines
 In directory baron.flightgear.org:/tmp/cvs-serv11954

 Modified Files:
engIO360C.xml propHO-V373-D.xml
 Log Message:
 Update by Anders Gidenstam
 [...]
   maxhp   180.0  /maxhp

 Doesn't the four cylinder IO-360 typically develop at least 200 HP ?

According to the FAA type certificate for the Zeppelin NT the engines are
of the type IO-360-C1G6. The Lycoming IO-360 line is further described in
TCDS 1E10, but I must admit that I have problems sorting out which 
information belongs to what engine variant in that document.

Up until this update I had only used the IO-360C config from JSBSim as is
and power is one of the settings I didn't change.

In this wikipedia article it seems somebody has managed to read TCDS 1E10 
http://en.wikipedia.org/wiki/List_of_Lycoming_O-360_variants
and states 200hp for the C1G6. It might be worth trying this higher 
setting in FG. In particular as the NT currently falls a few knots short 
of Vne :) (though one has to realize that both drag and propeller 
performance are guesstimated.)

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[James Turner]

On 31 Oct 2009, at 15:10, Ron Jensen wrote:

 Starting with fgfs --disable-real-weather-fetch --timeofday=noon 

 Also reported on IRC by stuart, MyName, pab...

And me.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Tim Moore]

On 11/01/2009 12:28 PM, James Turner wrote:
 
 On 31 Oct 2009, at 15:10, Ron Jensen wrote:
 
 Starting with fgfs --disable-real-weather-fetch --timeofday=noon 

 Also reported on IRC by stuart, MyName, pab...
 
 And me.
I believe this is fixed now; let me know if not.

Tim

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Durk Talsma]

Hi Tim,

On Sunday 01 November 2009 09:08:35 pm Tim Moore wrote:
 I believe this is fixed now; let me know if not.


Works for me. (And the moon is still correctly illuminated).

Cheers,
Durk

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/ZLT-NT/Engines

[Martin Spott]

Vivian Meazza wrote:
 [-- text/plain, Encoding 7bit, Zeichensatz: ISO-8859-1, 254 Zeilen --]
 
 Update of /var/cvs/FlightGear-0.9/data/Aircraft/ZLT-NT/Engines
 In directory baron.flightgear.org:/tmp/cvs-serv11954
 
 Modified Files:
engIO360C.xml propHO-V373-D.xml 
 Log Message:
 Update by Anders Gidenstam
[...]
   maxhp   180.0  /maxhp

Doesn't the four cylinder IO-360 typically develop at least 200 HP ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/ZLT-NT/Engines

[Ron Jensen]

On Mon, 2009-11-02 at 00:01 +, Martin Spott wrote:
 Vivian Meazza wrote:
  [-- text/plain, Encoding 7bit, Zeichensatz: ISO-8859-1, 254 Zeilen --]
  
  Update of /var/cvs/FlightGear-0.9/data/Aircraft/ZLT-NT/Engines
  In directory baron.flightgear.org:/tmp/cvs-serv11954
  
  Modified Files:
 engIO360C.xml propHO-V373-D.xml 
  Log Message:
  Update by Anders Gidenstam
 [...]
maxhp   180.0  /maxhp
 
 Doesn't the four cylinder IO-360 typically develop at least 200 HP ?
 
   Martin.

http://www.lycoming.com/engines/series/pdfs/360ci%20Engine%20Insert.pdf

While 200 hp is the top end of the 360 hp line (only the Turbocharged
TIO-360-C manages better at 210 hp), and the average rate horsepower is
180, the IO-360-C (which the file name implies this is) should be 200
hp.  Looking at the CVS history of this engine it appears it has been as
low as 160 and as high as 210 as people discuss the proper power for its
use in the c172p...  As to the Zepplin-NT, they don't give us an exact
model number but it appears to be slightly derated what ever version it
is http://www.zeppelinflug.de/seiten/E/zeppnt_techn.htm they list 145 kW
or 197 hp.


Ron





--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Tim Moore]

On 10/31/2009 04:58 AM, Ron Jensen wrote:
 On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv5452/src/Main

 Modified Files:
  fg_os_osgviewer.cxx renderer.cxx 
 Log Message:
 fix moon lighting at night

 This hasn't worked since the OSG port was initially checked in. A real
 phase-of-the-moon bug!


 Author: Tim Moore timoore@().com
 
 Tim, Did you get all this patch?  It seems to have made all the models
 black unless they have emissive materials...
 
 Thanks,
 Ron
 

I'm not seeing that here, obviously. How / where are you seeing this?

Tim

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Tim Moore]

On 10/31/2009 08:34 AM, Tim Moore wrote:
 On 10/31/2009 04:58 AM, Ron Jensen wrote:
 On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv5452/src/Main

 Modified Files:
 fg_os_osgviewer.cxx renderer.cxx 
 Log Message:
 fix moon lighting at night

 This hasn't worked since the OSG port was initially checked in. A real
 phase-of-the-moon bug!


 Author: Tim Moore timoore@().com

 Tim, Did you get all this patch?  It seems to have made all the models
 black unless they have emissive materials...

 Thanks,
 Ron


 I'm not seeing that here, obviously. How / where are you seeing this?
 
 Tim
A quick thing to try is to revert the one-line change in 
src/Main/fg_os_osgviewer.cxx.

Tim

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Ron Jensen]

On Sat, 2009-10-31 at 09:04 +0100, Tim Moore wrote:
 On 10/31/2009 08:34 AM, Tim Moore wrote:
  On 10/31/2009 04:58 AM, Ron Jensen wrote:
  On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote:
  Update of /var/cvs/FlightGear-0.9/source/src/Main
  In directory baron.flightgear.org:/tmp/cvs-serv5452/src/Main
 
  Modified Files:
fg_os_osgviewer.cxx renderer.cxx 
  Log Message:
  fix moon lighting at night
 
  This hasn't worked since the OSG port was initially checked in. A real
  phase-of-the-moon bug!
 
 
  Author: Tim Moore timoore@().com
 
  Tim, Did you get all this patch?  It seems to have made all the models
  black unless they have emissive materials...
 
  Thanks,
  Ron
 
 
  I'm not seeing that here, obviously. How / where are you seeing this?
  
  Tim
 A quick thing to try is to revert the one-line change in 
 src/Main/fg_os_osgviewer.cxx.
 
 Tim
 

Tim,

Its good in fgfs --fgviewer ...
Its bad in plane fgfs.  Reverting renderer.cxx fixed the problem.
Reverting fg_os_osgviewer.cxx while leaving renderer.cxx current also
solves the issue.

Ron


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Ron Jensen]

On Sat, 2009-10-31 at 08:34 +0100, Tim Moore wrote:
 On 10/31/2009 04:58 AM, Ron Jensen wrote:
  On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote:
  Update of /var/cvs/FlightGear-0.9/source/src/Main
  In directory baron.flightgear.org:/tmp/cvs-serv5452/src/Main
 
  Modified Files:
   fg_os_osgviewer.cxx renderer.cxx 
  Log Message:
  fix moon lighting at night
 
  This hasn't worked since the OSG port was initially checked in. A
 real
  phase-of-the-moon bug!
 
 
  Author: Tim Moore timoore@().com
  
  Tim, Did you get all this patch?  It seems to have made all the
 models
  black unless they have emissive materials...
  
  Thanks,
  Ron
  
 
 I'm not seeing that here, obviously. How / where are you seeing this?
 
 Tim
 

Starting with fgfs --disable-real-weather-fetch --timeofday=noon 

Also reported on IRC by stuart, MyName, pab...

Ron



--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Maritime/Military

[Martin Spott]

Vivian Meazza wrote:
 Update of /var/cvs/FlightGear-0.9/data/Models/Maritime/Military
 In directory baron.flightgear.org:/tmp/cvs-serv17265
 
 Modified Files:
OliverPerryFFG.ac 
 Log Message:
 Rotate to standard FG orientation

Please see 'data/Models/00README.CONTRIBUTE':

The following classes of static geometries and therefore the corresponding
subdirectories are being maintained via the FlightGear Scenery Model
Repository (http://scenemodels.flightgear.org/models.php) [...]

It's getting obvious to me, that friendly reminders are silently being
ignored. Why do you think did we put this README file there 
In consequence, it seems like we have to be a bit more verbose:

If you commit directly to CVS, then you're putting your change at risk
of getting overwritten the next time we're syncing the Scenemodels
repository to CVS.

Thanks for listening,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main fg_os_osgviewer.cxx, 1.28, 1.29 renderer.cxx, 1.127, 1.128

[Ron Jensen]

On Fri, 2009-10-30 at 18:15 -0500, Tim Moore wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Main
 In directory baron.flightgear.org:/tmp/cvs-serv5452/src/Main
 
 Modified Files:
   fg_os_osgviewer.cxx renderer.cxx 
 Log Message:
 fix moon lighting at night
 
 This hasn't worked since the OSG port was initially checked in. A real
 phase-of-the-moon bug!
 
 
 Author: Tim Moore timoore@().com

Tim, Did you get all this patch?  It seems to have made all the models
black unless they have emissive materials...

Thanks,
Ron




--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/ATCDCL AIPlane.cxx, 1.8, 1.9

[James Turner]

On 22 Oct 2009, at 13:54, Erik Hofman wrote:

 -std::auto_ptrunsigned char ptr( buf.c_str() );
 +std::auto_ptrunsigned char ptr( (unsigned char*) 
 buf.c_str() );

This still looks wrong to me - you can't create an auto_ptr from  
buf.c_str(), it will delete memory that's not supposed to be deleted.

To make this safe, fundamentally you need to allocate a buffer, copy  
buf.c_str() into it, and pass that buffer in via the auto_ptr. There  
is no way (that I can see) that this code can ever be safe, without  
using a copy to turn the temporary data from c_str() into something  
that lives on the heap.

Regards,
James


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/ATCDCL AIPlane.cxx, 1.8, 1.9

[James Turner]

On 22 Oct 2009, at 17:23, James Turner wrote:

  without
 using a copy to turn the temporary data from c_str() into something
 that lives on the heap.

This is factually wrong, I realise - of course the data returned by  
c_str() *does* live on the heap, but that does't change the original  
issue that you shouldn't delete or free it; std::string owns the  
buffer and will clean it up if necessary - for example, the next time  
a non-const method is called on the original string.



--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/ATCDCL AIPlane.cxx, 1.8, 1.9

[Erik Hofman]

James Turner wrote:
 On 22 Oct 2009, at 17:23, James Turner wrote:
 
  without
 using a copy to turn the temporary data from c_str() into something
 that lives on the heap.
 
 This is factually wrong, I realise - of course the data returned by  
 c_str() *does* live on the heap, but that does't change the original  
 issue that you shouldn't delete or free it; std::string owns the  
 buffer and will clean it up if necessary - for example, the next time  
 a non-const method is called on the original string.

I dislike the method of using strings to story binary data anyhow.
I've also found other reasons not to use auto_ptr.

Erik

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/ATCDCL AIPlane.cxx, 1.8, 1.9

[James Turner]

On 22 Oct 2009, at 17:50, Erik Hofman wrote:

 I dislike the method of using strings to story binary data anyhow.

Yes, agreed 100%.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation instrument_mgr.cxx, 1.40, 1.41 instrument_mgr.hxx, 1.6, 1.7

[James Turner]

On 14 Oct 2009, at 21:37, Roy Vegard Ovesen wrote:

 What if I really, really, really don't want a GPS? :-)

 But seriously, why must every aircraft have a GPS?

The problem here is the name. Don't think of it as 'GPS', think of it  
as 'lazy default navigation aid for people who are not concerned with  
realism'.

The route manager used to fit the above description, but that makes my  
'realistic' GPS work a pain. So what I've done is make the generic GPS  
mandatory at the C++ level. If you don't want GPS, you won't even  
notice - unless you look at the properties in the inspector, or open  
up the GPS dialog in the Equipment menu.

(I might also change the code to *not* create the GPS if /sim/realism/ 
simple-gps is false - but with a beta release coming up, I want to do  
the least surprising thing - and people have already complained about  
not being able to navigate arbitrary aircraft using the Route Manager  
or GPS)

Regards,
James


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation instrument_mgr.cxx, 1.40, 1.41 instrument_mgr.hxx, 1.6, 1.7

[James Turner]

On 14 Oct 2009, at 22:37, Pete Morgan wrote:

 I cannot see tcan on a civil aircraft, however its there on the nav
 display F12 with no purpose ?? confusing ??

I just realised, with my GUI-dialogs-selective-widget-visiblity fix of  
a few weeks back, I can update the default radios dialog to hide  
sections relating to instruments that aren't defined. So if there's no  
TACAN in the aircraft, that section won't appear.

I'll knock that up when I have a spare moment, and see how well /  
badly it works.

Regards,
James


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation instrument_mgr.cxx, 1.40, 1.41 instrument_mgr.hxx, 1.6, 1.7

[Pete Morgan]

Roy Vegard Ovesen wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Instrumentation
 In directory baron.flightgear.org:/tmp/cvs-serv24388/src/Instrumentation

 Modified Files:
 instrument_mgr.cxx instrument_mgr.hxx
 Log Message:
 Ensure we always create a GPS instrument.
 

 What if I really, really, really don't want a GPS? :-)

 But seriously, why must every aircraft have a GPS?

   
I definately dont want GPS.. I am trying to train myself with NBD and 
DME/VOR..

I cannot see tcan on a civil aircraft, however its there on the nav 
display F12 with no purpose ?? confusing ??

this is back to autopilot..

pete



--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Environment atmosphere.cxx, 1.3 , 1.4 atmosphere.hxx, 1.3, 1.4 enviro nment.cxx, 1.27, 1.28 environment.hxx , 1.11, 1.12

[Torsten Dreyer]

Hi John,

I just fixed what appeared to me as a bug:
mixing altitude_ft and altitude_m and wrong sign when computing temperature at 
sea level from temperature at altitude. 
Can you check and confirm that this is correct and reflects your original 
intention?

Thanks, Torsten

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Environment atmosphere.cxx, 1.3, 1.4 atmosphere.hxx, 1.3, 1.4 environment.cxx, 1.27, 1.28 environment.hxx, 1.11, 1.12

[John Denker]

On 09/20/09 08:52, Torsten Dreyer wrote:
 Hi John,
 
 I just fixed what appeared to me as a bug:
 mixing altitude_ft and altitude_m and wrong sign when computing temperature 
 at 
 sea level from temperature at altitude. 
 Can you check and confirm that this is correct and reflects your original 
 intention?

I'm not in a position to check it at the moment.

I'm happy to take your word for it.  If the fix
looks right to you, go for it.

My code adheres to the convention that says the 
lapse is a positive number in the troposphere.  
Note the minus sign:

d(temp)/d(height) = - lambda

The opposite convention is encountered often enough
to cause all sorts of confusion.

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Environment atmosphere.cxx, 1.3, 1.4 atmosphere.hxx, 1.3, 1.4 environment.cxx, 1.27, 1.28 environment.hxx, 1.11, 1.12

[Ron Jensen]

On Sat, 2009-09-12 at 10:21 -0500, Tim Moore wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Environment
 In directory baron.flightgear.org:/tmp/cvs-serv2733/src/Environment
 
 Modified Files:
   atmosphere.cxx atmosphere.hxx environment.cxx environment.hxx 
 Log Message:
 Merge branch 'topic/atmos-merge' into next
 
 John Denker's atmosphere changes. Original commit message:
 Two-parameter physics-based model of atmosphere up to 262,467 ft i.e.
 the top of the mesosphere. Correctly exhibits the HALT phenomenon.


Index: environment.cxx
629 : curt 1.1 FGEnvironment::_recalc_sl_temperature ()
630 : {

(...)

639 : timoore 1.28 if (elevation_ft = ISA_def[1].height) { 
640 : SG_LOG(SG_GENERAL, SG_ALERT, recalc_sl_temperature:  
641 :  valid only in troposphere, not   elevation_ft);
642 : return;


Quick question.  The old code would silently ignore updating the sea
level temperature if we were above 28000 ft.  This code seems to want to
spit gratuitous error messages if we get above whatever altitude
ISA_def[1].height represents. 

Is calling  _recalc_sl_temperature () above some vaguely defined
altitude an error that deserves to be an SG_ALERT?

Thanks,
Ron



--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Environment atmosphere.cxx, 1.3, 1.4 atmosphere.hxx, 1.3, 1.4 environment.cxx, 1.27, 1.28 environment.hxx, 1.11, 1.12

[John Denker]

On 09/13/09 19:22, Ron Jensen wrote:

 639 : timoore 1.28 if (elevation_ft = ISA_def[1].height) { 
 640 : SG_LOG(SG_GENERAL, SG_ALERT, recalc_sl_temperature:  
 641 :  valid only in troposphere, not   elevation_ft);
 642 : return;
 
 
 Quick question.  The old code would silently ignore updating the sea
 level temperature if we were above 28000 ft.  This code seems to want to
 spit gratuitous error messages if we get above whatever altitude
 ISA_def[1].height represents. 

1) As the message indicates, the altitude in question
is the top of the troposphere.  The layer numbers and
names are documented near the top of
  http://www.av8n.com/physics/altimetry.htm

I suppose the code would be improved by
  const int tropopause(1);
  ...
  if (elevation_ft = ISA_def[tropopause].height)


2) How sure are you that the error message is gratuitous?

 Is calling  _recalc_sl_temperature () above some vaguely defined
 altitude an error that deserves to be an SG_ALERT?

IMHO, yes.

It seems to me that it really is an error to call
_recalc_sl_temperature with a wildly out-of-range parameter.
Outside the troposphere the semantics of such a call is 
undefined and undefinable.  Perhaps it would be constructive
to figure out what routine is making this call, and figure 
out why it is doing something that doesn't make sense.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports runways.cxx, 1.40, 1.41

[James Turner]

On 29 Aug 2009, at 14:24, Torsten Dreyer wrote:

 Modified Files:
   runways.cxx
 Log Message:
 missing declaration of SGPropertyNode

Cheers Torsten - really odd that it built fine for me.

James


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/ec135 ReadMeFirst, 1.3, 1.4

[Martin Spott]

Martin Spott wrote:

 -Actual Version v.0.4
 +Actual version v0.5
 +---
 +-photorealistic cockpit in progress
 +-more realistic fdm
[...]

Arrrgh, 'patch' failed with a return code of 0 
I'll fix this,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs]

[Martin Spott]

Jon Stockill wrote:
 Martin Spott wrote:
 Vivian Meazza wrote:
 Update of /var/cvs/FlightGear-0.9/data/Models/Airport
 In directory baron.flightgear.org:/tmp/cvs-serv26998

 Added Files:
BAK-12-0.ac BAK12.xml 
 Log Message:
 Add runway arrester gear type BAK-12. Based on Dave Culp's original work
 
 Just as a reminder, as written in the 00README.CONTRIBUTE file:
 
 It's already there :-)

Isn't that a duplicate of this one:

  http://scenemodels.flightgear.org/modeledit.php?id=918

  which had been in CVS for several months ?
Two models with the same type name - is there any difference ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs]

[Jon Stockill]

Martin Spott wrote:

 Isn't that a duplicate of this one:
 
   http://scenemodels.flightgear.org/modeledit.php?id=918
 
   which had been in CVS for several months ?
 Two models with the same type name - is there any difference ?

Yes - the new one actually works as an arrester system, rather than just 
being inactive scenery. I'll update any instances of the old one to use 
the new model, and then remove the old version.

Jon

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Airport BAK-12-0.ac, NONE,

[Martin Spott]

Vivian Meazza wrote:
 Update of /var/cvs/FlightGear-0.9/data/Models/Airport
 In directory baron.flightgear.org:/tmp/cvs-serv26998
 
 Added Files:
BAK-12-0.ac BAK12.xml 
 Log Message:
 Add runway arrester gear type BAK-12. Based on Dave Culp's original work

Just as a reminder, as written in the 00README.CONTRIBUTE file:

The following classes of static geometries and therefore the corresponding
subdirectories are being maintained via the FlightGear Scenery Model
Repository (http://scenemodels.flightgear.org/models.php):

  Agriculture/
  Aircraft/
  Airport/
[...]


Thus, whenever you put a model into one of these directories, you're
putting it at risk of getting overwritten without notice if you don't
submit to the Scenemodels repository.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Models/Airport BAK-12-0.ac, NONE,

[Jon Stockill]

Martin Spott wrote:
 Vivian Meazza wrote:
 Update of /var/cvs/FlightGear-0.9/data/Models/Airport
 In directory baron.flightgear.org:/tmp/cvs-serv26998

 Added Files:
BAK-12-0.ac BAK12.xml 
 Log Message:
 Add runway arrester gear type BAK-12. Based on Dave Culp's original work
 
 Just as a reminder, as written in the 00README.CONTRIBUTE file:

It's already there :-)

Jon


--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS:data/Models/Airport BAK-12-0.ac, NONE,

[Vivian Meazza]

Martin Spott

 
 Vivian Meazza wrote:
  Update of /var/cvs/FlightGear-0.9/data/Models/Airport
  In directory baron.flightgear.org:/tmp/cvs-serv26998
 
  Added Files:
 BAK-12-0.ac BAK12.xml
  Log Message:
  Add runway arrester gear type BAK-12. Based on Dave Culp's original work
 
 Just as a reminder, as written in the 00README.CONTRIBUTE file:
 
 The following classes of static geometries and therefore the
 corresponding
 subdirectories are being maintained via the FlightGear Scenery Model
 Repository (http://scenemodels.flightgear.org/models.php):
 
   Agriculture/
   Aircraft/
   Airport/
 [...]
 
 
 Thus, whenever you put a model into one of these directories, you're
 putting it at risk of getting overwritten without notice if you don't
 submit to the Scenemodels repository.
 

Thanks Martin - I think Jon Stockill has that in hand. 

Vivian



--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/MPCarrier help.xml, 1.2, 1.3

[Martin Spott]

Vivian Meazza wrote:
 Update of /var/cvs/FlightGear-0.9/data/Aircraft/MPCarrier
 In directory baron.flightgear.org:/tmp/cvs-serv18340
 
 Modified Files:
help.xml 
 Log Message:
 Update to reflect recent changes

Please excuse my curiosity: Isn't the number of consecutive empty lines
pretty much pointless in proper XML style ?

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Network generic.cxx, 1.22,

[Martin Spott]

Hi Erik,

Erik Hofman wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Network
 In directory baron.flightgear.org:/tmp/cvs-serv24469
 
 Modified Files:
generic.cxx generic.hxx 
 Log Message:

Out of curiosity: Did you make sure there's nothing missing ?

jive: 12:54:04 /usr/local/src/FlightGear/src/Main g++ -O3 -march=opteron 
-DHAVE_CONFIG_H
-I. -I../../src/Include -I../.. -I../../src -I../../src/FDM/JSBSim
-I/opt/CERTI/include -I/opt/gnu/include -I/usr/local/include
-I/opt/FlightGear/include -DPKGLIBDIR=\/opt/FlightGear/share/FlightGear\ 
-g
-O2 -I/opt/FlightGear -D_REENTRANT -c -o fg_io.o fg_io.cxx
fg_io.cxx: In member function 'FGProtocol* FGIO::parse_port_config(const 
std::string)':
fg_io.cxx:201: error: no matching function for call to 
'FGGeneric::FGGeneric(std::basic_stringchar,
std::char_traitschar, std::allocatorchar )'
../../src/Network/generic.hxx:41: note: candidates are:
FGGeneric::FGGeneric(std::vectorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
std::allocatorstd::basic_stringchar, std::char_traitschar,
std::allocatorchar   )
../../src/Network/generic.hxx:37: note: 
FGGeneric::FGGeneric(const FGGeneric)


Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Cockpit hud.cxx, 1.50, 1.51

[James Turner]

On 16 Jun 2009, at 12:04, Tim Moore wrote:

 sg_location now uses C strings. Also, change uses of sg_throwable to  
 more
 specific exceptions like sg_io_exception.

A bit of a tangent, but: I've used exceptions in the code I've  
contributed, where I feel they are appropriate, but I've often  
wondered if I am doing something that might surprise other people who  
call my routines.

In general, I'd hope that various key points in the code trap  
exceptions (or some classes of exception) and provide some logging -  
for example, it seems reasonable that SGSubsystemManager::update  
should have a catch block around each update() call, which logs the  
exception message, and then decides whether to re-throw, continue with  
the next subsystem, or disable the failed subsystem permanently.  
Extending sg_exception with some severity information would be  
possible, or the severity could be implicit in the exception hierarchy  
- sg_fatal_exception, etc...

I'd be happy to make this kind of change, since I have been  
responsible for a specific set of 'crashes' which this would have  
caught - namely the AI traffic code looking up bogus airport  
identifiers, which I throw an exception for - this went unhandled,  
ultimately leading to a call to exit() by the C++ runtime - which the  
users percevied as a crash. The code in question should have of course  
been checking the airport identifier for validity, but equally, this  
is the kind of error that doesn't need to terminate the whole sim -  
and even if it did, popping up a message box with the exception text  
(and location) would have helped track down the cause much sooner.

James






--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports pavement.cxx, NONE, 1.1 pavement.hxx, NONE, 1.1 apt_loader.cxx, 1.23, 1.24 Makefile.am, 1.17, 1.18 simple.cxx, 1.61, 1.62 simple.hx

[James Turner]

On 14 Jun 2009, at 12:08, Frederic Bouvier wrote:

 FGPavement::FGPavement(const std::string aIdent, const SGGeod  
 aPos) :
  FGPositioned(TAXIWAY, aIdent, aPos, false)

Fred, are you sure we don't want to add a new FGPositioned::Type for  
this? I don't mind either way, it's whatever you think makes the most  
sense.

Regards,
James


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Airports pavement.cxx, NONE, 1.1 pavement.hxx, NONE, 1.1 apt_loader.cxx, 1.23, 1.24 Makefile.am, 1.17, 1.18 simple.cxx, 1.61, 1.62 simple.hx

[Frederic Bouvier]

James Turner a écrit :
 On 14 Jun 2009, at 12:08, Frederic Bouvier wrote:

   
 FGPavement::FGPavement(const std::string aIdent, const SGGeod  
 aPos) :
  FGPositioned(TAXIWAY, aIdent, aPos, false)
 

 Fred, are you sure we don't want to add a new FGPositioned::Type for  
 this? I don't mind either way, it's whatever you think makes the most  
 sense.
   

The two format for taxiways will coexist for a while, so I added a new
time. Don't know how it will be useful though

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/   Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer


--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal pushback.nas, 1.1, 1.2

[Stuart Buchanan]

gerard robin wrote:

 On mardi 05 mai 2009, Alexis Bory - xiii wrote:
  I still don't know if it's ok to let the pushback stuff in the Nasal dir.
  IMHO this should be further discussed.
 
 Won't it be better to have it within Aircraft/Generic  ?
 with others stuffs  like aar or radar 

I agree with Gerard. This should really be under Aircraft/Generic, so specific
aircraft can choose to activate it by including the .nas file. It doesn't 
really 
make much sense for a lot of our aircraft.

-Stuart



  

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Airports/TXKF parking.xml, NONE, 1.1

[Durk Talsma]

On Friday 10 April 2009 23:44:09 Syd Adams wrote:
 Update of /var/cvs/FlightGear-0.9/data/AI/Airports/TXKF
 In directory baron.flightgear.org:/tmp/cvs-serv16099/TXKF

 Added Files:
   parking.xml
 Log Message:
 new airport file from msmith..


FWIW, I just added a copy of this file into the world scenery repository, as 
Airports/T/X/K/TXKF.groundnet.xml, since that is the location that we 
ultimately want to store everything containing scenery related geometry 
information. 

I'm still in the process of converting my own ground networks, so the new 
location isn't activated by default yet. 

Cheers,
Durk
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal pushback.nas, 1.1, 1.2

[Alexis Bory - xiii]

Alexis Bory wrote:
  Update of /var/cvs/FlightGear-0.9/data/Nasal In directory
  baron.flightgear.org:/tmp/cvs-serv9196

  Modified Files: pushback.nas Log Message: - Now the pushback door
  will be created only if /sim/model/pushback has already been created
  by the modeler via the aircraft-set.xml file. - Varified the code,
  removed the class structure, tests the nasal dir initialization
  first. - As part of the Nasal dir, the script must *not* be declared
  in the aircraft-set.xml file.

Hi all,

Sure, I should have spent my time fixing the pushback *before*
commiting it. In the other hand this incident was enlightening.

Anyway I'm really sorry for the inconvenience.

I still don't know if it's ok to let the pushback stuff in the Nasal dir.
IMHO this should be further discussed.

I hope... well, I hope nobody keep being sad, upset or angry now.

Alexis


--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal pushback.nas, 1.1, 1.2

[gerard robin]

On mardi 05 mai 2009, Alexis Bory - xiii wrote:
 Alexis Bory wrote:
   Update of /var/cvs/FlightGear-0.9/data/Nasal In directory
   baron.flightgear.org:/tmp/cvs-serv9196
 
   Modified Files: pushback.nas Log Message: - Now the pushback door
   will be created only if /sim/model/pushback has already been created
   by the modeler via the aircraft-set.xml file. - Varified the code,
   removed the class structure, tests the nasal dir initialization
   first. - As part of the Nasal dir, the script must *not* be declared
   in the aircraft-set.xml file.

 Hi all,

 Sure, I should have spent my time fixing the pushback *before*
 commiting it. In the other hand this incident was enlightening.

 Anyway I'm really sorry for the inconvenience.

 I still don't know if it's ok to let the pushback stuff in the Nasal dir.
 IMHO this should be further discussed.


Won't it be better to have it within Aircraft/Generic  ?
with others stuffs  like aar or radar 

 I hope... well, I hope nobody keep being sad, upset or angry now.

 Alexis


Cheers


-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/AIModel AIManager.cxx, 1.87, 1.88 AIManager.hxx, 1.48, 1.49 AIThermal.cxx, 1.15, 1.16 AIThermal.hxx, 1.8, 1.9

[Erik Hofman]

Torsten Dreyer wrote:
 -// Written by David Culp, started Feb 2004.
 +// Original by Written by David Culp
  //
 -// Copyright (C) 2004  David P. Culp - davidcu...@comcast.net
 +// An attempt to refine the thermal shape and behaviour by WooT 2009
 +//
 +// Copyright (C) 2009 Patrice Poly ( WooT )
 //
 // This program is free software; you can redistribute it and/or
 // modify it under the terms of the GNU General Public License as
 @@ -37,6 +39,10 @@


Just a heads up: You can't do this.
Instead add you (Patroce Poly) as a second Copyright holder.

Erik

--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/AIModel AIManager.cxx, 1.87, 1.88 AIManager.hxx, 1.48, 1.49 AIThermal.cxx, 1.15, 1.16 AIThermal.hxx, 1.8, 1.9

[Frederic Bouvier]

- Erik Hofman a écrit :

 Torsten Dreyer wrote:
  -// Written by David Culp, started Feb 2004.
  +// Original by Written by David Culp
   //
  -// Copyright (C) 2004  David P. Culp - davidcu...@comcast.net
  +// An attempt to refine the thermal shape and behaviour by WooT
 2009
  +//
  +// Copyright (C) 2009 Patrice Poly ( WooT )
  //
  // This program is free software; you can redistribute it and/or
  // modify it under the terms of the GNU General Public License as
  @@ -37,6 +39,10 @@
 
 
 Just a heads up: You can't do this.
 Instead add you (Patroce Poly) as a second Copyright holder.

Indeed, this is not fair, and not authorized by most license. Modifying a file 
doesn't remove the copyright of the previous writers.

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/  Photo gallery - album photo
http://fgsd.sourceforge.net/   FlightGear Scenery Designer


--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/AIModel AIManager.cxx, 1.87, 1.88 AIManager.hxx, 1.48, 1.49 AIThermal.cxx, 1.15, 1.16 AIThermal.hxx, 1.8, 1.9

[Torsten Dreyer]

 Torsten Dreyer wrote:
  -// Written by David Culp, started Feb 2004.
  +// Original by Written by David Culp
   //
  -// Copyright (C) 2004  David P. Culp - davidcu...@comcast.net
  +// An attempt to refine the thermal shape and behaviour by WooT 2009
  +//
  +// Copyright (C) 2009 Patrice Poly ( WooT )
  //
  // This program is free software; you can redistribute it and/or
  // modify it under the terms of the GNU General Public License as
  @@ -37,6 +39,10 @@

 Just a heads up: You can't do this.
 Instead add you (Patroce Poly) as a second Copyright holder.

 Erik
You are right - sorry. It is corrected. I am sure there was no evil mind 
behind that.
Thanks for pointing it out.

Torsten



--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/AIModel AIManager.cxx, 1.87, 1.88 AIManager.hxx, 1.48, 1.49 AIThermal.cxx, 1.15, 1.16 AIThermal.hxx, 1.8, 1.9

[Erik Hofman]

Torsten Dreyer wrote:
 Erik
 You are right - sorry. It is corrected. I am sure there was no evil mind 
 behind that.

Probably not but I felt it was important to point out.
Anyway, thanks for fixing it.

Erik

--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[Melchior FRANZ]

* Melchior FRANZ -- Monday 16 March 2009:
 + vary callsign  TACAN id
 + fly refueling pattern

That's now done. The tanker flies a refueling pattern with length
50 nm and 25 degree turns. You get a warning 1 nm before the turn.
Note that pilots also tank during the turn!

Bank angle and turn rate may need adjustment, but in a first test
with the a4f in a turn it worked just fine.



[TODO]
 - support more than just KC135 and KA6 tanker
 - support helicopter refueling (i.e. configurable airspeed)
 - avoid collisions with mountains
  - consider turbulence

m.

--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation agradar.cxx, 1.3, 1.4 rad_alt.cxx, 1.2, 1.3 wxradar.cxx, 1.28, 1.29 wxradar.hxx, 1.20, 1.21

[Durk Talsma]

Hi,

On Tuesday 17 March 2009 23:01:38 Melchior Franz wrote:
 Update of /var/cvs/FlightGear-0.9/source/src/Instrumentation
 In directory baron.flightgear.org:/tmp/cvs-serv17937/src/Instrumentation

 Modified Files:
   agradar.cxx rad_alt.cxx wxradar.cxx wxradar.hxx
 Log Message:
 wxradar: read aircraft data from the property tree, rather than AIBase

 This allows to display objects that are in /ai/models/, but not managed
 by the AI manager, and it follows fgfs' design principle that subsystems
 should communicate over the property tree (if possible). This is a tad
 slower, but the radar is only updated once every second.


FWIW, I just checked in a small change that allows the AI Air Traffic 
controller to request the AI Aircraft to set a squawk code. The actual 
assigned code is written to the property tree and could therefore be used by 
the radar code for display purposes. For now, I've bound the actual code to 

/ai/models/aircraft[x]/transponder-id

I'm open to suggestions for a more appropriate location in the property tree 
if that is deemed necessary.

BTW: What are objects that are in /ai/models/ but not managed by the AI 
Manager? All the properties that are written to /ai/models  are part of the 
AIModels subsystem, (including multiplayer aircraft) and consequently managed 
by the AI Manager, or am I missing something?

Cheers,
Durk
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation agradar.cxx, 1.3, 1.4 rad_alt.cxx, 1.2, 1.3 wxradar.cxx, 1.28, 1.29 wxradar.hxx, 1.20, 1.21

[Melchior FRANZ]

* Durk Talsma -- Sunday 22 March 2009:
 FWIW, I just checked in a small change that allows the AI Air Traffic 
 controller to request the AI Aircraft to set a squawk code.

Yeah, I've read that, and we've immediately discussed on IRC how to use
that. Unfortunately, we didn't have an ATC/Radar screen expert there,
who could tell us in which way that should appear on the screen.
One idea would be to put it by where the callsign is now, and only
if it's not available use the callsign.



 For now, I've bound the actual code to 
 
 /ai/models/aircraft[x]/transponder-id

It's an essential info about the aircraft, so I think that's fine.
An alternative would be in an ./instrumentation/transponder/id or
something. Depends on whether there's more data of that sort to
be expected in the /ai/ dir.



 BTW: What are objects that are in /ai/models/ but not managed by the AI 
 Manager? All the properties that are written to /ai/models  are part of the 
 AIModels subsystem, (including multiplayer aircraft) and consequently managed 
 by the AI Manager, or am I missing something?

tanker.nas puts the tanker there. It's also artificially (un)intelligent,
but the main reason for putting it there is that it should be picked
up by the air-refueling code and radar. And in general, an instrument
shouldn't get its info via secret channels from some other subsystems.
The property system is for this kind of data exchange. At least this
was the original design idea.

m.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation agradar.cxx, 1.3, 1.4 rad_alt.cxx, 1.2, 1.3 wxradar.cxx, 1.28, 1.29 wxradar.hxx, 1.20, 1.21

[Durk Talsma]

On Sunday 22 March 2009 15:58:27 Melchior FRANZ wrote:
 * Durk Talsma -- Sunday 22 March 2009:
  FWIW, I just checked in a small change that allows the AI Air Traffic
  controller to request the AI Aircraft to set a squawk code.

 Yeah, I've read that, and we've immediately discussed on IRC how to use
 that. Unfortunately, we didn't have an ATC/Radar screen expert there,
 who could tell us in which way that should appear on the screen.
 One idea would be to put it by where the callsign is now, and only
 if it's not available use the callsign.

Sound good. Just let me know If there's anything that I need to change.


 tanker.nas puts the tanker there. It's also artificially (un)intelligent,
 but the main reason for putting it there is that it should be picked
 up by the air-refueling code and radar. And in general, an instrument
 shouldn't get its info via secret channels from some other subsystems.
 The property system is for this kind of data exchange. At least this
 was the original design idea.


Okay, I though that that might be the case. I've not been following that 
discussion too closely, and was assuming that the nasal tanker code would also 
make use of the AIModels code, and hence be managed by the AIManager. 

FWIW, I don't object against this change, but I am wondering whether it 
wouldn't be an idea to integrate the nasal tanker stuff with the existing 
AIModels system.

Cheers,
Durk
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation agradar.cxx, 1.3, 1.4 rad_alt.cxx, 1.2, 1.3 wxradar.cxx, 1.28, 1.29 wxradar.hxx, 1.20, 1.21

[Alexis Bory - xiii]

Melchior FRANZ wrote:
  * Durk Talsma -- Sunday 22 March 2009:
  FWIW, I just checked in a small change that allows the AI Air
  Traffic controller to request the AI Aircraft to set a squawk code.
 

  Yeah, I've read that, and we've immediately discussed on IRC how to
  use that. Unfortunately, we didn't have an ATC/Radar screen expert
  there, who could tell us in which way that should appear on the
  screen. One idea would be to put it by where the callsign is now, and
  only if it's not available use the callsign.

In the f-14 A/B/+ the IFF system display aircraft response on the radar
screen (that is the small video display center top of the backseat panel).
Echos are then surrounded by two horizontal bars, one for proper mode
response, the other for proper code response. There is also one of the
ECM warning lights set which illuminates when the f-14's receives a
request.
I am planning to work on this, but not in the near future.

  For now, I've bound the actual code to
 
  /ai/models/aircraft[x]/transponder-id

  It's an essential info about the aircraft, so I think that's fine. An
  alternative would be in an ./instrumentation/transponder/id or
  something. Depends on whether there's more data of that sort to be
  expected in the /ai/ dir.



  BTW: What are objects that are in /ai/models/ but not managed by
  the AI Manager? All the properties that are written to /ai/models
  are part of the AIModels subsystem, (including multiplayer
  aircraft) and consequently managed by the AI Manager, or am I
  missing something?

  tanker.nas puts the tanker there. It's also artificially
  (un)intelligent, but the main reason for putting it there is that it
  should be picked up by the air-refueling code and radar. And in
  general, an instrument shouldn't get its info via secret channels
  from some other subsystems. The property system is for this kind of
  data exchange. At least this was the original design idea.

Good news, the f-14b radar scripts don't flood anymore /ai/models/
These properties have been moved under /sim/model/f-14b.

Alexis


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation agradar.cxx, 1.3, 1.4 rad_alt.cxx, 1.2, 1.3 wxradar.cxx, 1.28, 1.29 wxradar.hxx, 1.20, 1.21

[Melchior FRANZ]

* Durk Talsma -- Sunday 22 March 2009:
 On Sunday 22 March 2009 15:58:27 Melchior FRANZ wrote:
  One idea would be to put it by where the callsign is now, and only
  if it's not available use the callsign.
 
 Sound good. Just let me know If there's anything that I need to change.

OK, I'll hack that in now.  :-)



 Okay, I though that that might be the case. I've not been following that 
 discussion too closely,

That's a mistake. Chasing the Nasal tanker is a lot of fun.  ;-)



 and was assuming that the nasal tanker code would also  
 make use of the AIModels code, and hence be managed by the AIManager. 

I didn't even check if that's possible. I assume not, but even if,
it would probably not be an advantage. Just one more redirection.
But I'd agree that having it in /ai/ isn't the most intuitive thing.
But then again: entirely static scenario-thunderstorms are also in
there.

I'm not really in the mood of doing that now, but in the long run
we should probably change the property structure to something like:

  /models/ai/...... for AI aircraft
 /multiplayer/...   ... for MP aircraft (even if they are AI-managed)
 /nasal/... or something
 /.../

Having an AI model dir on the top-level, and having it contain also
MP models, and other things (like the tanker) is IMHO not very clean.
(Yes, I'm aware that MP is partly handled by the AI-subsystem).


 
 but I am wondering whether it wouldn't be an idea to integrate the
 nasal tanker stuff with the existing AIModels system.

I'm not very familiar with the AI subsystem, and I don't see at the
moment how the tanker would profit from it. You mean, because it could
then be considered by the traffic manager? I'd need Nasal control
and flexibility. And it should work if the traffic manager is turned
off. At the moment it does that.

m.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[Melchior FRANZ]

* gerard robin -- Thursday 19 March 2009:
 I can only answer that i never had any problem with the actual AI/MP  radar, 
 it is very flexible , since the main required values x-shift, y-shift, in 
 addition to the other useful aircraft data ( range-nm, altitude, heading )  
 are there. These data remain  realistic. 

This whole AI radar type isn't realistic. Nobody complains more
often about game-like features than you, but here you insist on the
unrealistic radar. wxradar is a lot more realistic, and it works.

But I offer to write a small generic compatibility Nasal module that
scans the AI tree and adds the missing values. Then the tanker will
work for you now, and you won't even notice if/when we drop the AI
radar mechanism. Everything will just keep working.

m.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/Fokker-50/Models fokker50.ac, 1.1, 1.2

[Erik Hofman]

Mathias Froehlich wrote:
 Update of /var/cvs/FlightGear-0.9/data/AI/Aircraft/Fokker-50/Models
 In directory baron.flightgear.org:/tmp/cvs-serv2499/Aircraft/Fokker-50/Models
 
 Modified Files:
   fokker50.ac 
 Log Message:
 Set the ambient color equal to the rgb color.
 This is what currently is done in flightgears model loading stage anyway.

To be honnest I don't like this action. I've always made sure all color 
settings were right in the modeller and did'nt adjust them to look nice 
in FlightGear in any way. Same goes for the F-16, T-37, T-38, Fokker 
100, Fokker 70 and Fokker Dr.1

To me this is a step too far and reading the conversation I was under 
the impression this wasn't to be done automatically.

I do agree with the code change though.

Erik

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/Fokker-50/Models fokker50.ac, 1.1, 1.2

[Mathias Fröhlich]

Erik,

On Thursday 19 March 2009 09:08:29 Erik Hofman wrote:
 To be honnest I don't like this action. I've always made sure all color
 settings were right in the modeller and did'nt adjust them to look nice
 in FlightGear in any way. Same goes for the F-16, T-37, T-38, Fokker
 100, Fokker 70 and Fokker Dr.1
Reverted on AI/Aircraft/Fokker-*.
Anyway, I miss the F-16, T37 and T38 in the AI directory? Do you mean the 
'main aircraft models instead??'
I can revert them too if I have found them.

Note that I did only change the AI models and the 'Geometry' stuff since I have 
found plenty of models that needed I conversion model by model.

The 'main' Aircraft models work is left to the original authors.

Greetings

Mathias

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/AI/Aircraft/Fokker-50/Models fokker50.ac, 1.1, 1.2

[Erik Hofman]

Mathias Fröhlich wrote:
 Erik,
 
 On Thursday 19 March 2009 09:08:29 Erik Hofman wrote:
 To be honnest I don't like this action. I've always made sure all color
 settings were right in the modeller and did'nt adjust them to look nice
 in FlightGear in any way. Same goes for the F-16, T-37, T-38, Fokker
 100, Fokker 70 and Fokker Dr.1

 Reverted on AI/Aircraft/Fokker-*.
 Anyway, I miss the F-16, T37 and T38 in the AI directory? Do you mean the 
 'main aircraft models instead??'
 I can revert them too if I have found them.

Correct, I didn't see them in de CVS messages but sometimes I get the 
changes in two batches, therefore I did include them in the shortlist.

 Note that I did only change the AI models and the 'Geometry' stuff since I 
 have 
 found plenty of models that needed I conversion model by model.

Ok, I missed the AI part in the path, but thanks for reverting them.

Erik

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[gerard robin]

On lundi 16 mars 2009, Melchior FRANZ wrote:
 While we are at it, here some comments on tanker.nas:

 There's a menu entry AI/MP-Tanker, which opens a small dialog where
 you can request a tanker. It'll contact you and tell you something
 like this:

   MOBIL3 at 15000, heading 130 with 250 knots, TACAN 062X

 At the moment TACAN is always 062X, but that will vary in the future.
 The tanker will appear somewhere (not necessarily straight) ahead of
 you at an altitude of its choice. It will remove itself if it was out
 of range for a while. You can then ask for a new one.

 A similar script was presented a few months ago, but it had some
 issues that the authors never bothered to address (take it or leave
 it? :-), so I re-implemented it. This isn't finished either. There
 are some TODOs:

 - vary callsign  TACAN id
 - support more than just KC135 and KA6 tanker
 - support helicopter refueling (i.e. configurable airspeed)
 - fly refueling pattern(?)
 - avoid collisions with mountains

 m.


Again about that topic.

With the usual AI tankers we have a lot of data regarding the Radar , x-shift 
y-shift  in-range , rotation,  v-offset, .. and so on

That tanker feature don't gives such information  , it is missing , is it any 
valuable reason ?

Thanks

-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[Melchior FRANZ]

* gerard robin -- Thursday 19 March 2009:
 With the usual AI tankers we have a lot of data regarding the Radar
 x-shift y-shift  in-range , rotation,  v-offset, .. and so on
 
 That tanker feature don't gives such information  , it is missing ,
 is it any valuable reason ?

That's not exactly missing. It's not provided on purpose.

The Nasal tanker is a radar *target*. It gives enough hints for radar
implementations (be it the (wx)radar instrument or the f-14b's radar):
lat/lon/altitude/ktas/true-heading/bearing/elevation/range.

But the tanker cannot decide whether it is in some radar's range, nor
where it should appear on a radar screen. This depends entirely on
the radar and is the radar's job, not the tanker's. How would the
tanker decide whether it is in range? In which range?

The built-in AI radar is obsolete and should be phased out.

m.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[gerard robin]

On jeudi 19 mars 2009, Melchior FRANZ wrote:
 * gerard robin -- Thursday 19 March 2009:
  With the usual AI tankers we have a lot of data regarding the Radar
  x-shift y-shift  in-range , rotation,  v-offset, .. and so on
 
  That tanker feature don't gives such information  , it is missing ,
  is it any valuable reason ?

 That's not exactly missing. It's not provided on purpose.

 The Nasal tanker is a radar *target*. It gives enough hints for radar
 implementations (be it the (wx)radar instrument or the f-14b's radar):
 lat/lon/altitude/ktas/true-heading/bearing/elevation/range.

 But the tanker cannot decide whether it is in some radar's range, nor
 where it should appear on a radar screen. This depends entirely on
 the radar and is the radar's job, not the tanker's. How would the
 tanker decide whether it is in range? In which range?

 The built-in AI radar is obsolete and should be phased out.

 m.


Then, do you mean that the old Radar Fashion will be removed, what a pity.

It is very useful.  We could want to keep it .





-- 
Gérard
http://pagesperso-orange.fr/GRTux/

J'ai décidé d'être heureux parce que c'est bon pour la santé. 
Voltaire


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal tanker.nas, NONE, 1.1

[Melchior FRANZ]

* gerard robin -- Thursday 19 March 2009:
 Then, do you mean that the old Radar Fashion will be removed,
 what a pity. 

I haven't planned that (yet). But in the long run it should get
removed. This was an early mechanism to get the brand-new AI
models on the screen (for the T38?), and that was OK back then,
and a nice new feature. But it's simple and unrealistic and just
doesn't fit in our framework. A radar needs to be a regular
instrument -- and the wxradar is just that. Or it should be some
customized Nasal logic like in the f-14b. New AI objects like
the tanker shouldn't have to generate absurd values to emulate
that obsolete radar. That would only prolong its lifetime. That's
inhuman.   :-)

But you can easily generate shift-x/shift-y etc. for the radar
you are actually using. Your aircraft knows which radar that is.
The tanker doesn't know that. It's like demanding that the tanker
decides whether your gear is extended or retracted. It just doesn't
know.


 It is very useful.  We could want to keep it .

Did you have a look at the wxradar? You can check out the ufo.
Press Shift-p to enable the radar screen and Ctrl-c to see the
click-sensitive areas. Unfortunately, there are no button labels.
Clicking on the two range numbers increases/decreases the range.
You don't need any Nasal for that radar type, and you can select
radar shadows, symbols, and (once re-implemented) cloud shadows. 

m.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel