RE: [Flightgear-devel] options scanninng sequence

[Vivian Meazza]

Martin Spott

 Erik Hofman wrote:
 
  1. $FG_ROOT should be a global value
  2. ~/.fgfsrc should be a personal preference
  3. fgfs --fg-root should be a one time option overriding the defaults
 
  Does anybody have any objection to reversing the order?
 
 _I_ don't object, to my impression you proposal is the only one that
 makes sense   but my voice is not deciding,
 
 Martin.
 --
  Unix _IS_ user friendly - it's just selective about who its friends are !
 --
 

Just to add that it doesn't work properly under my Cygwin, but then my home
directory is home/vivian meazza/. That's automatically generated by Cygwin
and I'm not changing it. I note, however that XP users will install FG in
C:\program files\FlightGear.

Further, I do NOT want the code automatically saving my changes, we should
be given the option on exit. Apart from downloading a new version of
preferences.xml, is there any way back to the default values: there should
be?

Is there an option to disable this facility? In its current state I don't
want it on my system. 

Vivian





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] options scanninng sequence

[Vivian Meazza]

Erik Hofman

 Vivian Meazza wrote:
 
  Just to add that it doesn't work properly under my Cygwin, but then my
 home
  directory is home/vivian meazza/. That's automatically generated by
 Cygwin
  and I'm not changing it. I note, however that XP users will install FG
 in
  C:\program files\FlightGear.
 
 Could you test the CVS version again?
 
  Further, I do NOT want the code automatically saving my changes, we
 should
  be given the option on exit. Apart from downloading a new version of
  preferences.xml, is there any way back to the default values: there
 should
  be?
 
  Is there an option to disable this facility? In its current state I
 don't
  want it on my system.
 
 I've added --enable-save-on-exit and --disable-save-on-exit.
 This is a bit of an odd puppy since I've implemented the suggestion from
 Vassilii and this particular property is saved inside the user
 preferences.xml file, so you should only have the specify
 --disable-save-on-exit once.
 

Look like what we want, thanks - I'm busy right now, but I'll test it later.

V.



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Multiplayer voice comunication

[Vivian Meazza]

Martin Spott

 
 Andrea Vezzali wrote:
  Hi All! Some time ago on the mailing list I read something about
  multiplayer's voice comunication, does anyone is working on that?
 
 No, the solutions that people proposed in the past had been blessed
 with disregard by most FlightGear developers.
 

Not by me, Martin. We're currently tearing our hair out trying to get a good
MP solution. If we come up with something presentable, we can then turn our
attention to your scheme.

Vivian



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Texture compression experiments in plib

[Vivian Meazza]

Tiago Gusmão

 I'm having a HW problem and i can't enable AGP in linux, which makes the
 hunter, b1900d and the Nimitz lower FPSs dramatically, which i believe
 is caused by the NVRAM filling up with textures thus forcing texture
 transfers to the card (GF4 MX 440 64MB)
 
 so after Surge mentioned texture compression, i added it in plib, with
 amazing performance improvements in those situations, It also appears to
 be improving FPS in general in other situations.
 
 it doesn't check for the extension, **before trying**, check glxinfo for
 the presence of EXT_texture_compression_s3tc
 it's just an ugly hack, works for me and likely everyone else with s3tc,
 but it's bad code, i know,
 
 a brief explanation: http://www.digit-life.com/articles/reviews3tcfxt1/
 spec:
 http://oss.sgi.com/projects/ogl-
 sample/registry/EXT/texture_compression_s3tc.txt
 

I've applied this patch to my copy of plib-cvs. With a nVidia FX5200 card
there is no improvement in frame rate around KSFO, or near Nimitz (but I
don't get a drop there anyway). I think there is an improvement around SF
and the bridges.

I was hoping that it might enable me to run Jon's new KSFO scenery with
Tiger data, but no improvement there at all. Either Jon has to reduce the
ploy count markedly, or I have to upgrade my video card! 

On the other hand, this patch seems to have no adverse effects either.

Vivian




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Multiplayer display - one question

[Vivian Meazza]

Martin Spott

 Christian Mayer wrote:
 
  The universal solution is to download the plane from the person who uses
  it (the download protocoll must be included in the FGFS network code).
 
 Wouldn't it be much easier if people simply contribute their work to
 the community ?
 Look, someone uses a free, OpenSource flight simulator called
 FlightGear to participate in a free, OpenSource multiplayer
 environment. This person uses an aircraft that he isn't willing to
 contribute to the community and the community does have no better
 idea than discussing how to automagically fill the gap ?
 Ask him to contribute his aircraft. If he contributes, then everyone
 will find his work at the well-known (TM) place, the one and only
 authorised aircraft repository. If he does not, simply kick him out !
 
 Scrathing his head,

Stop scratching, Martin, that's how it works right now: if the model doesn't
exist in your local directory, that client is disregarded - you don't
process the data, don't see a replacement ac, don't bump into a ghost. 

That's fine by me.

You will see that client on Pigeon's map, that's all that happens, and if
someone is using that facility to navigate, well that's OK too.

Vivian



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37alloc_id865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] ATC background chatter in CVS

[Vivian Meazza]

Curt

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of is L. Olson
 Sent: 09 January 2006 18:41
 To: FlightGear developers discussions
 Subject: [Flightgear-devel] ATC background chatter in CVS
 
 I just committed a set of atc background chatter wav files to the base
 package in data/ATC/Chatter/UK
 
 These are from around Heathrow.  I've set things up so it's relatively
 easy to drop additional sets from different areas in sibling directories.
 
 So everything to hear background chatter in FlightGear is now committed
 to cvs.
 
 After you update cvs from simgear/flightgear/flightgear-base and
 recompile, just run flightgear and select ATC Chatter from the File -
 Sound Configuration dialog box.  Some of the files are louder/more
 understandable than others ... but it's background chatter and useless
 ear candy so you are better off not trying to understand and pay
 attention to what is really being said anyway.
 
 But it's fun useless ear candy. :-)
 

Nice try - perfectly understandable transmissions here :-). It runs under
Cygwin for a while, then fails with:

next chatter in 37 seconds
OpenAL error (AL_INVALID_VALUE): bind_source (alGenSources)
Failed to generate audio source.

Vivian



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] ATC background chatter in CVS

[Vivian Meazza]

Curt

 Frederic Bouvier wrote:
 
 Quoting Vivian Meazza :
 
 
 Nice try - perfectly understandable transmissions here :-). It runs
 under
 Cygwin for a while, then fails with:
 
 next chatter in 37 seconds
 OpenAL error (AL_INVALID_VALUE): bind_source (alGenSources)
 Failed to generate audio source.
 
 
 
 It seems that alDeleteSources is only called when SGSoundSample::stop()
 is
 called.
 Not when the sample is deleted ( the destructor only do alDeleteBuffers
 in that
 case ). I don't know if SGSoundSample::stop() is called in this case but
 this
 could be a problem.
 
 
 
 Interesting catch, thanks Fred.  I made a small change to fg_fx.cxx to
 call the stop() function first.  Perhaps that will cure the problem.
 
 In looking at this, I notice that the current sound system shows signs
 of being migrated from plib and perhaps isn't written optimally for
 openal ...  At some point it might be worth getting an openal expert (or
 someone more familiar with openal than me) to take a pass through the
 code and see if there are places where things could be restructured or
 fixed up to reduce the chances of these sorts of problems.
 

That fixed it - Fred does it again :-)

Thanks for some a nice enhancement.


Vivian



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] TACAN Electrical Issue

[Vivian Meazza]

Ron Jensen

 
 I started playing with TACAN today.  While it is enabled in
 Aircraft/Generic/generic-systems.xml it is not energized in
 Aircraft/Generic/generic-electrical.xml and therefore only works with
 custom electrical files.
 
 Suggested patch:
 --- data/Aircraft/Generic/generic-electrical.xml2005-12-12
 21:31:53.0 -0700
 +++ /usr/share/games/FlightGear/Aircraft/Generic/generic-electrical.xml
 2006-02-03 01:12:42.0 -0700
 @@ -53,6 +53,7 @@
  prop/systems/electrical/outputs/transponder/prop
  prop/systems/electrical/outputs/autopilot/prop
  prop/systems/electrical/outputs/adf/prop
 +prop/systems/electrical/outputs/tacan/prop
/bus
 

This is quite deliberate. TACAN is not a generic instrument, and therefore
you need to add it specifically to the configuration of your aircraft.

Vivian  



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] TACAN_freq_dat

[Vivian Meazza]

Ron Jensen wrote:

 The file TACAN_freq.dat.gz contains the wrong frequency data for our
 use.  It contains the ground reply channel frequencies, as we are using
 the frequencies to look up TACANs and VORTACs in nav.dat.gz and
 nav.dat.gz uses the VOR channel frequencies.
 
 Attached are modified TACAN_freq.dat and carrier_nav.dat files.  I
 didn't do diffs because every line in both files changed.
 
 Note that not all TACAN channels have VOR channels assigned,
 specifically channels 001-017 and 060-069 both X and Y.  I left
 these channels set to the ground reply frequencies, but multiplied them
 by 10 to avoid conflicts with the VOR channel frequencies.  The ground
 reply freqs are in the 900-1200 MHz range, so this is appropriate.
 
 With these two files installed you can use the TACAN system to fly TACAN
 and VORTAC on the correct channels.  The carriers will still show up on
 025Y and 029Y, but you won't pick up China Lake if the Nimitz isn't
 active as it has moved to its correct channel, 053X
 http://www.airnav.com/cgi-bin/navaid-info?NID
 

Since the code generates a subset of the nav.dat containing only
TACAN/VORTAC entries at runtime, the correct way to do it would be to amend
the data in nav.dat.gz by adding the TACAN data as new entries. 

However, much as I hate to fix one hack with another, this does seem to be a
good fix for the problem.

Thanks 

Vivian




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Re: [PATCH][RFC] speech synthesis with festival

[Vivian Meazza]

Melchior FRANZ

 * Erik Hofman -- Monday 06 February 2006 13:35:
  The original code was written for/by John Wojnaroski so you might be
  asking this a the wrong time. Personally I feel it would be a nice
 addition.
 
 OK, then I'll continue to work on it (as I've done since yesterday).
 I'll make it so that the preferences file decides how many voices there
 are. For each /sim/sound/voice[*]/{text,volume,pitch,speed} there will
 a channel be opened to festival and maintained by the subsystem.
 We could then add aliases for copilot, instructor, etc. Would be nice
 if the b29 copilot reported gear down etc., or the bo105 copilot
 gave some navigation hints (I think we are too far already. :-)
 
 BTW: the whole thing won't depend on festival. One can easily write
 a few lines of perl to simulate a festival server and use the text
 for different purposes. For example, to let a human or a trained
 monkey read it. And all others can map the text to the screen.log.
 
 I'll start to commit once I got permission. (The old ATC voice
 thing will lose the /sim/sound/voice property first, which is used
 as an enabled flag, and finally die.)
 

I'm working at getting Festival to compile under Cygwin. They claim that it
does, and, while it's very long-winded, it's looking good so far ...

Vivian



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Re: [PATCH][RFC] speech synthesis with festival

[Vivian Meazza]

Curtis L. Olson

 
 Vivian Meazza wrote:
 
 I'm working at getting Festival to compile under Cygwin. They claim that
 it
 does, and, while it's very long-winded, it's looking good so far ...
 
 
 
 Is that pronounced WINE-D or WIN-D?
 

Nah - that's as in it doesn't work - yet :-(

Vivian




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Re: [PATCH][RFC] speech synthesis with festival

[Vivian Meazza]

I wrote

 
  I'm working at getting Festival to compile under Cygwin. They claim
 that
  it
  does, and, while it's very long-winded, it's looking good so far ...
  
  
 
  Is that pronounced WINE-D or WIN-D?
 
 
 Nah - that's as in it doesn't work - yet :-(
 

After some trouble and lots of help from Melchior, we got Festival to work
under Cygwin last night. Here's what we found, in case any other Cygwin user
wants to try.

Festival compiles under Cygwin right out of the box - just follow the
instructions.

The instructions invite you to make test to check your installation. This
came up with a couple of errors, which I couldn't find a way to fix, but
don't seem affect the operation of Festival, so I ignored them. From the
command line, Festival does what it says it does.

Melchior's instructions need amending:

Just for the record, this all works for Cygwin:

  1) apply the attached patch basedir.diff in your fgfs dir
  2) copy these two files to src/Sound/:
 http://members.aon.at/mfranz/voice.cxx   [2.5 kB]
 http://members.aon.at/mfranz/voice.hxx   [2 kB]
  3) configure  make 

I needed ./autogen.sh, ./configure, make install as you would expect in
Cygwin.

Cygwin accepts '$ nice festival --server ' but this doesn't work with FG.
Perhaps the 'nice' settings need adjustment. No matter, '$ festival
--server' or '$ festival --server ' both work just fine. I couldn't find a
way to stop the festival server started in background with the '' command
in Cygwin, but Windows Task Manager does the trick.

You need --prop:/sim/presets/voice/host=localhost. I added it to my
system.fgfsrc file.

So after a little effort, Festival and FG work together. The default voice
is poor, but Melchior is working on that, so we can pick one of the better
ones that are available. 

It's a very nice facility, and I would encourage Cygwin users to implement
it. Well done Melchior, and thanks for the help. I look forward to this
forming part of the base code

Vivian

 



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Future feature proposal to think about...

[Vivian Meazza]

Lee

 
 Funny where you are sometimes, when ideas occur to you.  I was in
 the shower, thinking about various aspects of FG when I thought,
 while doing some logical toppling: wouldn't it be fun in
 multi-player if there was a mode where instead of one player to
 one aircraft we could have many people to one aircraft, so that
 several people could crew a single aircraft...
 
 Some sort of voice comms would be a must but then think of the
 tutorial possibilities...
 
 It's not too difficult to imagine several people occupying
 different roles on larger aircraft i.e first  second pilot,
 navigator, flight engineer etc.  not to mention the
 possibilities in combat related simulation.
 
 ...anyway, just something to think about.
 

Those busy working on MP are already thinking about this idea. It ought to
be possible, although we would have to live with the inherent network
latencies involved. We also have a controllable wingman in mind. 

All this after getting MP working properly, and then comes getting the
carrier into MP ... 

Vivian 



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] submodel suggestion

[Vivian Meazza]

Josh Babcock

 
 Perhaps there should be a way to tell a submodel to die when it hits the
 ground, even it it has not reached it's life/ limit yet.
 
 Josh
 

Right now there is no way that a submodel knows where the ground beneath it
is. There is no underlying dynamic model - just some simple mathematical
equations which try to model the flight path given some initial conditions,
and some values for the physical attributes of the submodel and the
environment. There are some limitations: no attempt is made to model the
windage on a bomb or bullet, and transonic drag is arbitrarily modelled for
a conventional tailed round (no boat-tail etc.).

Perhaps one for the future.

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] A4F Model

[Vivian Meazza]

Hi 

I started out by adjusting the catapult strop and holdback attachment points
for the A4, and noticed that we had an A4E YASim config (more or less) with
an A3F modified for the Blue Angels aerobatic team 3D model. So I tidied up
the 3d model, constructed the correct YASim config, including airbrakes and
spoilers, and added some eye candy: G-effects, gear steering and
compression, catapult strop and holdback. I've left the A4E config alone, in
case someone would like to provide a proper 3D model.

YASim came up trumps again for this one - I plugged in some good data,
re-measured the model, adjusted the CofG, and the result is a very flyable
model. I hope that this work will appear in cvs soon, but meanwhile here are
some screenshots to whet your appetite:

ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/a4f/

This is a very low poly model, and I've kept it that way, square(ish) wheels
and all. It should be readily usable by low spec computers.

And here's how to do it:

ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/a4f/A4carrftpierLandingC
ircuit.gif

Regards

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] A4F Model

[Vivian Meazza]

In YASim, The launch bar or strop and the holdback can be
attached to any part of the aircraft, including the nose-wheel leg. So a
nose-wheel tow can be simulated if that is appropriate for the aircraft type. IIRC
the first such aircraft was the F14 Tomcat, and all subsequent USN carrier
aircraft have been so equipped. So far as I am aware, the A4 was never fitted
with a nose-wheel tow capability, and certainly not the A4F.



Thanks for the offer of the diagram  please send it 
I will keep it against the day we do a nose-wheel tow aircraft. (Mathias is
still working on a F/A 18).



Thanks



Vivian 



P.S. I suppose I ought to qualify the any part
above: the holdback attachment point has to be aft of the launch bar attachment
point J



Isao Yamashita wrote









Looks so nice, but do you have the newer catapult hooks too (the one
hooks to the launch bar, and the tension bar holding at the back of the nose
gear strut) ?











I can send some diagrams if you need.











Isao

Vivian Meazza
[EMAIL PROTECTED] wrote:





Hi 

I started out by adjusting the catapult strop and holdback attachment points
for the A4, and noticed that we had an A4E YASim config (more or less) with
an A3F modified for the Blue Angels aerobatic team 3D model. So I tidied up
the 3d model, constructed the correct YASim config, including airbrakes and
spoilers, and added some eye candy: G-effects, gear steering and
compression, catapult strop and holdback. I've left the A4E config alone, in
case someone would like to provide a proper 3D model.

YASim came up trumps again for this one - I plugged in some good data,
re-measured the model, adjusted the CofG, and the result is a very flyable
model. I hope that this work will appear in cvs soon, but meanwhile here are
some screenshots to whet your appetite:

ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/a4f/

This is a very low poly model, and I've kept it that way, square(ish) wheels
and all. It should be readily usable by low spec computers.

And here's how to do it:

ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/a4f/A4carrftpierLandingC
ircuit.gif

Regards

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Re: fix for exit crash

[Vivian Meazza]

Melchior FRANZ

 
  I'm also getting the very annoying ... leaving my airspace ... crash,
  which looks very similar.
 
 Can you post a backtrace for that?
 

It doesn't happen every time, and it isn't happening right now. The next
time it does, I'll try to get a bt.

V.



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] English Electric Lightning

[Vivian Meazza]

Hi

AJ and I have been doing a bit more work on this model. The exterior is now
(nearly) as good as the interior. Hmm, perhaps not :-)

Here are some screen shots:

ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis
h.jpg 
ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis
h1.jpg 
ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis
h2.jpg 
ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis
h3.jpg 

It should be in cvs shortly.

Regards

Vivian




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] AI objects with hardened surface not possible? Dave Culp?

[Vivian Meazza]

Mathias Fröhlich

 
 On Saturday 11 March 2006 01:44, Georg Vollnhals wrote:
  Of course the ship-model is hardened when put into the scenery as a
  static object. It also works when I make a moving ship-object with fixed
  direction (see listed XML-file at the bottom of this message).
  Also creating a flight-plan and let the ship fly at ground-level works
  very fine and impressive.
  But I cannot get a hardened and landable surface.
 
  May be anyone (Dave Culp?) can answer whether it is possible to create
  flightplan-models with hardened surface?
 I hope I am allowed to answer too :)
 
 Well flightplans are ignored by the AICarrier that is true.
 Also AIAircraft do not contribute to the ground computaitions.
 
 Carriers have their own 'flightplan'. Vivian has coded the typical 'stay
 in an
 operation box' 'flightplan' for the carrier. So it is not easy to make
 that
 work with flightplans.
 
 I believe that AIModels will need a SGSubsystem which could either be
 something interpreting usual flightplans or that carrier box thing or may
 be
 a nasal subsystem, so that every AIModel can behave like the author
 scripted
 in nasal without hardcoding that in c++.
 
 For the solidness we will need IMO a hierarchical bounding box collider
 which
 is updated instead of rebuilt at each update(). The presence of movable
 objects like the carrier and the need to keep aircraft on the deck even if
 the carrier turns, this must be done with special care for these
 movements.
 Any yes I know that this does not yet work right, but this is not due to
 the
 way the FDM 'see' the carrier surface move rather than a usual problem of
 viscosous friction models in all our FDM's.
 
 For this current short term problem.
 I believe that it would be possible to make ship's surfaces solid and make
 ships but not carriers follow flightplans.
 An other alternative would be to move that solid tag into AIBase ...
 Let's see ...
 

Just to add a little to that - stay-in-a-box mode is selectable on/off from
the nimitz-demo file, and the limits of the box are selectable.

If you want a ship which has solid decks, add it to the nimitz-demo file as
another carrier, and make the path to the 3d model whatever you want it to
be. You might be able to constrain the operations box enough for your needs,
otherwise it's only a straight course and fixed speed atm, I'm afraid.

HTH

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Carrier Stuff

[Vivian Meazza]

Hi,

We now have some more eye candy in our carrier models: working catapult
strop, holdback, and JBDs (Jet Blast Deflectors). The catapult tracks have
also been lengthened to tae into account the new locations of the holdbacks
on the Seahawk and A4F. Some screenshots:

http://myweb.tiscali.co.uk/vmeazza/FlightGear/seahawk-JBD.jpg 
http://myweb.tiscali.co.uk/vmeazza/FlightGear/seahawk-JBD.jpg 
http://myweb.tiscali.co.uk/vmeazza/FlightGear/seahawk-on-cat.jpg 
http://myweb.tiscali.co.uk/vmeazza/FlightGear/seahawk_strop.jpg 
http://myweb.tiscali.co.uk/vmeazza/FlightGear/catapult_bridle-drop1.jpg 

You can see the strop dropping away from the aircraft on launch.

The last 3 screen shots were produced by Gerard Robin.

All JBDs work together, this is technically incorrect, and JBD #3 interferes
with cat #4. For this reason JBD #3 is inactivated atm. Mathias and I are
working on this. We should have the JBD raised only for the active cat in
due course.

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] b1900d questions.....

[Vivian Meazza]

Martin Spott wrote

 Hello Syd,
 two points I would like to comment on:
 
 syd  sandy wrote:
 
  The flight dynamics seem a bit off , Im not sure if anyone modified them
  again , but it seems to want to stall at take off speeds...   I want to
  fix that , but I think someone may have tweaked it to be more accurate
  ... and I'm no expert in that area... if everyone thinks its ok I'll
  leave it alone.
  One more -  any votes on keeping or removing the popup GPS ? I
 
 Although the b1900d flies pretty nice, the stall behaviour is somewhat
 strange - _and_ after a stall there's almost no chance to recover, even
 if you are at high enough altitude. I have to admit that I'm not
 completely sure and I don't want to blame innocent people, still I
 suspect this is not a problem specific to the b1900d but to YASim
 aircraft in general.

I have not noticed this for other YASim aircraft, but I do note that the
approach aoa is 5 degs while the wing stall angle of attack (aoa) is 7.5
degs. The wing stall aoa number looks far too low to me, and being so close
to the approach aoa is likely to cause difficulties. Possibly a typo for
17.5 degs? Or perhaps it is correct ... just a thought. 


Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)

[Vivian Meazza]

Frank Olaf Sem-Jacobsen

 
 I thought it was about time that I started to dig through and play with
 the code of flightgear with the aim of being able to contribute with one
 part or another when I get to grips with it. I am currently dual booting
 Windows and Linux, but since my main work environment is Windows I would
 much prefer to be able to develop in this environment and avoid having
 to reboot.  I didn't have too much like with trying to build using
 Cygwin last time, so I wonder if anyone has a quick and dirty howto for
 compiling flightgear and its dependencies in MSVS 2005? I looked at the
 wiki, but I think there are some main problems that I don't really
 understand yet. For instance, where are the output files of the
 different dependencies put and how do the projects that depend on them
 find them?  The, and probably many other small problems, currently
 prevents me from being able to build in a Windows environment.
 
 Any help is greatly appreciated.
 
 As per a previous e-mail, perhaps I could look into multiplayer ATC
 communications eventually...?
 

As luck would have it, I started trying to compile FG under MSVC 2005 this
very morning. It doesn't seem entirely straightforward, there seem to be a
huge number of errors, and much of the current code is marked as deprecated,
so it's hard to pick out the real problems/errors. I've given up for now,
but I'll try some more in due course.

Meanwhile, Cygwin works just fine, what's the problem with that, and can I
help?

Vivian 





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)

[Vivian Meazza]

Olaf Flebbe

 
  Cygwin last time, so I wonder if anyone has a quick and dirty howto for
  compiling flightgear and its dependencies in MSVS 2005? I looked at the
  wiki, but I think there are some main problems that I don't really
 
 Have a look at http://www.oflebbe/oflebbe/FlightGear 
 
 BTW: The patches for SimGear/FlightGear are in CVS now.
 
 Olaf
 

Looks like good work, unfortunately FG does not compile here atm using the
project files in cvs, and the above link is broken. SG seems to compile OK.
The errors I'm getting are:

Error   1   error PRJ0019: A tool returned an error code from Creating
Config.h   FlightGearLib
Error   7   error C2381: 'exit' : redefinition; __declspec(noreturn)
differs c:\program files\microsoft visual studio 8\vc\include\stdlib.h  406
Error   8   error C3861: 'exit': identifier not found
c:\cygwin\flightgear-cvs\source\src\main\fg_os.cxx  159

Any ideas?

Vivian





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)

[Vivian Meazza]

Fred

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of Frederic Bouvier
 Sent: 01 April 2006 18:50
 To: flightgear-devel@lists.sourceforge.net
 Subject: Re: [Flightgear-devel] compile with MSVC 2005 (the same as msvc
 8?)
 
 Frederic Bouvier a écrit :
  Vivian Meazza a écrit :
 
  Olaf Flebbe
 
 
 
 
  Cygwin last time, so I wonder if anyone has a quick and dirty howto
 for
  compiling flightgear and its dependencies in MSVS 2005? I looked at
 the
  wiki, but I think there are some main problems that I don't really
 
 
  Have a look at http://www.oflebbe/oflebbe/FlightGear
 
  BTW: The patches for SimGear/FlightGear are in CVS now.
 
  Olaf
 
 
 
  Looks like good work, unfortunately FG does not compile here atm using
 the
  project files in cvs, and the above link is broken. SG seems to compile
 OK.
  The errors I'm getting are:
 
  Error  1   error PRJ0019: A tool returned an error code from
 Creating
  Config.h  FlightGearLib
  Error  7   error C2381: 'exit' : redefinition;
__declspec(noreturn)
  differsc:\program files\microsoft visual studio
8\vc\include\stdlib.h
   406
  Error  8   error C3861: 'exit': identifier not found
  c:\cygwin\flightgear-cvs\source\src\main\fg_os.cxx 159
 
 
 
  Hi Vivian,
 
  try with this version of glut.h :
  ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/glut.h.zip

That version of glut.h works

 
  BTW: doo you download the Platform SDK ? It is mandatory.
 
 


Yes, otherwise Simgear, plib etc. wouldn't have compiled?
 

 For the first error, there is a typo in the Pre Build event of the
 Flightgear project. There must be config.h-msvc8 and not config.h.msvc8.
 This is why the tool ( copy ) returns an error.


So, how do I get to that to change it - it doesn't seem to appear in
PreBuildEvents so I guess I'm looking in the wrong place???

Thanks for the help so far

Vivian




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)

[Vivian Meazza]

Olaf Flebbe

 
 Yes there is a patch outstanding. Please go to the FlightGearLib
 Project in the solution explorer right click, select properties (the
 last entry) choose build events / pre build events.
 
 There was a typo: Please edit change the line to
 
 copy ..\..\src\Include\config.h-msvc8 ..\..\src\Include\config.h
 
 The Release Mode was correct only debug was wrong.
 
 I have no clue what went wrong with exit().
 
 Olaf
 
 
 2006/4/1, Vivian Meazza [EMAIL PROTECTED]:
  Olaf Flebbe
 
 
Cygwin last time, so I wonder if anyone has a quick and dirty howto
 for
compiling flightgear and its dependencies in MSVS 2005? I looked at
 the
wiki, but I think there are some main problems that I don't really
  
   Have a look at http://www.oflebbe/oflebbe/FlightGear
  
   BTW: The patches for SimGear/FlightGear are in CVS now.
  
   Olaf
  
 
  Looks like good work, unfortunately FG does not compile here atm using
 the
  project files in cvs, and the above link is broken. SG seems to compile
 OK.
  The errors I'm getting are:
 
  Error   1   error PRJ0019: A tool returned an error code from
 Creating
  Config.h   FlightGearLib
  Error   7   error C2381: 'exit' : redefinition; __declspec(noreturn)
  differs c:\program files\microsoft visual studio 8\vc\include\stdlib.h
 406
  Error   8   error C3861: 'exit': identifier not found
  c:\cygwin\flightgear-cvs\source\src\main\fg_os.cxx  159
 

OK, I've now got as far as trying to compile and link OpenAL. I get this
error:

Error   9   fatal error C1189: #error :  Do not know sized types on this
platformc:\cygwin\freealut-1.0.1\src\alutinternal.h 32
Error   10  fatal error C1083: Cannot open include file: 'unistd.h': No
such file or directory
c:\cygwin\freealut-1.0.1\test_suite\.libs\lt-test_errorstuff.c  17

Further help would be gratefully received

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Reminder: upcoming v0.9.10 release

[Vivian Meazza]

Curtis L. Olson

 Ron Jensen wrote:
 
 At the risk of repeating myself, TACAN is broken for everything but the
 carriers.  Replacing the two files below makes it work perfectly.
 
 Can someone submit them to CVS before the 0.9.10 release _please!_
 
 Last month I suggested a change[1] to TACAN_freq.dat and carrier_nav.dat
 to enable TACAN to work on the proper channels.
 
 I'd like to see this go in so the F4E I'm working on can use the TACAN.
 
 Since it seems the sourceforge list stripped the attachments they are on
 my webserver: http://www.jentronics.com/fgfs/TACAN_freq.dat.gz and
 http://www.jentronics.com/fgfs/carrier_nav.dat.gz
 
 
 [1]
 http://sourceforge.net/mailarchive/forum.php?thread_id=9643858forum_id=1
 919
 
 
 I don't know anything about the TACAN's, hopefully someone who does know
 something about these can take a look today.
 

TACAN is not actually broken. Due to the way the nav.dat file is
constructed, if you want to use TACAN in conjunction with Atlas, then the
existing TACAN data works. If you want to use TACAN with real maps, then you
need the data provided by Ron. Since most people do not have access to real
maps, but do have access to Atlas, then I propose we leave it the way it is,
but make Ron's data available for those that want it.


Regards,

Vivian




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)

[Vivian Meazza]

Olaf Flebbe

 Please use the OpenAL Distribution from creative, not the cygwin one.
 Since it is necessary to do some changes I have a a zip for you:
 
 http://www.oflebbe.de/oflebbe/FlightGear/AL.zip
 
 For other pitfalls http://www.oflebbe.de/oflebbe/FlightGear/index.html
 
 Please either use MSVC or cygwin headers and libraries, but please do
 not mix them.
 
 Olaf
 
 
 2006/4/2, Vivian Meazza [EMAIL PROTECTED]:
  Olaf Flebbe
 
  
   Yes there is a patch outstanding. Please go to the FlightGearLib
   Project in the solution explorer right click, select properties (the
   last entry) choose build events / pre build events.
  
   There was a typo: Please edit change the line to
  
   copy ..\..\src\Include\config.h-msvc8 ..\..\src\Include\config.h
  
   The Release Mode was correct only debug was wrong.
  
   I have no clue what went wrong with exit().
  
   Olaf
  
  
   2006/4/1, Vivian Meazza [EMAIL PROTECTED]:
Olaf Flebbe
   
   
  Cygwin last time, so I wonder if anyone has a quick and dirty
 howto
   for
  compiling flightgear and its dependencies in MSVS 2005? I looked
 at
   the
  wiki, but I think there are some main problems that I don't
 really

 Have a look at http://www.oflebbe/oflebbe/FlightGear

 BTW: The patches for SimGear/FlightGear are in CVS now.

 Olaf

   
Looks like good work, unfortunately FG does not compile here atm
 using
   the
project files in cvs, and the above link is broken. SG seems to
 compile
   OK.
The errors I'm getting are:
   
Error   1   error PRJ0019: A tool returned an error code from
   Creating
Config.h   FlightGearLib
Error   7   error C2381: 'exit' : redefinition;
 __declspec(noreturn)
differs c:\program files\microsoft visual studio
 8\vc\include\stdlib.h
   406
Error   8   error C3861: 'exit': identifier not found
c:\cygwin\flightgear-cvs\source\src\main\fg_os.cxx  159
   
 
  OK, I've now got as far as trying to compile and link OpenAL. I get this
  error:
 
  Error   9   fatal error C1189: #error :  Do not know sized types on
 this
  platformc:\cygwin\freealut-1.0.1\src\alutinternal.h 32
  Error   10  fatal error C1083: Cannot open include file: 'unistd.h':
 No
  such file or directory
  c:\cygwin\freealut-1.0.1\test_suite\.libs\lt-test_errorstuff.c  17
 

After untangling Cygwin stuff, and figuring out how I applied /MT, I
successfully compiled and ran cvs/HEAD under MSVC8. Only took me a week :-).

Unfortunately, I discovered that submodels no longer work. I downloaded
Fred's binary of -0.9.10-pre3 this morning, and they no longer work there
either. So far as I can see, they are still working under Cygwin as of last
night. 

I'm doing some more investigations, can anyone else confirm this problem?

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] compile with MSVC 2005 (the same as msvc 8?)

[Vivian Meazza]

Fred

 
  Unfortunately, I discovered that submodels no longer work. I downloaded
  Fred's binary of -0.9.10-pre3 this morning, and they no longer work
 there
  either. So far as I can see, they are still working under Cygwin as of
 last
  night.
 
 Do you have a test case ? What should I do to exhibit the problem ?
 
 -Fred
 

And if you ensure that AI models is checked in fgrun, they work just fine.
I'd forgotten that fgrun doesn't use fgfsrc. My fault, forget all the
forgoing. 

Sorry for the brain fade

Vivian 



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Proposal for 1.0

[Vivian Meazza]

AJ MacLeod

 On Thursday 06 April 2006 10:21, Martin Spott wrote:
  this is now going to be the third release in a row that relies on PLIB
  CVS, I find this is a bit unsatisfactory.
 I've been building CVS with plib-1.8.4 (the last release) for ages with no
 particular problems, so I'm not sure it's true to say that we _rely_ on
 PLIB
 CVS.  This is not to detract completely from your point though...
 
  On the other side people are
  waiting endlessly to get patches incorporated into PLIB.
 That seems to be true.  I'm personally using Tiago's texture compression
 patch
 with 1.8.4 and it is the sort of thing that would have been applied almost
 immediately were it part of simgear, say.
 
 We should also bear in mind the possibility that PLIB might not be the
 most
 suitable platform for fgfs in the future and that migration to OSG would
 be
 an option.  However, I'm not a coder and other than having played about
 with
 some fairly inspiring (visually) OSG applications, I have no really valid
 opinion on that matter; that would almost certainly be post-1.0 anyway I
 would imagine?
 

I think that this provides a sensible migration route to OSG, if that is the
way we are going, otherwise it seems a good proposal in its own right. Apart
from the number of updates required (small) I can't see a downside. 

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] A4F problem

[Vivian Meazza]

Fred

 
 This is what I am getting with CVS today ( --aircraft=a4f ) :
 
 Failed to load submodel: Failed to open file
  at i:/FlightGear/cvs/fgfsbase/Aircraft/a4/Models/strop.xml
 Failed to load aircraft from Aircraft/a4/Models/a4f-blue.xml
 (Falling back to glider.ac.)
 

I haven't changed anything - I'll check it out.

Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] A4F problem

[Vivian Meazza]

Fred

 
 This is what I am getting with CVS today ( --aircraft=a4f ) :
 
 Failed to load submodel: Failed to open file
  at i:/FlightGear/cvs/fgfsbase/Aircraft/a4/Models/strop.xml
 Failed to load aircraft from Aircraft/a4/Models/a4f-blue.xml
 (Falling back to glider.ac.)
 

/FlightGear/cvs/fgfsbase/Aircraft/a4/Models/strop.xml shouldn't be called at
all. Have you got the up-to-date version of: 

/FlightGear/cvs/fgfsbase/Aircraft/a4/Models/submodels.xml (version 1.3)?

this calls ~/strop.ac

Vivian 



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] A4F problem

[Vivian Meazza]

Fred

 
 Vivian Meazza a écrit :
  Fred
 
 
 
  This is what I am getting with CVS today ( --aircraft=a4f ) :
 
  Failed to load submodel: Failed to open file
   at i:/FlightGear/cvs/fgfsbase/Aircraft/a4/Models/strop.xml
  Failed to load aircraft from Aircraft/a4/Models/a4f-blue.xml
  (Falling back to glider.ac.)
 
 
 
  /FlightGear/cvs/fgfsbase/Aircraft/a4/Models/strop.xml shouldn't be
 called at
  all. Have you got the up-to-date version of:
 
  /FlightGear/cvs/fgfsbase/Aircraft/a4/Models/submodels.xml (version 1.3)?
 
  this calls ~/strop.ac
 
 
 
 True, but a4f-blue.xml contains :
 
  model
  pathAircraft/a4/Models/strop.xml/path
  nameNew-Strop/name
  offsets
x-m-0.44/x-m
y-m0.0/y-m
z-m-0.54/z-m
  /offsets
/model
 
 

Sorry about that, looks like I half-did a change. I'll tidy up that soonest.

V.



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] Updated F4E

[Vivian Meazza]

Ron Jensen


 http://www.jentronics.com/fgfs/ 
 
 Here is another update to the F4E, same place as it always is
 http://www.jentronics.com/fgfs/F4E.tgz 
 
 Today's update has some cosmetic fixes to the 3D model, it now rotates
 around its axises correctly.  (Thanks Dave)  It also has afterburner
 flames (again, thanks Dave).  There were some changes deep in the FDM as
 well.
 
 I added EGT gauges for the 3D cockpit, and started to model the radar
 display.  The dash looks a bit bare until I replace the gun camera and
 HUD glass.
 
 Carlos Zaragoza Koblischek did a nice texture for the model as well.
 
 Here's a snapshot http://www.jentronics.com/fgfs/f4-paint01.jpg  and the
 texture is here http://www.jentronics.com/fgfs/F4E_base.tgz 

Seeing this reminded me that we still need to sort out the TACAN problem. I
feel uneasy about using hacked frequency/TACAN channel assignments. It seems
to me that we should correct the underlying data in nav.dat.gz by

A. correcting the TACAN frequency where this is in error.

B. adding new VORTAC entries where appropriate.


Vivian



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] A4F - AAR Capability

[Vivian Meazza]

Hi,

I committed a new facility for the A4F yesterday. It now has a functioning
AAR capability with YASim, like the one already available for JSBSim. I have
also taken the opportunity to adjust the panel to make it more nearly like
that of an A4F, rather than an A4C, although a couple of the instruments are
not correct, principally the ASI should be replaced with a combined ASI/Mach
instrument. I have added a nav-display on which TACAN data is displayed. In
due course waypoints will also be displayed there as well.

To use all these goodies, you need to have included refuelling_demo_1.xml in
your preferences.xml file. You can then tune your TACAN to the channel of
the KC135 (039X), which is on a long N/S racetrack starting in the vicinity
of KSFO. You will see the TACAN position on the nav display (it's a Plan
Position Indicator so N is always up). You can make your approach, and when
you are within 250 ft of the tanker, a green light will come on in the fuel
contents gauge, and fuel transfer will take place. When you have taken
enough fuel, you can break off. If you also have nimitz_demo.xml in your
preference file, you cab retune your TACAN to the Nimitz channel (029Y), and
recover back aboard.

That should keep you busy for a while, enjoy!

Regards,

Vivian 

PS Yes, the A4 has a probe while the KC135 is a boom refueller. I'm working
on a KA6-D right now.  



---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

RE: [Flightgear-devel] A4F - AAR Capability

[Vivian Meazza]

Dave

  I committed a new facility for the A4F yesterday. It now has a
 functioning
  AAR capability with YASim, like the one already available for JSBSim.
 ...
 
 Great.  I can't wait to try it out.  BTW, now I can stop using the T-38 as
 a
 refueling demonstrator :)  It's still a radar demonstrator though, unless
 someone else has added radar to his model?
 
 Will the KA-6 be part of the carrier AI scenario?
 

That is the plan, but it's turning out to be a little more protracted than I
first thought (no surprise eh!). Weeks rather than days I now estimate.

Vivian



---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Air-to-Air Refueling (AAR)

[Vivian Meazza]

Hi,

We have now completed and committed to CVS the next stage in development of
our AAR capability - user to user AAR over the Multiplayer(MP) Network. This
comprises:


Updated code in cvs AIModels
Updated carrier_nav.dat.gz file
A flyable tanker - the KC135
AA TACAN which can now detect MP aircraft with the appropriate callsign.
A rudimentary radar which can detect a limited number of MP contacts.

If you want to fly an operable tanker mission, just select the KC135, and
use the callsign MOBIL1, 2 or 3 as your MP callsign. TACAN channels are
060-062X respectively 

If another MP user wants to refuel from you all they have to do is select an
AAR capable ac - A4F, Lightning, or T38. If you do not choose the A4F, then
you should deactivate any scenario involving a tanker; right now the results
with JSBSim with more than 1 tanker in the environment are uncertain.

The refueller should fly an agreed tanker towline. The receiver should tune
his TACAN to the appropriate channel, and/or use his radar to close on the
tanker. The FG map is also helpful. Once with 50 ft of the tanker, a green
light will show on the panel somewhere, and fuel will be transferred. ATM,
only the receiver's fuel level is affected, the tankers supply is unlimited.

It has all been tested briefly earlier today, and we might get some screen
shots later

Enjoy

Regards,

Vivian






---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] AAR

[Vivian Meazza]

Hi,



AAR
is fun, if a little tricky. These screen shots were taken with an AI tanker.



ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/KC135-KC135-1.jpg



ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/KC135-cockpit.jpg




The KC135 is AAR
capable so a full fuel load was taken.



We still have to practice to
do this with a MP tanker!



Vivian

RE: [Flightgear-devel] harrier checkin

[Vivian Meazza]

shavlir

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of @uiuc.edu
 Sent: 25 May 2006 04:31
 To: flightgear-devel@lists.sourceforge.net
 Subject: [Flightgear-devel] harrier checkin
 
 Since those of you who have checkin access never seem to be around when i
 am
 online, I guess the devel list will have to do.
 
 I am at a good checkpoint with the harrier model.  Since there are a
 million
 variants of the harrier, I picked the version to do a 3d model that was
 very
 similar to what the Flight model was based on(Sea Harrier FA2).  It is not
 the current harrier(AV8-B).
 
 Still a lot to do, but I figure people would at least like to have a 3d
 model
 to go with the flight model that already exists (I didn't touch the flight
 model).
 
 Enjoy
 https://netfiles.uiuc.edu/shavlir/Flightgear/harrier.zip
 
 Screenshots:
 https://netfiles.uiuc.edu/shavlir/Flightgear/harrier_panel_unfinished.jpg
 https://netfiles.uiuc.edu/shavlir/Flightgear/harrier_unfinished.jpg
 

Good progress, I look forward to the finished version. To be a bit picky, I
think the photograph is of a Sea Harrier FRS1, the nose of the FA2 is quite
a bit different.

http://en.wikipedia.org/wiki/Sea_Harrier

The larger radome caused the pitot tube to be relocated on the tail from the
nose. Otherwise, the 2 aircraft are the same in outward appearance.

Sorry to be picky, but I'm ex Royal Navy,

Vivian



---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgmap navaids

[Vivian Meazza]

Ron Jensen

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of 
 Sent: 02 June 2006 04:29
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] fgmap navaids
 
 On Fri, 2006-06-02 at 11:04 +1000, Pigeon wrote:
   The only thing that I'm missing now is TACAN.  It
   would be really great (and a slight improvement on Atlas) if the TACAN
   channel for a suitably equipped airfield was shown.
 
  I have just noticed I have sorta misinterpreted some of the nav data
  regarding TACAN, i.e. at the moment all the TACAN are missing on the
  map. I will look into this soon. And perhaps I shall ask you or Vivian
  on IRC later on about any specifics I needed to know.
 
 
 Can we get TACAN channel assignments fixed while you're at it?
 Currently the TACAN system assigns random, bogus channels that don't
 jive with the real world nav data.  I had a simple fix but Vivian
 thought it was a 'hack'.
 

I'm more than willing to be corrected on this one, but my understanding is
as follows:

A VORTAC station has 3 frequencies in RL - TACAN, VOR, and DME. In FG
nav.dat only the VOR and DME are held. Thus it is a fix in the case of
VORTAC to misalign the TACAN channel/frequency pairing to the VOR frequency
in stead of the TACAN frequency. Unfortunately, there are other stations in
the world which are TACAN only, which seem to have the correct TACAN
frequency assigned: Flesland TACAN is one such example. Thus we fix the
VORTAC at the expense of the TACAN. The correct fix is to modify nav.dat to
show all 3 frequencies for the VORTAC stations.

As I say, I think this is the case ...

Vivian



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

Re: [Flightgear-devel] Light inside the cockpit

[Vivian Meazza]

Gonzalo Aguilar Delgado

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of 
 Sent: 02 June 2006 12:56
 To: [EMAIL PROTECTED]; FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Light inside the cockpit
 
 
 
 Yep, you have control's light but you cannot see nothing inside cockpit.
 You cannot see the position of the controls, or switch positions, etc.
 
 I'm talking about put inside a switch with the inside light like in
 cars...
 
 That's because I love 3D cockpits. Makes feel like real planes...
 
 
  On Thursday 01 June 2006 12:30 pm, Gonzalo Aguilar Delgado wrote:
   I was fliying at night yesterday and found that is very dificult to
 see
   the controls inside de cockpit. I think that would be nice to have a
   inside cockpit light or somethig similar. Can we switch on/off
 position
   lights?
 
  Some of the aircraft have instrument lighting.  I don't know if there
 are any
  flood lights though.
 
 
  Dave
 
 

Some models have just such a switch - Hunter, Seahawk, Spitfire, Hurricane,
and a Jim has already pointed out, P51D. I'm not sure if there are any
others, it depends on the aircraft designer. To which ac are you referring?

Vivian 



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

Re: [Flightgear-devel] fgmap navaids

[Vivian Meazza]

Ron Jensen

 
 Hi Vivian
 
  I'm more than willing to be corrected on this one, but my understanding
 is
  as follows:
 
  A VORTAC station has 3 frequencies in RL - TACAN, VOR, and DME.
 
 This is my understanding, too.  Further A TACAN channel includes 3
 frequencies, Two for TACAN/DME and one for VOR/ILS. [1]

I'd like to see where this idea comes from - not [1], which is a very
simplistic description. A TACAN channel includes just 2 frequencies -
airborne (or interrogation) and ground (or reply). If you have a
TACAN receiver (military), the response frequency contains both the bearing
and range information. If you have a DME instrument (civilian) you will get
range information only. VOR is described by its frequency. Thus a VOR/DME
station should have a frequency and a channel associated with it and a DME
just a channel. AKAIKS DAFIF does just this.

If Navaids are collocated as defined by AFMAN33-120_USAFESUP1_I 17 DECEMBER
2004, then frequency pairing is mandated. However, not all TACAN channels
have an associated VOR frequency assigned. Nav.dat seems to assume that
TACAN _uses_ the associated VOR assigned frequency. Where there is no VOR
frequency / TACAN channel pairing, then nav.dat, in a fit of madness, seems
to use the mandated Localizer / TACAN channel pairing. What it does for
TACAN channels which have neither, I can't find out for now. Perhaps there
are none. We have a GIGO situation here.

   In FG nav.dat only the VOR and DME are held.
 
 Actually, nav.dat only holds the VOR freq. The DME uses the associated
 VOR frequency.

Yes - incorrectly - should be the frequency indicated by the DME Channel

   Thus it is a fix in the case of VORTAC to misalign the TACAN
 channel/frequency
  pairing to the VOR frequency in stead of the TACAN frequency.
 
 There is not a mis-alignment.  The TACAN spec includes the VOR freq
 pairing, as well as the DME freq pairing.  

Not for all TACAN channels, at least not in the reference which I am using
(AFMAN33-120_USAFESUP1_I 17 DECEMBER 2004). It is simply incorrect to use
the paired VOR frequency for a stand alone TACAN ...

 It is possible in real life
 to tune a VOR/DME reciever to (most?) TACAN stations and receive DME
 information.

   Unfortunately, there are other stations in
  the world which are TACAN only, which seem to have the correct TACAN
  frequency assigned: Flesland TACAN is one such example.
 
 Flesland TACAN (FLE) uses channel 092X [2]
 Flesland VOR/DME (FLS) uses channel 102Y (115.55 MHz) [3]
 
 zgrep Flesland nav.dat.gz:
 12  60.300036  005.213589185 11450 130   0.000 FLE  Flesland TACAN
 12  60.311261  005.212194213 11555 130   0.000 FLS  Flesland VOR-DME
 
 
I'm wrong here - the nav.dat data is incorrect, well rubbish really. The
only correct bit is that the TACAN and VOR-DME are separate. (Well, and the
positions)

 Under the current version of TACAN.dat FLE is tuned using 058Y and FLS
 is not tuneable.
 
 FLS should give DME only to the onboard TACAN system, currently the
 TACAN system in FG would ignore it, if it were tuneable, I think.
 
   Thus we fix the VORTAC at the expense of the TACAN.
 
 I don't see this.  With a corrected TACAN.dat and the current nav.dat
 both VORTAC and TACAN work fairly well.  I use HIF TACAN all the time:
 
 12  41.120503 -111.963681   4806 11120  40   0.000 HIF  Hill TACAN

   The correct fix is to modify nav.dat to show all 3 frequencies for the
 VORTAC stations.
 
 If I understand correctly, you are concerned because the current TACAN
 uses the name of the DME station to determine whether or not to provide
 TACAN service.  Adding a section for TACAN Azimuth that mirrors the DME
 entries for VORTAC and TACAN stations makes sense, the TACAN DME would
 respond to all DME entries (12/13) in nav.dat and TACAN azimuth would
 respond only to the new (number??) TACAN entries in nav.dat.
 
 Overall, I don't see a way to proceed without first replacing TACAN.dat.
 

I would very much like get nav.dat fixed so that it corresponds to the RL
situation, and we can provide proper VOR, TACAN and DME facilities. I'm not
clear how practical this is: probably cannot be done, in the short term at
least. (If you feel inclined to take that on, I for one would be delighted.)
It would also probably require a rewrite of some of the DME code.

In the interests of expediency, I think the short term (and probably long
term as well) is to use the TACAN channel / VOR frequency pairing which you
produced, and just accept that there are blocks of channels which cannot be
used, and hope that nav.dat copes with that situation.

We at FG pride ourselves on our accuracy and realism. This is all far from
that. I really, really, don't like to do this. As I said before, it's a hack
to fix a hack, and I'm sure will lead to misunderstandings in the future.

Overall, this has forced me to research this properly, instead of relying on
memory. I hope that we are all clear on this now. I suppose we ought to
record all this somewhere.

Re: [Flightgear-devel] Boeing 777-200

[Vivian Meazza]

Justin Smithies

 
 Hi all
  Curtis has just uploaded mine  Syd Adams new 777-200 model to
 the FG
 d/l section.
 It has cabin lights switchable , logo lights and strobes / landing gear.
 3d cockpit , although the AP requires some work, so if anyone can tweek
 the AP
 to work correctly we would be very gratefull ;)
 We are still adding other instruments etc so its a work in progress
 project.
 
 Fell free to test it out and give us your comments.
 
 The D/L section on the FG site will contain daily updates from our cvs .
 

I uploaded a revised AP for the KC135 yesterday - it works well enough for
that ac - feel free to use it.

Vivian



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

[Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

Hi,

In the course of developing the KC135, I noticed that parts of the autopilot
function do not work in that model, copied from the B737 - the bits
described as vor/loc and app. Investigation showed that the cause was simple
- in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash I
rustled up an electrically driven one. Simple solution? Wrong: when I tried
to implement a dedicated instrument.xml configuration for the KC135, using
the new Heading Indicator, the old one was still present (and still
inoperative). This is caused by xmlauto.cxx initiating before
instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I
changed the initiation order. But by this time I realised that the simple
Heading Indicator we have is not what would be fitted to a KC135, or indeed
any jet ac since the '50s onward. We need what I would call a flux gate
compass (you might know a more modern term). This is more or less just the
property orientation/heading-magnetic-deg, but I thought that, for
completeness a proper flux gate instrument electrically driven etc, would be
nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever
sort is configured and does not generate spurious ones.

Now, I might have got hold of the wrong end of the stick here, and someone
may well know better. I intend to arrange the upload of these pretty trivial
changes at the weekend unless otherwise directed, or as I would have said in
a former existence UNODIR.

Regards

Vivian 



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

Re: [Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

Curt wrote

 
 I think the simple solution here is to modify the autopilot config so
 the input is not from a vacuum driven heading indicator since you don't
 have one, but from a different property that you do have.

There is one - nearly - as I said orientation/heading-magnetic-deg. But it's
not derived from an instrument, and therefore has no supply, neither can it
fail, not does it have any error. Further, use of such a property will not
stop, AFAIKS, the generation of spurious and unnecessary instruments, caused
by incorrect initiation, and a hack to get around this. This looks
unprofessional.
 
 The autopilot is designed to be very configurable in this respect and
 even though it can be complex, you can create a custom config for each
 aircraft that matches it's real world capabilities and design quite
 closely.

So it is. Except the existing Heading Indicator is quite inappropriate for
even halfway recent military or civil aircraft.

 
 Vivian Meazza wrote:
  In the course of developing the KC135, I noticed that parts of the
 autopilot
  function do not work in that model, copied from the B737 - the bits
  described as vor/loc and app. Investigation showed that the cause was
 simple
  - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
  Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash
 I
  rustled up an electrically driven one. Simple solution? Wrong: when I
 tried
  to implement a dedicated instrument.xml configuration for the KC135,
 using
  the new Heading Indicator, the old one was still present (and still
  inoperative). This is caused by xmlauto.cxx initiating before
  instrumentmgr.xml, and creating the unnecessary nodes which it needs. So
 I
  changed the initiation order. But by this time I realised that the
 simple
  Heading Indicator we have is not what would be fitted to a KC135, or
 indeed
  any jet ac since the '50s onward. We need what I would call a flux gate
  compass (you might know a more modern term). This is more or less just
 the
  property orientation/heading-magnetic-deg, but I thought that, for
  completeness a proper flux gate instrument electrically driven etc,
 would be
  nice. So I coded up one, and amended xmlauto.cxx so that it uses
 whichever
  sort is configured and does not generate spurious ones.
 
  Now, I might have got hold of the wrong end of the stick here, and
 someone
  may well know better. I intend to arrange the upload of these pretty
 trivial
  changes at the weekend unless otherwise directed, or as I would have
 said in
  a former existence UNODIR.
 
  Regards
 
  Vivian
 
 
 
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 
 
 
 --
 Curtis Olsonhttp://www.flightgear.org/~curt
 HumanFIRST Program  http://www.humanfirst.umn.edu/
 FlightGear Project  http://www.flightgear.org
 Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



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

Re: [Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

Jon

 
  In the course of developing the KC135, I noticed that parts
  of the autopilot function do not work in that model, copied
  from the B737 - the bits described as vor/loc and app.
  Investigation showed that the cause was simple
  - in JSBSim a jet ac does not have vacuum system. No vacuum -
  no Heading Indicator - no Heading Indicator - no vor/loc etc.
 
  Vivian
 
 I don't understand this. Is it that JSBSim code is missing some internal
 capability, or that most JSBSim aircraft models (the XML files) do not
 seem to have defined a vacuum system? Is this a code or a definition
 problem?
 

Well, unless you can show me that modern jet aircraft have a vacuum system
that is gear driven from the engine or bled from it somewhere - the existing
code is just fine and totally realistic.

The problem is that the existing Heading Indicator is not the correct
instrument, vacuum or electrically driven, and there is some programming
that could be improved a little, but not in JSBSim.

Vivian  





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

Re: [Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

AJ wrote

 On Wednesday 14 June 2006 21:51, Josh Babcock wrote:
  Can't you just supply whatever property regarding the vacuum system that
  the instrument is looking for?
 
 He could (which ISTR I had to do for the Lightning) but I think it would
 be
 nice to have the correct system available too.  Some aircraft have
 multiple
 types of the same instrument to provide emergency backups and providing
 for
 this is where the hacks start to get a bit messy I think.
 

We really don't need to hack this one. Sure we could paper over this one
with a few lines of Nasal, but that won't solve the underlying problem
(minor but below the high standards we set ourselves, or I thought we did)

Vivian 



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

Re: [Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

Josh

 
 Vivian Meazza wrote:
  Hi,
 
  In the course of developing the KC135, I noticed that parts of the
 autopilot
  function do not work in that model, copied from the B737 - the bits
  described as vor/loc and app. Investigation showed that the cause was
 simple
  - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
  Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash
 I
  rustled up an electrically driven one. Simple solution? Wrong: when I
 tried
  to implement a dedicated instrument.xml configuration for the KC135,
 using
  the new Heading Indicator, the old one was still present (and still
  inoperative). This is caused by xmlauto.cxx initiating before
  instrumentmgr.xml, and creating the unnecessary nodes which it needs. So
 I
  changed the initiation order. But by this time I realised that the
 simple
  Heading Indicator we have is not what would be fitted to a KC135, or
 indeed
  any jet ac since the '50s onward. We need what I would call a flux gate
  compass (you might know a more modern term). This is more or less just
 the
  property orientation/heading-magnetic-deg, but I thought that, for
  completeness a proper flux gate instrument electrically driven etc,
 would be
  nice. So I coded up one, and amended xmlauto.cxx so that it uses
 whichever
  sort is configured and does not generate spurious ones.
 
 
 Can't you just supply whatever property regarding the vacuum system that
 the instrument is looking for?
 

Why would I want to do that when a proper solution is to hand? It's only a
handful of lines of code to fix this, and I've already written them.

Vivian



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

Re: [Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

Curt wrote

 
 Vivian Meazza wrote:
  There is one - nearly - as I said orientation/heading-magnetic-deg. But
 it's
  not derived from an instrument, and therefore has no supply, neither can
 it
  fail, not does it have any error. Further, use of such a property will
 not
  stop, AFAIKS, the generation of spurious and unnecessary instruments,
 caused
  by incorrect initiation, and a hack to get around this. This looks
  unprofessional.
 
 
 As has always been the case, if the current instrumentation is not
 sufficient for your needs, you can always create a new instrument.
 
 /orientation/heading-magnetic-deg closely approximates an advanced
 inertial system you might find on an advanced modern aircraft.
 Reliable, trust worthy, dead on.  You can also get true heading if you
 prefer that.  If you need something that is tied to the electrical
 system, something that has various failure modes, something that models
 sensor error, or if you just don't like
 /orientation/heading-magnetic-deg for any other reason, then you'll need
 to consider modeling a new heading approximation system in nasal, or
 create a new instrument in C++ .  There are some acronyms for these
 sorts of things, AHRS, IMU, INS.  Your jet probably has some sort of
 ring laser based gyro system in real life?  I don't know how deep you
 want to get into modeling this system.  My goal is to stock the kitchen
 so all you cooks can create your culinary masterpieces.  But if you want
 some new vegetable, you might need to plant it yourself.
 

As I wrote in my original posting - that's already done - I've done a
fluxgate compass suitable for use at least up to the '70s. I'll submit that
for inclusion in CVS shortly. An even more modern instrument is trivial, but
I haven't done one yet.

I also have a patch prepared which prevents xmlauto.cxx from generating
spurious instruments, and which uses whichever Heading Indicator that is
present. That's probably a 'fancy waistcoat', and I'm still pondering if
it's worth submitting.

Vivian 





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

Re: [Flightgear-devel] Autopilot Bug/Feature

[Vivian Meazza]

Roy Vegard Ovesen wrote:

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of 
 Sent: 16 June 2006 10:26
 To: flightgear-devel@lists.sourceforge.net
 Subject: Re: [Flightgear-devel] Autopilot Bug/Feature
 
 På 16.06.2006 10:19 CEST skrev Vivian Meazza [EMAIL PROTECTED]
 
 snip...
 
 I also have a patch prepared which prevents xmlauto.cxx from generating
 spurious instruments, and which uses whichever Heading Indicator that is
 present. That's probably a 'fancy waistcoat', and I'm still pondering if
 it's worth submitting.
 
 As you can see the helpers in xmlauto are hardcoded to the instruments
 that existed and were also hardcoded at the time. I think that these
 helper values should be moved into the instrument code that they belong
 to. For example the heading error should be moved into the heading
 indicator instrument code. This would result in the heading error only
 being available when the heading indicator instrument was present in the
 instrumentation configuration file.
 
 Some other helper values are IMHO redundant and should be removed all
 together (vertical speed conversion into feet/s).
 

I was just thinking of calculating the error values in Nasal, but I
personally prefer your suggestion.

V.



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

Re: [Flightgear-devel] Memory leak

[Vivian Meazza]

Lee

 
 On Saturday 17 June 2006 07:34, Melchior FRANZ wrote:
  * Lee Elliott -- Saturday 17 June 2006 05:02:
   Is anyone else seeing a memory leak in current cvs?
 
  I would be surprised if we had no leaks at all. But in a short
  test with $ fgfs --aircraft=ufo --airport=kufo  ...  i didn't
  see anything like you observed. The memory consumption was
  quite stable after a few minutes. (This was with ATC turned
  off.)
 
  m.
 
 Tried fgfs --aircraft=ufo --airport=kufo and had no problems.
 Went back to the a/c I was testing and just let it sit there
 while doing nothing but reduce the sound volume - no problem.
 
 I then closed the canopy (nasal), which resulted in a slight
 increase of fgfs vm utilisation but after waiting for a minute
 or two it was stable.  I then revealed the 2D panel and that's
 when the vm utilisation for fgfs started to ramp up (I ssh'd in
 from another m/c and ran top to watch this).
 
 I switched back to the ufo and when I revealed the 2D panel
 (C-172 default) fgfs vm utilisation seemed to start ramping,
 although a lot more slowly than the a/c I was testing, so it
 looks as though it may be something to do with the 2D panel,
 which is a bit strange.
 
 As I said, the rate seems quite a bit lower with the ufo - I had
 to wait about a minute or so before it was apparent that fgfs's
 vm utilisation was ramping and it was only grabbing an extra mb
 every 30 seconds or so.
 
 Do you see this?
 

I just left the KC135 running airborne - it chewed up VM and finally froze.
2D panel as well. I'm not clear if this is the same phenomenon that you are
seeing, or if the 2D panel is significant.

Vivian



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

Re: [Flightgear-devel] Memory leak

[Vivian Meazza]

Lee Elliott wrote

 
 On Saturday 17 June 2006 20:18, Vivian Meazza wrote:
  Lee
 
   On Saturday 17 June 2006 07:34, Melchior FRANZ wrote:
* Lee Elliott -- Saturday 17 June 2006 05:02:
 Is anyone else seeing a memory leak in current cvs?
   
I would be surprised if we had no leaks at all. But in a
short test with $ fgfs --aircraft=ufo --airport=kufo  ...
i didn't see anything like you observed. The memory
consumption was quite stable after a few minutes. (This
was with ATC turned off.)
   
m.
  
   Tried fgfs --aircraft=ufo --airport=kufo and had no
   problems. Went back to the a/c I was testing and just let it
   sit there while doing nothing but reduce the sound volume -
   no problem.
  
   I then closed the canopy (nasal), which resulted in a slight
   increase of fgfs vm utilisation but after waiting for a
   minute or two it was stable.  I then revealed the 2D panel
   and that's when the vm utilisation for fgfs started to ramp
   up (I ssh'd in from another m/c and ran top to watch this).
  
   I switched back to the ufo and when I revealed the 2D panel
   (C-172 default) fgfs vm utilisation seemed to start ramping,
   although a lot more slowly than the a/c I was testing, so it
   looks as though it may be something to do with the 2D panel,
   which is a bit strange.
  
   As I said, the rate seems quite a bit lower with the ufo - I
   had to wait about a minute or so before it was apparent that
   fgfs's vm utilisation was ramping and it was only grabbing
   an extra mb every 30 seconds or so.
  
   Do you see this?
 
  I just left the KC135 running airborne - it chewed up VM and
  finally froze. 2D panel as well. I'm not clear if this is the
  same phenomenon that you are seeing, or if the 2D panel is
  significant.
 
  Vivian
 
 Sounds very much like it - I first noticed under the same
 conditions.
 
 I'll try cvs with Melchior's latest update, but a bit later - I'm
 of to a birthday now.
 

I have now completed a bit more testing using the Seahawk using cvs-head of
this am on Windows XP. With the 3D panel there is no memory leak. When I
switch to the 2d panel on the fly, the memory leak starts. When I switch
back to 3d, the leak stops.

This can be repeated at will. 

Vivian



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

Re: [Flightgear-devel] tacan

[Vivian Meazza]

Josh

 
 What property can I increment to change the channel on the TACAN? I have
 a knob on a TACAN instrument that is supposed to either inc/dec the
 channel, or the x/y selector, depending on the position of another
 switch. I could do this by introducing another property and some nasal
 to translate between it and the three existing numeric properties, but
 this seems like a bit of a kludge.
 
 You need to set these properties for the individual channels:

/instrumentation/tacan/frequencies/selected-channel[1]
/instrumentation/tacan/frequencies/selected-channel[2]
/instrumentation/tacan/frequencies/selected-channel[3}
/instrumentation/tacan/frequencies/selected-channel[4]

Note that channel 1 is [1], not [0] as you might have guessed.

Vivian



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

Re: [Flightgear-devel] tacan

[Vivian Meazza]

Josh Babcock wrote

 
 Vivian Meazza wrote:
  Josh
 
 
  What property can I increment to change the channel on the TACAN? I
 have
  a knob on a TACAN instrument that is supposed to either inc/dec the
  channel, or the x/y selector, depending on the position of another
  switch. I could do this by introducing another property and some nasal
  to translate between it and the three existing numeric properties, but
  this seems like a bit of a kludge.
 
   You need to set these properties for the individual channels:
 
  /instrumentation/tacan/frequencies/selected-channel[1]
  /instrumentation/tacan/frequencies/selected-channel[2]
  /instrumentation/tacan/frequencies/selected-channel[3}
  /instrumentation/tacan/frequencies/selected-channel[4]
 
  Note that channel 1 is [1], not [0] as you might have guessed.
 
  Vivian
 
 
 
 
 
 Yeah, but then I have to write nasal code. If the channel is 099X, there
 is nothing that I can increment to get the right answer. I need to test
 each digit and decide to increment, or zero and carry. It just seems a
 little odd, I would have expected one integer to hold the numbers, and
 one string to hold the X/Y part.
 
 Perhaps I will write some nasal code to live in controls.nas that
 translates between a single number in selected-channel[0] and 1-3. That
 way the existing behavior will be preserved, and there will also be a
 number that can be incremented or decremented between 0 and 126.
 

It was designed to work with the menu item in which each column is set
independently, and we need a string with which to search the TACAN channel/
frequency pairing database. 

But I'm not sure what you are trying to. Others have created a TACAN control
panel, so there must be a way to do it. If you would explain in a bit more
detail ... 

Vivian 



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

Re: [Flightgear-devel] Memory leak

[Vivian Meazza]

Dave Perry
 
 I have had  lock-ups on longer X-C flights with the pa24-250 recently
 that could be from a memory leak.  So I used the system monitor to check
 on VM growth.  The only 2D pannel used in the pa24-250 is the radio
 stack.  So I tried commenting out various components of the radio stack
 in the file radio-panel.xml.  If I comment all the radio stack in this
 file, the memory leak is gone.  I did not try all combinations, but the
 leak rate seems to get greater the more radios are not commented out.
 
 I do not remeber this occurring even on very long X-C flights when I
 first submitted the pa24-250.
 
 System info
 FC4 Linux updated with yum update last Saturday
 Plib, SimGear, fgfs source, and base all updated from CVS on Saturday
 also.
 AMD Athlon XP 3200+ with 512 MB RAM
 Nvidia GeForce 7800 GS OC with 256MB GDDR3
 

Hmm - it's beginning to look as if this problem is long-standing. It only
seems to involve 2d panels: those ac with pure 3d panels are unaffected.
Some 3d panels have 2d elements - these are also affected. 

Linux and Windows both seem to be affected, but Melchior cannot reproduce
the memory leak on his set-up. 

A date when you first noticed this effect would perhaps help in tracking it
down.

Vivian





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

Re: [Flightgear-devel] Cygwin Build of FlightGear

[Vivian Meazza]

Georg Vollnhals wrote

 
 
  when I try running flightgear. Very, very frustrating. I hate to do
 this,
  but I guess I will next try to completely delete all cygwin directories.
  This is just so strange.
 This was the only solution for me which worked!
 
  I'd really like to know how many are using cygwin, and if they are also
  having any trouble.
 
 
 Together with FlightGear, only a few people. Otherwise we should have
 more errormessages on the list from unknown people!
 

I stopped using Cygwin for FG when OpenAL-cvs stopped compiling under
Cygwin. I changed to MSVC8 - and that was quite an adventure. I wouldn't
like to do all that again. Still, now it's all done it works well, and
provides a good editor and quick compiler. When OpenAL gets its act together
I'll probably go back.

Vivian



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

Re: [Flightgear-devel] wxradar question

[Vivian Meazza]

Justin Smithies asked:

 
 Me and Syd have implemented the wxradar into our 777-200 model and have
 noticed that it will only display the clouds if 3d clouds are selected.
 Is there a reason for this or is it simply something that was overlooked ?
 

The wxradar displays the positions of the 3d clouds, and therefore needs 3d
clouds to be enabled to work ... logical eh?

Regards,

Vivian


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..~/.cvspass???

[Vivian Meazza]

Arnt Karlsen

 
 On Mon, 03 Jul 2006 00:28:06 -0400, Josh wrote in message
 [EMAIL PROTECTED]:
 
  Arnt Karlsen wrote:
 
  
   ..this works, thanks, but I _should_ be able to use Ralf's Makefile
   too. The idea is make this useable off a Live CD too.
 
  Oh, I see. Yes, it should come with a valid .cvspass for an anonymous
  user.
 
  Josh
 
 ..is this a posh suggestion I should drop doing the FGLiveCD4KOSH?
 Or can anyone show me a valid .cvspass so I can fix my CD .cvspass?
 

Hmm - paranoiac or what? Your .cvspass file should look something like:

/1 :pserver:[EMAIL PROTECTED]:2401/var/cvs/FlightGear-0.9 4IedZ

Vivian 


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..fixed, was:..~/.cvspass???

[Vivian Meazza]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of Arnt Karlsen
 Sent: 03 July 2006 17:08
 To: FlightGear developers discussions
 Subject: [Flightgear-devel] ..fixed, was:..~/.cvspass???
 
 On Mon, 3 Jul 2006 15:10:03 +0100, Vivian wrote in message
 [EMAIL PROTECTED]:
 
  Arnt Karlsen
 
  
   On Mon, 03 Jul 2006 00:28:06 -0400, Josh wrote in message
   [EMAIL PROTECTED]:
  
Arnt Karlsen wrote:
   

 ..this works, thanks, but I _should_ be able to use Ralf's
 Makefile too. The idea is make this useable off a Live CD too.
   
Oh, I see. Yes, it should come with a valid .cvspass for an
anonymous user.
   
Josh
  
   ..is this a posh suggestion I should drop doing the FGLiveCD4KOSH?
   Or can anyone show me a valid .cvspass so I can fix my CD .cvspass?
  
 
  Hmm - paranoiac or what?
 
 ..naaa, just _royally_ fed up with junk that fails me all over the
 damned place, including ParallelKnoppix and this time it hit Josh,
 Josh, I apologise, and yes, I'll toss in a valid .cvspass.
 
  Your .cvspass file should look something like:
 
  /1 :pserver:[EMAIL PROTECTED]:2401/var/cvs/FlightGear-0.9
  4IedZ
 
 ../1  is line number?  _Huh???!!!_  Thanks a _lot_, Josh, looks like
 your suggestion had cvs append the correct entries into .cvspass.  :o)
 And AIbdZ here is guest flipped over etc like a burger.
 Tech comfort zone is where people _know_ how to fix stuff.  ;o)
 

/1 precedes each line, not a line number

If you can get guest out of that one you are a better man than I, Gunga
Din. I made that hash value up.

Vivian


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ASI: YASim Systems/pitot bug ?

[Vivian Meazza]

Melchior

 
 Seems that there are two bugs that make the bo105 ASI show
 positive speeds when flying backwards:
 
 1. YASim delivers a positive /velocities/airspeed-kt on backward
flight.
 
 2. Systems/pitot.cxx wouldn't handle negative values correctly,
anyway, as it squares the speed without checking for negatives.
 
 The second is easy to fix, but I have no idea about the first.
 

A pitot tube compares the pressure along the _forward_ axis of the tube,
caused by forward flight, with the static pressure. I don't think such a
device will measure the speed backwards. It is only accurate when the
airflow is co-axial with the tube.

You need some other device to measure backward velocity. In the only case
with which I am familiar (Westland Wessex HAS1 and 3) there was a Doppler
radar. Used to get into difficulties over calm seas when attempting an
auto-hover IIRC. 

Vivian 



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] chrome animation

[Vivian Meazza]

Syd

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of  sandy
 Sent: 30 July 2006 08:23
 To: flightgear-devel@lists.sourceforge.net
 Subject: [Flightgear-devel] chrome animation
 
 Is there a way to blend the chrome texture without  completely hiding
 the aircrafts underlying texture , so one can show seams , rivets or
 environment mapping effects on glass ? I have found no documentation on
 this animation . Am I  looking for something that doesnt exist ?
 

No there isn't and yes you are!

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Seahawk

[Vivian Meazza]

Hi,

Melchior has produced a nice addition to the Seahawk: the managed view.
This adjusts the pilot's view to where he might look during manoeuvres. I
have adjusted the g-effects (black/red-out and head shake) to suit. 

We think it makes a worthwhile enhancement to the realism of flying the
Seahawk.

It's in cvs now - enjoy. We welcome any comments that you might have.

Vivian  


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Flight Sim Development

[Vivian Meazza]

Hi, 

You might find this an amusing take on someone else's Flight Sim

http://www.youtube.com/watch?v=tcW3hbnR2EI 

Made me laugh anyway,


Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Cygwin Installation problem

[Vivian Meazza]

Thomas Biwer



That was a long time ago! The problem then was within some
SimGear code, however that was resolved. AKAIK, 0.9.10 compiles OK under
Cygwin, but I havent tried it for ages, since I use the CVS version.



Seems possible that you have:




 the wrong version of SimGear
 the wrong version of the data.




If neither of these are the case, then Im right out
of ideas for now.



Vivian













Hello there, 











I compiled FlightGear 0.9.10 on this machine over here using Windows XP
and Cygwin and it did properly without showing errors or warnings. When trying
to run it for the first time using the cygwin console it starts first but then
hangs up at installing scenery objects. I started it again with
using --log-level=debug and the last thing it seems to do is generating
ocean tile (when path to scenery is specified bz
--fg-scenery=/...)or generating lights (when scenery path stays
unspecified). 











I think Vivian Meazza described a similar problem over here: http://mail.flightgear.org/pipermail/flightgear-devel/2005-August/038846.html












Hardware problems seem unlikely since FG worked properly on the same
machine when installed over the installing file downloaded from flightgear.org.






















-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] simgear compile errors

[Vivian Meazza]

Michal Fabik

 
 Hello,
 I've cvs-updated the simgear source a couple of hours
 back and encountered the following:
 
 1) configure says I don't have openAL installed which
 is not true. Reinstalling openAL with --prefix=/usr
 fixed this.
 
 2) make says
 .
 .
 .
 In file included from
 ../../simgear/math/SGMath.hxx:31,
  from
 ../../simgear/math/point3d.hxx:54,
  from
 ../../simgear/math/sg_types.hxx:41,
  from sg_path.hxx:36,
  from sg_path.cxx:35:
 ../../simgear/math/SGVec3.hxx:21:21: error: osg/Vec3f:
 No such file or directory
 ../../simgear/math/SGVec3.hxx:22:21: error: osg/Vec3d:
 No such file or directory
 .
 .
 .
 
 the whole (...)math/osg folder is missing.
 

That's part of the OSG file structure - have you compiled OSG, and done the
necessary includes?

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] CVS - OSG

[Vivian Meazza]

Hi,

SG-CVS fails to build under MSVC8 atm. It fails in SGQuat.hxx. copysign is
not recognised. Replacing

  sin05ang = copysign(sqrt(sin05ang), sig);
 with 
sin05ang = _copysign(sqrt(sin05ang), sig);
 ^
seems to do the trick

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] OSG - Bugs

[Vivian Meazza]

Hi,

Just a quick report on some tests with FG-OSG compiled under MSVC8 using
Olaf's project files etc. that I've carried out on the models for which I am
responsible:
 
   Hurricane/Spitfire/Seafire won't start. The starter spins
continuously, but the engine won't fire.
   A4F crashes FG, without any error message that I have found so far.
   Hunter and Seahawk have lost their exhausts (of course). 
   The Engage Launch-bar command (L) is broken.
   The Mixture control (M/m) seems to be broken. 
 The frame rate is well down - approximately 40-50% in like-for-like
circumstances.
 The scenery is significantly darker than with plib with the same
settings 
   
It would be fair to say that under osg pretty much everything is broken. And
finally the someone nicked the sun it disappears from time to time - reset
gets it back. Lot's of work there, but there are no indications of where the
problems might lie, I'm afraid.

Vivian 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear starting time

[Vivian Meazza]

Olaf Flebbe wrote

 Hi,
 
  i noticed that the version of flightgear i built from scratch using
  cygwin takes significantly more time to start up (about 4-5
  minutes) than the one i installed using the exe-file from
  flightgear.org http://flightgear.org (about 1-2 minutes). is there
  any specific reason for this and are there any ways to accelerate the
  start of flightgear somehow?
 cygwin I/O is dead slow. Thats the price you pay for emulating a UNIX
 style I/O system. You can accelerate by using MSVC8, for instance. It's
 free, too.
 

The I/O of Cygwin was improved considerably about a year ago, but was still
a little slower than with an executable produced with MSVC8. It also ran a
little slower; as is pointed out above that's the price you pay for
emulating Unix.

However, FG-OSG compiled using Olaf's stuff (for which we must be most
grateful) is both significantly slower to load and run than FG-Plib compiled
with MSVC8 here. 

Vivian




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear starting time

[Vivian Meazza]

Olaf Flebbe

 
 
 However, FG-OSG compiled using Olaf's stuff (for which we must be most
  grateful) is both significantly slower to load and run than FG-Plib
 compiled
  with MSVC8 here.
 
 You actually see a slowdown on loading ?
 

Yes, I haven't timed it exactly, but I would estimate 15=25% longer -
certainly noticeably. 

Vivian 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG - Bugs

[Vivian Meazza]

Ralf Gerlich

 
 Hi,
 
 Ralf Gerlich wrote:
  - transparency issues:
- runway lights shine through panel:
  http://www.custom-scenery.org/fileadmin/fg_osg/fgfs-screen-001.png
  http://www.custom-scenery.org/fileadmin/fg_osg/fgfs-screen-002.png
 
- runway lights shine through cloud layers in an awkward way:
  http://www.custom-scenery.org/fileadmin/fg_osg/fgfs-screen-003.png
 
- 2D-cloud layers flood into cockpit
  http://www.custom-scenery.org/fileadmin/fg_osg/fgfs-screen-005.png
 
 Additionally, I found that the prop of the C172 block the view on the
 waves of the carrier, which seems odd to me.
 
 http://www.custom-scenery.org/fileadmin/fg_osg/fgfs-screen-009.png
 
 I'm just collecting. These things might not have anything to do with the
 OSG switch and may just have been there in the plib version as well.
 

The reflector gun sight on the Seahawk does the same. So I would assume that
it's a transparency ordering bug.

Vivian 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG Performance on WIndows

[Vivian Meazza]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-
 [EMAIL PROTECTED] On Behalf Of Olaf Flebbe
 Sent: 05 November 2006 22:43
 To: FlightGear developers discussions
 Cc: Mathias Fröhlich
 Subject: [Flightgear-devel] OSG Performance on WIndows
 
 Hi,
 
 while double (and triple ;-) - checking everthing I discovered that I
 had a prerelease of Mathias overhauled AC3D Loader in my 3rdparty.zip.
 You may find an update on my website. Sadly, this doesn't change
 framerate.
 
 Uncommenting sceneView-update() in render.cxx gives a performance jump
 from 60FPS to 80FPS. (plib was 100FPS). Traversing the scenegraph seems
 to be quite timing relevant. Can we limit this special update-traversal
 only to the aircraft (IMHO it is all it does)?
 

I can't find a render.cxx, but I do have renderer.cxx, and
sceneView-update() is already uncommented, so no improvement here.

Vivian 



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG Performance on WIndows

[Vivian Meazza]

Lets hope that youre correct. Right now we
have _fewer_ features, and a _lower_ frame rate. I hope that adding back
the features we used to have wont further reduce the frame rate, let
alone adding new ones.



Were in danger of limiting the use of FG to high end
machines. I have a reasonable machine, with a FX6200 video card, and FG performance
is barely acceptable under certain circumstances already. 



Vivian 







Curtis Olson
wrote:







I have no idea, but I do
know that plib/ssg was very tight and clean and fast code. OSG is very
feature rich, it has far more capabilities than plib/ssg, but features usually
come with a price. I wouldn't be surprised if we take some amount of a
frame rate hit moving to OSG. Hopefully we can find ways to optimize to
minimize this problem, and perhaps there is something glaring we can find that
will win a large amount of this performance loss back. 

Curt.





On 11/5/06, Olaf Flebbe [EMAIL PROTECTED] wrote:

Hi,

while double (and triple ;-) - checking everthing I discovered that I
had a prerelease of Mathias overhauled AC3D Loader in my 3rdparty.zip.
You may find an update on my website. Sadly, this doesn't change framerate. 

Uncommenting sceneView-update() in render.cxx gives a performance jump
from 60FPS to 80FPS. (plib was 100FPS). Traversing the scenegraph seems
to be quite timing relevant. Can we limit this special update-traversal 
only to the aircraft (IMHO it is all it does)?

Can somebody confirm that the framerate with OSG is better compared to
plib on Linux? Default c172 at KSFO, please. Does anybody has a idea
whats going on? The OSG Code is pretty #ifdef'less. 

Olaf




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier 
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642

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






-- 
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/http://www.humanfirst.umn.edu/http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d 








-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG Performance on WIndows

[Vivian Meazza]

Martin Spott

 Vivian Meazza wrote:
 
  Let's hope that you're correct. Right now we have _fewer_ features, and
 a
  _lower_ frame rate. I hope that adding back the features we used to have
  won't further reduce the frame rate, let alone adding new ones.
 
 Hey, guys, you're talking about a _development_ source code tree, don't
 forget about this!! It's funny to realize that people got used to have
 such a consistent and stable development tree that they already see the
 whole project at risk just because _real_ development is currently
 taking place  :-)
 
 Mathias did a huge task to make the switch over to OSG actually happen.
 Apparently the next item on the TODO list is to remove the glitches of
 the port and do some fine tuning, afterwards to remove the dirty hacks
 that had been implemented in the PLIB version - and which are still
 present - and add them as a 'clean' solution to the OSG version.
 
 Don't feel to be looking at the dark side of the moon just because
 your field-glasses got dirty  ;-)
 

Hmm when most of your ac are broken, you have no idea how to fix them, and
your computer has just totally frozen while trying to run fg-osg for the 3rd
time ... when you are up to your arse in alligators, it's hard to remember
that your original aim was to drain the swamp.

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG Performance on WIndows

[Vivian Meazza]

Frederic Bouvier

 Quoting Vivian Meazza :
 
  Martin Spott
 
   Vivian Meazza wrote:
  
Let's hope that you're correct. Right now we have _fewer_ features,
 and
   a
_lower_ frame rate. I hope that adding back the features we used to
 have
won't further reduce the frame rate, let alone adding new ones.
  
   Hey, guys, you're talking about a _development_ source code tree,
 don't
   forget about this!! It's funny to realize that people got used to have
   such a consistent and stable development tree that they already see
 the
   whole project at risk just because _real_ development is currently
   taking place  :-)
  
   Mathias did a huge task to make the switch over to OSG actually
 happen.
   Apparently the next item on the TODO list is to remove the glitches of
   the port and do some fine tuning, afterwards to remove the dirty hacks
   that had been implemented in the PLIB version - and which are still
   present - and add them as a 'clean' solution to the OSG version.
  
   Don't feel to be looking at the dark side of the moon just because
   your field-glasses got dirty  ;-)
  
 
  Hmm when most of your ac are broken, you have no idea how to fix them,
 and
  your computer has just totally frozen while trying to run fg-osg for the
 3rd
  time ... when you are up to your arse in alligators, it's hard to
 remember
  that your original aim was to drain the swamp.
 
 If all broken ac are like the A4F ( the model is yours, isn't it ), then
 there
 was an inconcistency it the model, where some objects are declared groups
 where
 they should be polys because they have vertices and triangles data in
 them.
 
 Check the differences in a4-blue.ac
 

Yes, I saw you had fixed that, but that's the only one with that particular
problem. Since it worked under plib, and AC3D didn't complain, I would never
have worked that one out - thank you. If only the rest were that easy - the
others seem to be keyboard/panel control problems, but I expect you read my
earlier posting.

Vivian 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG Performance on WIndows

[Vivian Meazza]

Fred wrote:

 Selon Vivian Meazza :
 
  Yes, I saw you had fixed that, but that's the only one with that
 particular
  problem. Since it worked under plib, and AC3D didn't complain, I would
 never
  have worked that one out - thank you. If only the rest were that easy -
 the
  others seem to be keyboard/panel control problems, but I expect you read
 my
  earlier posting.
 
 Would you mind reminding me what are the current problems as detailed as
 you can
 so I can try to debug myself ?
 

These are the bugs so far:

 
Hurricane/Spitfire/Seafire won't start. The starter spins
 continuously, but the engine won't fire.
A4F crashes FG, without any error message that I have found so far.
Hunter and Seahawk have lost their exhausts (of course).
The Engage Launch-bar command (L) is broken.
The Mixture control (M/m) seems to be broken.
The frame rate is well down - approximately 40-50% in like-for-like
 circumstances.
The scenery is significantly darker than with plib with the same
 settings
 
 It would be fair to say that under osg pretty much everything is broken.
 And
 finally the someone nicked the sun it disappears from time to time - reset
 gets it back. Lot's of work there, but there are no indications of where
 the
 problems might lie, I'm afraid.


And to which I can add:
The radar in the KC-135E is also broken - but that is to be
expected,   and I expect that it will be fixed in due course. 

The transparency of the Seahawk gunsight causes the carrier wake to
disappear.

Masts are no longer visible in the scenery - but a transparent
effect  is visible if you look closely. 

I suspect the last 2 are an artefact of transparent object ordering in the
environment.

I don't think that the Launchbar problem is a keyboard issue

Vivian




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] web site hacked ?

[Vivian Meazza]

Andrew Gluszynski

 
 Hi all,
 
 I dont normaly post to this mailing list, but i think the web site has
 been hacked?
 

It has, but this still works http://flightgear.org/ 

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Last new OSG version - better framerates

[Vivian Meazza]

Maik Justus wrote

 
 Hi Georg,
 very good new. Thanks to Mathias for this improvement.
 Maik
 
 Georg Vollnhals schrieb:
  Hi,
  I just did some further tests with the LAST NEW OSG version from Mathias
 and
 
  GOOD NEWS, really improved framerates
 
  (test details as already reported, not important for now as same for old
  OSG/ new OSG version):
 
 

BAD NEWS - no discernable improvement on MSVC8/Windows ... I expect we will
get there eventually.

The worst feature is wild variations in frame rate between 1-3 (software
rendering) and 30-35. This is on a 2.8 GHz P4 with 0.5 Gb RAM and a nVidia
FX6200 with 256 Kb VRAM. 

But it's not all bad news - along the way the engine start bug in the
Hurricane/Spitfire/Seafire has been fixed. I'm not sure what fixed it, but
if it works, it works.

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] MSVC8 update

[Vivian Meazza]

Olaf Flebbe wrote:

 FYI: I did a major overhaul to the build system for MSVC8 (again). Now
 with a common infrastructure for building OSG itself, FlightGear/Plib
 branch and FlightGear/OSG. Now FlightGear is linked dynamically, even in
 the plib case, making support more easy.
 
 http://www.oflebbe.de/oflebbe/FlightGear
 
 BTW: Slowdown for OSG is now only around 25% for me. Mathias, thank you
 for your support!
 

I built FG using your new stuff combined with Mathias' updates over the
weekend. I see a great improvement in frame rates - now only about 10% down.
Really quite usable. Well done all. 

The scenery around KSFO still pulls the frame rate down significantly, and
it's all still slow to load. Perhaps there's still more improvement to
come?

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] MSVC8 update

[Vivian Meazza]

I wrote:

 I see a great improvement in frame rates - now only about 10%
 down.

Perhaps a little optimistic: 20% down would be more accurate. Still a very
worthwhile gain though.

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Last new OSG version - better framerates

[Vivian Meazza]

Mathias Fröhlich wrote

 
 It would still be interesting why we get consistently bad performance
 reports
 on win32 and most unix users report equal to much better performance...
 

It certainly would. My system comprises a P4 2.8 with .5 Gb RAM and a
recently purchased nVidia FX 6200 with 256 Mb of VRAM. Where previously I
saw 80 - 100 fps with the Cessna I now see 40 - 65. If I use a really
demanding model like the Sea Vixen it is interesting that the degradation
seems to be proportionately less: 35-55 down to 25-45. Of as much concern is
the frame rate is the wild fluctuations down to 1. In particular the
external views of the as seem to be more downgraded than cockpit view.

Olaf's recent update to the MSVC8 project files gave us a few more frames.
So perhaps we are seeing a difference caused by the compiler optimisation?  

I notice that the loading of the scenery files takes a lot longer than with
plib, and also that scenery seems to reduce the frame rate more than it used
to. I wonder if this could be a fruitful area for investigation?

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] CVS-OSG - Bug

[Vivian Meazza]

Hi,

Here' a nice effect:

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

But I don't think it's intentional. Something wrong with LMT and GMT
perhaps? It looks as if the illumination of the ac is at noon, while the
scenery is midnight.

Now if we could do that for all the ac on the parked on the apron - wow :-)

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS-OSG - Bug

[Vivian Meazza]

I wrote:

 Here' a nice effect:
 
 ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/floodlight.jpg
 
 But I don't think it's intentional. Something wrong with LMT and GMT
 perhaps? It looks as if the illumination of the ac is at noon, while the
 scenery is midnight.
 
 Now if we could do that for all the ac on the parked on the apron - wow :-
 )
 

It's not a bug - it's a feature - OSG implements AC3D point lights. I can't
work out how to control them, but I'm sure they will come in useful at some
point.

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG crashes and Reply: osg/plib fps

[Vivian Meazza]

Mathias Fröhlich

 
 On Tuesday 21 November 2006 22:44, Georg Vollnhals wrote:
  I can only confirm the big fps improvement, with the OSG cvs compile of
  this evening I get (nearly) stable 85 fps at KSFO with the Cessna.
  This might say nothing to you, but the *very first* OSG compile started
  here with about 48 fps, one of my latest reports after first
  improvements was about 65 fps and *now* I get 85 fps - that is nearly
  doubled speed and very smooth!  And no fps reduce anymore when crossing
  KSFO terminal buildings east to west (west to east is another strange
  story, see bad news.) Very good work, Mathias, thank you once again!
 Ok. It settles down more slowly than I expected.
 But it is getting better ...

It certainly is. Here with MSVC8/Win32 frame rates are the same or better
for cockpit views of 3D panel models when compared to plib. 2D models remain
25% down. Interestingly, external views also remain about 25% down, and are
often worse than the cockpit view. I can't think why this might be so, but
it's a fault in the right direction.

KSFO has a huge effect on frame rates - 50% reduction compared with over the
sea, but I have not seen the effects described by Georg.

There is still some bad news - the frame rates fluctuates wildly between 1-3
and 50-51 and then there is a not infrequent hang while the computer goes
and does something else. 
 
 
  Then the BAD NEWS:
  1. Strange behaviour:
  Crossing KSFO terminal buildings E - W does not reduce framerate nor
  are any problems visible
  Crossing KSFO terminal buildings W - E reduces framerate from 85 to 56,
  stuttering, then in most cases (several tests, reproducable!) FG crash!
  What is the reason for this (unlogic) behaviour?
  Can anyone else reproduce this?
  - Default Cessna 172p, default KSFO scenery. After takeoff do an
  immediate left-turn crossing that parked yellow-red 737, then a right
  turn in direction of the KSFO terminals, crossing them E - W. (This
  should not do anything). After having passed the terminals fly until you
  can make a normal turn back  to the KSFO terminals, trying to cross them
  in W - E direction. Watch your fps, any changes?. IF no crash occures
  pass the terminals and  do  this procedure 2 times again. IF you manage
  to fly further, you are lucky and we all have more knowledge.
 Noted.
 
 I am still not responding well to bug reports. Most of them are just
 secondary
 effects of 'things not yet done right'. I spend more time improving the
 ground than hunting bugs that will most likely disappear when we some
 cleanup
 has happened.
 

It's all very encouraging, well done Mathias. Let's hope there's more to
come so that we can start to use the more advanced features of OSG.

Sorry I couldn't make this report earlier - MSVC decided to stop compiling
cvs-osg. Probably something I did: a complete rebuild of the project solved
it - just took a day of work ... 

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG fps

[Vivian Meazza]

Olaf Flebbe wrote

 
 now FlightGear OSG is running almost at the same speed (sometimes
 faster) than plib for me.
 FreeGlut was the culprit. Switching the the good old glut gives another
 10% FPS boost. And it fixes a bug: For me the c172p with freeglut is
 accellerating itself at the runway without using the throttle. With
 glut-3.7.6 it stays at the starting position.
 

Yes, a small gain ( 10%) here. The big improvement was down to Mathias'
recent changes. But most important is that with GLUT the bug in the start
for the Hurricane/Spitfire/Seafire has been fixed.

It remains the case, that while cockpit views are now comparable, or better
than plib, external views are still about 25% down, and usually less than
the cockpit view. My guess is that transparencies have a disproportionate
affect on frame rates.

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Cows

[Vivian Meazza]

Hi, 

There have been several complaints about our fauna, namely headless cows,
over on the IRC channel. I've done one with a head:

 ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lowish-poly-cow.jpg

it's 180 vertices, so heads ain't free. If no one objects, I intend to
replace the headless version in cvs-head in a couple of days for a trial. It
will, of course be possible to revert if it causes too much of a hit on
frame rate.

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] osg, libgif and debian sid

[Vivian Meazza]

Josh Babcock wrote

 
 I'm having trouble with OSG and debian's giflib3g-dev package.
 When I try to compile OSG, i get the following error. Has anyone else
 seen this? If not, I will take it to the OSG list. I am compiling the
 version in OSG_OP_OT-1.2-Flightgear.tar.gz
 
 Josh
 

You don't need gif stuff for FlightGear- just remove all references to it.

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Spitfire/Seafire mag compass doesn't work in CVS- fixed

[Vivian Meazza]

Nick Warne wrote

 
 Hi all,
 
 Latest CVS osg
 
 I found the magnetic compass isn't working in the Spitfire/Seafire.
 
 After a lot of faffing about (using the Hurricane compass as reference, as
 that worked), I found the issue... or rather diff did.
 
 --- Spitfire/Models/compass.xml 2006-12-28 14:07:08.0 +
 +++ Hurricane/Models/compass.xml2006-12-28 14:06:24.0
 +
 @@ -4,7 +4,7 @@
animation
  typerotate/type
  object-nameCompass/object-name
 -  propertyinstrumentation/magentic-compass/indicated-heading-
 deg/property
 +propertyinstrumentation/magnetic-compass/indicated-heading-
 deg/property
  center
x-m-0.02725/x-m
y-m0/y-m
 
 
 Can you see it?  In Spitfire/Models/compass.xml the the property
 tag, 'magnetic' is spelt wrong.
 
 I must have looked at that line a thousand times, and even looking at the
 diff
 output it is hard to see.
 

Well, it certainly is an error, but not in cvs head cvs-plib perhaps? There
was another bug to do with electrical outputs which I have corrected.

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)

[Vivian Meazza]

John Denker wrote

 On 01/31/2007 05:59 PM, AJ MacLeod wrote:
 
  Please correct me if I'm wrong, but I suspect you're only looking at
 aircraft
  which use old fashioned simple XML electrical systems.
 
  Most vaguely recent aircraft which have had any significant attention
 paid to
  their electrical system will be using a nasal based one...
 
 Well, I'm only smart enough to find ones that refer to DG by the name DG.
 This includes one with an electrical.nas.
 
 If you know of others, or a way to find others, please share.
 
 find . | xargs grep -I '[/]DG'
 ./Aircraft/Spitfire/Systems/electrical.xml:
 prop/systems/electrical/outputs/DG/prop
 ./Aircraft/E3B/Systems/electrical.xml:
 prop/systems/electrical/outputs/DG/prop
 ./Aircraft/KC135/Systems/electrical.xml:
 prop/systems/electrical/outputs/DG/prop
 ./Aircraft/SeaVixen/Systems/seavixen-electrical.nas:DG = Output.new
 (DG,
 

Hmm. There's some terminological inexactitude that has crept in here. In the
Sea Vixen Pilot's notes what we might now call the hsi but was then called
the compass indicator is the instrument on the panel. It has its own power
supply and serviceability status. It is fed by the Master Reference Gyro
(normal) or a Directional Gyro (Standby) each with its own power supply and
serviceability status. 

I have modeled the MRG to reflect the data I have available, but have yet to
do fast erection. The DG is probably less well modeled right now. 

The fluxgate compass is a different device which I added as an alternative
to the then existing vacuum-driven item. And yes the Spitfire etc.
electrical systems need updating to the latest nasal script standard.

Vivian


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FG IVAO client (II)

[Vivian Meazza]

Pep.

 
 
 Sorry, I forgot to post the bitmap... Here it is...
 
 Regarding the command-line thing, it might be good to start 
 there. However, what should be the right tool to use when it 
 comes the time to set up the GUI?
 

I'm not entirely clear about what you require, but your picture looks very
similar to 2d panel instruments we already have in FlightGear. Given the
central display, the surrounds and other bits could be fairly readily made
using free modelling tools (Blender) with textures made with the Gimp or
Inkscape, all driven by some XML and/or NASAL. 

The central panel looks a much more difficult.

Of course, I might have misinterpreted your picture and/or your requirements

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [BUG] simgear/math/polar3d.cxx: bothfunctions assume inverted longitude

[Vivian Meazza]

Melchior

 
 
 * Melchior FRANZ -- Sunday 25 February 2007:
  I would fix the files if people agree that what I consider a bug is 
  indeed a bug.
 
 I assume that the whole stuff should be dumped and replaced with
 geo_*_wgs_84() functions, right? And this is the end of my 
 one-man thread.  :-)
 

That's what I use elsewhere in AIModel. I'd go with your suggestion, but
it's not my call.

Vivian

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] [ANN]- AIShips - Flightplans

[Vivian Meazza]

Hi,

I've just added to cvs (with Melchior assistance/advice) the facility for
AIShips to follow a 'flightplan', and added a scenario to demonstrate it in
cvs-data (PAVictoria_demo.xml). This has a couple of ferries running between
Port Angeles and Victoria, British Columbia. The new code introduces the
concept of a 'WAIT' token to the flightplan: when this token is reached the
AIShip waits for the specified time. I've also added Dene Maxwell's nice
ferry to the inventory. I hope that this new eye-candy will add to your
enjoyment of FlightGear.

Vivian

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [BUG] Spitfire throttle boost gauge fails (withfix)

[Vivian Meazza]

Nick wrote

 
 Hi all,
 
 Flying the Spitfire, if you get airborne and then drop the 
 throttle to zero, 
 the gear warning alarm klaxon sounds.  Hitting 'k' or 'K' to 
 turn this off 
 then produces:
 
 Nasal runtime error: non-objects have no members
   at 
 /usr/share/FlightGear/data/Aircraft/Spitfire/Models/spitfire.n
 as, line 76
 
 From now on the throttle boost gauge will not work.
 
 
 The reason is in spitifre.nas, line 46 a global var:
 
 throttle = 
 props.globals.getNode(/controls/engines/engine/throttle, 1);
 
 later in spitfire.nas in the 'resetWarn = func{ }' is this, line 493:
 
 throttle = getprop(controls/engines/engine/throttle);
 
 so here the second assignment stomps on the first.  I guess renaming 
 the 'throttle' var in this func to something else fixes this, 
 but also it can 
 be declared in the func as a local var:
 
 var throttle = getprop(controls/engines/engine/throttle);
 
 to fix it.
 

Thanks, Nick, I can reproduce that here. I'm on the case,

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AI flights...

[Vivian Meazza]

Syd wrote

 HI all , playing around with Traffic , having fun , but noticed a few 
 things .
 Just want to know if Im doing something wrong , or I'm expecting 
 something that doesnt work yet
 Aircraft seem to appear only if you start at about the same 
 time a s the 
 departure time:
 Ive sat at the destination airport waiting for the flight to 
 arrive ,  
 it hasn't yet :
 Ive followed the flight after takeoff , and the AI aircraft 
 flies in a 
 straight line after takeoff, no coarse changes:
 This is with traffic schedules placed in /AI/Aircraft , not 
 included in 
 the fgtraffic.xml
 In this playing around I've also noticed how incorrect the smaller BC 
 airports are , some have taxiways where there really are none , 
 windsocks in the middle of runways , beacons a kilometer off 
 or more 
 I REALLY need to get Terragear to compile !Which leads me to another 
 question , can JUST the airports be rebuilt , or does the 
 10x10 degrees 
 scenery also need to be redone at the same time ?

The AITraffic might or might not work, but you can play with a couple of
ferries plying between Victoria (BC) and Port Angeles which are now in cvs.
Should make a nice addition to your eye-candy around Vancouver. It shouldn't
take you too much to add a ferry or 2 working out of Vancouver

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AI flights...

[Vivian Meazza]

Dene wrote:

 
  By the way , I've also enabled the Victoria ferries , nice 
 addition . 
  I
  added a screenshot to my webpage of one leaving Port 
 Angeles... I'll 
  probably add a Vancouver route too 
 

 Aww...com'on Syd...what's the URL?...since I can't see Vivians 
 enhancements to the Picton ferries I would like to see the BC ones.
 ;-)

Syd didn't really catch the action. Bit more here:

ftp://abbeytheatre2.org.uk/fgfs/AIShip/ferry1.jpg
ftp://abbeytheatre2.org.uk/fgfs/AIShip/ferry2.jpg
ftp://abbeytheatre2.org.uk/fgfs/AIShip/ferry3.jpg

And you can't see the rotating radar antenna. Don't worry too much about the
exhaust effect. I'm still working on that. I've attached submodels to all AI
Objects: should be in cvs soonish. That should allow designers to do all
sorts of things. If Mathias passes the trigger property over MP we could do
lots more ...

Vivian


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] altimeter - encoder - kap140.nas

[Vivian Meazza]

 Melchior wrote:

 
 * Dave Perry -- Saturday 24 March 2007:
  Does anyone know what happened to John Denker?
 
 My way or the highway?
 
 
 
  I am still interested in the improved altimeter/atmosphere 
 model being 
  added to FlightGear.
 
 So am I. I had just done code review and pointed out why *I* 
 didn't consider the patches in a committable state yet. 
 Everyone was free to disagree. JD did, and it ended in a 
 clash with notorious teacher attitude and (willful?) 
 misinterpretation. After that *I* was no longer willing to 
 deal with the matter. No idea about all the other developers 
 with write access.
 
 My code review was based on what changes *I* would demand 
 before I'd commit. After all, the one who finally commits 
 code is really responsible for its quality, not (only) the 
 author. Maik and Vivian can probably confirm that I take this 
 rather seriously.  :-}
 

True, but remember that constructive criticism is an oxymoron. :-)

Vivian 



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Generic aar.nas/AI properties

[Vivian Meazza]

Markus Zojer

 
 Hello all!
 
 First off, when linking the B-2(yasim) to the generic aar.nas I 
 experienced a constant switching of the engines/out-of-fuel property 
 which unsurprisingly results in low thrust. Could this be 
 related to the 
 broken fuel-consumed-lbs property (of yasim?) that is jumping around 
 close to zero?
 
 Secondly, is live manipulating of AI model properties 
 possible at the 
 moment?
 
 In the flightgear property browser I found 
 orientation/true-heading-deg 
 and some radar properties but I think it would come in handy 
 to be able 
 to manipulate speed, altitude and waypoints (and maybe more 
 Wink) for an 
 AI model. So it would be possible to spawn an AI tanker at 
 a desired 
 location or be able to launch testbeds or rockets from a plane and 
 direct it to a desired location.
 

Several AI tankers are already available - you can use any of these:

  --ai-scenario=refueling_demo  (KC135-E)
  --ai-scenario=refueling_demo_1(KC135-E}
  --ai-scenario=refueling_demo_2(KA6-D)

If these don't suit - then modify them to your taste.

We only have Ballistic objects atm, but you can use this to simulate
unguided rockets. I have in mind to do something about guided weapons in the
future.

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] lightning tacan

[Vivian Meazza]

Nick Warne wrote:

 On Friday 06 April 2007 14:00:14 AJ MacLeod wrote:
 
  The tanker in refueling_demo doesn't have TACAN at all.  In fact, I 
  think we have a bit of needless duplication with those 
 demos, and one 
  of them could be removed without too much pain...
 
 OK, Csaba found the bug I was seeing, and he fixed it, so no 
 doubt a fix is on 
 the way soon - I am so pleased, I thought I was going mad.  
 Thanks Csaba!!!
 
 
 As to the refueling_demo.xml.  I think this should stay, as 
 it can be used for 
 you own tanker scenerio.  I was testing over FHAW (Ascention 
 Island) and 
 tweaked the file so that it used TACAN also:
 
   entry
callsignESSO1/callsign
TACAN-channel-ID040X/TACAN-channel-ID
typeaircraft/type
classtanker/class
modelModels/Geometry/KC135/KC135.xml/model
 !--   latitude37.61633/latitude
longitude-122.38334/longitude --
latitude-7.974748/latitude
longitude-14.382520/longitude
altitude3000/altitude
heading020/heading
speed280/speed
roll-15/roll
   /entry
 
 
 It is very handy to have around.

 
 I'm sure you have spotted it by now - the TACAN code in C++ relates the
aircraft or carrier callsign to the assigned TACAN frequency (not channel).
The tag TACAN-channel-ID is for display purposes only so that if you open
the property browser you can quickly identify the assigned channel. So,
provided the mobile unit has one of the pre-assigned callsigns, it will also
have the pre-assigned TACAN frequency, no matter if the tag is present or
correct. For example:

12  999999   0   11030   0.000 ES1  ESSO1 TACAN

The reason for this is historical - the nav.dat data file only contains
TACAN frequency for fixed sites, and not TACAN channel. The file
carrier_nav.dat is simply an extension of that file for mobile units.

Just to make this clear - the tag TACAN-channel-ID has no effect on the
actual TACAN channel/frequency of a mobile unit - tag callsign determines
that.

Vivian  

  


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [RFC] tacan rewrite

[Vivian Meazza]

Csaba Halász

 Hello!
 
 I have looked into tacan code when investigating a bug found by Nick.
 From the one-liner fix it grew to this massive patch. Here is what I 
 did:
 
 Moved tacan parameters from carrier_nav.dat to the 
 appropriate model node in the property tree (eg. 
 /ai/models/carrier/navaids/tacan).
 Implementation added to AIBase (could even make a different 
 class, say AIBaseWithTacan). Ideally, the values should come 
 from 3 places: i) the scenario, ii) the model and iii) the 
 network. Until iii) works I automatically set up a tacan 
 channel for mp aircraft with callsign MOBIL (the isTanker 
 flag was set based on this anyway.) While normally a 
 configuration file is preferable to hardcoding things, in 
 this case I think it is a bad choice to pollute the globals 
 with information needed by a hack. And nobody ever tweaked 
 these settings.
 
 Added support for tacan position offset from the model 
 position. For now I just put in a temporary solution that 
 should work OK for carriers (the only place where this is 
 used currently). I don't know how to properly add a 
 body-relative vector to the lat,lon,alt coordinates.
 
 I have changed the channel-ID to lower case in the scenario 
 xml and the property tree. A quick search didn't show 
 anything that used it, so hopefully nothing is broken. Just a 
 matter of personal preference, feel free to ignore.
 
 Also, code cleanups here and there. At least I think they are 
 cleanups :) The TACAN::update function could use some 
 optimization so that it does not update unchanged nodes.
 
 There is an indicated-ground-speed-kt property which seems to 
 hold the closing speed. Should it be the ground speed of the 
 selected target, or do we need a rename? In the second case, 
 we should also add a little integration or something to make 
 the values more stable. (Given that ETA is also calculated 
 from this, I think it is a misnomer.)
 
 With these changes theoretically it should be possible to 
 operate the tacan from the source aircraft in MP for example.
 
 Grab the patch from: 
 http://w3.enternet.hu/jester/fgfs/tacan-20070412.diff
 
 Now you can start telling me why this doesn't make any sense :)
 


Doesn't make any sense to me - what bug are you trying to fix? TACAN works
as is for AI and MP aircraft, and at the moment allows up to 3 of each, but
it is trivial to increase that to any number you like, without recourse to
hard coding. 

Why do you want to offset a TACAN position? Why on earth are you hard coding
TACAN idents? Why limit the MP to only one tanker ident?

What is wrong with the existing FLOLS and Parking Position Code?

If you don't know how to properly add a body-relative vector to the
lat,lon,alt coordinates don't muck with Mathias' code - he does know.

I'm not persuaded by this - try to convince me that something is wrong with
the existing code and its method, and while you are trying to do that, I
will not accept hard coding TACAN channels for mobile transmitters, any more
than I would for fixed sites.

Vivian



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [RFC] tacan rewrite

[Vivian Meazza]

Csaba Halász

 
 On 4/12/07, Vivian Meazza [EMAIL PROTECTED] wrote:
 
  Doesn't make any sense to me - what bug are you trying to fix?
 
 None, it is already fixed. This is just a follow-up.
 
  Why do you want to offset a TACAN position?
 
 You know why: because on the carriers the tacan altitude is 
 100 feet. And that *is* fixed, no matter where the carrier 
 happens to be. It should be fixed relative to the carrier. So 
 as to hide this detail I have introduced the TACAN position 
 which gets calculated from the model position and an offset vector.

Well - if a carrier ever moves from sea level we can take the elevation add
the carrier altitude. Is anything more needed?
 
  Why on earth are you hard coding TACAN idents?
  Why limit the MP to only one tanker ident?
 
 It is actually a limit of 9, MOBIL1-9. I could have used a 
 *local* configuration file (or property) there, but this is 
 just a temporary solution - I expect tacan information to 
 come through MP protocol. Then this code will just disappear 
 without affecting anything else. And please note that the 
 isTanker flag *is* set from this hardcoded MOBIL callsign 
 as well. I don't think my solution is that much worse. At 
 least it is well localized.

Yes - I know - wrote it. And I think that you might have misinterpreted the
code here. The flag isTanker is set if any MP object has a callsign starting
with MOBIL - it can be followed by anything. But just because it has the
callsign MOBIL* doesn't imply that it fitted with TACAN - that is determined
by the callsign/TACAN ID assignment in carrier_nav.dat. Any callsign can be
associated with any TACAN ID - MOBIL is just a bit of a pun. Not all tankers
have TACAN transmitters - the Sea Vixen in the Buddy-Buddy role is one such
example. The inverse is, I think, true: I know of no airborne TACAN
transmitter which isn't a tanker, but I'm a bit out of date here, and this
might have changed. Of course, the association of the callsign MOBIL* with a
tanker is a hack - the property isTanker ought to be passed over MP. But
when this was written no properties were passed, and adding them to the MP
servers is not trivial.
  
 And these changes make it possible to provide tacan 
 parameters from MP. Like changing channels, disabling 
 transmitter and such. All at runtime. That is a desirable 
 goal is it not? My solution might not be the best way to do 
 it, though.

Switching on/off is indeed desirable, but not changing channels at runtime.
Channels are assigned by headquarters for a mission and not changed in
flight. In my day, this was only done by the ground crew, but it might well
be possible in flight nowadays. Passing the appropriate property value over
MP should suffice, if we had a controllable TACAN transmitter in the
aircraft, which right now we don't.
 
  What is wrong with the existing FLOLS and Parking Position Code?
 
 Nothing, that was just a code cleanup. Refactored duplicated 
 code that reads a x-offset-m, y-offset-m and z-offset-m 
 triplet into a corrected SGVec3d. It now lives in 
 FGAIBase::readOffsetFromScenario() because I happened to need 
 that too. Surely that is not a bad thing?

It is indeed a bad thing - only properties that are common to more than one
AI Object live in AIBase. The FLOLS and ParkPos offsets are peculiar to
AICarriers, and so it is right that they should live there.

  If you don't know how to properly add a body-relative 
 vector to the 
  lat,lon,alt coordinates don't muck with Mathias' code - he 
 does know.
 
 I pointed out what I don't know so that somebody who does can 
 help me out (and it does not slip in unnoticed). In the 
 meantime that code works for the 2 cases currently in use. 
 (My guess is that I would need to convert to cartesian, 
 rotate by the yaw,pitch,roll add the offset and convert 
 back.) Do you think I should have done nothing because I am 
 not sure about that little detail?

Well, I think it's better if patches don't have built in problems - the
trouble is no one is likely to pick up on little details for you. 

 Personally I also disliked the old TACAN::search from a 
 coding point of view. Lots of code duplication, variable 
 names like str1,str2, ... str6 etc.

Fair comment. It grew out of the old dme code, and I would have probably
done it differently with a clean sheet of paper approach

 I won't mind if this does not get into cvs. I am having much 
 fun with FG - both flying and coding. So I thought why not 
 try something other than bug fixes (even though this started 
 out as that as well).

Well, you haven't convinced me that this is a valid change, in fact I think
it flawed in several important respects. Sorry, especially if you have spent
any great time on this. But thank you very much indeed for finding and
correcting the original bug. Hmm - no one noticed for 6 months! Oh well ...
particularly as it had been fixed once. 
 
 Hope Mathias doesn't mind that I mucked with his code. 
 Looks like JSB is next :)

I sure he

Re: [Flightgear-devel] [RFC] tacan rewrite

[Vivian Meazza]

Csaba Halász

   On 4/12/07, Vivian Meazza wrote:
  
Why do you want to offset a TACAN position?
  
   You know why: because on the carriers the tacan altitude is 100 
   feet. And that *is* fixed, no matter where the carrier happens to 
   be. It should be fixed relative to the carrier. So as to 
 hide this 
   detail I have introduced the TACAN position which gets calculated 
   from the model position and an offset vector.
 
  Well - if a carrier ever moves from sea level we can take the 
  elevation add the carrier altitude. Is anything more needed?
 
 Umm, actually that is what I have done. Just in a more 
 generic way, such as possibly accounting for lateral 
 displacement and non-level orientation of the carrier. 
 Admittedly does not amount to much in case of the tacan, but 
 seems to be more logical this way. Looks like just for me.
 
Why on earth are you hard coding TACAN idents?
Why limit the MP to only one tanker ident?
  
   It is actually a limit of 9, MOBIL1-9. I could have used a
   *local* configuration file (or property) there, but this 
 is just a 
   temporary solution - I expect tacan information to come 
 through MP 
   protocol. Then this code will just disappear without affecting 
   anything else. And please note that the isTanker flag 
 *is* set from 
   this hardcoded MOBIL callsign as well. I don't think my 
 solution 
   is that much worse. At least it is well localized.
 
  Yes - I know - wrote it. And I think that you might have 
  misinterpreted the code here. The flag isTanker is set if any MP 
  object has a callsign starting with MOBIL - it can be followed by 
  anything. But just because it has the callsign MOBIL* doesn't imply 
  that it fitted with TACAN - that is determined by the 
 callsign/TACAN 
  ID assignment in carrier_nav.dat. Any callsign can be 
 associated with 
  any TACAN ID - MOBIL is just a bit of a pun. Not all tankers have 
  TACAN transmitters - the Sea Vixen in the Buddy-Buddy role 
 is one such 
  example. The inverse is, I think, true: I know of no airborne TACAN 
  transmitter which isn't a tanker, but I'm a bit out of date 
 here, and 
  this might have changed. Of course, the association of the callsign 
  MOBIL* with a tanker is a hack - the property isTanker ought to be 
  passed over MP. But when this was written no properties 
 were passed, 
  and adding them to the MP servers is not trivial.
 
   And these changes make it possible to provide tacan 
 parameters from 
   MP. Like changing channels, disabling transmitter and 
 such. All at 
   runtime. That is a desirable goal is it not? My solution 
 might not 
   be the best way to do it, though.
 
  Switching on/off is indeed desirable, but not changing channels at 
  runtime. Channels are assigned by headquarters for a 
 mission and not 
  changed in flight. In my day, this was only done by the 
 ground crew, 
  but it might well be possible in flight nowadays. Passing the 
  appropriate property value over MP should suffice, if we had a 
  controllable TACAN transmitter in the aircraft, which right now we 
  don't.
 
 Right. Next step would be to send tacan channel over MP as 
 well and then this temporary workaround would vanish. In the 
 meantime I thought it wouldn't matter as I assumed pretty 
 much everybody uses the default config anyway. But changing 
 my version to support this is easy as all the pieces are in 
 place. Carriers come from scenarios now - no need for their 
 tacan to be in the carrier-nav.dat, might as well add them to 
 the scenario (which essentially models the headquarters) If 
 in the future they come from MP, the carrier-nav.dat is again 
 not needed. Also note that runtime includes whenever a new 
 pilot joins, similar to passing the call sign. Everybody else 
 should see the tacan of *my* aircraft as *my* ground crew 
 (the command line) set it - not as it is mapped in *their* 
 carrier-nav.dat.
 
What is wrong with the existing FLOLS and Parking Position Code?
  
   Nothing, that was just a code cleanup. Refactored duplicated code 
   that reads a x-offset-m, y-offset-m and z-offset-m triplet into a 
   corrected SGVec3d. It now lives in
   FGAIBase::readOffsetFromScenario() because I happened to 
 need that 
   too. Surely that is not a bad thing?
 
  It is indeed a bad thing - only properties that are common to more 
  than one AI Object live in AIBase. The FLOLS and ParkPos 
 offsets are 
  peculiar to AICarriers, and so it is right that they should live 
  there.
 
 Umm, I think you missed something here. I did not move those 
 offsets anywhere. I just added a generic convenience function 
 that reads a generic offset value. I have only moved the 
 parsing code, the value is still stored wherever it was up to now.

Exactly my point: AIBase only reads generic values. Offsets are not generic
values, and their reading should remain where they are at present. If
another AI Object comes up with a requirement, then that is a different
matter

Re: [Flightgear-devel] [RFC] tacan rewrite

[Vivian Meazza]

gh.robin wrote:

... Snip ...
 
 Hello Vivian, Csaba
 I am a TACAN user, with Tankers and Carriers, (mainly 
 developing French Navy 
 Aircraft models) i have read with interest that long conversation.
 
 I can say, the existing TACAN system, which has been 
 implemented and improved 
 by Vivian suit to me, it is very simple to use and cover 
 every requests.
 
 Many thanks to Vivian who has spend so many hours on it .
 
 I feel only one useful development  which could come, 
 it is out of TACAN development but involve AI/MP system, i 
 mean the carriers 
 which could be part of an external AI system (not user 
 dependent)  in order 
 to give to every navy pilots, on line, the same carriers 
 position, and so, to 
 give the pleasure to land/take off all together to/from the 
 same place.
 

Thank you for the kind remarks. 

A carrier passed over MO=P ahs long been on the wish list. Several people
have been working on it (I'm not one of them), but there are no results so
far. We live in hope :-)

Vivian 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel