RE: [Flightgear-devel] Re: Wing motion

2005-12-19 Thread Vivian Meazza
Melchior FRANZ

 * Jon S. Berndt -- Monday 19 December 2005 05:04:
  Would it be possible to change the visual appearance of wing flex during
  flight?
 
 As Curt and Joacim have mentioned already, there are ways to do it:
 
 (A) ornithopter method: several instances of the wing. This has the
 disadvantage that you'd need a lot of them for smooth transitions.
 No problem for the fast moving ornithopter, but one would probably
 need a *lot* of such instances for a glider wing.
 
 (B) bo105 method: wing/blade made of smaller parts that are each
 animated with smaller rotations. Smooth movements, but the hinges
 between them can look quite ugly. Not a big problem for the bo105,
 because the blade is dull and black. Wouldn't work well for a shiny
 white wing.
 
 (C) tween method: this isn't implemented in fgfs yet, but plib offers
 an ssgTweenController (A morph controller) class. Maybe we should
 make it available in fgfs for wings/blades. It interpolates between
 two or more objects with the same number of verticesfaces, so one
 would only need two instances of the wing and could smoothly
 interpolate. Would probably work better than either (A) or (B).
 (see http://plib.sourceforge.net/ssg/branches.html and the
 test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx)
 

The tween method would be the way to go. There might well be other
applications for this animation: I'm thinking of pilot animation in
particular. So the effort involved could be well worth it.

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] STL errors?

2005-12-13 Thread Vivian Meazza
Jon S. Berndt

 
  Do you have NOMINMAX defined and
 
  #ifdef HAVE_CONFIG_H
  #include config.h
  #endif
 
  at the beginning of every .cpp/.cxx file ?
 
  -Fred
 
 Not as far as I know. But this is straight from an unaltered current CVS
 distribution of FlightGear. I've got the very latest compilers/tools from
 Cygwin, so I thought maybe something had changed with g++.
 
 Note that new JSBSim compiles fine on my machine (same files). Maybe
 I'll
 dispense with the old JSBSim code in FlightGear immediately. I just wanted
 to get the basic distribution compiled as-is.
 

FG-cvs builds OK here under the latest version of Cygwin without the need
for any fixes. However, I have this:

LDFLAGS=-L/usr/local/lib
CXXFLAGS=-pipe -O2 -Wall -DWIN32 -DNOMINMAX -DHAVE_WINDOWS_H  
CFLAGS=$CXXFLAGS

export LDFLAGS
export CXXFLAGS
export CFLAGS

in my BASH.PROFILE file. It used to be needed, but I think it's redundant
nowadays

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] W2K or XP?

2005-12-10 Thread Vivian Meazza
Jon S Berndt

 
 Anyone got a good reason why I should install W2K or XP as preferred
 over the other one?
 
 
Try W2K doesn't work very well all of the time, while XP works pretty well
most of the time as a reason.

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Rendering multiplayer aircraft as AI aircraft

2005-12-09 Thread Vivian Meazza
Erik Hofman wrote:

 
 Gregory Richards wrote:
  Rendering multiplayer aircraft as AI aircraft is a feature I'm
  particularly interested in, and I've heard rumors of it being done, but
  I can't find any information on who if anyone is doing it.  If nobody's
  working on it right now, I'd love to hack at it myself.  (No guarantees
  of success ;) )
 
 I don't think anybody is working towards using the AIModels code for
 displaying multiplayer aircraft right now, but it would be useful to have.
 

Oliver Schroeder, Mathias, and I have all been discussing merging the MP and
AI code, so that we could sort out the animations and the jerky movements of
MP models, and give us the capability of passing AI models over the net.

The discussions have reached an advanced stage, but have stalled due to the
work-loads of Oliver and Mathias.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Gear animation tutorial

2005-11-26 Thread Vivian Meazza
Josh Babcock

 
 I just made up a tutorial about making gear retraction animations run
 smoothly with complicated landing gears. It's still missing the final
 animation code, but I thought I'd throw it up to see what everybody
 thinks. It's got lots of in-line images, so be warned. I'm considering
 changing this to in-line thumbnails hotlinked to the full sized images.
 Please give feedback.
 
 http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html
 

Gosh, Josh, what an effort. Well done. Couple of points. First, I model the
gear with the oleos extended, which helps with getting the compression
right. Most drawings show the gear with the oleos at some intermediate
compression. Some interpretation/intelligent guesswork is usually required.
Second, sometimes the movement of jacks and draglinks etc. is too difficult
to model well, so I cheat and hide them once they can no longer be seen
readily (I do that anyway to save vertices).

And one typo: separate.

I'm impressed!

Vivian

 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] RenderTexture::BeginCapture(): Texture is notinitialized!

2005-11-18 Thread Vivian Meazza
Arthur Wiebe

 Subject: [Flightgear-devel] RenderTexture::BeginCapture(): Texture is
 notinitialized!
 
 When running fgfs 0.9.9 I get this output:
 
 opening file:
 /Users/arthur/Projects/FlightGearOSX/data//Navaids/carrier_nav.dat
 /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat
 RenderTexture::BeginCapture(): Texture is not initialized!
 /Users/arthur/Projects/FlightGear/../SimGear/SimGear/simgear/threads/SGThr
 ead.hxx:233:
 failed assertion `status == 0'
 Abort trap
 
 At first if failed right after this line:
 /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat
 
 But then I uncompressed TACAN_freq.dat.gz and carrier_nav.dat.gz and
 got past that. And now it aborts with RenderTexture.
 
 As long as things go like this there'll be no Mac release anytime soon.

There should be no need to uncompress either file.

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] RenderTexture::BeginCapture(): Texture isnotinitialized!

2005-11-18 Thread Vivian Meazza
Arthur Wiebe

 
 On 11/18/05, Vivian Meazza [EMAIL PROTECTED] wrote:
  Arthur Wiebe
 
   Subject: [Flightgear-devel] RenderTexture::BeginCapture(): Texture is
   notinitialized!
  
   When running fgfs 0.9.9 I get this output:
  
   opening file:
   /Users/arthur/Projects/FlightGearOSX/data//Navaids/carrier_nav.dat
   /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat
   RenderTexture::BeginCapture(): Texture is not initialized!
  
 /Users/arthur/Projects/FlightGear/../SimGear/SimGear/simgear/threads/SGThr
   ead.hxx:233:
   failed assertion `status == 0'
   Abort trap
  
   At first if failed right after this line:
   /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat
  
   But then I uncompressed TACAN_freq.dat.gz and carrier_nav.dat.gz and
   got past that. And now it aborts with RenderTexture.
  
   As long as things go like this there'll be no Mac release anytime
 soon.
 
  There should be no need to uncompress either file.
 
  Vivian
 
 
 
 There isn't. It was one of those things that comes from the top of
 your head but ends up being smoke.

Good, otherwise I would have to panic :-)

V.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] [0.9.9] screenshots for flightgear.org

2005-11-17 Thread Vivian Meazza
Melchior FRANZ

 Here are four screenshot offerings for the FlightGear page. All
 of the shots show new features. I have the original ppm files in
 case jpeg artifacts are a problem.
 
   http://members.aon.at/mfranz/concorde-gui.jpg  [130 kB]
   http://members.aon.at/mfranz/seafire-nimitz.jpg [70 kB]
   http://members.aon.at/mfranz/clouds-winter-bo105.jpg   [182 kB]
   http://members.aon.at/mfranz/lightning-rain-b1900d.jpg  [83 kB]
 
 I don't mind if you (Curt) don't use them. But we should *really* put new
 ones up before 0.9.9 is released. All people who see the release note
 will check the HP and would be disappointed to see only old screenshots.
 That leaves a bad taste before they even tried fgfs. Even worse:
 reviewers will have the same experience!
 

Here's one:

ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/HurricaneIIb-3.jpg  

No particular reason, I just like it.

Vivian 




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Problems in the latest CVS version

2005-11-15 Thread Vivian Meazza
AJ

 On Tuesday 15 November 2005 13:18, Dai Qiang wrote:
  I am using the latest CVS version of SimGear,
  FlightGear data and source. After I enabled the Nimitz
  demo, I found the Hunter plane moved backward slowly
  when it's landed on the Nimitz, because Nimitz was
  moving forward, and Hunter remained at its original
  position.
 
 Just checking the obvious - you have engaged the parking brake, haven't
 you?
 (Shift - b)
 
 Likewise, on land, if the 747 is sitting on a sloping runway without the
 brakes on, it will naturally roll downhill.
 

Hunter starts with the brakes on by default. It works here with cvs as of
this morning.

V.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Citation pitch down divergence. Fixed?

2005-11-11 Thread Vivian Meazza
Josh Babcock

 
 Lee Elliott wrote:
  On Thursday 10 Nov 2005 20:20, Andy Ross wrote:
 
 After some prodding from Curt, I finally spent a few hours
 yesterday tracking down the pitch down discontinuity in the
 Citation.
 
 Well, I didn't find a discontinuity.  I can now graph the lift
 curve from a Surface (a real one, part of the real aircraft,
 not an isolated test instance) and verify that it's valid and
 correct looking through the entire AoA regime.
 
 But I think I *did* find the problem: it seems that I, er,
 misdocumented the incidence and twist parameters in the
 YASim configuration.  The README.yasim file states that these
 numbers are positive for positive AoA (i.e. a positive
 incidence on a wing generates extra lift, and a negative twist
 causes the wing tips to stall after the root).  But the code
 was interpreting the number as a rotation about the YASim Y
 axis, which points out the left wing and therefore is positive
 *down*.  Oops.
 
 The reason the citation exhibited this especially is just
 luck: the file lists an incidence of 3.0 (which is relatively
 high, and the inversion bug therefore puts the wing 3 degrees
 closer to a negative stall) the solver happens to generate a
 nose-down cruise configuration of about 1.5 degrees, and the
 elevator authority is actually quite high (which causes higher
 pitch rates under autopilot control).
 
 So the bottom line is that Curt was right: it *was* the
 negative AoA stall (probably the tail's, not the wing's)
 happening too soon. :)
 
 I'm a little leery of changing this in code this close to a
 release -- the risk of breaking working aircraft is too high.
 For the short term, this can be fixed in the Citation-II.xml
 file by simply negating the incidence and twist values on the
 wing.  I did this and tried the autopilot in a maximum speed
 cruise at low level (which should produce the highest
 nose-down AoA) without any odd behavior.
 
 Curt, can you try that and see if it appears to fix the
 handling issues?  Likewise, anyone with a YASim aircraft that
 makes use of incidence or twist values is encouraged to try
 the same modification and report any problems.  We can go back
 after the release and fix the code and all the aircraft files.
 
 Andy
 
 
  I'll try to check the ones I've done over the weekend.  The one
  that concerns me most is the B-52F.  The wing incidence is set
  to 6 and the twist to -4 and I'm starting to wonder how it
  manages to fly at all.
 
 Nose down. The fuselage is about 5 deg down when in level flight.
 
 
  I got some good info on the B-52F from someone who flew around
  3000 hrs in that model and around 6000 hrs total in all models,
  apart from the A/B, and it was flying to within around 10 kts or
  so of what it should have been doing and was climbing at about
  the right rate.
 

The negative incidence issue might also explain some odd values I was forced
to put into the B29 config to make it fly well. I'll try an updated version
later.

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8

2005-11-09 Thread Vivian Meazza
Jim Wilson wrote

 
  -Original Message-
 
  If you contributed something that is missing, or poorly described here,
  please send me something better.
 
 
 Hi Curt,
 
 This may not be helpful at this point (haven't been reading for a few
 days).
 
 Here's an addition:
 
 * Material animation added to Simgear's 3D model support, allowing things
 like dimmable cockpit lights and other exotic color and transparency
 morphs in 3D models.
 

Here's something we seem to have missed:

* Extensive revisions to the Multiplayer code. Multiplayer servers are now
available. A Google-based map server is also available

Hope we can get this in somewhere

Regards,

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8

2005-11-07 Thread Vivian Meazza
Vassilii Khachaturov

 
  Hey, someone noticed :-) It was fixed in cvs Thursday last though.
 
 :) Of course, I keep looking at the CVS commits since I am learning FG.
 Actually I kept thinking of doing this one myself, since nobody answered
 my challenge yet to tell me about smth interesting to do for FG while
 learning GL.
 
 Eventually, this should probably be configurable wrt individual
 G-tolerances, and adapted to all aircraft.
 

I'm considering adding a selectable anti-g suit, thus upping the g
tolerance. The feature can be easily added to any aircraft, but I suppose in
theory ought to be added to _all_.

V.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8

2005-11-07 Thread Vivian Meazza
Curtis L. Olson

 
 I was scanning through the cvs logs trying to refresh my memory on what
 has been changed, added, and fixed since the release of v0.9.8 (last
 January).  Here's what I came up with, although after staring at cvs
 logs for 2 hours I started having minor hallucinations.  So I'm posting
 this here in hopes that people can add to it, or correct my mistakes.
 If you contributed something that is missing, or poorly described here,
 please send me something better.
 
 Thanks!
 
 Curt.
 
 For upcoming v0.9.9 ...
 
 * New well integrated volumetric clouds by Harald Johnsen
 * Removed 'old' 3D clouds code.
 * Fixed the jitter problem with 3d cockpits.
 * Volumetric shadows are now supported so that aircraft can cast
   shadows upon themselves as well as the ground.
 * Better support for redoing livery textures on an individual aircraft.
 * Support for seasonal terrain textures.  (Updates to summer textures
   plus new winter textures added.)
 * Add status updates to the initial splash/startup screen.
 * Allow switching the tower view location at any time.
 * Add support for configuring views with asymmetric view frustums.
 * Many updates to gui/dialog box infrastructure.  Ability to alter
   border thickness, change fonts, dialog boxes are draggable across
   the screen, you can enable automatic line wrapping, select
   colors, allow key presses to be bound to widgets, .
 * Updates and enhancements to many of the dialog boxes to fix problems,
   expose new features, enhance usability, etc.
 
 * Updated JSBSim version since the last release.  (More updates
   pending after this release.)
 * YASim: expose spool-time of a jet engine as a config parameter,
   add an oil temp model, support gear compression along any arbitrary
 axis,
   reworked MP calculations for super/turbochargers.
 * Allow setting individual sample/update rates for any of the PID
   autopilot stages.
 
 * Support TACAN instruments for mobile and fixed beacons.  And an IVSI
instrument.
 * Deprecated old (somewhat less the spectacularly conceived)
   electrical system model in favor of a much more flexible script based
   system that can be tailored to any individual aircraft.
 * Include an external utility that can feed saved nmea tracks back
   into FlightGear.  If you take a gps on a real flight with you and
   capture the output, you can replay your flight in FlightGear.
 
 * Many updates and fixes to the joystick configuration files, many new
   joysticks directly supported.
 
 * Removed all lingering dependencies on plib's SL sound library.
 * Add support for OpenAL 1.1 and alut.
 * Better cross platform compatibility with our standard network
 structures.
 * More cpu friendly frame rate throttling code that can leave more cpu
   available for other apps.
 * Various Nasal (scripting) bug fixes and language improvements.
 * Various bug fixes, various platform/compiler compatibility fixes,
   several memory leaks fixed.
 
 * New aircraft available (in various stages of developement): A380,
   Boeing 314 (seaplane), Citation Bravo (glass cockpit), F-8E
   Crusader, Hurricane IIb, MiG-15bis, TU-114, B29, C150, and SR20.
 
 * Aircraft that have had updates since the last release: 737, A-10,
   AN-225, B-52F, BAC-TSR2, Citation-II (550), Comper Swift, Concorde,
   Hunter, OV10, Spitfire, T37, B1900d, bo105, C172 et. al., DHC2F
   (Beaver), F16, Fokker DR1 Triplane, Fokker 50 (turboprop), Fokker
   100 (jet), J3 Cub, P51, Santa, Seahawk, and 1903 Wright Flyer.
 
 


You might consider adding the following:

* Carrier - added working arrester wires and catapults. The carrier is
selectable as a starting position. AI has been added to the 
carrier in the form of an operating box and an automated turn
into/outof wind. TACAN beacon added.

Regards

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8

2005-11-07 Thread Vivian Meazza
Erik Hofman


 Vivian Meazza wrote:
 
  You might consider adding the following:
 
  * Carrier - added working arrester wires and catapults. The carrier is
  selectable as a starting position. AI has been added to the
  carrier in the form of an operating box and an automated turn
  into/outof wind. TACAN beacon added.
 
 Also:
 * Added a generic, XML configurable, autopilot framework, and several
 high level, configurable filter implementations for use by autopilot
 designers.
 * Added a transponder and Altitude encoder.
 * Made the instruments code much more configurable, it is now possible
 to only include instruments that are actually present.
 * Implemented the groundcache code which made it possible for aircraft
to follow the ground precisely and, as a result, made it possible to
land on 

aircraft carriers (and fly under bridges). At the moment, carrier operations
are restricted to aircraft models using YASim FDM only.

V. 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8

2005-11-06 Thread Vivian Meazza
Visalia Khachaturov

 
 A very cool user-felt feature is Vivian's redout/blackout, currently
 implemented in the hunter. Please add it to the list.
 
 I couldn't resist from taking the following picture that shows the redout
 sphere from the side:
 
 http://www.tarunz.org/~vassilii/fg/Images/hunter-redout.jpg
 

Hey, someone noticed :-) It was fixed in cvs Thursday last though.

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Speckle-Master 3000 DeLuxe Pro -- for theultimative despeckling experience

2005-10-30 Thread Vivian Meazza
Melchior FRANZ

 
 Here's a script that removes ugly speckle noise as often seen on
 low-end nVidia cards, such as the GF4 MX440. Here's an example
 from the Hunter (which is meanwhile mostly fixed):
 

Mostly? I thought we had fixed all such problems in the Hunter years ago??

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Santa's r[ae]i?ndeer

2005-10-27 Thread Vivian Meazza
Erik Hofman

 
 Vassilii Khachaturov wrote:
  Why are the bells commented out in raindeer-sound.xml?
  They do sound cute.
 
 I think it's a leftover from a previous test.
 It's corrected now.
 

What happened to the poor reindeers' antlers?

V.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,

2005-10-26 Thread Vivian Meazza
Alex Romosan


 Vivian Meazza [EMAIL PROTECTED] writes:
 
  Alex Romosan asked:
 
  Vivian Meazza [EMAIL PROTECTED] writes:
 
   The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx
 so
  far
   as the compiler was concerned.
  
   It now compiles and runs OK
 
  i don't understand. does the cvs version compile or do you still have
  to make those changes to get it to compile?
 
 
  Before I made the corrections cvs failed to compile. After I made the
  corrections (those in the diff) cvs compiled and ran.
 
 this is why i would've have liked to see the original error message.
 if the compiler didn't like those changes here it should've not liked
 them everywhere else. unfortunately i don't have cygwin installed to
 compile it myself.
 
 --alex--
 

A quick inspection of the diff should show you that the compiler didn't like
'string' in the .hxx file where 'const string' was used in the .cxx. I
changed the .hxx file. Perhaps I should have changed the .cxx, but anyway it
works. 

It is entirely possible that the fault lies in the cvs version that I have
here, but I think I have the correct HEAD version.

V. 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATC AIEntity.cxx, 1.12,

2005-10-25 Thread Vivian Meazza
Erik Hofman

 
 Martin Spott wrote:
 
  I have the impression that the changes to the FlightGear subtree didn't
  make it into CVS - at least they didn't appear on checkout. Am I the
  only one who misses these changes ?
 
 I guess so, the CVS changelog was sent out to me by mail.
 
 Erik
 

I'd be more impressed if this extensive change to CVS compiled under Cygwin,
so far I've found and corrected half a dozen errors, but now I think I've
stuck on

AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument
of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT,
_Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits =
std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers

SNAFU

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,

2005-10-25 Thread Vivian Meazza
Andy Ross

 
 Vivian Meazza discovered:
  AIFlightPlan.cxx:69: error: passing `const std::string' as `this'
 argument
  of `std::basic_string_CharT, _Traits, _Alloc
 std::basic_string_CharT,
  _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits
 =
  std::char_traitschar, _Alloc = std::allocatorchar]' discards
  qualifiers
 
 Heh, don't you just *love* C++ error messages? :)
 Translated:
 
   AIFlightPlan.cxx:69: error: passing `const string' as `this' argument
   of `string::operator=()' discards qualifiers
 
 You can't assign to a const object, basically.  No idea why this compiles
 correctly on other platforms...
 

Cracked that one - I introduced it in correcting others. So all done now. 

Just preparing a diff of the changes that I had to apply to get Cygwin to
compile.

Thanks

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,

2005-10-25 Thread Vivian Meazza
Vivian Meazza wrote

 
 Andy Ross
 
 
  Vivian Meazza discovered:
   AIFlightPlan.cxx:69: error: passing `const std::string' as `this'
  argument
   of `std::basic_string_CharT, _Traits, _Alloc
  std::basic_string_CharT,
   _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char,
 _Traits
  =
   std::char_traitschar, _Alloc = std::allocatorchar]' discards
   qualifiers
 
  Heh, don't you just *love* C++ error messages? :)
  Translated:
 
AIFlightPlan.cxx:69: error: passing `const string' as `this' argument
of `string::operator=()' discards qualifiers
 
  You can't assign to a const object, basically.  No idea why this
 compiles
  correctly on other platforms...
 
 
 Cracked that one - I introduced it in correcting others. So all done now.
 
 Just preparing a diff of the changes that I had to apply to get Cygwin to
 compile.
 

I attach a diff against CVS - HEAD which I applied to get CVS to compile
under Cygwin. It may not be the best or preferred way to do it, but the
patch works here, so far as I can see.

Regards,

Vivian


CVS.diff
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,

2005-10-25 Thread Vivian Meazza
Alex Romosan asked

 
 Vivian Meazza [EMAIL PROTECTED] writes:
 
  I attach a diff against CVS - HEAD which I applied to get CVS to compile
  under Cygwin. It may not be the best or preferred way to do it, but the
  patch works here, so far as I can see.
 
 
 diff -u -w -b -r1.11 AIFlightPlan.hxx
 --- AIFlightPlan.hxx25 Oct 2005 13:49:56 -  1.11
 +++ AIFlightPlan.hxx25 Oct 2005 19:17:09 -
 @@ -77,14 +77,14 @@
time_t getStartTime() { return start_time; };
 
voidcreate(FGAirport *dep, FGAirport *arr, int leg, double alt,
 double speed, double lat, double lon,
 -bool firstLeg, double radius, const string fltType,
 const string aircraftType, const string airline);
 +bool firstLeg, double radius, string fltType, string
 aircraftType, string airline);
 
void setLeg(int val) { leg = val;};
void setTime(time_t st) { start_time = st; };
int getGate() { return gateId; };
double getLeadInAngle() { return leadInAngle; };
 -  const string getRunway() { return rwy._rwy_no; };
 -  const string getRunwayId() { return rwy._id; };
 +  string getRunway() { return rwy._rwy_no; };
 +  string getRunwayId() { return rwy._id; };
void setRepeat(bool r) { repeat = r; };
bool getRepeat(void) { return repeat; };
void restart(void);
 
 why do you need to do this? 

Er ... because Cygwin wouldn't compile?

what was the error when trying to compile
 the cvs version?


The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far
as the compiler was concerned.

It now compiles and runs OK

V. 
 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,

2005-10-25 Thread Vivian Meazza

Alex Romosan asked:
 
 Vivian Meazza [EMAIL PROTECTED] writes:
 
  The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so
 far
  as the compiler was concerned.
 
  It now compiles and runs OK
 
 i don't understand. does the cvs version compile or do you still have
 to make those changes to get it to compile?


Before I made the corrections cvs failed to compile. After I made the
corrections (those in the diff) cvs compiled and ran.

V.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Multiplayer, the next steps

2005-10-24 Thread Vivian Meazza
Mathias Fröhlich wrote

Oliver Schroeder wrote:

...snip
 
  3) sending properties for the carrier (Nimitz)
  In order to prepare flightgear to send abitary properties, I think the
  carrier is predestined. Everything we need is almost already there. What
 we
  need is a method in FGAICarrier which I can call from the network code
 and
  is able to extrapolate position, speed etc from network data. As far as
 I
  know, it should be sufficient to send position, speed and rudder angle.
  There is possibly more to say (eg. how to elect the feeder and what
  happens when the feeder dies etc). I have ideas on that, but we will see
  how to cope with that when we know how we actually handle carrier
  properties.
 To that topic, I might be able to help.
 Positions and speeds (both linear and rotational) together with a
 timestamp
 when this state is valid should be enough. From that you should be able to
 predict the position in some way.
 That is the way the carrier is moved below the FDM during one timestep.
 Ask if you have questions for the extrapolation ...

AICarrier passes the initial position, base course and speed to AIShip,
which then handles the positional and rotational updates, which it passes
back to AICarrier for further manipulation.

If the carrier needs to alter course in response to a command or its simple
AI rules, AICarrier passes tgt course and/or tgt speed to AIShip which uses
these data to adjust position and orientation using some pragmatic
calculations involving rudder angle, speed and turn radius, and passes them
back to AICarrier. AIShip is not a Ship Dynamic Model - it uses some voodoo
to simulate reasonably realistic ship movements. 

We should be able to adapt and use this mechanism to both update the carrier
position from the network and extrapolate the current position/orientation
between network updates. This method might or might not need the network
update to be timestamped. We might try without first since this avoid the
need to time-synchronize all players.
  
 Also I think we should not focus on the carrier itself, I think we should
 send
 the data of an object like an aircraft or carrier or whatever over the
 net.
 Such a thing has positions (position and orientation) and a timestamp (may
 be
 something to identify the object).
 Additionally it has a list of properties it needs to send (Some
 deflections -
 whatever).
 In a first stage, I think, we can send just the propery names together
 with
 the values in each packet.
 
 In a second stage, think about a scheme where we do not need to resend the
 mapping between the property names and the values in each packet.
 May be a separation between a 'realtime packet' only having a uuid to
 identify
 the model and some minimal binary data and a 'uuid description' which
 provides the mapping between the property values in the 'realtime packet'
 and
 the property names which need to be set from that values.
 
 For the election which properties need to be sent, there must be a, at
 best
 generic, mechanism to get that from the specific object (carrier, FDM,
 ...).
 Also Ideas, comments?
 

In general, Oliver's work plan seems a sensible way forward, and is
supported. The inclusion of the carrier in the multiplayer environment is in
particular a very worthwhile enhancement, which I think could be built on
existing code without too much difficulty (famous last words):-).

By choosing to work on the carrier first we can move incrementally to the
longer term aim of making all MP objects AI objects, thus making use of
existing methods of setting properties and extrapolating position etc. We
should not lose sight of this aim when designing the necessary messages.

We need to ensure that there is only one carrier named Nimitz in the
environment. (Other names are of course available). We also need to ensure
that the carrier model is moved smoothly otherwise I think there remains the
possibility that any aircraft on deck will become detached and fall off.
This might pose particular problems when initiating and/or updating. While
there is some low-pass filtering in AIShip, this might need enhancing. 

We only need send data on initiation and then on change.

So far as election of the feeder is concerned, network latency might do that
for us, although some there might be some risk that a deadlock might occur. 

Just some explanation and further thoughts, hopefully helpful

Regards,

Vivian 




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] build break with cygwin and gcc 3.4.4in FlightGear approach.cxx

2005-10-17 Thread Vivian Meazza
Georg Vollnhals wrote

 when I tried to build a CVS version of FlightGear I had a *lot* of
 trouble and errors. Many developers of this list tried to help me but
 the break-through was an advice of *KEVIN JONES* not to use gcc 3.4.4
 (what I had done until then).
 I followed his detailled instructions as he was just writing a
 tutorial/manual about building FlightGear 0.9.8/FlightGear CVS under
 Cygwin and all went fine. Absolute not problems with the build when
 using gcc 3.3.3 !!! Try it!
 Kevin will publish his tutorial/manual soon and I hope he is not angry
 about my answer.
 But he helped me so much with his advice at a time where I already had
 given up my trials because I would not show up here with another ask for
 help and all further hints did not work.
 So to repeat it, the key-advice for me was to go back to gcc 3.3.3!
 Thank you once again, Kevin Jones :-)
 And I hope it will help you too, Ima.
 Regards
 Georg
 
 
 
 Ima Sudonim schrieb:
 
  Hi,
 
  I am having a problem building flightgear on cygwin (cygwin updated
  last friday).
 
  I am using cvs from this morning. The GCC is cygming 3.4.4
 
  Any ideas what's wrong or how to fix it?
 
 

I was about to say that gcc 3.4.4 works here - then I remembered that it
doesn't - MIDG-II.cxx continues no fail with:

MIDG-II.o:MIDG-II.cxx:(.text+0x1067): undefined reference to
`SGFile::SGFile(std
::basic_stringchar, std::char_traitschar, std::allocatorchar  const)'

followed by a series of similar errors. 

It has been suggested here that it is a SimGear problem, but I have updated
and recompliled SimGear several times since I first reported this error.

I have fixed the error by removing the offending file from the makefile.
FG then compiles perfectly. 

FlighGear-cvs has failed to compile here under Cygwin/gcc 3.4.4 with a
series of different errors almost continuously since 10 Aug.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cygwin - Compile errors

2005-10-12 Thread Vivian Meazza
I wrote:

 
 Erik Hofman
 
 
  Vivian Meazza wrote:
   This mornings' cvs fails to compile here under Cygwin with the
 following
   error:
  
   MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)':
   MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is
   ambiguous
 
  This should be fixed.
 
   Since I don't need MIDG-II, I've fixed it locally by removing MIDG-
  II.cxx
   from the makefile.
 
  What, again?
  :-)
 
 
 er ... as usual :-) Quickest way - and involves absolutely no thought.
 

still problems with the accursed MIDG-II.cxx

MIDG-II.cxx: In member function `bool MIDGTrack::load(const std::string)':
MIDG-II.cxx:344: error: 'class SGFile' has no member named 'eof'
MIDG-II.cxx: In function `int myread(SGIOChannel*, SGIOChannel*, char*,
int)':
MIDG-II.cxx:379: error: 'class SGFile' has no member named 'eof'
MIDG-II.cxx: In member function `int MIDGTrack::next_message(SGIOChannel*,
SGIOC
hannel*, MIDGpos*, MIDGatt*)':
MIDG-II.cxx:410: error: 'class SGFile' has no member named 'eof'

Usual fix applied :-)

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cygwin - Compile errors

2005-10-12 Thread Vivian Meazza
Frederic Bouvier

 Quoting Vivian Meazza [EMAIL PROTECTED]:
 
  I wrote:
 
 
   Erik Hofman
  
   
Vivian Meazza wrote:
 This mornings' cvs fails to compile here under Cygwin with the
   following
 error:

 MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t,
 size_t)':
 MIDG-II.cxx:31: error: call of overloaded
 `ulEndianSwap(uint32_t*)' is
 ambiguous
   
This should be fixed.
   
 Since I don't need MIDG-II, I've fixed it locally by removing
 MIDG-
II.cxx
 from the makefile.
   
What, again?
:-)
   
  
   er ... as usual :-) Quickest way - and involves absolutely no thought.
  
 
  still problems with the accursed MIDG-II.cxx
 
  MIDG-II.cxx: In member function `bool MIDGTrack::load(const
 std::string)':
  MIDG-II.cxx:344: error: 'class SGFile' has no member named 'eof'
  MIDG-II.cxx: In function `int myread(SGIOChannel*, SGIOChannel*, char*,
  int)':
  MIDG-II.cxx:379: error: 'class SGFile' has no member named 'eof'
  MIDG-II.cxx: In member function `int
 MIDGTrack::next_message(SGIOChannel*,
  SGIOC
  hannel*, MIDGpos*, MIDGatt*)':
  MIDG-II.cxx:410: error: 'class SGFile' has no member named 'eof'
 
  Usual fix applied :-)
 
 Your SimGear doesn't seem up to date.
 

Well, I thought it was. Anyway I've updated SG again, and recompiled both it
and FG - same error. Hmm ... you ought to be right ... and eof() is in
SGFile.cxx, but it was before (I checked)

Can't spare the time to investigate further: MIDG-II is chopped as usual.

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cygwin - Compile errors

2005-10-12 Thread Vivian Meazza
Frederic Bouvier

 
 Quoting Vivian Meazza :
 
  Frederic Bouvier
   Your SimGear doesn't seem up to date.
  
 
  Well, I thought it was. Anyway I've updated SG again, and recompiled
 both it
  and FG - same error. Hmm ... you ought to be right ... and eof() is in
  SGFile.cxx, but it was before (I checked)
 
  Can't spare the time to investigate further: MIDG-II is chopped as
 usual.
 
 Multiple copies of SimGear then ?
 

Possible, but how does the rest of fg compile? Actually, I thought perhaps
I'd forgotten to make install. The shader animation works, and that's in the
cvs version only. 

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Cygwin - Compile errors

2005-10-11 Thread Vivian Meazza
This mornings' cvs fails to compile here under Cygwin with the following
error:

MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)':
MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is
ambiguous

/usr/include/plib/ul.h:334: note: candidates are: void ulEndianSwap(unsigned
int
*) near match
/usr/include/plib/ul.h:350: note:  void ulEndianSwap(int*) near match


I have up-to-date plib, sg, and fg cvs versions.
 
Since I don't need MIDG-II, I've fixed it locally by removing MIDG-II.cxx
from the makefile.

Regards,

Vivian

 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Cygwin - Compile errors

2005-10-11 Thread Vivian Meazza
Erik Hofman

 
 Vivian Meazza wrote:
  This mornings' cvs fails to compile here under Cygwin with the following
  error:
 
  MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)':
  MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is
  ambiguous
 
 This should be fixed.
 
  Since I don't need MIDG-II, I've fixed it locally by removing MIDG-
 II.cxx
  from the makefile.
 
 What, again?
 :-)
 

er ... as usual :-) Quickest way - and involves absolutely no thought. 

Thanks!

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: RFC: FlightGear 0.9.9

2005-10-03 Thread Vivian Meazza
Melchior FRANZ wrote:

 
 The new shadows should possibly be activated by default. Or does
 not enough 3D hardware/software support it, so that this would
 cause too many problems? Activate 3D clouds by default, too?
 

Both shadows and 3d clouds, although great eye candy, both cause a
significant frame rate hit, and should therefore be off by default IMHO.

And I'm not sure that we have a cvs version which compiles under Cygwin, at
least last time I tried a couple of days ago we hadn't. Or perhaps I should
say I haven't. That's not a FG problem - I haven't been able to compile
OpenAL under Cygwin yet. I have a workaround, of course. 

Regards,

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Never ending story: Building SimGear CVS underCygwin

2005-09-30 Thread Vivian Meazza
Georg Vollnhals

 
 Hi Vivian, hi Erik, hi all!
 
 Vivian:
 Thank you very much, one step further to SimGear (and to a FlightGear
 CVS version !!!):
 1. After you hint I could now activate cut and paste as it is not
 active by default.
 I made a little Google search and could solve it :-)
 2. I put your bash_profile vars into [cygwin/home/Georg/.bash_profile]
 (seems to be my special user profile) and it works very well.
The epheremis-error disappeared
 
 BUT THE NEXT PROBLEM OCCURED IMMEATELY:
 
 Erik:
 
 //THIS SEEMS TO BE QUITE A SIMILAR ERROR AS I HAD IT ALREADY
 //IN SWAP_TEST_CPP
 //AND ERIK HOFMANN FIXED IT (thank you Erik :-) )
 //(swap_test.cpp:12: error: not valid conversion of unsigned int* to
  uint32_t*
 //swap_test.cpp:12: Fehler: Argument 1 von void
 sgEndianSwap(uint32_t*) wird initialisiert
 //(swap_test.cpp:12: error: argument 1 of void
 sgEndianSwap(uint32_t*) gets initialised)
 

The problem in swap_test is corrected in the latest cvs - make sure that you
are up to date.

Do cvs -z3 update -P -A -d -C 

In your simgear/source directory

Then try again.

V.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] RE: Feedback: Building SimGear CVS under Cygwin

2005-09-29 Thread Vivian Meazza
Georg Vollnhals

 
 Hi all,
 further help is needed, please!
 
 /1. I have experienced exactly the same problem using WinCVS. The solution
 is
 /drastic - you have to delete the source directory created by WinCVS and
 /start over with a clean checkout using the command line cvs provided as
 part
 /of Cygwin. Then ./autogen, ./configure etc.
 /..
 /Vivian
 
 Thank you Vivian, this helped me to solve the problem but I got another
 one :-(
 Might be anyone had the same problem already solved?
 
 What I did until now:
 1. installed plib-1.8.4 without problems
 (./configure; make; make install)
 2. built SimGear CVS with Cygwin cvs command after deleting all old stuff
 3. unpacked and built zlib-1.1.4
 (tar xvfz ..; ./configure; make; make install)
 4. SimGear/source
 ./autogen.sh
 ./configure
 
 make - ERROR!
 

Yup - you were too soon - there were problems with SimGear/FlightGear-cvs
under Cygwin. These were corrected yesterday. Try again :-). You don't need
to do anything with zlib-1.1.4.

If you are using Norman Vines pre-prepared OpenAL stuff there is a further
problem, I think, you will need an earlier version of FlightGear
configure.ac ver 1.3 will do. DO NOT DOWNLOAD THIS WITH WINCVS OR YOU WILL
BE STARTING OVER. Guess who forgot ... duh.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Another error: Building SimGear CVS under Cygwin

2005-09-29 Thread Vivian Meazza
Georg Vollnhals

 thank you for your quick replies.
 I am sorry to show up here again with another error message .. but one
 solved, the next came :-/
 
 Erik:
 /Anyhow, I have fixed this in CVS now Georg, thanks for reporting this.
 /Erik
 This is solved, thank you!
 but this is the (very long, sorry) error output of make:
 (BTW: getting this errors is very educational. I had to read nearly an
 hour until
 I found out how to redirect the *error* messages under Cygwin bash with
 2.
 But the bash and me get more and more friends  :-) )

not really necessary - just copy/paste from the Cygwin window.
 
 (not translated, I only changed the German expressions
 Zeichen = char Fehler   = error)
 
 In file included from /usr/lib/gcc/i686-pc-
 cygwin/3.4.4/include/c++/vector:72,
  from ../../simgear/math/sg_types.hxx:40,
  from ../../simgear/misc/sg_path.hxx:36,
  from ../../simgear/ephemeris/stardata.hxx:31,
  from ephemeris.hxx:45,
  from ephemeris.cxx:28:
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In
 member function `void std::vectorbool,
 _Alloc::_M_insert_range(std::_Bit_iterator, _ForwardIterator,
 _ForwardIterator, std::forward_iterator_tag)':
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522:
 error: expected unqualified-id vor (-char
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In
 member function `void std::vectorbool,
 _Alloc::_M_fill_insert(std::_Bit_iterator, size_t, bool)':
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823:
 error: expected unqualified-id vor (-char
 In file included from /usr/lib/gcc/i686-pc-
 cygwin/3.4.4/include/c++/vector:75,
  from ../../simgear/math/sg_types.hxx:40,
  from ../../simgear/misc/sg_path.hxx:36,
  from ../../simgear/ephemeris/stardata.hxx:31,
  from ephemeris.hxx:45,
  from ephemeris.cxx:28:
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member
 function `void std::vector_Tp,
 _Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratortypename
 _Alloc::pointer, std::vector_Tp, _Alloc , size_t, const _Tp)':
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307: error:
 expected unqualified-id vor (-char
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member
 function `void std::vector_Tp,
 _Alloc::_M_range_insert(__gnu_cxx::__normal_iteratortypename
 _Alloc::pointer, std::vector_Tp, _Alloc , _ForwardIterator,
 _ForwardIterator, std::forward_iterator_tag)':
 /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384: error:
 expected unqualified-id vor (-char
 make[3]: *** [ephemeris.o] error 1
 make[2]: *** [all-recursive] error 1
 make[1]: *** [all] error 2
 make: *** [all-recursive] error 1
 
 Is this a gcc-error or error in ephemeris.* ???
 

Well, all I can say is that it compiles here, using gcc 3.4.4

I have found it necessary to add the following to my bash_profile:

LDFLAGS=-L/usr/local/lib
CXXFLAGS=-pipe -O2 -Wall -DWIN32 -DNOMINMAX -DHAVE_WINDOWS_H  
CFLAGS=$CXXFLAGS

export LDFLAGS
export CXXFLAGS
export CFLAGS

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Feedback: Building SimGear CVS under Cygwin

2005-09-26 Thread Vivian Meazza
Georg Vollnhals

 
 Hi Dave and Erik,
 this just as a feedback to your replies to demonstrate that your help was
 not for trash and I really tried to solve the problem:
 
 /Did you do a cvs -z3 up -Pd?
 /The -Pd flags cause cvs to add new directories and remove empty
 /directories from the tree. The above message indicates to me there is a
 /directory missing
 /Erik
 
 I use the Win32 CVS-GUI program with the command line
 cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/SimGear-0.3 co source
 as recommended by the FlightGear CVS page.
 I compared the stuff (folders, files) on my HD with that in the SimGear
 CVS library and found no
 diffence. Despite that I deleted all and built a complete new CVS on my HD
 (obviously with all subfolders and files).
 Same error messages as described after ./autogen.sh, ./configure and make.
 :-(
 
 /Try removing autom4te.cache and re-running autogen.sh.  Not sure if this
 is your problem, but it /often sorts out autotools problems for me.
 /
 /Cheers - Dave
 
 Tried it, same result as already described by me. :-(
 
 Erik and Dave, thank you very much for your prompt and gentle help.
 I give up *for now* as a have no valid knowledge of all this complicated
 stuff and it is like a blind man searching for something. Might be in 2006
 I am informed enough to try it again.
 Going now to other FlightGear stuff where I can help and hope for a new
 binary Win32 FlightGear release within the next months!
 Thank you once again for your help and time!
 

1. I have experienced exactly the same problem using WinCVS. The solution is
drastic - you have to delete the source directory created by WinCVS and
start over with a clean checkout using the command line cvs provided as part
of Cygwin. Then ./autogen, ./configure etc.

2. You can then go back to using WinCVS providing you DO NOT UPDATE THE ROOT
DIRECTORY. If you do then it's back to para 1 above. I learned this one the
hard way, and I still forgot, updated configure.ac the other day and whoops,
back to para 1

3. The problem is .infig.status: error: cannot find input file: \ . WinCVS
and Cygwin see different parts of the directory tree by default; the
solution must lie in the WinCVS settings somewhere, but I've never found it.
(I haven't tried too hard though).

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] new multiplayer patch

2005-09-22 Thread Vivian Meazza
Erik Hofman

 
 Oliver Schroeder wrote:
 
  The problem lies in XDR_encode_double() and XDR_decode_double(). Making
 all
  arguments const  did the trick. You can find my updated version here:
  http://www.o-schroeder.de/fg_server/tinyxdr.tgz
 
 It's committed.
 
 Erik
 

That seems to break Simgear under Cygwin:

swap_test.cpp:12: error: invalid conversion from `uint32_t*' to `unsigned
int*'

swap_test.cpp:12: error:   initializing argument 1 of `void
sgEndianSwap(unsigned int*)'

I don't think swap_test.cpp does anything, so I've removed it from the
makefile here

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear configure.ac, 1.94, 1.95

2005-09-16 Thread Vivian Meazza
Erik Hofman

 Martin Spott wrote:
  Hello Erik,
 
  Erik Hofman wrote:
 
 Update of /var/cvs/FlightGear-0.9/FlightGear
 In directory baron:/tmp/cvs-serv29428
 
 Modified Files:
 configure.ac
 Log Message:
 Prepare for OpenAL 1.1 and a separate alut lubrary.

Er ... Erik are you about to break Cygwin again?

Regards

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS:FlightGear configure.ac, 1.94, 1.95

2005-09-16 Thread Vivian Meazza
Erik Hofman

 Vivian Meazza wrote:
 
  Er ... Erik are you about to break Cygwin again?
 
 BTW, form the openal (1.1) Changelog:
 
 * More fixes for Cygwin/MinGW compilation plus some #include cleanups.
 The linux subtree compiles now under Linux, MinGW/MSYS and Cygwin
 (with and without -mno-cygwin).
 
 Erik
 

That sounds like really good news, but I hardly dare try - cvs has been more
or less broken under Cygwin since mid Aug. There are work-arounds but  

Vivian  


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] cygwin problems (was Re cvslogs etc)

2005-09-16 Thread Vivian Meazza
David Luff

 
 On 16/09/2005 at 10:34 Vivian Meazza wrote:
 
 Erik Hofman
 
  Vivian Meazza wrote:
 
   Er ... Erik are you about to break Cygwin again?
 
  BTW, form the openal (1.1) Changelog:
 
  * More fixes for Cygwin/MinGW compilation plus some #include cleanups.
  The linux subtree compiles now under Linux, MinGW/MSYS and Cygwin
  (with and without -mno-cygwin).
 
  Erik
 
 
 Fantastic :-)
 
 
 That sounds like really good news, but I hardly dare try - cvs has been
 more
 or less broken under Cygwin since mid Aug. There are work-arounds but
 
 Vivian
 
 
 If you mean FG cvs, it's compiling and running fine for me under Cygwin at
 the moment, with the exception of a couple of files in the utils directory
 that are easily tweaked to work.  I haven't updated Cygwin for a while
 though - it's gcc version 3.3.3.  It's possible I'm carrying local mods
 though that I've forgotten about.  What problems are you seeing?
 

In addition to those there's one general problem - --real-weather-fetch
which causes YASim to segfault. There's a workaround with JBSim. Harald's
working on a fix.

There's a problem which you probably aren't aware of - there's some new MP
code around which I'm testing, but which needs a fix to enable it to compile
under Cygwin. 

And of course there was the bug (in 3d clouds IIRC) which had me tearing my
hair out for the last 2 weeks of Aug. Fixed now - phew.

Like you, I have tweaked things so that cvs does compile under Cygwin. But
technically it's broken. 

The OpenAL sounds like good news. I'll have to untangle Norman's OpenAL fix
first though, I expect.

Vivian  


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Segfaults with real weather fetch

2005-09-15 Thread Vivian Meazza
Lee Elliott

 
 since updating from cvs yesterday I now seem to get segfaults
 whenever I try to use real-weather-fetch.
 
 Anyone else?
 

Everybody else: it's a known bug in 3dClouds which causes YASim to fail.  

We await a fix from Harald.

Just don't use real-weather-fetch until the fix is available.

Regards

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Question: Online forums?

2005-09-14 Thread Vivian Meazza
AJ MacLeod wrote

 Personally, I very much prefer mailing lists.  I can quite see the
 advantages
 of web-based forums, but I'm not convinced they outweigh the
 disadvantages.
 
 For one thing, it's much easier to keep up with the mailing lists, as I
 monitor my email through most of the day for real work purposes anyway.
 In
 contrast, although I do visit some web-based forums now and again, it's
 very
 infrequently, and you have to keep revisiting to see whether anything's
 been
 posted or not - automatic emails to say something's been posted would
 obviously be very annoying.
 

I'm in much the same situation as AJ, and agree with his view on this one.

Regards

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter and Citation Information Needed)

2005-09-03 Thread Vivian Meazza
Andy Ross

 
 Vivian Meazza wrote:
  YASim has not yet implemented shut down/start up controls for
  gas turbines.  Therefore there are none for the Hawker Hunter.
 
 As far as I can see, there is no generic implementation possible
 for turbine startup and shutdown.  Everything would have to be
 done specifically for each engine type.  Maybe the best thing to
 do would be to expose some appropriate inputs to the engine
 code (running or not, current RPM, station temperatures, etc...)
 and implement the details per-engine in Nasal...
 
 I'm wholely open to suggestions.
 
 FWIW: why do people care about this stuff so much?  Engine
 startup and shutdown is a boring, algorithmic, checklist task.
 It's not exactly what I'd call fun, and it certainly won't ever
 be implemented at a fidelity level useful for flight training.
 What's the deal? :)

No idea. I suppose flameouts and relights could enliven a dull mission.
Then we could do compressor surge, and bird strikes ... nah, forget it :-)

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Pulsing splash screen at startup (on Cygwin)

2005-09-02 Thread Vivian Meazza
Harald JOHNSEN

 
 Richard Bytheway wrote:
 
 ...
 
 
 
 The correction should be in cvs soon, or you can change in
 SG/timestamp.cxx line 119:
 #if defined( WIN32 )
 with
 #if defined( WIN32 )  !defined(__CYGWIN__)
 

Following earlier discussions with Harald, I did that change in 2 places, as
per the attached diff file. I'm not sure if it's strictly necessary, but
I've tested it extensively, and it seems to work.

Vivian 


timestamp.diff
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] CVS - Cywin Problems

2005-08-30 Thread Vivian Meazza
Some time ago I wrote that I was having trouble with CVS compiling under
Cygwin using gcc version 3.4.4-1, on a Pentium 4 2.8, with a Nvidia GForce
5200 using driver 77.77. FG complies without error, but hangs at the end of
loading scenery objects. Running --log-level=debug shows that the main
loop is in fact running, while the splash screen fades in and out at about 1
hz.

This behaviour has been confirmed by AJ on a similarly specified machine.
Meanwhile Norman Vine's version exits without any apparent fault or
exception at much the same point. 

After many trials it seems that the last date on which cvs compiled and ran
was around 10 - 12 Aug. Up to now it has neither proved possible to track
the date down more accurately, as the results are inconsistent, nor which of
SG or FG are to blame. I will continue to investigate further.

Regards

Vivian


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Simgear

2005-08-25 Thread Vivian Meazza
bass pumped

 any idea when we will see the next release?
 

Not for a while I hope - I've just spent 10 days trying to locate a bug
which prevents FG-cvs running under Cygwin. I've got as far as tracking it
to something introduced into SimGear about 7 Jul. 

Vivian




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] crashes in GL

2005-08-25 Thread Vivian Meazza
Jon Stockill

 
 Harald JOHNSEN wrote:
  Jon Stockill wrote:
 
  Due to the death of the machine I was doing all my flightgear work on
  I'm currently trying to set up another machine so I can still build
  packages, but I've run into a bit of a problem. While my old packages
  work ok on this machine (it's not gonna win any awards for framerates,
  but it proves it works) the current cvs code segfaults on startup like
  this:
 
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 16384 (LWP 18753)]
  0x401861b2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1
  (gdb) bt
  #0  0x401861b2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1
  #1  0x401863f3 in glXCreateGLXPbufferSGIX () from
  /usr/X11R6/lib/libGL.so.1
 
 
 
  #2  0x0846a17a in RenderTexture::Initialize (this=0x891d220, width=1,
  height=1075494657, shareObjects=false, copyContext=false)
  at RenderTexture.cpp:508
 
 
  You are not supposed to have this width and height, in the bbcache.cxx
  code there is
  rt-Initialize(256, 256, true);
 
 This gets stranger and stranger. I rebuilt the code from scratch
 (suggested by Harald), and it still failed with the same error. So I
 deleted the whole thing, and checked it all out from CVS again - a
 completely clean start. Same error. Checked out the code on another
 machine, built it, runs ok. Copied the binary from the working machine
 to the problem machine, and now the error is back - same binary,
 different machines, different result - a segfault caused by an out of
 range value which is supposed to be hard coded.
 
 Tests so far have ruled out plib/simgear/flightgear version problems,
 and compiler problems (since the working binary fails on the problem
 system).
 
 Does anyone have any idea where I should be looking before I go
 completely insane?
 

No, but if it's any compensation, cvs has been broken under Cygwin since,
well, I've tracked it back to around 7th Jul. For me it started when I
downloaded a clean copy. Norman Vine's version is exiting as soon as the
load sequence finishes, mine and a machine AJ is testing on hangs at the
same point.  At the moment the problem seems to be in Simgear, possibly in
Harald's new GL stuff, but that's a very tentative diagnosis. Right now I
can't see anything obviously wrong, and am really at a loss as to what to do
next. The last known good seems to be 7th Jul - you might like to roll cvs
(FG and SG) back to that point and see what happens.

I'd be interested to compare notes

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] crashes in GL

2005-08-25 Thread Vivian Meazza
Jon Stockill

 
 I rolled back cvs to 7th July, built flightgear, and still have exactly
 the same problem - I guess it's related to something on this system.
 
 --
 Jon Stockill
 [EMAIL PROTECTED]
 

And SG? Before you tear your system apart, AJ has just reported similar
symptoms over on IRC. He's just updated to CVS HEAD.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Multiplayer Location Transformation to Lat/Lon/Alt

2005-08-11 Thread Vivian Meazza
Alberico Family

 Jim Wilson did a good job of pointing me in the right direction toward
 making views attached to players in a multiplayer scenario.
 
 I attack it today and made good progress, but remain bogged down by the
 transformations required.  Bottom line is I need to take the 4x4 player
 position matrix and convert that to what is needed by the view properties
 (lat/lon/alt, etc.) The objective is to dynamically alter custom view(s),
 based on player positions(/orientation).
 
 A 2-part question, with hopes no one has to spend much time answering:
 1.) Can someone point me to a good writeup on the details of the various
 coordinate systems and transformations in FG?  (sorry: I'm sure that's
 been
 asked many times)
 2.) Is there a utility method existing somewhere in the code already to do
 these specific transformations?  It seems unlikely this is the first time
 someone is interested in taking the player positions and converting them
 to
 lat/lon/alt.
 
 Thanks in advance.  Maybe this will all become clear to me after tomorrow
 morning's coffee(s). sigh

Look in src/AIModel/AICarrier.cxx - there are several examples of
conversions from Cartesian co-ordinates to geodetic and vice versa.

There are a wide range of utilities in simgear/math.cxx. The comments are in
the most part self-explanatory, so you will probably find what you need
there.

Hope you succeed - we really need this one.

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobaticjet

2005-07-28 Thread Vivian Meazza
[EMAIL PROTECTED]

 
 
 At this site http://hcilab.uniud.it/pan  you can download the results of a
 joint
 project between the HCI Lab of the University of Udine
 and the aerobatic team of the Italian Air Force (the
 Frecce Tricolori).
 
 The Lab has produced a detailed, flyable model
 of the MB-339 PAN jet. The leader of the Frecce Tricolori
 (Capt. Tammaro) was a member of the development team
 and beta-tester of the model. Development took about
 1 year, at the end of which the Frecce Tricolori
 officially approved the public release of the model.
 
 
 -
 Visita http://domini.interfree.it, il sito di Interfree dove trovare
 soluzioni semplici e complete che soddisfano le tue esigenze in Internet,
 ecco due esempi di offerte:
 
 -  Registrazione Dominio: un dominio con 1 MB di spazio disco +  2 caselle
email a soli 18,59 euro
 -  MioDominio: un dominio con 20 MB di spazio disco + 5 caselle email
a soli 51,13 euro
 
 Vieni a trovarci!
 
 Lo Staff di Interfree
 -
 

Nice model. I particularly like the horizon ball.

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet

2005-07-28 Thread Vivian Meazza
Dave Culp

... snip ...
 
 The present system makes smoke/contrails by releasing AI objects rapidly.
 There are three problems with it now:
 
 1)  Orienting the objects properly.  Only applies for long (i.e.
 cylindrical,
 rectangular) models.
 
 2)  Matching the release rate to the airplane's speed.
 
 3)  Making a smoke model that merges well with the others.  I've heard (on
 this list) that this may be a plib limitation.  It may require the use of
 a
 different visual model, like billboards or particle fields.
 
 
 On the other hand, maybe a whole new tactic is needed.
 
 
I think Harald is working on this as an offshoot of his 3d clouds. I'm quite
sure we can't do better with the AI ballistic approach as it stands.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)

2005-07-27 Thread Vivian Meazza
Mathias Fröhlich

 
 Hi,
 
 On Sonntag 17 Juli 2005 10:16, Vivian Meazza wrote:
  Before we do any rework of the MP code, it works as is in 0.9.8 (with
 some
  bugs), but it is fundamentally broken in CVS. In cvs the received
 aircraft
  are displayed close to the observer, rather than in their proper
 locations.
  It works OK in 0.9.8. Melchior suggested this was something to do with
 one
  of your recent updates, but I haven't rolled back to establish if this
 is
  the case.
 
 The jitter removal patch was the cause for that.
 But to be honest, that current multiplayer protocol cannot really work.
 It transmits only offsets to the tile center without the information on
 which
 tile it is.
 This was more or less sufficient for the case we had the scenery center at
 the
 tile center. But flying across tile bondaries was still broken ...
 
 I have now included a patch to the multiplyer protocoll which does:
 
 1. place the 3d model into the scenery using a placement transform which
 can
 dynamically change its scenry center.
 2. Transmits unique position and orientation data for the 3d model.
 3. Thus breaks protocol compatibility.
  :-/
 
 Since the fg_server only forwards the network packets without looking into
 them, this will still work with that code.
 But the position data sent by a flightgear release version cannot be
 understood by the current version. The same holds for the other way.
 
 Opinions?
 
 Given that it will make that usable in some way I will vote for applying.
 
 Anyway, this protocol is very error prone since it neither cares for
 alignment
 nor for endianess. I don't know of it still works for x86_64, don't talk
 about the sgi's in Erik's zoo ...
 :)

This patch does not work for Cygwin. I'm not sure if Multiplayer ever worked
under Cygwin.

Norman Vine did a bit of quick diagnosis last night, and came up with a
cause and a fix. Apparently Linux uses 4 bytes while Cygwin uses 8 as
standard.

I attach Norman's diff against cvs/head.

Btw, if there any other Cygwin users still out there - I've just updated my
copy of Cygwin. The latest version gives a worthwhile improvement in both
file reading and in frame rate. 

Vivian


mpmessages.diff
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)

2005-07-24 Thread Vivian Meazza
Mathias Fröhlich


 
 On Sonntag 17 Juli 2005 10:16, Vivian Meazza wrote:
  Before we do any rework of the MP code, it works as is in 0.9.8 (with
 some
  bugs), but it is fundamentally broken in CVS. In cvs the received
 aircraft
  are displayed close to the observer, rather than in their proper
 locations.
  It works OK in 0.9.8. Melchior suggested this was something to do with
 one
  of your recent updates, but I haven't rolled back to establish if this
 is
  the case.
 
 The jitter removal patch was the cause for that.
 But to be honest, that current multiplayer protocol cannot really work.
 It transmits only offsets to the tile center without the information on
 which
 tile it is.
 This was more or less sufficient for the case we had the scenery center at
 the
 tile center. But flying across tile bondaries was still broken ...
 
 I have now included a patch to the multiplyer protocoll which does:
 
 1. place the 3d model into the scenery using a placement transform which
 can
 dynamically change its scenry center.
 2. Transmits unique position and orientation data for the 3d model.
 3. Thus breaks protocol compatibility.
  :-/
 
 Since the fg_server only forwards the network packets without looking into
 them, this will still work with that code.
 But the position data sent by a flightgear release version cannot be
 understood by the current version. The same holds for the other way.
 
 Opinions?
 
 Given that it will make that usable in some way I will vote for applying.
 
 Anyway, this protocol is very error prone since it neither cares for
 alignment
 nor for endianess. I don't know of it still works for x86_64, don't talk
 about the sgi's in Erik's zoo ...

That's got to be better than broken. Shame it's not backward compatible
though. Let's get it into cvs then we can move forward.

Norman Vine came up with some modified code over on the IRC channel:

globals-get_multiplayer_tx_mgr()-
SendMyPosition(globals-get_aircraft_model()-get3DModel()-
  get_POS() +
globals-get_scenery ()-get_center() );
I think that this is probably what wants to be sent in 
  FGMultiplay::process() {

Is this any good to us? Or does it conflict with your diff?

Vivian




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport

2005-07-23 Thread Vivian Meazza
Paul Surgeon

 
 On Saturday, 23 July 2005 14:04, Paul Kahler wrote:
  All this multiplayer chat stuff has me thinking game. It would
  probably be more in line with simulation if chatting took place on a
  simulated radio. You'd not only have to be close enough to someone, but
  you'd have to be on the same frequency in order to talk to them. The
  idea of having little on-screen identifiers might be OK as long as it
  can be turned off. I really like that FGFS focuses on simulation and not
  game play.
 
  If you want to be highly realistic, mutiplayer voice chat with proper
  radio frequencies would be ideal. Bandwidth might be a problem for large
  groups, but small ones should be no problem. Of course it's much more
  complicated too ;-)
 
 
 I was going to comment on this earlier but decided not too since I may
 step on
 someone's toes. However since we are now on the topic ...  :)
 
 The FS2004/IVAO network have voice comms working quite nicely.
 If you tune your radio in FS2004 to an active frequency (within range)
 TeamSpeak automatically connects to the server the frequency is hosted on
 and
 joins the channel.
 This happens in the background and is totally seamless.
 All you do is, tune to an ATC frequency and use the PTT key to make radio
 contact. Just like one would in real life.
 
 TeamSpeak doesn't use huge amounts of bandwidth and on the client side
 will
 happily run on a 56K dialup with multiplayer running.
 
 Chat windows are fine for development purposes but are totally evil and
 1980's
 technology when it comes to ATC.   :P
 In the early days of SATCO (pre VATSIM, IVAO) it was all text and it was a
 major pain to fly and try to type at the same time. Even shortcut keys
 used
 to build text messages were a pain.
 Getting a late landing clearance due to another aircraft clearing the
 active
 runway invariably meant an aerobatics display on short finals while trying
 to
 type a reply and configure for landing.
 
 One doesn't have to jump in the deep end by trying to implement all the
 features in one go.
 Someone can simply host a TeamSpeak server and create a KSFO_TWR channel
 which
 the pilots can join.
 Then when things get more busy we can add KSFO_APP, KSFO_CTR, UNICOM, etc.
 Getting TeamSpeak to switch servers and channels by tuning the radios can
 come
 at a later stage.
 

This has already been discussed. Teamspeak in not GPL'd. I think the
licensing arrangements would give us problems. That would be a pity, because
on the face of it, it's pretty much what we want. Certainly it's the right
way to go though.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] feature request: MultiPlayer's CallsignsinViewport

2005-07-23 Thread Vivian Meazza
Paul Surgeon

 
 On Saturday, 23 July 2005 16:08, Vivian Meazza wrote:
  This has already been discussed. Teamspeak in not GPL'd. I think the
  licensing arrangements would give us problems. That would be a pity,
  because on the face of it, it's pretty much what we want. Certainly it's
  the right way to go though.
 
  Vivian
 
 TeamSpeak doesn't have to be part of the FG package.
 It's a separate program that has an API you can interface to.
 
 People run FlightGear on MS operating systems which are not GPL either so
 I
 don't see what the issue is.
 
 Paul
 

As I understood the discussion, we are GPL, but Teamspeak is not. Therefore
we can't integrate it with our software. Nothing to stop groups of
individuals using it though.

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] suggestions/questions regarding multiplayer

2005-07-20 Thread Vivian Meazza
Oliver Schroeder

 Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza:
  Oliver Schroeder
   3) artificial life at airports
   [...]
  Would a dedicated instance of FlightGear running all the AI traffic
 needed
  and passing them to the server for distribution to all players do the
  trick? (filtering by range if that's how you decide to do it).
 
 I *think* that the flightgear client is kind of to big and this kind of
 program (lets call it injector) does not need all of its functions. Eg.
 there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a
 stripped down version of the flightgear client would be just what we need.

Yes FG is big, and would have unused functions. Against this has to be
balanced the time and risk in developing and maintaining a stripped down
version. I don't have a handle on the size of that task or the risks
involved.
 
I suggested some time ago that the first player's system might handle all
the admin tasks - that way you get the AI traffic, carrier movements etc.
virtually free. However, there are significant questions surrounding that
idea: in particular what happens when the first player leaves. It ought to
be possible for the 2nd player to take up the task, because both systems
should be aligned. There is also the load on the individual client to be
taken into account.

This is beginning to look like some of the NATO data links where there was
no central server, but each unit contributed to the whole environment. Hmm
...
 
  We should be aiming for the server to co-ordinate the whole environment
 -
  traffic, weather, time. We need to be clever about bandwidth though -
 and
  only send this kind of background data strictly when needed. The client
  FGFS will have to do much of the work, I suppose.
 
 There are arising some questions about it.
 First of all: what can and what should be handled by the server?
 Currently it knows only very few things about what it is actually serving.
 It
 knows a little bit about callsigns, will know a bit about distances and
 different kinds of clients in the near future.
 Adding knowledge to the server adds lines of code which have to be
 changed
 in order to improve things (code changes have to be done in the client
 _and_
 the server).
 What about letting a scriptable client (i.e. a striped down version of
 fgfs)
 do most of such things?
 

I'm not sure exactly what you mean by a scriptable client. Does this mean
that it has pre-scripted AI traffic, carrier movements, weather etc.? A
little crude perhaps, but effective, but see my comments above. On the other
hand we could tell each client what the AI traffic should be and let the
client do all the updating. Less bandwidth required, at the trade-off of a
build up of errors. Good enough for AI traffic, but perhaps not for the
carrier. Of course, this is what happens with the player aircraft - they
must already exist on the client system, and this could also be the case for
the AI traffic flightplan.

If you are saying that the server should have as little knowledge as
possible, then I would go along with that. I think the server probably needs
to coordinate the network time but beyond that ... there is a case for the
server to filter by range, but this could also be done by the client.

I have no strong view on how this should be achieved. We should build on
what we already have in order to achieve a fully coordinated environment. We
should not be re-inventing wheels, flaps or anything else :-)

Vivian




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] CVS

2005-07-20 Thread Vivian Meazza
Neville van Deventer


Hi List,
 
Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org
without getting the following error
 
Error validating location: I/O exception occurred: Connection refused: I
HATE YOU
 
I followed the Instructions on the web-site, and I get the same thing for
simgear as well.
 
Any suggestions on how I can connect to the CVS ??
 
Thanks in Advance
 
Neville van Deventer 

Works here. What _exactly_ are you doing? 

Any possibility that you have a virus on your system?

Regards,

Vivian

P.S. Please use plain text on this list



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] CVS

2005-07-20 Thread Vivian Meazza
Neville van Deventer

 
  Thanks for the responses Vivian and Curtis,
 
 In Future I Will use Plain Text, my Appologies ...
 
 OK, Setup and what I'm Doing,
 
 I Just tried it now again, while writing this message so you can check the
 logs for the past 5 min's or so, I've been thying this most of the day,
 but
 with no success.
 
 I'm using the guest username and password as described on the Web Page.

This definitely works

cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 login

CVS password: guest

I've just tried it.

Vivian




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-19 Thread Vivian Meazza
Peter Stickney

 On Monday 18 July 2005 18:25, Josh Babcock wrote:
 
  All the 3350s had this turbo/super setup. You can see it in some of
  these images:
 
  URL's snipped
 
 ... snip ...
 
 There were 3 flavors of the R3350.  One was the engine used on the
 B-29.  It had a single-speed gear driven blower.  The
 turbosuperchargers (The B-29 used 2 per engine - basically the same
 model used on the B-17 and B-24 - with twice the displacement, and
 about the same RPM, it needed twice the mass flow, and using the
 paired turbosuperchargers meant that they could deliver a working
 system without having to interrupt production) fed air at what were
 essentially sea level conditions to the engine's mechanical blower.
 The production versions peaked out at about 2200 HP, and a useful Full
 Throttle Height of around 25,000'.

OK, so what we have here is a 2 stage supercharger. The first stage is the 2
turbos and the second stage is the single stage gear-driven supercharger. 

I have enough data now for a reasonable simulation, but to make it more
accurate, I wonder if you could describe the action of the supercharger
pressure regulator? I can model it as just controlling the manifold pressure
between 0 and full. I interpret 0.8 (#8 on the dial) as being the setting
for full throttle height (military power). Settings 9 and 10 are emergency
settings. Did the controller act on the throttle, or a control a wastegate
to adjust the turbos, or just dump pressure, or? 
 
 But that's not the only way to do it.  I've been preparing a series of
 articles on supercharging reciprocating engines.   Is there any
 interest for me to pull some of it out and present it here?

Probably not here, but personally I would be _most_ interested in anything
you have on this subject. This list is a great place to learn, and this can
lead to more realistic simulation. If you like, send me anything you feel
like off-list, or point me to a website.

I have been struck by the lack of detailed information on the web on the
R3350, a stark contrast to the Merlin/Griffon.

Thanks

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] suggestions/questions regarding multiplayer

2005-07-19 Thread Vivian Meazza
Oliver Schroeder

 some of you may already have taken notice of my multiplayer server for
 flightgear (http://www.o-schroeder.de/fg_server). It's working quite well
 in
 sane environments but I want to improve it and therefor have some
 questions
 you may be able to answer.
 
... snip ...
 
 3) artificial life at airports
  The server gives a lot of opportunities. One of the first things which
 came
 to my mind was artificial traffic at airports. It should be fairly easy
 to
 write clients in any (network capable) language which do simulate a
 client.
 This can be simply a helicopter standing near a hangar or even a plane
 flying
 around an airport. This would disburden fgfs itself (since it does not
 need
 to create AI traffic itself) and allow an arbitrary number of artificial
 clients, each serving it's own airport (or whatever area), bringing life
 to
 many areas of the world without manipulating fgfs itself.
 

Would a dedicated instance of FlightGear running all the AI traffic needed
and passing them to the server for distribution to all players do the trick?
(filtering by range if that's how you decide to do it). 

We would like something like this for the carrier in any case. 

We should be aiming for the server to co-ordinate the whole environment -
traffic, weather, time. We need to be clever about bandwidth though - and
only send this kind of background data strictly when needed. The client FGFS
will have to do much of the work, I suppose.

Regards,

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] suggestions/questions regarding multiplayer

2005-07-19 Thread Vivian Meazza
Ampere K. Hardraade

... snip ...
 
 
  As Pigeon said, make that a separate window, because the ATC line is
  allready nearly impossible
  to read ;) It should not be hard to code but the atc code is not good
  for that (anyway it does not
  queue messages).
 I agree.  That ATC line is horrible.
 
 Use a Nasal-generated transparent window instead.  One will then have
 control
 over the font size, font style, font color of the displayed text, as well
 as
 the number of lines that can be displayed.  As for the message buffer, a
 queue can be used.  There is a queue written in Nasal already:
 http://cvs.flightgear.org/cgi-
 bin/viewcvs/viewcvs.cgi/data/Aircraft/A380/Systems/AFDX/Switch/queue.nas?r
 ev=1.3cvsroot=FlightGear-0.9content-type=text/vnd.viewcvs-markup
 

I don't think we want competing methods for essentially the same function.
If the ATC line is unreadable - (it's just about OK if you toggle the menu)
- then that needs fixing up as well.

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-18 Thread Vivian Meazza
Peter Stickney

 On Friday 15 July 2005 06:45, Vivian Meazza wrote:
  Josh Babcock
 
   Vivian Meazza wrote:
  
   
Josh Babcock ought to be asking for the turbo charger for the
 B29 now,
   but
hasn't yet (perhaps he's now using JSBSim?). I've been unable to
 find
   much
available on the web for the Wright R-3350. I'm doing some work
 on the
aircraft carrier right now, but I've done some preparation for
 the turbo
simulation.
  
   Nope, I've just been busy with animations and other non-fgfs
 stuff. I
   don't have much data on the R-3350-23, but I do have the pilot's
 manual
   and a lot of web sites. If someone is offering to help with the
 engines
   I would love it. I am available to give all the info I have. I
 don't
   really feel I know enough about engines to do this properly
 myself.
 
  If by 'someone' you mean me, then I guess I should help here. I need
 some
  thing to test my putative modifications to YASim on anyway.
 
  I need a few hard numbers, which perhaps you could give me or point
 me at a
  suitable web site/s:
 
 From a variety of sources, including the FAA Type Certificate Data
 Sheet E-218 (Wright Double Cyclone C18BA series) and the 1950 edition
 of Model Designations of USAF Aircraft Engines.
 
  1. propeller gearing.
 0.35:1
 
  2. max manifold pressure.
 Now - that will depend on the specific rating.  Exceeding the
 allowable boost for an RPM/Mixture combination is Very, Very Bad. (As
 in, as the P2V Manual puts it, Trouble is indicated by internal
 engine parts exiting teh exhaust stacks.
 
  3. full throttle altitude which may also be described as the
 critical
  altitude.
 
 Military Power - 2200 HP/2800 RPM/ 44 Hg / SL-25,000'  15 Minute
 limit
 For the engine and turbosupercharger combination.
 Without the turbo - (Mechanical blower only), the ratings were:
 2200 HP/2800 RPM/ 44 Hg /Sea Level
 2200 HP/2800 RPM/ 42 Hg / 7,000'.
 
 Note the decrease in MAP as altitude increses.  Wright Engines from
 teh late 1930s on were rated to a constant power, not a constnat
 Manifold Pressure.  As altitude increased, Temperature and Back
 Pressure (Not relevant for the turbo) decreased, giving more power
 for a given MAP. MAP was decreased to hold constant power.
 
 
  4. the rated HP and the rated altitude.
 
 Normal Power - 2000 HP/2400R RPM/ 42 Hg/  SL-25,000'  Continuous
 (Turbo)
 2000 HP/2400 RPM/42 Hg/ Sea Level
 2000 HP/2400 ROM/41 Hg/ 4200'  on the Mechanical blower only.
 
  5. take-off HP.
 
 2200 HP/2800 RPM / 44 Hg
 
  6. Copies of the relevant pages of the Pilot's Manual. Post these
 somewhere
  that I can access/fetch. Particularly any description of the
 variable boost
  control.
 
 That was the FE's job.  The supercharger system of a B-29, or any
 other turbosupercharged airplane worked like this: (Well, was
 supposed to work like this - Early B-17s and B-24s with the
 mechanical oil pressure driven turboregulators required more
 fiddling, but the electronic turboregulators used on later -17s, 24s,
 P-38s, P-47s, B-29s and subsequent airplanes did work like this)
 
 There was a potentiometer dial on the turboregulator control box that
 was calibrated from 0 to 10.  This selected the amount of output.
 from the turbo system as a whole, 0 being no output. The turbos
 supplied air to the inlet of the engine's mechanical supercharger at
 slightly over sea level ambient (29.92 on a Standard Day).  This was
 done to keep the turbo moving, so that it didn't freeze up due to
 poor lubrication at Sea Level.  The engine's throttle was set to
 provide whatever power conditions were required, and as the airplane
 climbed, the tubo's Volume Control was tweaked to keep providing
 its sea level conditions to the engine's supercharger.  The
 Turboregulator governed on the selected pressure rise (The Volume
 and turbo RPM and, often, bearing temperature.  The Pilot of Flight
 Engineer had no indication, or control over the turbo except the
 potentiometer.  As far as the engine was concerned, it was sitting
 happily at Sea Level the whole time.  Once it had reached the point
 where the turbosupercharger/mechanical blow couldn't supply the
 proper power conditions any more, power dropped off normally.
 
 I don't know, but it sound like you could be making things a bit more
 complicated than they were.  The Turbos were basically Black Boxes.
 There wasn't anything more to do with them but set them to the
 appropriate pressure rise  let them go.
 

Very helpful. I think you will find that the turbo pressure was controlled
by the pilot, at least at critical point of the flight. While the pilot can
regard the turbo as a black box, we need to know a little more about it so
that the FDM can be set up correctly.

This is the first reference that I have seen to a turbo/mechanical blower
combination. I would be interested in seeing your source. This is for the
R-3350-23?

Thanks

Vivian





___
Flightgear-devel mailing list

RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-18 Thread Vivian Meazza
Peter Stickney

... snip ...

 An addition/correction to my previous posting.
  Once it had reached the point
  where the turbosupercharger/mechanical blow couldn't supply the
  proper power conditions any more, power dropped off normally.

Yes. That's known as the full throttle altitude or the critical
altitude, and is important in setting up the FDM.

 As it turns out, the B-29's turboregulator control was a little bit
 different from what I described.  The Volume Control  governed off
 total system MAP.  If you set the potentiometer to , say, '*8, it
 maintained the overall MAP until the turbo reached its limits.  So,
 for example, you set the engines to Max Continuous, you wouldn't need
 to twiddle the turbos as you climbed from Sea Level to 25,000'+.
 Sorry if I cased some confusion, there.

OK, all is clear.
 
 Zeno's Warbirds has, IIRC, a Realplayer movie on flying the B-29.
 That's a pretty good resource.

An _excellent_ resource. Thanks for pointing us to it. Didn't show up on my
Google search for B29. Odd for such a good site.

Vivian





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-18 Thread Vivian Meazza
Josh Babcock

 
  As it turns out, the B-29's turboregulator control was a little bit
  different from what I described.  The Volume Control  governed off
  total system MAP.  If you set the potentiometer to , say, '*8, it
  maintained the overall MAP until the turbo reached its limits.  So,
  for example, you set the engines to Max Continuous, you wouldn't need
  to twiddle the turbos as you climbed from Sea Level to 25,000'+.
  Sorry if I cased some confusion, there.
 
  Zeno's Warbirds has, IIRC, a Realplayer movie on flying the B-29.
  That's a pretty good resource.
 
 True, though for some reason I have not checked it out. I do have the
 .ram file that points to the stream though. Also, note that to go past 8
 on the turbo dial required opening a safety latch and per the pilot's
 handbook was not to be done for more than 2 min. which I think is the
 equivalent of the RAF WEP. I'm not sure what bearing this has on the
 engine modeling but at some point I should put in a nasal script to blow
 up the turbos after some extended period at settings above 8. I'll have
 to figure out what conditions would actually cause a failure though.
 

Thanks to Peter's input, I think that:

a. I now understand the operation of the turbo regulator

b. Have the numbers to proceed. 

If we assume the critical altitude to be 25,000 ft with the boost at 0.8 (#8
on the dial), everything should fall into place. WEP (or combat power)
should fall naturally out of this calculation.

Failure - don't worry about the conditions :-). After about 5 mins or so,
according to OAT, the rear row of the cylinders would overheat, leading to
an engine fire which burnt through the firewall, causing catastrophic
failure of the wing main spar. Should be easy enough to model! Apparently,
this was not really cured until the up-engined version which was the B50.

V.





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Overhauling the networking code (was:Multiplayer crashes with unknown aircrafts, any solution?)

2005-07-17 Thread Vivian Meazza
Mathias

 
 Hi,
 
 this is a very good idea IMO.
 I was thinking about a very similar approach but never had the time and
 not
 yet the actual need to follow that.
 
 If you do something like that, you might take care for the MATHWORKS guys
 which use the network code like it is at the moment. So one will need
 probably some compatibility mode here.
 

Before we do any rework of the MP code, it works as is in 0.9.8 (with some
bugs), but it is fundamentally broken in CVS. In cvs the received aircraft
are displayed close to the observer, rather than in their proper locations.
It works OK in 0.9.8. Melchior suggested this was something to do with one
of your recent updates, but I haven't rolled back to establish if this is
the case. 

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Overhaulling the networking code

2005-07-17 Thread Vivian Meazza
Harald JOHNSEN

 Ampere K. Hardraade wrote:
 
  [...]As to /surface-positions, the properties inside this node can
  allow one to see
 
  the animations of others correctly.
 
 Displaying an animated aircraft won't be easy. Animation code in xml
 file is refering properties from
 the FG property tree (ie the user property tree) so we need a way to
 change some properties
 during the rendering of a MP aircraft. Perhaps can we do this with a
 temporary aliasing in the tree
 so that some branches point to the MP aircraft ?

Multiplayer models are already animated - gear goes up/down correctly. The
problem is that all models are controlled by the receiving player, not the
transmitting one. Shouldn't be too hard to fix.

 There is also some data/properties that can be guessed depending on the
 current 'action'.
 We can do a good guess of the different surface position for some
 standard manoeuvres.
 We can draw a smooth gear up/down animation without knowing the real
 value of
 /gear/gear[0]/position-norm for example, and if we were using this value
 it would be
 impossible to have a smooth animation because of the latency of the
 network.

Is this the right approach? Could we include e.g. the gear up command in a
message, and let the rx system sort it out? That's almost what happens now.
Smooth transitions already happen, but, as I said, under the control of the
rx player.
 
 In the future we could also consider to have one server handling all AI
 objects for the clients
 to have a coherent environment. Imagine that you are training landing on
 the Nimitz with
 your friends but the ship is at a different position on each client.
 This would be very weird.

Very good idea, and weather. I don't suppose clouds would be easy?

Vivian 




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Overhaulling the networking code

2005-07-17 Thread Vivian Meazza
Harald JOHNSEN


 Vivian Meazza wrote:
 
  Multiplayer models are already animated - gear goes up/down
  correctly. The
  problem is that all models are controlled by the receiving player, not
 the
  transmitting one. Shouldn't be too hard to fix.
  Is this the right approach? Could we include e.g. the gear up
  command in a
  message, and let the rx system sort it out? That's almost what happens
  now.
  Smooth transitions already happen, but, as I said, under the control
  of the
  rx player.
 
 Yes, so we can say they are not animated atm.
 
 receiver property tree using the c172p model
 root0\
 |-position/*
 |-surface/*
 |-other properties
 
 'player' 1 property subtree in receiver memory using a Concorde model
 root1\
 |-position1/*
 |-surface1/*
 |-eof
 
 'player' 2 property subtree in receiver memory using the ufo model
 root2\
 |-position2/*
 |-surface2/*
 |-eof
 
 So on the receiver side the c172p.xml, concorde.xml and ufo.xml
 animation code point to the root0
 property tree so all animations will reflect the receiver plane
 animations.
 An apparent simple hack is to change the root while rendering other
 'player' models
 but this will break because the root1  root2 don't contain all the
 necessary properties to render
 a model. That's why I was thinking of doing this while renderering a model
 :
 root0\
 |-position/ = point to /root1/position1
 |-surface/ = point to /root1/position1
 |-other properties
 
 So the receiver should manage a subset of the property tree for each
 transmitters.
 
 Concerning animation command I won't pretend that it is the way to do it
 in FG, but this is done like that
 in all MP games. Sending keyframe animation sequence is a waste of
 bandwith and worse of all
 it gives ugly results. This can work on a local network with a 50 ms
 ping but not on the internet
 with a 250ms ping. But this is only an optimization and has no impact on
 the design of the mp code.

Now I'm not sure I understand the problem, let alone the answer. I'm sure
that you can come up with a good answer. Keyframe animation?

 Very good idea, and weather. I don't suppose clouds would be easy?
 

 Cloud movement is based on wind direction and speed so it should be the
 same at all time if the
 initial situation is the same. To construct the initial situation I
 think it's enought to send the cloud layer
 information and the delta time during the connection to the server.
 

It would be highly desirable to get at least the gear and flap animation,
and the weather/clouds sorted. I'm not sure that I feel a pressing need for
flight-control surfaces to be animated. 

I guess the first player will set the environment for all subsequent
players, or would the server have some say in this? How would the initial
conditions be the same, since players enter and leave at any time? What
would happen when the first player left the sim? Would METAR data be
updated? Could/should the server provide METAR data and time? Pretty much
thinking out loud here.

V. 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Overhaulling the networking code

2005-07-17 Thread Vivian Meazza
Vassilii Khachaturov

 
  Very good idea, and weather. I don't suppose clouds would be easy?
  
  Vivian
  
  Cloud movement is based on wind direction and speed so it should be the
  same at all time if the
  initial situation is the same. To construct the initial situation I
  think it's enought to send the cloud layer
  information and the delta time during the connection to the server.
 
  Harald.
 
 Why is there any need at all for the cloud info to be sent over the
 network? Since it's obvious that the FDM is local anyhow, and one
 could always cheat with it, some conventions must be needed anyhow.
 If everybody uses the real-time WX feed, everybody will fly consistent
 and see consistent clouds on the screen. Or are you talking about making
 everybody having the same clouds at the precisely same spots, not
 just the general cloud layer properties?

Ideally cloud layers, thickness, types etc. should all be the same. Same for
wind and turbulence. I'm sure that we can do it. At least by ensuring that
initial conditions are all consistent.   

 At this moment, I am skeptical about getting WX updates from the server.
 Does server-side push of WX update to everybody make sense at all other
 than
 the fact that this way it might be possible to cut down on the traffic
 to the metar NOAA feed? 

Well that's probably worth doing.

 The downside is that probably the WX update
 comes less frequently than other planes' position update; if a
 a plane update is dropped, it's not a big deal, just its next movement
 will be a bit more jerky; whereas if a wx change is missed,
 things will fly differently. 

They certainly will fly differently if they don't get the same weather by
some means. Have you now countered your own argument? We could make life
interesting by having 2 duty runways crossing each other, and no ATC.
 
 Another downside is that everybody
 needs metar from different places, so in the worst case, with N
 players flying in N different places on the Earth, the total data
 sucked off NOAA is the same, yet the server now must be the
 one doing it all. Of course, if everything is just doing pattern work
 at KSFO, there may be some saving achieved...

N players at N different places. Not a lot of fun in that, but I guess it
could happen. Then the load on NOAA is the same in either case. In all other
cases there would be a (small) saving.

Don't forget, in FlightGear realism is everything.   

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] One bug with multiplayer...

2005-07-16 Thread Vivian Meazza
Vassilii Khachaturov


  On a side note, while testing the multiplay mode, robitabu on
  #flightgear irc and I have discovered the Instant Replay is also sent
  to all other players. Kind of a nice feature when you want to show
  people stuff, but also probably something you don't want all the time...
  :)
 
 That's pretty cool! it's pretty harmless though, isn't it? also,
 when people want to see others' action a lot, and one is lazy to do
 takeoffs/landings all the time, this can be a nice alternative
 to the boring AIs in single-player --- fly a nice circuit one time,
 and loop it via the network to the others.
 
 I wonder if during the replay the others' positions is shown current
 (i.e., wherever they're during the replay), as it were during the original
 play, or not shown at all (which would be my bet)?

Not shown at all, so far as I can see.

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-15 Thread Vivian Meazza
Andy Ross


 Vivian Meazza wrote:
  You certainly are! The Boost Control works by adjusting the
  _throttle_ (in accordance with reality and your earlier suggestion).
 
 Why not just use a solution setting that doesn't involve the boost
 control cutout?  

Why? The Merlin has a Boost Control Cutout, and the code works. But you are
still confused - the Boost Control replaces the function of the misnamed
wastegate, controlling the manifold pressure by retarding the throttle. This
was your proposal which I implemented with Melchior's assistance. 

 I'd think that a flat out solution would be most
 likely wrong anyway -- that's where engines are going to vary the most
 between installations.  Choosing anything at the edge of a performance
 envelope and expecting the conditions to hold in the middle is always
 problematic.  What's wrong with using a cruise value for the cruise
 solution?

I do use the cruise value - based on the full throttle altitude. It's fine.
YASim provides a good solution. Very impressive.

  The patch in my previous email, combined with your recent cvs input
  does all that is required, both now and in preparation for the
  supercharger/turbo charger thing. If you can suggest a way of doing
  it using the existing code, then I'm listening.
 
 As I read it, though, your patch is currently a noop.  All it does is
 add a new configuration option and adjust the handling of the
 wastegate in a way that will never make a difference in practice
 (skipping the wastegate handling for superchargers is irrelevant --
 supercharged engines already have a very high wastegate setting that
 cannot be reached by an engine, running or not).

I'm afraid that you are quite, quite wrong here. Supercharged engines do not
have a high wastegate setting, and it is readily reached by the running
engine over much of its operating range. This is what the full throttle
height means. The Merlin's Boost Control operates from sea level up to the
full throttle height, which can be up to 22,000ft depending on model. 

 I'm not arguing against it in principle.  I'm just saying that I'm
 going to wait until we have a real issue that needs to be solved;
 using the _running boolean (which just indicates whether fuel is being
 burned) 

Actually it means that the magnetos are  O and engine rpm  60, but of
course you know that. But I'm going to revisit this.

 is not the right mechanism long-term. Can you explain again,
 really carefully, exactly what behavior this patch gives you that you
 need right now?

This patch does the following:

a. ensures that the manifold pressure is ambient when the engine is not
turning.

b. allows a windmilling engine to develop supercharger/turbo pressure

c. skips the wastegate if the parameter 'supercharger' is true so that the
Boost Control function which _you_ suggested be written (in Nasal), and
which Melchior and I spent several days writing and tuning, can operate
instead of the wastegate function. 

d. It allows accurate data to be used in the wastegate parameter. While the
wastegate function is skipped, the wastegate parameter still has to be
entered accurately to allow YASim to solve properly.

This patch really is needed to allow the Merlin engine simulation to work
properly. With it in place it is possible to plug in the numbers from the
contemporary performance curves and get a simulation which closely matches
the published figures. 

I'm going to try to do some work on Josh's B29 engines next.

Hope this answers all your queries.

Vivian






___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-15 Thread Vivian Meazza
Josh Babcock

 Vivian Meazza wrote:
 
 
  Josh Babcock ought to be asking for the turbo charger for the B29 now,
 but
  hasn't yet (perhaps he's now using JSBSim?). I've been unable to find
 much
  available on the web for the Wright R-3350. I'm doing some work on the
  aircraft carrier right now, but I've done some preparation for the turbo
  simulation.
 
 Nope, I've just been busy with animations and other non-fgfs stuff. I
 don't have much data on the R-3350-23, but I do have the pilot's manual
 and a lot of web sites. If someone is offering to help with the engines
 I would love it. I am available to give all the info I have. I don't
 really feel I know enough about engines to do this properly myself.

If by 'someone' you mean me, then I guess I should help here. I need some
thing to test my putative modifications to YASim on anyway.

I need a few hard numbers, which perhaps you could give me or point me at a
suitable web site/s:

1. propeller gearing.

2. max manifold pressure.

3. full throttle altitude which may also be described as the critical
altitude. 

4. the rated HP and the rated altitude.

5. take-off HP.

6. Copies of the relevant pages of the Pilot's Manual. Post these somewhere
that I can access/fetch. Particularly any description of the variable boost
control.

That would be a good start. If the best data you have is already in the
existing config file, then I can work with those. I take it that you YASim
config file in cvs contains the right locations etc for the engines? I can
re-measure, of course, but it will save time.

This should be too difficult if we can get some good data.

Vivian







___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-15 Thread Vivian Meazza
Andy Ross

 
 I wrote:
  We're about to go in circles again, and my blood pressure is rising.
  So try this: DON'T reply to my message paragraph by paragraph.
  Start from scratch, post a configuration file that you want to use
  that does not work.  Explain why.  Use numbers.  Ask for
  suggestions.  Don't touch the C++ code until you have convinced me
  of what you want to do.
 
 OK, I gave this some thought on the train on the way to work, and I
 think I understand now what you are trying to say: the cutout system
 is Nasal-based, and won't run during solution.  It also engages during
 the specified cruise parameters, something that I was expecting it
 would not*.  So you want to use the wastegate setting as a proxy for
 the boost control, but you are stymied because if you use the
 wastegate, it then becomes active at runtime.

Yes, good old train. Nearly right, except we now have a Boost Control
(nasal) which replaces the function of the wastegate. The Boost Control
Cutout is part of this implementation. This is just terminology - your
analysis is correct. We no longer need a wastegate for the supercharger (and
only the supercharger - not the turbo), but have to have an accurate
'wastegate-mp'(perhaps we should call it max-mp) setting so that YASim
solves correctly.  

 * Are you sure it does?  The boost control will be actively modifying
   the throttle at low altitudes and high throttle settings.  Cruise is
   generally at high altitude and middle throttle.  My guess is that it
   would *not* be active, honestly.  High performance cruise is what
   the engine was tuned for -- the boost control is there to prevent it
   from damaging itself in non-optimized situations.

Yup. Absolutely sure - we have curves of boost against altitude at max power
rpm which show exactly at which altitude the Boost Control stops operating
for most of the Merlin variants. This altitude is called the full throttle
altitude. So we set the cruise values at the full throttle altitude. We
know exactly the relevant data at this point. With a bit of experimentation
we can derive an accurate turbo-mul parameter and everything falls into
place for the full speed supercharger gear ratio, including non-full
throttle settings. We also have full throttle altitudes for the medium speed
supercharger gear, so we can experiment further to get the right number for
the lower boost setting. The combat power also falls out along the way when
the Boost Control Cutout is operated. We have a very good simulation at the
cost of very little effort or code.
 
 Does that sound like what you want?  If so, then I argue that the way
 to do this is to map a property input to the wastegate pressure.  You
 can then use an otherwise-unused property to set it to whatever value
 you want for solution, and leave it at a very high value in the
 property system for runtime usage.

I'm not sure about this on 3 counts: 

1. Does Nasal initialise before YASim runs the solver or after?

2. I'm not clear what you mean by an otherwise-unused property

3. We have a perfectly good solution in C++ already. As you have said we
will need the supercharger Boolean when we need to differentiate between
gear-driven superchargers and turbos. This is nigh, because Josh has reached
the point where he would like to do the B29 turbo-charged engines. We (I
that is) will shortly be testing a more appropriate curve for turbo output
pressure v rpm. 

It would also be highly desirable to fix the ambient pressure at zero rpm
and the windmilling outputs. The diff does this, albeit I realize that you
consider it imperfect, it is better than that in cvs right now, and would
surely do as a temporary fix until you can find the time to come up with
something better. The diff certainly doesn't break anything.

Vivian 





 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-14 Thread Vivian Meazza
Andy Ross

 Vivian Meazza wrote:
  Back from a holiday in France. The modified software tests OK
  here. One small snag: the MP is not ambient when the engine is not
  running. Strictly, this should be turning, I suppose, because a
  wind-milling supercharger will produce some pressure. Near enough
  though.
 
 Yeah, good point.  But it's more complicated than running vs. not
 running I think.  If a normally aspirated engine is turning with the
 throttle closed (whether or not it is burning fuel), it will try to
 suck a vacuum in the manifold.  Superchargers will produce the same
 RPM-to-boost curve as they do when the engine is running, because
 their impeller is being driven at the same speed.  

Already fixed in the patch.

 But turbochargers
 don't, because their impeller is driven by exhaust pressure; in a
 windmilling situation, the exhaust pressure is going to be *less* than
 ambient and the turbo will want to turn backwards! (No idea if this
 actually happens or not -- is there a relief system to prevent this?)

No - a windmilling engine is an air pump pushing air from the inlet manifold
to the exhaust manifold, to the extent allowed by the throttle. The near
vacuum in the inlet manifold is a symptom, not a cause, and air will not
flow in the reverse direction, unless the engine suddenly stops pumping.
(perhaps in the event of catastrophic failure). A windmilling turbo engine
will provide a small positive pressure to the power turbine, but not to the
same extent as a gear-driven supercharger. 

 Anyway, the bug here is obvious: playing with the throttle on the
 ground with the engine shut down cause the manifold pressure gauge to
 move up and down, which clearly doesn't happen in reality.  But a fix
 is going to be subtle and hard, so I'm willing to live with this until
 we can come up with a realistic set of requirements.

Fix is already in cvs. Are you using the right version

 While we're listing obvious shortcomings of the current model, note
 that it also doesn't handle intercooling, which I'd argue is more
 important than getting idle/windmilling manifold pressure correct. :)

I've been thinking about intercooler/aftercooler (there is a subtle
historical difference) recently. I concluded that you can regard the
supercharger (1st stage/intercooler/2nd stage/aftercooler, or any
combination) as simply producing an output pressure (or temperature, I
think). If you know the full throttle (aka critical) height, you can set the
turbo-mul parameter accordingly, and that seems to produce an accurate
enough simulation. Trying to simulate the effects of any charge cooling (and
I forgot - the fuel is introduced upstream of the supercharger in the Merlin
to aid cooling and mixing) supposes a level of detailed knowledge which I
don't think we have available. You might come to a different conclusion. 

Idle manifold pressure is important - otherwise we'll never get the aircraft
to land! Anyway - that was fixed by your cvs input.
 
  I've wasted a couple of days coming to the conclusion that the
  published graphs for the Merlin show the so-called boost pressure
  in psi absolute, with zero at 1 atmosphere.
 
 You mean gauge, right?  Normally absolute pressure connotes
 interpreting zero as vacuum.

Yes. I meant pressure measured against a standard, not against ambient. The
current parameter mp-inhg is all that I need (suitably manipulated to turn
it into Brit units). No problem: all works well, once I understood what the
graphs that I have were using.

  Moving on, the Boost Control/Boost Control Cutout has been written
  in Nasal.  This works well, but YASim needs to be told to ignore the
  wastegate. I tried setting an improbable value for the wastegate,
  but of course, YASim uses the wastegate value when solving, so this
  doesn't work.
 
 I'm a little confused.  The boost cutout works by mapping a property
 name to the wastegate setting.  You can set that property to any value
 you like (say, 100) during solution.  Note that the improbably
 high wastegate mechanism is actually the way that YASim implements
 this internally.  For a normally aspirated engine, the _maxMP value is
 set to 1.0e06, so I know that this will work.

You certainly are! The Boost Control works by adjusting the _throttle_ (in
accordance with reality and your earlier suggestion). If the Boost Control
is to work, then the wastegate must be non-op. I thought I could do this by
using, say, 300 inhg for the wastegate setting, but this doesn't work
because YASim uses this value in the solution. So, while YASim needs the
accurate wastegate (or more correctly - max MP) for its calculation, it has
to skip applying this so that the Boost Control (which includes the Boost
Control Cutout) can function. No problem - fix is in the patch.  

 The supercharger Boolean isn't a bad idea in principle, as it will be
 needed eventually to handle the difference between turbocharging and
 supercharging.  But I'd rather wait until we have

RE: [Flightgear-devel] Shadows

2005-07-13 Thread Vivian Meazza
Harald JOHNSEN wrote

... snip ...

 Perhaps can we use a real ogl light for the aircraft landing light and
 fake light for the airport lights,
 and since the view is centered on the aircraft the hack could be good
 enought.
 

Are you going to progress OGL lights for aircraft landing lights?

I'm holding off doing fake landing lights on my models pending a better
solution (that's my excuse anyway :-) )

Regards

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New super/turbo MP code is in

2005-07-13 Thread Vivian Meazza
Andy Ross

 Vivian Meazza wrote:
  Meanwhile, you are distracting Andy from updating the awaited
  supercharger code.
 
 Heh, fair enough.  This is checked in now, with a general rewrite
 to clarify things and fix the bug where MP was reported before
 the wastegate application.
 
 The only new property is boost-gauge-inhg, which represents the
 delta between the actual MP and ambient pressure (not strictly
 correct, of course, but good enough for a first cut).
 
 I ran the solver over a bunch of piston planes, and didn't see
 much change, so I think this should be OK.  If everyone could fly
 a circuit or two in their favorite piston-engined plane and
 report success, that would be helpful.
 

Back from a holiday in France. The modified software tests OK here. One
small snag: the MP is not ambient when the engine is not running. Strictly,
this should be turning, I suppose, because a wind-milling supercharger will
produce some pressure. Near enough though.

I've wasted a couple of days coming to the conclusion that the published
graphs for the Merlin show the so-called boost pressure in psi absolute,
with zero at 1 atmosphere. Illogical, but by making that assumption, I can
readily adjust the turbo-mul parameter to make the full-throttle height
accord with the published figures. Once this is adjusted, the rest of the
simulation seems very close. Overall, most satisfying.

Moving on, the Boost Control/Boost Control Cutout has been written in Nasal.
This works well, but YASim needs to be told to ignore the wastegate. I tried
setting an improbable value for the wastegate, but of course, YASim uses the
wastegate value when solving, so this doesn't work. 

I attach a patch which addresses both issues. This adds a Boolean parameter
supercharger to the config file. If this is true, the wastegate function
is skipped over, so that the supercharger output can be controlled by the
Boost Controller via the throttle.

Vivian 


yasim4.diff
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] CVS for OpenAL

2005-06-30 Thread Vivian Meazza
Simon Hollier

 
 Andy Ross wrote:
  Simon Hollier wrote:
 
 Andy Ross wrote:
 
 And your usage of the ellipsis is non-standard; it should
 represent missing text.
 
 It did represent missing text: Some of use were tought, 
 
 
  Except that text wasn't missing.  You quoted it, remember?  And even
  if not, it was *my* text and can't be inserted into your sentence
  using an ellipsis.  Just give up, you can't win. :)
 
 
 Fair enough, but I could win ;)
 
 
  The original point was serious, by the way.  Screaming at developers
  is a bad way to get tech support, and bass pumped didn't seem to
  understand why Martin was annoyed.
 
 Agreed!
 

Meanwhile, you are distracting Andy from updating the awaited supercharger
code. 

Being careful with both syntax and spelling,

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Shadows

2005-06-26 Thread Vivian Meazza
Harald JOHNSEN

 Paul Kahler wrote:
 
 Oh does that sound like a bad hack. What happens to objects that have
 specular highlights? Would the illumination be as if the sun were
 shining rather than the spotlight? Lighting is important, but this
 doesn't seem like it's physically correct at all. OTOH, fake lighting is
 better than no lighting ;-)
 
 Paul
 
 
 
 You are right, this is totaly incorrect lighting. For correct lighting
 and correct specular we should use an
 Opengl light for each light source. The problem is that opengl is sill
 slow for spot lights, and there can be
 more than 100 light around an airport. Of course opengl can not handle
 more than 8 lights in hardware
 (and I am not sure that it is still realtime on lot of machines) so we
 would have to switch ogl lights
 depending on the position of objects or ground geometry... a bit
 overkill I think.
 Perhaps can we use a real ogl light for the aircraft landing light and
 fake light for the airport lights,
 and since the view is centered on the aircraft the hack could be good
 enought.
 

I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce
5200, the frame rate hit is about 10 in external view (I can live with it)
and no noticeable effect in internal - perhaps 1 or 2.  

There's a bit of a funny with the interaction between the Hurricane
propeller disk and the ac shadow: it makes the shadow disappear, and there's
something throwing a shadow on to the disk, which I've not seen in real
life, although I might not have noticed it. Is there anything I can do
within the ac model to tidy this up?

It would be nice to assign 2 of the 8 OpenGL lights to ac landing lights.

Well done indeed

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Shadows

2005-06-26 Thread Vivian Meazza
Frederic Bouvier

 Vivian Meazza a écrit :
 
 I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia
 gForce
 5200, the frame rate hit is about 10 in external view (I can live with
 it)
 and no noticeable effect in internal - perhaps 1 or 2.
 
 
 Yes, it is very nice. I have a drop of 10 fps ( 50 - 40 ) when I enable
 all ( ac + ai + to )
 
 There's a bit of a funny with the interaction between the Hurricane
 propeller disk and the ac shadow: it makes the shadow disappear, and
 there's
 something throwing a shadow on to the disk, which I've not seen in real
 life, although I might not have noticed it. Is there anything I can do
 within the ac model to tidy this up?
 
 
 
 2 stranges things that I know are inherent to the shadow volume technique
 :
 1. even when surfaces are smoothed, the shadows are hard and apply to a
 whole quad when a fuselage shadows itself ( try the A320, look at the
 airframe and press t to see what I mean ).
 2. transparent surfaces ( the suspension chains of the bridges, or the
 metallic structures ) produce filled shadows.

Yes, I can see that. The markings on the Hunter are on separate transparent
object: these throw a shadow. It seems as if I'm going to abandon that
method if shadows are to be usable with that model. Pity; it saves a huge
amount of artwork and texture. The edges of the shadows are a bit too hard;
a little penumbra would be good 
 
 Let wait the hardware to catch up a hit, and we could have clouds and
 mountains casting shadows ;-)

Nice if aircraft could throw shadow on cloud.

Altogether it's a nice enhancement.

V.







___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] cygwin simgear problem

2005-06-25 Thread Vivian Meazza








tom bonnell



Not really, except to say that Ive compiled the cvs
version under Cygwin successfully in the last couple of days. 



Do you have a reasonably up-to-date version of Cygwin?



I take it that plib compiled correctly?



You might like to try the cvs version.



Vivian





In the
make process of simgear 3.8 undercygwin I get these errors. can you help?

/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:
In member functio
n `void std::vector_Tp,
_Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratorty
pename _Alloc::pointer, std::vector_Tp, _Alloc , size_t, const
_Tp)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307: error:
expect
ed unqualified-id before '(' token
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In member
functio
n `void std::vector_Tp,
_Alloc::_M_range_insert(__gnu_cxx::__normal_iteratort
ypename _Alloc::pointer, std::vector_Tp, _Alloc , _ForwardIterator,
_ForwardI
terator, std::forward_iterator_tag)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384: error:
expect
ed unqualified-id before '(' token
make[3]: *** [ephemeris.o] Error 1
make[3]: Leaving directory `/cygdrive/c/simgear/simgear/ephemeris'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/cygdrive/c/simgear/simgear'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/cygdrive/c/simgear/simgear'
make: *** [all-recursive] Error 1

__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 








___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-25 Thread Vivian Meazza
Josh Babcock

 
 Vivian Meazza wrote:
  Josh Babcock
 
 
 
 Right now I've only researched the RR Merlin in any detail. Enough for
 
 our
 
 current range of supercharged models. I don't know if Josh Babcock
 needs
 anything special for the B29.
 
 
 I had done some research on the R-3350s, but it was a while ago. I do
 know that the turbos are controled by an amplified rheostat, which I
 think controls the the waste gate.
 
 Josh
 
 
 
  Yes, that would be logical.
 
  Unless you have any turbo output pressure v height data, then I would
 expect
  that the standard wastegate will model this well enough. Was there any
 form
  of override which you would like to model?
 
  Are we going to get out hands on this model soon? I think there are
 quite a
  few people looking forward to it, I know I am.
 
 Weekly updates at http://jrbabcock.home.comcast.net/flightgear/superfort
 I think Gerard was going to be commiting this, I'll have to check and
 see what's up.

The link doesn't work. I think it might be time to consider giving aircraft
designers cvs access for their own work. 
 
 I'm not sure if that main control qualifies as an override. It's just a
 dial that goes from 0 to 10 with a small mechanical safety switch for
 going higher than 8. The pilot was supposed to st it to different
 numbers at different power conditions and phases of the mission. 9 and
 10 were for emergencies.

Looks as if the pilot could adjust the wastegate settings in flight thus
controlling the turbo output. This will need a bit more investigation in
YASim. You are doing the B29 in YASim?

V.  



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] cygwin simgear problem

2005-06-25 Thread Vivian Meazza
Fred

 There was a similar problem report not far ago. It seems cygwin switched
 recently from gcc 3.3 to, and that is the problem.
 Vivian, what is your own version of gcc ?
 
 -Fred
 
 Vivian Meazza wrote :
 
  tom bonnell
 
  Not really, except to say that I've compiled the cvs version under
  Cygwin successfully in the last couple of days.
 
  Do you have a reasonably up-to-date version of Cygwin?
 
  I take it that plib compiled correctly?
 
  You might like to try the cvs version.
 
  Vivian
 
  In the make process of simgear 3.8 undercygwin I get these errors. can
  you help?
 

gcc 3.4.4-1 updated last Thursday. I've just downloaded simgear cvs/head,
and compiled. No problems here. 

I had a problem: I thought possible file corruption, which is why I updated.
It would certainly be worth trying going back to 3.3 and then re-downloading
3.4.4-1, which is what I did. I'm neither sure if that was the problem, nor
if that solved it, but it all works here now.

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-25 Thread Vivian Meazza
Jon Berndt

 
  Thanks,
  My question could be a question to Jon, Dave, and any JSB specialist.
  I just wonder, about, the opportunity to get profit of your work for
  developments on the JSB branch. The properties should be the same  on
  the global FG level.
  Both FDM -YASim -JSBSim with a different philosophic approach should
  give the same end results.
  
  --
  Gerard
 
 See the FGPiston.h file in JSBSim. See the constructor in FGPiston.cpp for
 exact specification in the new XML format (documentation pending). Here is
 some data on what can be specified:
 
 Models Dave Luff's Turbo/Supercharged Piston engine model.
 Additional elements are required for a supercharged engine.  These can
 be
 left off a non-supercharged engine, ie. the changes are all backward
 compatible at present.
 
 - NUMBOOSTSPEEDS - zero (or not present) for a naturally-aspirated
 engine,
   either 1, 2 or 3 for a boosted engine.  This corresponds to the
 number of
   supercharger speeds.  Merlin XII had 1 speed, Merlin 61 had 2, a
 late
   Griffon engine apparently had 3.  No known engine more than 3,
 although
   some German engines apparently had a continuously variable-speed
   supercharger.
 
 - BOOSTOVERRIDE - whether the boost pressure control system (either a
 boost
   control valve for superchargers or wastegate for turbochargers) can
 be
   overriden by the pilot.  During wartime this was commonly possible,
 and
   known as War Emergency Power by the Brits.  1 or 0 in the config
 file.
   This isn't implemented in the model yet though, there would need to
 be
   some way of getting the boost control cutout lever position (on or
 off)
   from FlightGear first.
 
 - The next items are all appended with either 1, 2 or 3 depending on
 which
   boost speed they refer to, eg RATEDBOOST1.  The rated values seems
 to have
   been a common convention at the time to express the maximum
 continuously
   available power, and the conditions to attain that power.
 
 - RATEDBOOST[123] - the absolute rated boost above sea level ambient
 for a
   given boost speed, in psi.  Eg the Merlin XII had a rated boost of
 9psi,
   giving approximately 42inHg manifold pressure up to the rated
 altitude.
 
 - RATEDALTITUDE[123] - The altitude up to which rated boost can be
   maintained.  Up to this altitude the boost is maintained constant
 for a
   given throttle position by the BCV or wastegate.  Beyond this
 altitude the
   manifold pressure must drop, since the supercharger is now at
 maximum
   unregulated output.  The actual pressure multiplier of the
 supercharger
   system is calculated at initialisation from this value.
 
 - RATEDPOWER[123] - The power developed at rated boost at rated
 altitude at
   rated rpm.
 
 - RATEDRPM[123] - The rpm at which rated power is developed.
 
 - TAKEOFFBOOST - Takeoff boost in psi above ambient.  Many aircraft
 had an
   extra boost setting beyond rated boost, but not totally uncontrolled
 as in
   the already mentioned boost-control-cutout, typically attained by
 pushing
   the throttle past a mechanical 'gate' preventing its inadvertant
 use. This
   was typically used for takeoff, and emergency situations, generally
 for
   not more than five minutes.  This is a change in the boost control
   setting, not the actual supercharger speed, and so would only give
 extra
   power below the rated altitude.  When TAKEOFFBOOST is specified in
 the
   config file (and is above RATEDBOOST1), then the throttle position
 is
   interpreted as:
 
 - 0 to 0.95 : idle manifold pressure to rated boost (where attainable)
 - 0.96, 0.97, 0.98 : rated boost (where attainable).
 - 0.99, 1.0 : takeoff boost (where attainable).
 
 A typical takeoff boost for an earlyish Merlin was about 12psi,
 compared
 with a rated boost of 9psi.
 
 It is quite possible that other boost control settings could have been
 used
 on some aircraft, or that takeoff/extra boost could have activated by
 other
 means than pushing the throttle full forward through a gate, but this
 will
 suffice for now.
 
 Note that MAXMP is still the non-boosted max manifold pressure even
 for
 boosted engines - effectively this is simply a measure of the pressure
 drop
 through the fully open throttle.
 

That all looks very good. Does your implementation of the Boost Control just
control the pressure, or does it act on the throttle as I understand was the
way it worked in the Merlin? In simulation terms the outcome is probably the
same.

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-25 Thread Vivian Meazza
Jon Berndt

  That all looks very good. Does your implementation of the Boost Control
 just
  control the pressure, or does it act on the throttle as I understand was
 the
  way it worked in the Merlin? In simulation terms the outcome is probably
 the
  same.
 
  V.
 
 Hi, Vivian:
 
 That would be a question for Dave Luff, who wrote that engine model for
 JSBSim. If I had
 time I'd look at the FGPiston.cpp code, but I've got really limited time
 today and
 tomorrow; I'm getting the new JSBSim code integrated with FlightGear,
 among other things
 I've got to do.
 
 The last post I see from Dave was about 6 months ago on the JSBSim list.
 

Don't worry, it was only for interest. I can poke around in the code for
myself.

Thanks

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-25 Thread Vivian Meazza
Josh Babcock

 
 Melchior FRANZ wrote:
  * Josh Babcock -- Saturday 25 June 2005 00:26:
 
 Weekly updates at http://jrbabcock.home.comcast.net/flightgear/superfort
 
 
  I committed this, as it looks very nice and even flies, and there was a
 kind
  of consense that this should be in cvs. I have yet to be able to land
 it,
  though. Always goes into a deadly spin if I turn ...  (There's some ugly
  garbage hanging on the right main landing gear, and both don't retract.)
 
  m.
 
 
 
 Hmm, the right one should retract. The ugly junk is for testing, and
 will go away. Right now the stall speed is unusually high, and stalls
 can get pretty violent. The turn indicator is by far the most important
 instrument right now. I have not had a chance to fix this.
 

I've been having a look at the yasim config files. There are some odd
entries. I've tried to do a little fixing up, but with no real success. I
think you need to go to the new propeller definitions.

I have a nagging memory that the Wright Cyclone R-3500 was fitted with
reduction gearing between the crankshaft and propeller, although I can't
find any reference to it right now. Do you have any details of the ratio?
It's needed to migrate to the new Yasim propeller definition.

You could use the R-2600 ratio, I suppose: 

Propeller Reduction Gear Ration (crankshaft to propeller): 16:9

That comes from here:

http://wrightpattjobs.wpafb.af.mil/museum/engines/eng42a.htm

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] RE: cygwin simgear problem

2005-06-25 Thread Vivian Meazza


 
 
 There was a similar problem report not far ago. It seems cygwin switched
 recently from gcc 3.3 to, and that is the problem.
 Vivian, what is your own version of gcc ?
 
 -Fred
 
 Vivian Meazza wrote :
 
   tom bonnell
  
   Not really, except to say that I've compiled the cvs version under
   Cygwin successfully in the last couple of days.
  
   Do you have a reasonably up-to-date version of Cygwin?
  
   I take it that plib compiled correctly?
  
   You might like to try the cvs version.
  
   Vivian
  
   In the make process of simgear 3.8 undercygwin I get these errors. can
   you help?
  
 
 gcc 3.4.4-1 updated last Thursday. I've just downloaded simgear cvs/head,
 and compiled. No problems here.
 
 I had a problem: I thought possible file corruption, which is why I
 updated.
 It would certainly be worth trying going back to 3.3 and then re-
 downloading
 3.4.4-1, which is what I did. I'm neither sure if that was the problem,
 nor
 if that solved it, but it all works here now.
 
 
 I downloaded cygwin from internet a day ago I used older version of
 cygwin and  compiled the same simgear.tar withot having any problems. I
 make and install zlib(in simgear)   plib1.8 and I think as you said the
 problem is caused from cygwin. What can i do TO MAKE it work??
 

You can go back to gcc-g++ 3.3.3 by opening Cygwin setup, checking the
appropriate box and re-downloading. That should fix the SimGear problem. If
not then you are stuck with going forward to SimGear-cvs and using
gcc-3.4.4. Either way, it's easy.

V.   



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-24 Thread Vivian Meazza


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-devel-
 [EMAIL PROTECTED] On Behalf Of Vivian Meazza
 Sent: 20 June 2005 13:13
 To: 'FlightGear developers discussions'
 Subject: RE: [Flightgear-devel] Re: New turbo/supercharger code
 
 Melchior FRANZ
 
 
  * Vivian Meazza -- Saturday 18 June 2005 12:22:
   void Thruster::setThrottle(float throttle)
   {
   _throttle = Math::clamp(throttle, 0, 1);
   }
  
   Will this prevent a negative value for:
  
   control-input axis=/controls/engines/engine[0]/boost-control
   control=THROTTLE/
 
  No, but this will:
 
  ControlMap.cpp:83:
 
map-src0 = map-dst0 = rangeMin(type);
 
 
  ControlMap.cpp:222:---
 
  float ControlMap::rangeMin(int type)
  {
  // The minimum of the range for each type of control
  switch(type) {
  case FLAP0:return -1;  // [-1:1]
  case FLAP1:return -1;
  case STEER:return -1;
  case CYCLICELE: return -1;
  case CYCLICAIL: return -1;
  case COLLECTIVE: return -1;
  case MAGNETOS: return 0;   // [0:3]
  default:   return 0;   // [0:1]
  }
  }
 
 
  There's no THROTTLE, so we get the default 0 set for map-{src,dst}0.
  You can avoid that by setting {src,dst}{0,1} explicitly, for example:
 
 control-input axis=/controls/engines/engine[0]/boost-control
src0=-1 src1=1 dst0=-1 dst1=1
  control=THROTTLE/
 
 
 Right - that fixes the problem.


With Melchior's valuable help I have developed a nasal simulation of the
Boost Control and Boost Control Cutout for the Hurricane. This should be
committed to cvs shortly. When a preset boost value is exceeded, the Boost
Control acts to reduce throttle opening. This action can be overridden by
the Boost Control Cutout which allows maximum boost. The output of the Boost
Control is smoothed by a low-pass filter selected by Melchior. You will
notice an overshoot and some lag if the throttle is opened quickly.

To make it work a patch (for cvs/head) is required to YASim - attached. A
new attribute 'supercharger' has been added to the aircraft config file.
When this is true, the attribute 'wastegate' no longer controls the
supercharger output. If you want to try the update to the Hurricane, you
will need to apply this patch. It will not adversely affect any other YASim
model, so far as I can tell.

Both the nasal and YASim patch are temporary; both will require reworking
when Andy comes up with his revision of YASim to include the new
supercharger code.

Any testing would be welcome, although Melchior is doing his best to break
it already! In particular any feedback on any adverse effects on other
models would be good.

Regards,

Vivian 


yasim3.diff
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-24 Thread Vivian Meazza
Gerard

  With Melchior's valuable help I have developed a nasal simulation of the
  Boost Control and Boost Control Cutout for the Hurricane. This should be
  committed to cvs shortly. When a preset boost value is exceeded, the
 Boost
  Control acts to reduce throttle opening. This action can be overridden
 by
  the Boost Control Cutout which allows maximum boost. The output of the
 Boost
  Control is smoothed by a low-pass filter selected by Melchior. You will
  notice an overshoot and some lag if the throttle is opened quickly.
 
  To make it work a patch (for cvs/head) is required to YASim - attached.
 A
  new attribute 'supercharger' has been added to the aircraft config file.
  When this is true, the attribute 'wastegate' no longer controls the
  supercharger output. If you want to try the update to the Hurricane, you
  will need to apply this patch. It will not adversely affect any other
 YASim
  model, so far as I can tell.
 
  Both the nasal and YASim patch are temporary; both will require
 reworking
  when Andy comes up with his revision of YASim to include the new
  supercharger code.
 
  Any testing would be welcome, although Melchior is doing his best to
 break
  it already! In particular any feedback on any adverse effects on other
  models would be good.
 
  Regards,
 
  Vivian
 
 Do we have the same project, on JSBSim ?
 What must be done for it ?

I'm not sure where the supercharger stuff is at on JSBSim. Certainly doesn't
have a Boost Control Cutout. I'm not working on it - I've only just begun to
understand YASim. One thing at a time :-). I'm not aware of any requirement
in JSBSim 

Right now I've only researched the RR Merlin in any detail. Enough for our
current range of supercharged models. I don't know if Josh Babcock needs
anything special for the B29.

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-24 Thread Vivian Meazza
Josh Babcock

 
 
  Right now I've only researched the RR Merlin in any detail. Enough for
 our
  current range of supercharged models. I don't know if Josh Babcock needs
  anything special for the B29.
 
 
 I had done some research on the R-3350s, but it was a while ago. I do
 know that the turbos are controled by an amplified rheostat, which I
 think controls the the waste gate.
 
 Josh
 

Yes, that would be logical.

Unless you have any turbo output pressure v height data, then I would expect
that the standard wastegate will model this well enough. Was there any form
of override which you would like to model?

Are we going to get out hands on this model soon? I think there are quite a
few people looking forward to it, I know I am.

V. 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Lights was: Shadows

2005-06-22 Thread Vivian Meazza
Martin Spott

 Roman Grigoriev wrote:
 
  We can simply use ARB extension - that support on ATI and NV but if you
 want
  get some boost knowing some aspects of architecture sometimes up to 30%
 you
  can simple use vendor specific extentions.
 
 I simply fear exactly such proceeding this will manouvre FG into (a)
 vendor specific corner(s) and offend numerous users,
 

Not if Roman makes the hardware-specific extensions user-selectable, and as
I understand it, that is his proposal.

I think Roman should press on with this at full speed. It's been hanging
around for years. I would love to have some code to test. It all looks very
attractive.

Regards,

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Re: gear/flaps handling (b29, hurricane, ...)

2005-06-22 Thread Vivian Meazza
Melchior

 
 And this is by no means innovative. Andy had done this for several
 control functions already. Just a few were/are missing. What is new
 is the fact that the default bindings for gear and flaps do now also
 report key/button release. This is required for gear/flaps without
 defined 'notches', that can stop anywhere during movement. An overriding
 function *can*, but doesn't *have* to use this information. The default
 wrapper doesn't. The b29's maybe will. (The Hurrican doesn't either. :-)
 


The Hurricane will, once I get my head around it. Right now it's spinning
from so many cvs updates :-). And the Electric system seems to be bent if
not broken. Something else to fix.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] latest OpenAL not compatable?

2005-06-21 Thread Vivian Meazza
Dave Culp

 
 I just downloaded the latest OpenAL from CVS and can't get SimGear to
 compile
 with it.  Here's the error:
 
 if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../..  -
 I/usr/X11R6/include
 -g -O2 -D_REENTRANT -MT openal_test1.o -MD -MP -MF
 .deps/openal_test1.Tpo
 -c -o openal_test1.o openal_test1.cxx; \
 then mv -f .deps/openal_test1.Tpo .deps/openal_test1.Po; else rm -f
 .deps/openal_test1.Tpo; exit 1; fi
 /usr/local/include/AL/alut.h: In function `int main(int, char**)':
 /usr/local/include/AL/alut.h:52: error: too few arguments to function
 `ALboolean alutInit(ALCchar*, ALCdevice**, ALCcontext**)'
 openal_test1.cxx:42: error: at this point in file
 

What are you trying to compile it on?

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Short Reference Document error?

2005-06-20 Thread Vivian Meazza


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-devel-
 [EMAIL PROTECTED] On Behalf Of Jon Berndt
 Sent: 20 June 2005 01:33
 To: FlightGear developers discussions
 Subject: RE: [Flightgear-devel] Short Reference Document error?
 
  So, you think the UK is part of Europe, eh? We use the same convention
 as
  the US for ./,
 
  Vivian.
 
 Heh. :-) What's above the number 4 (not on the numeric keypad)? Is it a
 $ or a ?
 (not sure that will print correctly)?
 
 Jon
 

Er ... $ I have no difficulty with that :-) No € (euro) though :)).

V.
attachment: winmail.dat___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Re: New turbo/supercharger code

2005-06-20 Thread Vivian Meazza
Melchior FRANZ

 
 * Vivian Meazza -- Saturday 18 June 2005 12:22:
  void Thruster::setThrottle(float throttle)
  {
  _throttle = Math::clamp(throttle, 0, 1);
  }
 
  Will this prevent a negative value for:
 
  control-input axis=/controls/engines/engine[0]/boost-control
  control=THROTTLE/
 
 No, but this will:
 
 ControlMap.cpp:83:
 
   map-src0 = map-dst0 = rangeMin(type);
 
 
 ControlMap.cpp:222:---
 
 float ControlMap::rangeMin(int type)
 {
 // The minimum of the range for each type of control
 switch(type) {
 case FLAP0:return -1;  // [-1:1]
 case FLAP1:return -1;
 case STEER:return -1;
 case CYCLICELE: return -1;
 case CYCLICAIL: return -1;
 case COLLECTIVE: return -1;
 case MAGNETOS: return 0;   // [0:3]
 default:   return 0;   // [0:1]
 }
 }
 
 
 There's no THROTTLE, so we get the default 0 set for map-{src,dst}0.
 You can avoid that by setting {src,dst}{0,1} explicitly, for example:
 
control-input axis=/controls/engines/engine[0]/boost-control
   src0=-1 src1=1 dst0=-1 dst1=1
 control=THROTTLE/
 

Right - that fixes the problem.

Before:

In the config file:

control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
control-input axis=/controls/engines/engine[0]/boost-control
  control=THROTTLE/

Outcome:

boost: 0 
type: hurricaneIIb
YASim solution results:
   Iterations: 1
 Drag Coefficient: 1000
   Lift Ratio: 1
   Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201

After:

In the config file:

control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
  control-input axis=/controls/engines/engine[0]/boost-control
   src0=-1 src1=1 dst0=-1 dst1=1
control=THROTTLE/

Outcome:

boost: 0
type: hurricaneIIb
YASim solution results:
   Iterations: 2202
 Drag Coefficient: 6.39448
   Lift Ratio: 886.777
   Cruise AoA: 2.52573
   Tail Incidence: -2.34135
Approach Elevator: -0.270048
CG: -3.420, 0.000, -0.200

The 2 throttle axes are additive now. All seems to be OK to move onto the
next phase: put something meaningful in
=/controls/engines/engine[0]/boost-control.

My WAG is that the problem is that
=/controls/engines/engine[0]/boost-control is being initiated with
something that YASim doesn't like, Melchior's addition sorts that out.

Thanks Melchior - good spot.

Regards,

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-19 Thread Vivian Meazza
Andy Ross

 
 Vivian Meazza wrote:
  control-input axis=/controls/engines/engine[0]/boost-control
 
  Here is the setting in the property browser
 
  Controls/engines/engine/boost-control= 1.0
 
 Case bug or just a typo?
 

Oh, were it that easy! Unfortunately, neither - my mail client did that -
it's right in the code.

I've checked n times.

V.





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-19 Thread Vivian Meazza
Andy Ross wrote

 Vivian Meazza wrote:
  I would deduce that the property:
  Controls/engines/engine/boost-control
  Does not exist when the solver runs.
 
 It should still see a zero for undefined properties, 

What does it do for defined properties that contain null/nil? 

 although you can
 make arbitrary property settings in the approach/cruise definitions up
 at the top.  Some of the aircraft

???
 
 Note again, though, that you appear to have a case bug.  The property
 tree name is controls, not Controls.

There is no case error, sorry to have mislead you here.
 
 I would back out your changes to the last version that works and
 re-add them one at a time.  The change to the property input for the
 throttle control will not cause a change in solution results.
 Something else must have been modified.

No - nothing else has been modified. I've gone back to the cvs-head version
of source and data. This is the _only_ change in the code anywhere:

!--control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/--
control-input
axis=/controls/engines/engine[0]/boost-control control=THROTTLE/

this is the solver output in fgfs:

YASim solution results:
   Iterations: 1
 Drag Coefficient: 1000
   Lift Ratio: 1
   Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201

Same thing using yasim.exe. You can check for yourself very quickly and
easily.

My hypothesis remains that the value of 

/controls/engines/engine[0]/boost-control 

is null/nil at solve time. Since this property hasn't been initialized with
this as the only change this ought to be the case??? If I do initialize the
property using nasal, then the outcome is the same, therefore I deduce that
the property remains null/nil despite apparent initialization until after
solve-time. I have had to add this to some nasal to work around this
elsewhere:

if (mp == nil){mp = 0};

But not in this test - the only change to cvs-head is as above.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-19 Thread Vivian Meazza
Andy Ross

  No - nothing else has been modified. I've gone back to the cvs-head
 version
  of source and data. This is the _only_ change in the code anywhere:
 
  !--control-input axis=/controls/engines/engine[0]/throttle
 control=THROTTLE/--
  control-input axis=/controls/engines/engine[0]/boost-control
 control=THROTTLE/
 
 Bingo.

Not. At least, only in the sense of RTB. This is where we came in. It might
not produce any thrust, but it should solve shouldn't it?

 That's the bug.  You commented out the throttle!  
 How is the
 engine supposed to produce thrust when the throttle input is zero? :)
 
 You need *both* the inputs for them to be added together.

Yes. I wish!

Next trial:

Config file:

control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
control-input
axis=/controls/engines/engine[0]/boost-control control=THROTTLE/

Output:

YASim solution results:
   Iterations: 1
 Drag Coefficient: 1000
   Lift Ratio: 1
   Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201

Do you suppose that whatever is or isn't in
/controls/engines/engine[0]/boost-control
Is breaking YASim?

And I've tried initializing /controls/engines/engine[0]/boost-control in
hardcode, and in Nasal, and in .XML - no difference. I can only think that
initialization creates the property with a null value, and then only gives
it the correct value after YASim has tried to use it and failed. I can show
that this is the case with NASAL, otherwise I wouldn't need this: 

if (mp == nil){mp = 0};

Any better theory? 

Vivian 




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-19 Thread Vivian Meazza


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-devel-
 [EMAIL PROTECTED] On Behalf Of Andy Ross
 Sent: 19 June 2005 18:34
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] New turbo/supercharger code
 
 Vivian Meazza wrote:
  Not. At least, only in the sense of RTB. This is where we came in. It
 might
  not produce any thrust, but it should solve shouldn't it?
 
 Er, huh?  I guess I don't understand how you think that would work.
 What the solver does is figure out how much drag the airframe needs to
 produce in order to meet the specified performance numbers.  If there
 is no thrust, then the only drag that works is zero and you get a
 failure.  I honestly thought everyone was clear on this point.
 
 This is going in circles.  Start with your working file.  Add *only*
 the line specifying the new boost control axis.  Touch nothing else.
 Don't come back until you make it work.
 
 I assure you that you will get the same solution after you add the
 axis.  Once it is there, you can start playing with it at runtime.
 
 Andy
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@flightgear.org
 http://mail.flightgear.org/mailman/listinfo/flightgear-devel
 2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-18 Thread Vivian Meazza
Andy Ross wrote:

 Vivian Meazza wrote:
  Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
  boost)
 
 Can you try it with the CVS code?  This may be interacting badly with
 your local changes, which makes debugging difficult.  Nothing in this
 mechanism should require any of the new code.

I've already done that, but didn't take exact readings; the outcome looks
the same, I think. I'll do it again. The new/old code should have no impact
on this.

 Also on this subject: I started integrating the RPM-based supercharger
 attenuation, and noticed that your code added three new engine
 properties:
 
 mp-pascals: Is this needed?  The standard so far for manifold pressure
has always been inHg.  Having lots of duplicate units around
complicates things; we can always do conversions in the panel
animations or Nasal code.

I don't use it: I only include it because I thought we ought to have SI
units.

 boost-pressure-psi-gauge: This looks to have been hardcoded to sea
level; it should be using ambient, no?  Also, must the units be
PSI, or can I change them to inhg?  The final name would then be
boost-gauge-inhg (units go last, and pressure is implicit in
the units).

OK with the name. PSI(gauge) is what we use over here, otherwise it's inhg
absolute for the US. Gauge-inhg makes no sense. In real life there's no
difference between the way the US and UK measure the pressure, it's the zero
on the gauge which is different, so I think it's correct the way it is.
Gives the right gauge readings anyway. 

 boost-pressure-inhg: Reading the code, this looks like an absolute
manifold pressure, and not a boost at all.  Is this a mistake, it
looks like a synonym for mp-inhg to me.

I named it that way to distinguish it from mp-inhg, which in the current
code reports supercharger output before the 'wastegate' is applied. The
existing mp-inhg should be retired or renamed to supercharger-output-inhg to
reflect what it reports (useful for testing). Then boost-pressure-inhg can
be renamed accordingly.

The important thing is for the pressure, in whatever units you want (apart
from gauge-inhg), is reported _after_ the 'wastegate' etc. have been applied
to the supercharger output. 

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-18 Thread Vivian Meazza
Andy Ross

 Vivian Meazza wrote:
  Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
  boost)
 
 Can you try it with the CVS code?  This may be interacting badly with
 your local changes, which makes debugging difficult.  Nothing in this
 mechanism should require any of the new code.
 
Here's the result of the short experiment conducted using a clean download
of the YASim directory from this morning cvs-HEAD:

This is the entry in the config file

control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/

Here is the setting in the property browser

Controls/engines/engine/boost-control= 1.0

Here is the output in the property browser

Engines/engine/mp-inhg = 145.518585 
Engines/engine/prop-thrust = 4230.001953
Velocities/airspeed-kt = 45.839

Same outcome. I guess that something somewhere isn't reading the input axis.
I haven't found it yet, but in passing (and only peripherally related to
this problem) I found this in thrusters.cpp 

void Thruster::setThrottle(float throttle)
{
_throttle = Math::clamp(throttle, 0, 1);
}

Will this prevent a negative value for:

control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/ 

when we get it to work?

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-18 Thread Vivian Meazza
I wrote:


I found this in thrusters.cpp
 
 void Thruster::setThrottle(float throttle)
 {
 _throttle = Math::clamp(throttle, 0, 1);
 }
 
 Will this prevent a negative value for:
 
 control-input axis=/controls/engines/engine[0]/boost-control
 control=THROTTLE/
 
 when we get it to work?


Another potential pooh trap?
 
// Returns the input/output range appropriate for the given
// control.  Ailerons go from -1 to 1, while throttles are never
// lower than zero, etc...
static float rangeMin(int type);
static float rangeMax(int type);

V.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] New turbo/supercharger code

2005-06-18 Thread Vivian Meazza
I wrote:

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-devel-
 [EMAIL PROTECTED] On Behalf Of Vivian Meazza
 Sent: 18 June 2005 11:23
 To: 'FlightGear developers discussions'
 Subject: RE: [Flightgear-devel] New turbo/supercharger code
 
 Andy Ross
 
  Vivian Meazza wrote:
   Engines/engine/boost-pressure-psi-gauge = 46.00167 (correct order of
   boost)
 
  Can you try it with the CVS code?  This may be interacting badly with
  your local changes, which makes debugging difficult.  Nothing in this
  mechanism should require any of the new code.
 
 Here's the result of the short experiment conducted using a clean download
 of the YASim directory from this morning cvs-HEAD:
 
 This is the entry in the config file
 
 control-input axis=/controls/engines/engine[0]/boost-control
 control=THROTTLE/
 
 Here is the setting in the property browser
 
 Controls/engines/engine/boost-control= 1.0
 
 Here is the output in the property browser
 
 Engines/engine/mp-inhg = 145.518585
 Engines/engine/prop-thrust = 4230.001953
 Velocities/airspeed-kt = 45.839
 
 Same outcome. I guess that something somewhere isn't reading the input
 axis.

Ok - problem solved, or rather, cause identified. The solver is failing
silently. This is the output:

YASim solution results:
   Iterations: 1
 Drag Coefficient: 1000
   Lift Ratio: 1
   Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201

I would deduce that the property:

Controls/engines/engine/boost-control

Does not exist when the solver runs. So now to try to get around that one.

V.
 



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


  1   2   3   4   5   6   >