Re: [Flightgear-devel] Trees

[Vivian Meazza]

> Behalf Of Syd
> Sent: 14 April 2008 08:03
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Trees
> 
> 
> John Wojnaroski wrote:
> > My apologies to all the "tree-huggers" out there ;-)  but 
> how does one
> > disable all the trees?
> >
> > Great for mountains and forests scenery tiles; however last 
> month when 
> > I
> > was up at Ames don't recall all that lumber around the 
> runway and know 
> > that NASA will not care for all the trees around KDFW when 
> they start 
> > the research phase of the project.
> >
> > Regards
> > JW
> >
> >
> >   
> Hi John,
> Setting  to 0 in the materials.xml file should 
> do it . Haven't tried myself , I like it as dense as possible 
> :). Cheers, Syd
> 
 
Nothing like doing things the hard way :-). Try

 --prop:sim/rendering/random-vegetation=false

I use it and it works here.

Vivian



-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AI Aircraft Models

[Vivian Meazza]

Georg Vollnhals wrote

> 
> Durk Talsma schrieb:
> > On Wednesday 09 April 2008 15:38, Melchior FRANZ wrote:
> >   
> >> * Stuart Buchanan -- Wednesday 09 April 2008:
> >> 
> >>> As I mentioned in my reply to Vivian, I don't want any 
> dependency on 
> >>> the Aircraft tree,
> >>>   
> >> You don't want that, fine. And *I* don't want a parallel 
> structure of 
> >> aircraft with megabytes of duplicated files.
> >> 
> >
> > I object against adding dependencies on the main Aircraft 
> directories. 
> > When we
> > get ready for the next release, This is going to bite us 
> severely for all the 
> > good reasons Stuart explained. 
> >
> > FWIW, I proposed the AI/Aircraft directory originally to 
> contain many 
> > light
> > weight models that were originally intended for use by the computer 
> > controlled AI system. As such, the AI directory was 
> supposed to contain many 
> > additional texture directories for all the different 
> liveries, this implies 
> > that the AI/Aircraft could potentially grow quite a bit. 
> The fact that we 
> > also store some copies of liveries used in the main 
> directory only adds a 
> > small percentage to the overall size of the package. The 
> fact that these 
> > aircraft could also be used in multiplayer environment is a 
> nice bonus.
> >
> > For these reasons, I consider the argument that these copies add an
> > unacceptable increase of the base package largely void. 
> After all, we also 
> > don't have a policy for NOT adding new aircraft to the base 
> package, so the 
> > size of the CVS repository can't be an issue at all. 
> >
> > I do forsee that adding loads of AI aircraft could add to 
> the size of 
> > the
> > release version of the base package.  That being the case, 
> we could consider 
> > spawning off a separately downloadable, optional AI 
> aircraft package 
> > (including not only aircraft, but also traffic files, etc 
> etc). This would be 
> > a point worth discussing. Keep the AI/Aircraft directory 
> separate from the 
> > main aircraft directory is a complete no-brainer in my opinion.
> >
> > Cheers,
> > Durk
> >
> >   
> >From the viewpoint of a scenery-designer I fully agree with having at
> least low-texture - and if possible lower poly - AI aircraft 
> models. It is very easy to have some of these 
> "lighter-weighted" aircraft placed in the scenery without 
> framerate-punishment. So I did with EDDV and EDDW and 
> following the English Forum there are others who do the same.
> 
> So there are 3 arguments to have an independent AI aircraft 
> folder - may be separated as an extra downloadable package : 
> 1. Improving the MP framerate situation 2. Using them for AI 
> traffic 3. Using them for scenery design
> 

1. A long time ago in the early days of MP the policy was agreed: "If you
don't have it you don't see it". No glider, no ufo, nothing. And AFAIK
that's still the case. IF we want to depart from this long standing policy,
then that's a slightly different debate.

2. MP aircraft should be reasonably lightweight, but with good texture,
fully animated and no interior detail. A good way to achieve this is by
using the data already available in the main model file. This is good data
management practice, and avoids duplication. I would think this also applies
for AI Aircraft for the traffic manager; here of course you might want
textures in the AI/Aircraft directory, but not necessarily.

3. Dead, low poly models for inclusion in scenery should join those already
available in Models/Aircraft. Even then the option exists for using a
wrapper for textures in the main Aircraft file if this is appropriate. 

4. We don't seriously think that OSG is fit for a release this side of
Christmas do we? Should we really be using .png in anything other than osg
only models such as the Buccaneer, and even then I think I removed all .png
textures from the AI/MP version. (And now I'm going to have to :-))

Vivian

 



-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AI Aircraft Models

[Vivian Meazza]

Melchior FRANZ wrote

 
> 
> * Stuart Buchanan -- Wednesday 09 April 2008:
> > As I mentioned in my reply to Vivian, I don't want any 
> dependency on 
> > the Aircraft tree,
> 
> You don't want that, fine. And *I* don't want a parallel 
> structure of aircraft with megabytes of duplicated files.
> 
> So, please let's discuss that first, before anyone dumps more 
> of that stuff into $FG_ROOT/AI/!
> 
> 
> Do we really want MP support for all aircraft in the base 
> package, at a cost of an extra 200 MB of data? Wrappers are 
> fine (like Vivian described), but do we want a complete 
> concorde.ac with all textures
> *again* in the AI/ dir? If someone wants the Concorde 
> displayed, then s/he can install it, no? 
> 
> I'd prefer fgfs to show better information about which 
> aircraft couldn't be shown because they aren't installed, and 
> a better LOD concept (LOD in the aircraft dir, where it 
> belongs). And if we really want the independence, then we 
> should make sure that this is cheap. Textures should be 
> scaled down a *lot*, the model should be drastically 
> poly-reduced, the whole aircraft shouldn't take more than 250 
> kB (or something). And we don't need MP-versions of Ogel, 
> wrightfligher and others.
> 
> m.

If you install the .ac file, the model file, slightly amended, and the
textures, you might as well go the whole hog and install the complete
aircraft. Stuart's proposal will significantly increase the size of the base
package. I'm inclined towards Melchior's view on this one.

V.



-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] AI Aircraft Models

[Vivian Meazza]

Stuart Buchanan wrote
> 
> 
> Hi All,
> 
> The recent model-loading patch has made a big difference in 
> making MP usable again around KSFO. However, there is 
> obviously still an FPS cost in having a large number of MP 
> aircraft in the immediate area, which makes flying there hard 
> work, particularly with a taildragger like the very nice 
> Stampe - I'm getting 15 fps rather than 45 fps. 
> 
> Ironically, this is particularly a problem for us CVS users, 
> as we have all the aircraft in FG_DATA. Those with a basic 
> installation will get a glider model for missing aircraft, 
> which is much cheaper!
> 
> So, I spent a little while last night creating AI models for 
> some of the aircraft that I maintain (and in the process 
> discovering how many of them have bit-rotted...). 
> 
> I think this is worthwhile as:
> 1) It will mean that for the next release, all MP users will 
> be able to see all the other users, even if they don't have a 
> specific aircraft installed.
> 2) A dedicated AI model is cheaper than a heavily LoD'd 
> aircraft model.
> 3) For the majority of aircraft, once the initial model has 
> been created, little changes that would be visible to another 
> MP user, so keeping an AI model in sync with a main model is 
> not too difficult.
> 
> To create them I did the following:
> - Copied over the complete aircraft directory from 
> $FG_DATA/Aircraft to $FG_DATA/AI/Aircraft
> - Removed any extraneous files/directories (-set.xml, FDM, 
> Panels, sounds), typically just leaving a Model directory.
> - Use ImageMagick to convert any .rgb textures to png. 
> - Use a text editor to replace all the ".rgb" references to ".png"
> - Hacked out all the cockpit, sub-models and irrelevant 
> animations from the model .xml file.
> 
> For the aircraft I have converted so far, this has resulted 
> in a Model sub-directory, a single .ac file, a couple of .png 
> textures and a model .xml file.
> 
> This took less than 10 minutes per aircraft, including 
> testing with two MP sessions on the same box. So far, on the 
> simple aircraft I have created, this has been fool-proof.
> 
> I think this is a worthwhile task, and something that will 
> make life better in the longer term. 
> 
> I'd like to create more AI aircraft, but obviously this is 
> something that might step on the toes of the aircraft 
> maintainers.  So, if you are an aircraft maintainer, and 
> would be happy for me to create an AI version of your 
> aircraft using the process above, please drop me a line on-list.
> 
> Comments on whether this is a good idea are very welcome. 
> 

Unless you have actually generated different .ac file or textures from the
main model I would suggest that you use the ones in the main model files
like this:


../../../../Aircraft/seahawk/Models/SeaHawk-FGA6-WV859.ac

../../../../Aircraft/seahawk/Models

This would ensure that the main model and the AI model are kept in step.

And this reminds me, I have some AI models here of my ac which I don't
thinly I've uploaded yet

Vivian



-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] _Drastic_ framerate reduction approaching Nimitz

[Vivian Meazza]

> Behalf Of Tobias Ramforth
> Sent: 05 April 2008 20:28
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] _Drastic_ framerate reduction 
> approaching Nimitz
> 
> 
> Hello,
> 
> I am experiencing a drastic reduction in framerate, when approaching 
> Nimitz in an airplane. As soon as it is "in sight" (i.e. is getting 
> cached for display, I guess) the framerate drops from about 
> 40 to about 
> 5 and the game is no longer playable.
> "In sight" also means when directly starting from KSFO into Nimitz' 
> direction.
> When the Nimitz is out of sight again the framerate 
> normalizes. This can 
> either be done by passing by or turning.
> 
> I think there might be something wrong with the Nimitz 
> implementation!? Can anyone confirm this behaviour?
> 
> I am using up-to-date versions of every lib from SVN/CVS and 
> flightgear 
> CVS head, as well.
> 

No adverse effects seen here with up-to-date versions of FG/SG. OSG is a
couple of days old. Frame rates here are 35 all around Nimitz, and away from
the area as well, using the Seahawk.

Nimitz hasn't been altered in any way for some years now, so it is unlikely
to be a something wrong there, more likely elsewhere in your implementation.

Vivian



-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS - Frame Rates under Windows XP

[Vivian Meazza]

Tim Moore

> Sent: 01 April 2008 12:35
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] CVS - Frame Rates under Windows XP
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Heiko Schulz wrote:
> |
> |> AND, with Linux and the same Graphics Card 7800 GS
> |> 512 MB, i can notice the
> |> same decrease of performance from FG-PLIB  to FG-OSG
> |> ,
> |> I ever had   about 20% less performance   with OSG.
> |>
> |> I am running FG on  AMD ATHLON 3200 (32 bit) with
> |> AGP  mothercard.
> |>
> |> May be OSG is more accurate with modern (recent)
> |> CPU. (i must test it).
> |>
> |>
> |> Cheers
> |>
> |>
> |> --
> | I notice a difference between OSG and Plib too- but
> | this is known!
> | But we can discuss and find out, how to make it
> | faster- time for Tim to answer!
> 
> I suggested that Vivian post his experiences here. I've been 
> working with him for several months on trying to resolve 
> these problems. I'm convinced that his machine is cursed :) I 
> don't develop on Windows and so have run out of ideas other 
> than general suggestions. I'm hoping that more experienced 
> Windows developers will have some ideas for how to proceed.
> 
> One thing seems clear: the OSG version uses more memory than 
> the plib version does. Therefore there is a more memory 
> "pressure;" the entire system needs to deal with this. Memory 
> allocation, especially on Windows, seems to be expensive. ~ 
> Vivian had some improved results today turning off the replay 
> system, which may give us a clue. I think it will only help 
> performance to, in general, optimize the memory usage of FlightGear.
> 

Just an update. Using

 --prop:sim/replay/disable=true

Makes FG-OSG as smooth as plib is with

 --prop:sim/replay/disable=false

I tried Csaba's MinGW build - frame rates are improved by 20% across the
board, and only 20% below plib (which of course might see further
improvement with a MinGW build.

So I conclude that:
1. There is a problem with replay, 
2. MinGW has about the same performance gap between OSG and plib on XP as
gcc does on Linux.
3. MinGW performance is probably as good as it gets.
4. Either MSVC8 doesn't compile such fast code as MinGW, or there is a
setting wrong somewhere.

Vivian




-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS - Frame Rates under Windows XP

[Vivian Meazza]

Heiko Schulz wrote

> Sent: 31 March 2008 20:45
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] CVS - Frame Rates under Windows XP
> 
> 
> 

Vivian Meazza  schrieb:

> 
> > Hi
> >  
> > About 10 days ago I got fed up with low frame rates
> > using OSG around KSFO,
> > so I went out and bought the best nVidia AGP card
> > that I could find - 7600gs
> > with 512Mb of VRAM. I fitted it with great
> > anticipation to my machine - P4
> > 2.8Ghz/800Mhz FSB with 1.5 Gb of RAM running XP -
> > and, precisely NOTHING. No
> > change in frame rate between the new card and the
> > old - a FX6200 with 256Mb
> > VRAM - for FG-OSG-HEAD. On the other hand plib-HEAD
> > flies. Here are some
> > comparative results:
> >  
> > Aircraft: Seahawk   
> >  OSG
> >  PLIB
> >KSFOGeneral  Ocean  
> > KSFOGeneral
> > Ocean
> > every check box turned to off:
> > 25  30  60  
> >  4580
> > 117
> > with everything checked, traffic manager on:
> >15   25  36  
> >  2550
> > 80
> > as above with shadows and 3d clouds:
> > 
> >  1840
> > 65
> > as above but with trees and precipitation:
> >10   15 40 (but the rain
> > turned itself off!)
> >  
> > Aircraft: c172p
> > every check box turned to off:
> >   3340  60  
> > 4590
> > 130
> > with everything checked, traffic manager on:
> >   2733  40  
> > 3050
> > 75
> > as above with shadows and 3d clouds:
> > 
> > 3050
> > 65
> > as above but with trees and precipitation:
> >   1525  30 
> >  
> > Aircraft: Buccaneer (particles)
> > as  above but with trees and precipitation:
> >818  20 
> >  
> > In addition to the difference in frame rate, OSG
> > also stutters, while plib
> > is commendably smooth. I've tried both executables
> > generated here using
> > MSVC8, and Fred's pre-cooked binaries. So far as I
> > can see the results are
> > identical. I've profiled both OSG and plib - for
> > anyone interested, some of
> > the results are here:
> >  
> > ftp://abbeytheatre2.org.uk/fgfs/OSG/
> >  
> > While I am no expert in profiling code, the results
> > seem to me to show that
> > we are getting stuck in the bowels of OSG somewhere,
> > while plib is
> > well-ordered, with no particular cpu-hog, which is
> > pretty much what the
> > above table indicates.
> >  
> > My principle concern is that there appears to be
> > very little headroom for
> > future developments in OSG for shadows, or 3d
> > clouds, or landing lights, on
> > what is a not-very-old and pretty capable machine. I
> > would be grateful if
> > some Windows user(s) could confirm at least the
> > shape of these comparative
> > results. I understand that Linux users get much
> > better results than these.
> > We might be getting towards the point when Windows
> > users are stuck with plib
> > (and that's not all bad) while Linux users get to
> > play with all the new
> > goodies. We might be drifting away from our cross
> > platform ethic.
> >  
> >  
> > Vivian
> >  
> > Luckily the new card wasn't terribly expensive
> > otherwise I would be quite
> > p'd off
> >  
> Hi,
> 
> With the recent built by Fred I found the old stutters
> again- but I could sovle this for me.
> 
> But I can't see any of those problems you have- I can
> run FGFS with all features we have - plus heavy
> self-written interactive traffic and mp. And the best-
> I can run other programs beside too without any
> problems (blender as an graphic example!)
> 
> You should know, that you have to set some things on
> your pc, Nvidea and FGFS:
> 
> - switch Vsync in the Nvidea settings
> - use the frame-rate-throttle!
> 
> I use a CoreDuo 2,6 Ghz and a Gainward 8800GT - but
> there were people in the german forum and the official
> forum (kid's playground) having no problems with the
> recen

[Flightgear-devel] CVS - Frame Rates under Windows XP

[Vivian Meazza]

Hi
 
About 10 days ago I got fed up with low frame rates using OSG around KSFO,
so I went out and bought the best nVidia AGP card that I could find - 7600gs
with 512Mb of VRAM. I fitted it with great anticipation to my machine - P4
2.8Ghz/800Mhz FSB with 1.5 Gb of RAM running XP - and, precisely NOTHING. No
change in frame rate between the new card and the old - a FX6200 with 256Mb
VRAM - for FG-OSG-HEAD. On the other hand plib-HEAD flies. Here are some
comparative results:
 
Aircraft: Seahawk   
 OSG  PLIB
   KSFOGeneral  Ocean   KSFOGeneral
Ocean
every check box turned to off:
25  30  604580
117
with everything checked, traffic manager on:
   15   25  362550
80
as above with shadows and 3d clouds:
  1840
65
as above but with trees and precipitation:
   10   15 40 (but the rain turned itself off!)
 
Aircraft: c172p 
every check box turned to off:
  3340  60   4590
130
with everything checked, traffic manager on:
  2733  40   3050
75
as above with shadows and 3d clouds:
 3050
65
as above but with trees and precipitation:
  1525  30 
 
Aircraft: Buccaneer (particles)
as  above but with trees and precipitation:
   818  20 
 
In addition to the difference in frame rate, OSG also stutters, while plib
is commendably smooth. I've tried both executables generated here using
MSVC8, and Fred's pre-cooked binaries. So far as I can see the results are
identical. I've profiled both OSG and plib - for anyone interested, some of
the results are here:
 
ftp://abbeytheatre2.org.uk/fgfs/OSG/
 
While I am no expert in profiling code, the results seem to me to show that
we are getting stuck in the bowels of OSG somewhere, while plib is
well-ordered, with no particular cpu-hog, which is pretty much what the
above table indicates.
 
My principle concern is that there appears to be very little headroom for
future developments in OSG for shadows, or 3d clouds, or landing lights, on
what is a not-very-old and pretty capable machine. I would be grateful if
some Windows user(s) could confirm at least the shape of these comparative
results. I understand that Linux users get much better results than these.
We might be getting towards the point when Windows users are stuck with plib
(and that's not all bad) while Linux users get to play with all the new
goodies. We might be drifting away from our cross platform ethic.
 
 
Vivian
 
Luckily the new card wasn't terribly expensive otherwise I would be quite
p'd off
 
 
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flight Gear Build

[Vivian Meazza]

Hmm - I had to abandon cygwin over a year ago because they haven't updated
the gcc version. The solution is the free download of MSVC8 from MS. The
project files are in the source code, although a bit old. I've tried with
MSVC9, but that compiles FG, but won't run  here.
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wong,
Sophia
Sent: 28 March 2008 14:39
To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] Flight Gear Build



I am currently having problem to build Flightgear-1.0.0.

Following is the configuration of my workstation:

Openal-0.0.8 source code (Successfully built)

Freealut 1.1.0 (Successfully built)

Freeglut 2.2.0 (Successfully built) - I was not able to build Freeglut 2.4.0

Plib-1.8.5 (Successfully built)

Simgear 1.0.0 (Successfully built)

My Window XP is running the emulator cygwin 3.4.4 (gcc- 3.4.4-3)

The following error was one of the compiler errors I ran into:

 

/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/streambuf:781 

In member function 'Virtual std::streamsize std:: _streambuf < _CharT,
_Traits >:: xsgetn, <_CharT*, std::streamsize);

Streambuf.tcc:54 error: expected unqualified_id before '(' token.

 

I am not sure if it is because of the incompatibility between cygwin (gcc
compiler was installed with cygwin) and flightgear.

Anyone ran into this problem?

 

Thanks.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] CVS - Data Re-organisation

[Vivian Meazza]

Hi all,

A few days ago the data in cvs was reorganised with several directories
being moved from Models to AI/Aircraft. This not only broke the carriers
(because the move wasn't completed correctly), and lumped ships and aircraft
in the same directory, but also misunderstood the purpose of the AI/Aircraft
directory. This is intended to hold "lightweight" models for use by the AI
Traffic Manager and Multiplayer, usually, but not exclusively, in the form
of xml wrappers which actually point elsewhere, either to the appropriate
Aircraft or Models directory. It was not intended to be a heap for anything
which didn't fit conveniently elsewhere. This change has neither been
discussed nor agreed. 

Subject to there being no substantive objections here, I intend to revert
this change over the coming weekend. This has been discussed with and agreed
upon by fellow core developers, This is also the consensus view on *IRC*.

Now, this probably isn't the best solution, and putting ships under
Models/Geometry is, to say the least, a bit eccentric. So we can work on
deriving a better answer, once we have got back the status quo ante.

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] model-paging patch - testers wanted

[Vivian Meazza]

Lee

> Sent: 19 March 2008 15:53
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] model-paging patch - testers wanted
> 
> 
> On Wednesday 19 March 2008 14:43, Vivian Meazza wrote:
> > Stefan Seifert
> >
> > > Sent: 19 March 2008 14:40
> > > To: FlightGear developers discussions
> > > Subject: Re: [Flightgear-devel] model-paging patch - 
> testers wanted
> > >
> > > On Wednesday 19 March 2008 15:16:29 Vivian Meazza wrote:
> > > > I've been testing this patch for some while now. I 
> would strongly 
> > > > recommend anyone who uses multiplayer to use it. There is
> > >
> > > no obvious
> > >
> > > > downside, but as Till said, there is more work to be done.
> > >
> > > It really
> > >
> > > > needs lots of people to give this a good testing, but right
> > >
> > > now it's
> > >
> > > > probably nearly good enough for inclusion in cvs.
> > >
> > > I vote for including it in CVS right away. This is 
> exactly what CVS 
> > > is for: synchronizing sources between developers and keeping a 
> > > history of all changes.
> > >
> > > Pushing around patches manually is exactly what CVS is meant to 
> > > replace. So why not just use it?
> > >
> > > Remember: release early, release often.
> >
> > I nearly said that - and chickened out at the last minute - yes - I 
> > support this.
> >
> > V.
> 
> Heh - I really don't like that phrase.  It may sound 'cool' but to 
> me it's saying 'design by trial and error', which is an oxymoron:)
> 
> I also think it does nothing to encourage quality and is likely to 
> increase the number of bugs that will be encountered by people who 
> are trying to use the s/w, or who are trying to develop for it.
> 
> All in all, I regard it as a bit of a cop-out by developers who are 
> too lazy to thoroughly think things through and, with regard to 
> commercial s/w, a method of extorting money for faulty goods.
> 
> It certainly doesn't encourage confidence that the s/w will work and 
> as FG isn't just an academic exercise in s/w development - a lot of 
> people and groups are using it for a very wide range of purposes - 
> I can't agree that it's a good idea.
> 
> Sure - new features and developments have to be beta-tested in a 
> wider environment, and cvs is right for that, but not for alpha 
> testing.
> 
> Just a personal view:)
> 

OK, Lee - yes, no alpha testing. In this particular case the patch is well
into beta. The alpha testing was done by me and others. I hope that you will
test it.

And as a carrot, the quicker this is done, the quicker we can move on to
getting the other goodies and bug fixes into cvs.

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] model-paging patch - testers wanted

[Vivian Meazza]

Stefan Seifert

> Sent: 19 March 2008 14:40
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] model-paging patch - testers wanted
> 
> 
> On Wednesday 19 March 2008 15:16:29 Vivian Meazza wrote:
> 
> > I've been testing this patch for some while now. I would strongly 
> > recommend anyone who uses multiplayer to use it. There is 
> no obvious 
> > downside, but as Till said, there is more work to be done. 
> It really 
> > needs lots of people to give this a good testing, but right 
> now it's 
> > probably nearly good enough for inclusion in cvs.
> 
> I vote for including it in CVS right away. This is exactly 
> what CVS is for: 
> synchronizing sources between developers and keeping a history of all 
> changes.
> 
> Pushing around patches manually is exactly what CVS is meant 
> to replace. So 
> why not just use it?
> 
> Remember: release early, release often.
> 

I nearly said that - and chickened out at the last minute - yes - I support
this.

V.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] model-paging patch - testers wanted

[Vivian Meazza]

Till Busch wrote:

> Sent: 19 March 2008 13:31
> To: 'FlightGear developers discussions'
> Subject: [Flightgear-devel] model-paging patch - testers wanted
> 
> 
> hi all,
> 
> as noted earlier in another thread, i am working on a 
> model-paging patch.
> 
> i need testers! if you want flightgear multiplayer to not 
> pause when other 
> pilots join, you are welcome to test my patch. some people 
> are running 
> flightgear with my patch alredy -- feedback is very positive so far.
> 
> get the files at http://flight.bux.at
> 
> -modelpaging-vX.X.X-beta-flightgear.patch
> -modelpaging-vX.X.X-beta-simgear.patch
> 
> current version is 0.4.4, but i will re-release frequently.
> 
> please don't forget to provide feedback after testing for a while.
> 
> 
> i started the project at the end of february with a simple 
> idea: move all 
> 3d-model loading to the DatabasePager-thread. my first 
> attempts looked 
> promising, though they were a little too optimistic (or 
> naive?). the patch 
> has evolved a lot since.
> 
> currently it does the following things:
> 1. revive SGModelLib, move functions for xml-model-loading there
> 
> 2. replace all calls to sgLoad3dModel with calls to either 
> SGModelLib::loadModel() or SGModelLib::loadPagedModel()
> almost all models will be loaded by the DatabasePager. the 
> few exceptions are: 
> your own plane, shared models in scenery, random objects, 
> AIBallistic models.
> 
> 3. simplify mode-loading functions (avoid passing around fg_root)
> 
> 4. avoid supurious MatrixTransform nodes in loaded models
> 
> 5. fix some memory leaks
> 
> 
> 
> NOTE: i'm still not pushing for integration in cvs. this 
> patch is huge and it 
> needs more testing. a little more clean-up is also needed.
> 
> 

I've been testing this patch for some while now. I would strongly recommend
anyone who uses multiplayer to use it. There is no obvious downside, but as
Till said, there is more work to be done. It really needs lots of people to
give this a good testing, but right now it's probably nearly good enough for
inclusion in cvs.

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] New problem with submodels

[Vivian Meazza]

Lee wrote

> Sent: 19 March 2008 11:43
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] New problem with submodels
> 
> 
> On Wednesday 19 March 2008 11:05, Vivian Meazza wrote:
> > Lee wrote:
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] 
> On Behalf Of 
> > > LeeE
> > > Sent: 13 March 2008 14:06
> > > To: FlightGear developers discussions
> > > Subject: Re: [Flightgear-devel] New problem with submodels
> > >
> > >
> > > On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...]
> > >
> > > > > > In theory nothing has been changed in submodels in a long 
> > > > > > time, and  remains a bool. However I have
> > >
> > > been making
> > >
> > > > > > changes in AIBallistic, so the problem probably lies there, 
> > > > > > and I'm investigating. I can sort of reproduce your bug,
> > >
> > > but here all
> > >
> > > > > > the submodels behave in the same way. If they don't 
> then it is 
> > > > > > possible that you haven't enabled AI Models.
> > > > > >
> > > > > > Vivian
> > > > >
> > > > > Hmm...  I have
> > > > >
> > > > > --prop:sim/ai-traffic/enabled=true
> > > > > --prop:sim/ai-traffic/level=3
> > > > >
> > > > > and
> > > > >
> > > > > --disable-random-objects
> > > > >
> > > > > in my .fgfsrc but they are the only AI related things I
> > >
> > > specifically
> > >
> > > > > set, and disabling the random objects is probably irrelevant 
> > > > > here.
> > > > >
> > > > > Actually, I haven't updated from FG cvs since mid
> > >
> > > February, so this
> > >
> > > > > problem dates from before then.  I'm also pretty sure the 
> > > > > problem wasn't apparent around early/mid December 
> 2008 because I 
> > > > > remember using trajectory markers while I was working 
> on the TFA 
> > > > > stuff for the BAC-TSR2 and I sent the resulting 
> update to Curt 
> > > > > on
> > >
> > > 2008-12-17.
> > >
> > > > > After some more testing last night, I have to revise 
> the ratio 
> > > > > of affected instances to ones that show the problem - 
> far more 
> > > > > instances _are_ affected than work correctly.  I'd now guess 
> > > > > that somewhere around nine out of ten instances are showing
> > >
> > > this strange
> > >
> > > > > behaviour, but there still doesn't appear to be a discernible 
> > > > > pattern.
> > > > >
> > > > > LeeE
> > > >
> > > > You need  --enable-ai-models. Without this you will see 
> > > > AIBallistic stuff, but they won't move correctly.
> > > >
> > > > I think there _is_ bug, but not quite the one you 
> describe. If you 
> > > > could just try again with the correct settings, and let me
> > >
> > > know what
> > >
> > > > you observe.
> > > >
> > > > V.
> > >
> > > I just went to try this and found that I'm already supplying 
> > > --enable-ai-models on the command line:(
> > >
> > > Sorry - I should have checked there as well.  I just use bash 
> > > history to call up my FG start command and thought I only 
> had stuff 
> > > that I change regularly included in it.
> >
> > OK - I've found the bug - the submodels are aligning to a 
> non-existent 
> > external force, because I failed to initialise the value, 
> trivial to 
> > fix. That's the good news. The bad news is that this fix 
> has got mixed 
> > up here with Till Busch's excellent scenery etc. paging 
> patch (which I 
> > recommended highly, and for which more testers are needed), 
> and which 
> > is mixed up with an extensive improvement to the 
> air-to-ground radar. 
> > I hope you can bear with us until we get it all sorted.
> >
> > Meanwhile, the terrain warning stuff has finally reached cvs-head.  
> > While I was about it, I added a more realistic rad alt (the terrain 
> > warning radar tilted through 90 degrees). An exa

Re: [Flightgear-devel] New problem with submodels

[Vivian Meazza]

Lee wrote:

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of LeeE
> Sent: 13 March 2008 14:06
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] New problem with submodels
> 
> 
> On Thursday 13 March 2008 08:12, Vivian Meazza wrote:
> [snip...]
> > > > In theory nothing has been changed in submodels in a long time, 
> > > > and  remains a bool. However I have 
> been making 
> > > > changes in AIBallistic, so the problem probably lies there, and 
> > > > I'm investigating. I can sort of reproduce your bug, 
> but here all 
> > > > the submodels behave in the same way. If they don't then it is 
> > > > possible that you haven't enabled AI Models.
> > > >
> > > > Vivian
> > >
> > > Hmm...  I have
> > >
> > > --prop:sim/ai-traffic/enabled=true
> > > --prop:sim/ai-traffic/level=3
> > >
> > > and
> > >
> > > --disable-random-objects
> > >
> > > in my .fgfsrc but they are the only AI related things I 
> specifically 
> > > set, and disabling the random objects is probably irrelevant here.
> > >
> > > Actually, I haven't updated from FG cvs since mid 
> February, so this 
> > > problem dates from before then.  I'm also pretty sure the problem 
> > > wasn't apparent around early/mid December 2008 because I remember 
> > > using trajectory markers while I was working on the TFA stuff for 
> > > the BAC-TSR2 and I sent the resulting update to Curt on 
> 2008-12-17.
> > >
> > > After some more testing last night, I have to revise the ratio of 
> > > affected instances to ones that show the problem - far more 
> > > instances _are_ affected than work correctly.  I'd now guess that 
> > > somewhere around nine out of ten instances are showing 
> this strange 
> > > behaviour, but there still doesn't appear to be a discernible 
> > > pattern.
> > >
> > > LeeE
> >
> > You need  --enable-ai-models. Without this you will see AIBallistic 
> > stuff, but they won't move correctly.
> >
> > I think there _is_ bug, but not quite the one you describe. If you 
> > could just try again with the correct settings, and let me 
> know what 
> > you observe.
> >
> > V.
> 
> I just went to try this and found that I'm already 
> supplying --enable-ai-models on the command line:(
> 
> Sorry - I should have checked there as well.  I just use bash 
> history to call up my FG start command and thought I only had stuff 
> that I change regularly included in it.
> 

OK - I've found the bug - the submodels are aligning to a non-existent
external force, because I failed to initialise the value, trivial to fix.
That's the good news. The bad news is that this fix has got mixed up here
with Till Busch's excellent scenery etc. paging patch (which I recommended
highly, and for which more testers are needed), and which is mixed up with
an extensive improvement to the air-to-ground radar. I hope you can bear
with us until we get it all sorted.

Meanwhile, the terrain warning stuff has finally reached cvs-head.  While I
was about it, I added a more realistic rad alt (the terrain warning radar
tilted through 90 degrees). An example of the use of these are to be found
in the Buccaneer. I hope that you can make some use of this lot.

Hang on - it will get better. 

Vivian

P.S. it all works here - I thought you would like to know that :-)



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Res: segmentation fault

[Vivian Meazza]

Christian Schmitt

> Sent: 18 March 2008 14:19
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Res: segmentation fault
> 
> 
> Cleber Santz wrote:
> > Hi,
> > 
> > I solve the problem with plib (removed v1.84 already instaled), 
> > but
> > now i`m getting segmentation fault when run flightgear.
> > 
> > I think the problem is with data (fg can`t find models) 
> but i make
> > checkout with the lastest data. I get 2 different dump, first with 
> > carrier enable so i disable carrier and get a another dump.
> > 
> > I send the 2 segmentation fault, w/o carrier, in attached files.
> > 
> >Any help ??
> > 
> > Best regards,
> > Cleber Santz.
> > 
> >
> Hi,
> 
> I encountered something like this yesterday, too. I did not run the 
> debugger, but going back to CVS from 14-Mar-08 made FG run 
> again. Maybe 
> you should try this, too.
> 

The recent unannounced and un-agreed changes in the data structure in cvs
have broken the carrier, I know what is wrong, and when I get a moment I
will fix it. In the meanwhile - blame the perpetrator (not me).

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] New problem with submodels

[Vivian Meazza]

Lee,

> Sent: 13 March 2008 01:58
> 
> On Wednesday 12 March 2008 08:26, Vivian Meazza wrote:
> > LeeE wrote
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] 
> On Behalf Of
> > > Sent: 11 March 2008 23:19
> > > To: FlightGear developers discussions
> > > Subject: [Flightgear-devel] New problem with submodels
> > >
> > >
> > > Hi,
> > >
> > > For a long time now I've been using ballistic submodels for
> > > trajectory markers.
> > >
> > > When using the trajectory markers, a simple inverted 'T' two
> > > line object is created at the aircraft position once per
> > > second, aligned with the aircraft roll and pitch axis.  The
> > > submodels have no weight, 0 buoyancy and are unaffected by
> > > wind, so once created they remain in place and provide a
> > > representation of the aircraft's flight trajectory.
> > >
> > > I just tried using them, having not used them for a while, and
> > > found that about half of the submodel instances are rolling
> > > over and spinning around.
> > >
> > > The problem seems to be random and about 50-50, with no obvious
> > > pattern between instances that behave properly and those that
> > > rotate and spin.
> > >
> > > As they're all created from the same config I'm at a bit of a
> > > loss as to how to fix it.
> > >
> > > I noticed that the README.submodels doc doesn't include a
> > > definition for the  tag but it is used in one
> > > of the examples.  I've always used this tag as a bool i.e.
> > > 'true/false', like the  tag, but in the examples the
> > >  value is '0' whereas the  tag values are
> > > either 'true' or 'false'. Is '0' used in  to
> > > represent a bool or is it now a numeric value?
> >
> > In theory nothing has been changed in submodels in a long time,
> > and  remains a bool. However I have been making
> > changes in AIBallistic, so the problem probably lies there, and
> > I'm investigating. I can sort of reproduce your bug, but here all
> > the submodels behave in the same way. If they don't then it is
> > possible that you haven't enabled AI Models.
> >
> > Vivian
> 
> Hmm...  I have
> 
> --prop:sim/ai-traffic/enabled=true
> --prop:sim/ai-traffic/level=3
> 
> and
> 
> --disable-random-objects
> 
> in my .fgfsrc but they are the only AI related things I specifically 
> set, and disabling the random objects is probably irrelevant here.
> 
> Actually, I haven't updated from FG cvs since mid February, so this 
> problem dates from before then.  I'm also pretty sure the problem 
> wasn't apparent around early/mid December 2008 because I remember 
> using trajectory markers while I was working on the TFA stuff for 
> the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17.
> 
> After some more testing last night, I have to revise the ratio of 
> affected instances to ones that show the problem - far more 
> instances _are_ affected than work correctly.  I'd now guess that 
> somewhere around nine out of ten instances are showing this strange 
> behaviour, but there still doesn't appear to be a discernible 
> pattern.
> 
> LeeE
> 

You need  --enable-ai-models. Without this you will see AIBallistic stuff,
but they won't move correctly.

I think there _is_ bug, but not quite the one you describe. If you could
just try again with the correct settings, and let me know what you observe.

V.



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] New problem with submodels

[Vivian Meazza]

LeeE wrote

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of 
> Sent: 11 March 2008 23:19
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] New problem with submodels
> 
> 
> Hi,
> 
> For a long time now I've been using ballistic submodels for 
> trajectory markers.
> 
> When using the trajectory markers, a simple inverted 'T' two line 
> object is created at the aircraft position once per second, aligned 
> with the aircraft roll and pitch axis.  The submodels have no 
> weight, 0 buoyancy and are unaffected by wind, so once created they 
> remain in place and provide a representation of the aircraft's 
> flight trajectory.
> 
> I just tried using them, having not used them for a while, and found 
> that about half of the submodel instances are rolling over and 
> spinning around.
> 
> The problem seems to be random and about 50-50, with no obvious 
> pattern between instances that behave properly and those that 
> rotate and spin.
> 
> As they're all created from the same config I'm at a bit of a loss 
> as to how to fix it.
> 
> I noticed that the README.submodels doc doesn't include a definition 
> for the  tag but it is used in one of the 
> examples.  I've always used this tag as a bool i.e. 'true/false', 
> like the  tag, but in the examples the  value 
> is '0' whereas the  tag values are either 'true' or 'false'.  
> Is '0' used in  to represent a bool or is it now a 
> numeric value?
> 

In theory nothing has been changed in submodels in a long time, and
 remains a bool. However I have been making changes in
AIBallistic, so the problem probably lies there, and I'm investigating. I
can sort of reproduce your bug, but here all the submodels behave in the
same way. If they don't then it is possible that you haven't enabled AI
Models.

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [PATCH] support AI parking as startup position

[Vivian Meazza]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Csaba Halász
> Sent: 28 February 2008 13:36
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] [PATCH] support AI parking as 
> startup position
> 
> 
> Hello, I have made a little patch for a requested feature. 
> Makes it possible to start at a parking location defined in 
> the AI/Airports/*/parking.xml files, using the parkpos 
> command line option. Note that the name to pass is the 
> concatenation of the "name" and "number" fields in the xml.
> 
> This can be extended by
> - adding an option to list the available positions
> - allowing startup at a randomly picked location
> - marking position as used/free when appropriate
> - adding parking position information to airportinfo nasal function
> 

This utility works nicely, and appears to have no downside. I used FGRun to
set the Parking Position from the Carrier entry - handy. I would support its
inclusion in cvs.

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Object avoidance

[Vivian Meazza]

I wrote:

> Subject: Re: [Flightgear-devel] Object avoidance
> 
> 
> Lee
> > Subject: Re: [Flightgear-devel] Object avoidance
> > 
> > 
> > On Sunday 17 February 2008 11:35, Vivian Meazza wrote:
> > > Markus
> > >
> > > > Subject: Re: [Flightgear-devel] Object avoidance
> > > >
> > > > LeeE wrote:
> > > > > On Friday 15 February 2008 17:08, Melchior FRANZ wrote:
> > > > >> * R. van Steenbergen -- Friday 15 February 2008:
> > > > >>> Melchior FRANZ wrote:
> > > > >>>> ...you could abuse that by
> > > > >>>> launching an invisible, lightweight, and very fast 
> submodel,
> > > > >>>> and check where and at which altitude it lands.
> > > > >>>
> > > > >>> Don't they call that 'radar' in real life? :) (The 
> very fast,
> > > > >>> lightweight submodels being microwave photons in that
> > > > >>> case)
> > > > >>
> > > > >> Hehe, yes. Except that ours don't come back. And I'm not
> > > >
> > > > sure if they
> > > >
> > > > >> collide with static/random buildings. They hardly do with
> > > >
> > > > trees. Hmm
> > > >
> > > > >> ... cows?
> > > > >>
> > > > >> m.
> > > > >
> > > > > Markus Zojer has used this technique for the TFA
> > functions in the
> > > > > B-1B.  I had a look at it and experimented with it when
> > I wanted
> > > > > to add TFA to a couple of aircraft I've done - it's a very
> > > > > appealing approach because it's almost like simulating a real 
> > > > > radar.
> > > > >
> > > > > I had a play with the technique but hit some problems with it,
> > > > > mainly because the trajectory of the submodels is 
> fixed to the 
> > > > > pitch of the aircraft.  I found it fine while the 
> > aircraft was in
> > > > > level flight but I hit some issues when the aircraft
> > was pitched
> > > > > up or down to any significant degree and in the end I
> > decided to
> > > > > use the Nasal geo functions instead.
> > > >
> > > > I am still working on the terrain following function,
> > rewriting it
> > > > completely for the 3rd time and again used "the real radar"
> > > > approach, as you are not dependent in the scanning 
> > resolution of the
> > > > geo properties. The fixed radar beam (submodels) could 
> be refined 
> > > > if we would add the property absolute to the pitch angle of the 
> > > > submodel  (so the submodel
> > > > leaves the plane at always the same pitch angle).
> > > >
> > > > Due to the ongoing environment development in OSG, now low level
> > > > flying is really flashing :)
> > > >
> > > > Expect the new version included in the next release (coming
> > > > hopefully within the next 10 days).
> > > >
> > > > Fly on,
> > > > Markus
> > > >
> > > > > As I mentioned previously, the geo functions do interact with
> > > > > static buildings and structures, as long as the 
> scanning scheme 
> > > > > has a high enough resolution to ensure sampling them - 
> > I haven't
> > > > > tried with random objects though - still on OSG 2.2
> > here and the
> > > > > performance hit when using
> > > > > OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here.
> > > > >
> > > > > I have noticed that pylons are not detected and I would
> > doubt that
> > > > > trees are detected either, presumably because they have
> > no area.
> > > > > The pylons are made with line objects that have no
> > width and the
> > > > > trees, at least in plan, also have no width, so it'll be very
> > > > > unlikely to hit the exact point where they are in any 
> scanning 
> > > > > scheme.  Adding a transparent horizontal plane poly to 
> > the top of
> > > > > these objects probably would make it work, but not only
> > would it
> > > > > increase the render load but also probably introduce more
> > > > > transparency render artifacts an

Re: [Flightgear-devel] Patch v2 - Rain & Snow

[Vivian Meazza]

Nicolas wrote

> Subject: Re: [Flightgear-devel] Patch v2 - Rain & Snow
> 
> 
> With the attachment, it's better...
> 
> Le lundi 18 février 2008 à 20:51 +0100, Nicolas a écrit :
> > Hi,
> > 
> > New revision for the precipitation patch...
> > 
> > The patch is always linked to METAR informations.
> > 
> > Changelog of this new release :
> > 1) Link the precipitation object to tile element :
> > Now, there is one precipitation object per tile. It permits 
> to use the 
> > world coordinate. I have followed the Tim'advices...
> > 
> > 2) Add links between precipitation and cloud layers :
> > When you are above the cloud layer, the precipitations are stopped.
> > 
> > 
> > For the next release, I hope fixed the wind issue...
> > 
> > 
> > Thank's to Tim and Vivian to help my with this developpement.
> > 
> > 
 

Coming along nicely - 

ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-snow.jpg


Still snowing in the cockpit though, and I'm not sure that the
precipitation's origin moves enough in response to ac speed. I like the way
the rain turns to snow at altitude, and the reaction to cloud layer.

A good version 2, I would recommend its inclusion in CVS. Thanks Nicklas,

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] PNG textures in CVS

[Vivian Meazza]

AJ

> Subject: [Flightgear-devel] PNG textures in CVS
> 
> 
> Hi all,
> 
> Now that our data has been "properly" branched, I would like 
> to move to using 
> PNG (or, where suitable, JPEG) textures in my models.  I've 
> seen no drawbacks 
> in my testing so far, only considerable benefits...
> 
> In disk space:
> 2.5M 2008-02-18 20:50 throttle_panel.rgb
> 981K 2008-02-18 20:50 throttle_panel.png
> 
> ...and even more importantly (to me) in simplifying workflow.
> 
> I can compose a texture in inkscape, export it to PNG with a 
> keystroke or two 
> and see the results in AC3D virtually instantly.  Using RGB 
> means converting 
> the png output from inkscape to rgb before reloading in ac3d 
> - one extra 
> step, but when you repeat the above process literally 
> hundreds of times the 
> extra hassle is very significant.
> 
> I'm not suggesting we convert all our existing textures to 
> PNG or JPEG, only 
> asking if there is any objection to my using such textures in 
> models destined 
> for CVS from now on.
> 
> Anyone?
> 
> Cheers,
> 

I can't see why we shouldn't do this. I can't see any downside, and there
are several advantages as pointed out. And should I be wrong and we find
there is a snag that we haven't foreseen, then reversion to RGBA is easy.

I support this proposal.

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Object avoidance

[Vivian Meazza]

Lee
> Subject: Re: [Flightgear-devel] Object avoidance
> 
> 
> On Sunday 17 February 2008 11:35, Vivian Meazza wrote:
> > Markus
> >
> > > Subject: Re: [Flightgear-devel] Object avoidance
> > >
> > > LeeE wrote:
> > > > On Friday 15 February 2008 17:08, Melchior FRANZ wrote:
> > > >> * R. van Steenbergen -- Friday 15 February 2008:
> > > >>> Melchior FRANZ wrote:
> > > >>>> ...you could abuse that by
> > > >>>> launching an invisible, lightweight, and very fast submodel, 
> > > >>>> and check where and at which altitude it lands.
> > > >>>
> > > >>> Don't they call that 'radar' in real life? :) (The very fast, 
> > > >>> lightweight submodels being microwave photons in that
> > > >>> case)
> > > >>
> > > >> Hehe, yes. Except that ours don't come back. And I'm not
> > >
> > > sure if they
> > >
> > > >> collide with static/random buildings. They hardly do with
> > >
> > > trees. Hmm
> > >
> > > >> ... cows?
> > > >>
> > > >> m.
> > > >
> > > > Markus Zojer has used this technique for the TFA 
> functions in the 
> > > > B-1B.  I had a look at it and experimented with it when 
> I wanted 
> > > > to add TFA to a couple of aircraft I've done - it's a very 
> > > > appealing approach because it's almost like simulating a real 
> > > > radar.
> > > >
> > > > I had a play with the technique but hit some problems with it, 
> > > > mainly because the trajectory of the submodels is fixed to the 
> > > > pitch of the aircraft.  I found it fine while the 
> aircraft was in 
> > > > level flight but I hit some issues when the aircraft 
> was pitched 
> > > > up or down to any significant degree and in the end I 
> decided to 
> > > > use the Nasal geo functions instead.
> > >
> > > I am still working on the terrain following function, 
> rewriting it 
> > > completely for the 3rd time and again used "the real radar" 
> > > approach, as you are not dependent in the scanning 
> resolution of the 
> > > geo properties. The fixed radar beam (submodels) could be refined
> > > if we would add the
> > > property absolute to the pitch angle of the submodel  (so the
> > > submodel
> > > leaves the plane at always the same pitch angle).
> > >
> > > Due to the ongoing environment development in OSG, now low level 
> > > flying is really flashing :)
> > >
> > > Expect the new version included in the next release (coming 
> > > hopefully within the next 10 days).
> > >
> > > Fly on,
> > > Markus
> > >
> > > > As I mentioned previously, the geo functions do interact with 
> > > > static buildings and structures, as long as the scanning scheme 
> > > > has a high enough resolution to ensure sampling them - 
> I haven't 
> > > > tried with random objects though - still on OSG 2.2 
> here and the 
> > > > performance hit when using 
> > > > OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here.
> > > >
> > > > I have noticed that pylons are not detected and I would 
> doubt that 
> > > > trees are detected either, presumably because they have 
> no area. 
> > > > The pylons are made with line objects that have no 
> width and the 
> > > > trees, at least in plan, also have no width, so it'll be very 
> > > > unlikely to hit the exact point where they are in any scanning 
> > > > scheme.  Adding a transparent horizontal plane poly to 
> the top of 
> > > > these objects probably would make it work, but not only 
> would it 
> > > > increase the render load but also probably introduce more 
> > > > transparency render artifacts and ordering issues.
> >
> > OK I can give you submodels which are stabilised in pitch 
> within a few 
> > days, if this is really a good approach - submodels are a big frame 
> > rate hit.
> >
> > Would an alternative be to duplicate the code which calculates the 
> > ground intersection for submodels, without the cost of "flying" the 
> > submodel? This approach would take more coding, but might be less 
> > frame rate intensive. However, the methods which ar

Re: [Flightgear-devel] [ANN] New Eye-Candy

[Vivian Meazza]

Curt
 
Er ... I took me a few minutes to work out what you meant there. Glad you
like it. Now I've added a little more - must be mad :-)
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Olson
Sent: 17 February 2008 03:43
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] [ANN] New Eye-Candy


On Sat, Feb 16, 2008 at 7:15 PM, Csaba Halász wrote:


Vivian, thanks for the fun feature ;)
Here are some "appetizer" screenshots:
http://picasaweb.google.com/Csaba.Halasz/BuccaneerFormationFlying



I don't want to spoil anyone's easter egg Vivian, but nice touch with the
wingman pilot figure!  I had to do a double take to see if I really saw what
I just thought I saw! :-)

Curt.

-- 
Curtis Olson: http://baron.flightgear.org/~curt/ 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Object avoidance

[Vivian Meazza]

Markus

> Subject: Re: [Flightgear-devel] Object avoidance
> 
> 
> LeeE wrote:
> > On Friday 15 February 2008 17:08, Melchior FRANZ wrote:
> >   
> >> * R. van Steenbergen -- Friday 15 February 2008:
> >> 
> >>> Melchior FRANZ wrote:
> >>>   
>  ...you could abuse that by
>  launching an invisible, lightweight, and very fast submodel, and 
>  check where and at which altitude it lands.
>  
> >>> Don't they call that 'radar' in real life? :) (The very fast, 
> >>> lightweight submodels being microwave photons in that case)
> >>>   
> >> Hehe, yes. Except that ours don't come back. And I'm not 
> sure if they 
> >> collide with static/random buildings. They hardly do with 
> trees. Hmm 
> >> ... cows?
> >>
> >> m.
> >> 
> >
> > Markus Zojer has used this technique for the TFA functions in the
> > B-1B.  I had a look at it and experimented with it when I wanted to 
> > add TFA to a couple of aircraft I've done - it's a very appealing 
> > approach because it's almost like simulating a real radar.
> >
> > I had a play with the technique but hit some problems with it,
> > mainly because the trajectory of the submodels is fixed to the 
> > pitch of the aircraft.  I found it fine while the aircraft was in 
> > level flight but I hit some issues when the aircraft was pitched up 
> > or down to any significant degree and in the end I decided to use 
> > the Nasal geo functions instead.
> >
> >   
> I am still working on the terrain following function, rewriting it 
> completely for the 3rd time and again used "the real radar" 
> approach, as 
> you are not dependent in the scanning resolution of the geo 
> properties. The fixed radar beam (submodels) could be refined 
> if we would add the 
> property absolute to the pitch angle of the submodel  (so the 
> submodel 
> leaves the plane at always the same pitch angle).
> 
> Due to the ongoing environment development in OSG, now low 
> level flying 
> is really flashing :)
> 
> Expect the new version included in the next release (coming  
> hopefully 
> within the next 10 days).
> 
> Fly on,
> Markus
> > As I mentioned previously, the geo functions do interact with static
> > buildings and structures, as long as the scanning scheme has a high 
> > enough resolution to ensure sampling them - I haven't tried with 
> > random objects though - still on OSG 2.2 here and the performance 
> > hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too 
> > great here.
> >
> > I have noticed that pylons are not detected and I would doubt that
> > trees are detected either, presumably because they have no area.  
> > The pylons are made with line objects that have no width and the 
> > trees, at least in plan, also have no width, so it'll be very 
> > unlikely to hit the exact point where they are in any scanning 
> > scheme.  Adding a transparent horizontal plane poly to the top of 
> > these objects probably would make it work, but not only would it 
> > increase the render load but also probably introduce more 
> > transparency render artifacts and ordering issues.
> >

OK I can give you submodels which are stabilised in pitch within a few days,
if this is really a good approach - submodels are a big frame rate hit.

Would an alternative be to duplicate the code which calculates the ground
intersection for submodels, without the cost of "flying" the submodel? This
approach would take more coding, but might be less frame rate intensive.
However, the methods which are used are some of the most frame rate heavy
around so perhaps in practice not too different. 

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] [ANN] New Eye-Candy

[Vivian Meazza]

Hi all

Tim Moore has just uploaded the wingman code to cvs (thanks Tim). If you
want to experiment on a dull Friday afternoon, you will need to update cvs
data as well. Then 
--aircraft=buccaneer-wingman will give you 1 Buccaneer as a wingman, Ctrl-I
in runtime will bring up a menu of a small selection of formations. You can
add to these with additions to the Buccaneer/Formations folder.
--ai-scenario=wingman2_demo will add a further pair of Buccaneers to your
formation. 

The cost in frame rate here is small so add a bit of fun to your flying.
Enjoy,

Vivian

P.S. I have yet to work out how, or indeed if, we can pass the wingmen on
MP. 






-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] XML Particles patch

[Vivian Meazza]

Tim Moore

> Subject: Re: [Flightgear-devel] XML Particles patch
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Tiago Gusmão wrote:
> | Hi
> |
> | Here's the patch to add particles by XML to the OSG branch 
> | (instructions
> | inside):
> | http://gusmao.home.sapo.pt/particlesv1.tar.gz
> | (that page is not an error, you will have to click in 
> "AQUI", because it
> | doesn't like hotlinking much)
> |
> This is checked in. I did some cleanup of the code. New 
> classes that I check in go in the simgear namespace without 
> the SG prefix.
> | There is a short document here: 
> | http://gusmao.home.sapo.pt/README.xmlparticles
> Whoops, I haven't checked this in yet but will do so shortly.
> 
> |
> | A few problems and limitations are known:
> | The deletion of at least some of the objects seems not to work, the 
> | xml parsing code really gets boring, so not everything is 
> configurable 
> | or property-driven at the moment There shouldn't be any significant 
> | changes in the future in the existing XML spec, but i don't promise 
> | anything! Default values aren't yet established
> |
> | Cheers,
> | Tiago
> Thanks!

Well done Tiago and Tim. Built and tested. The Buccaneer making use of this
new facility, and is in cvs now. Vortices next? I've been looking at csp for
hints :-)

Thanks

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [ANN] dual control c172p prototype

[Vivian Meazza]

Anders Gidenstam

> Subject: Re: [Flightgear-devel] [ANN] dual control c172p prototype
> 
> 
> 
> Just to inform that I moved this aircraft to a new location:
> 
> http://www.gidenstam.org/FlightGear/DualControl/
> 
> And in case anyone is curious this is what it looks like for 
> the pilot 
> and copilot: 
> http://www.gidenstam.org/FlightGear/DualControl/images/pilot.jpg
> http://www.gidenstam.org/FlightGear/DualControl/images/copilot.jpg
> 
> Autopilot and ADF aren't properly shared yet but most other 
> things work.
> 

This is good work, the equivalent and parallel development for the Buccaneer
has been in cvs for some time now. Shouldn't this be too - before it gets
left languishing on the shelf?

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Patch v1 - Rain & Snow

[Vivian Meazza]

Nicolas wrote

> Subject: [Flightgear-devel] Patch v1 - Rain & Snow
> 
> 
> Hi,
> 
> I propose my first tries... still much work to get a good 
> implementation.
> 
> >From the README (into path) :
> -
> 
> This first try permits to add a basic snow and rain effects 
> in using particle from OSG.
> 
> For the moment, the patch uses the METAR informations to 
> enable / disable rain or snow effects. (intensity of effects 
> is : low, meddium,
> high)
> 
> For the next release of patch :
> 1) Add the wind direction and velocity effect
> 2) it's raining cats and dogs in my plane !!! (fixed this issue)
> 3) I want to the density of effects depend on altitude. If 
> I'm higher than clouds layer, rain (or snow) is stopped...
> 4) The particle effects have to depend on the camera position.
> 5) If you have propositions... :)
> 

Just in case anyone has tried, this patch will not compile under MSVC8 - fix
is easy, just add "return true" at line 121 in precipitation.cxx (as
discussed with Nicolas over on IRC).

Although this patch has its problems, principally with transparency ordering
- cockpit canopies make the rain disappear, it is a _significant_
improvement on the existing. I would recommend its inclusion in cvs, and the
retirement of the old code.

If it is intended that there are some user-settable parameter as described
in lines 111 - 121 of the code, then they should be exposed in the property
tree (or perhaps they are redundant?) I'm sure that the next iteration will
be even better. 

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] tree textures

[Vivian Meazza]

Syd wrote

> Subject: [Flightgear-devel] tree textures
> 
> 
> I tried to commit my tree texture sets (summer, fall,winter), 
> but it appears I can't write to the Trees folder , so this 
> might be a waste of time, but does the  work for 
> the material.xml file ? What I,m trying to do is select a 
> tree texture based on the sim/startup/season property , (and 
> to get rid of that ugly gray snow, freeze and solidify the 
> lakes and rivers), but I've had no luck yet ...  
> Cheers
> -- 
> Syd&Sandy <[EMAIL PROTECTED]>
> 

I know winter stuff was at least partly broken a (long) while back, but did
you investigate textures/terrain.winter?

I would be pleasantly surprised if  worked in materials.xml


Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] XML Particles patch

[Vivian Meazza]

Tiago Gusmão wrote

> Subject: [Flightgear-devel] XML Particles patch
> 
> 
> Hi
> 
> Here's the patch to add particles by XML to the OSG branch 
> (instructions 
> inside):
> http://gusmao.home.sapo.pt/particlesv1.tar.gz
> (that page is not an error, you will have to click in "AQUI", 
> because it 
> doesn't like hotlinking much)
> 
> There is a short document here: 
> http://gusmao.home.sapo.pt/README.xmlparticles
> 
> A few problems and limitations are known:
> The deletion of at least some of the objects seems not to 
> work, the xml parsing code really gets boring, so not everything is 
> configurable or property-driven at the moment
> There shouldn't be any significant changes in the future in 
> the existing 
> XML spec, but i don't promise anything!
> Default values aren't yet established
> 

Nice work so far. Just a few comments:

Gravity/buoyancy appear to be non op.

Wind has some effect, but not what I would expect (hmm might still be using
the osg wind?).

Fluid effects work, at least for air, but I'm not absolutely sure they are
correct.

Size is broken in this patch, but fixed with Tiago's help locally.

The XML is a bit of a mess - 

It doesn't seem always adhere to our (de facto) convention of including the
units in the tag:

, , but ,  etc

,  etc, but elsewhere in animations we use  .

 etc. in radians - AFAIK this is the only use of radians in models
- everywhere else is in degrees (including within particles).

This look and feel issue is important because the XML is intended to be
included in the Model file along with other animations where the difference
in conventions is going to lead to confusion, mistakes, and frustration.

It's only a few minutes work to get this right before we have all written
too many particle animations to make change easy. I'll do it for you if you
like.

Despite all this, particles work and work well: I have been able to recreate
the existing smoke effects in the Buccaneer relatively easily. The cost in
frame rate is a little disappointing here, but I hope this can be improved.

Well done Tiago, we have been waiting a long time for this!

Vivian





-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] trees

[Vivian Meazza]

Stuart 

> Sent: 27 January 2008 10:42
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] trees
> 
> 
> --- Vivian Meazza wrote:
> > The patch is broken here - there is some corruption in 
> simgear.patch 
> > which causes the file to appear empty when it is read by the patch 
> > utility, or by Vi etc. Csaba provided me with a complete patched 
> > Simgear source (thanks) so I was able to compile and run 
> fg. The trees 
> > look very nice, and, at least in the numbers I saw, have a minimal 
> > impact on frame rate (2-3). I would think that "on" could be the 
> > default mode.
> 
> It looks like the checked in source to mat.hxx has some 
> strange characters on lines 70, 111, 218, 240, 290. In each 
> case they appear on the line above a block comment. vi thinks 
> they are ^L characters.
> 
> The simgear.patch file doesn't change them, though it does 
> include one of them to provide context information for the 
> patch utility on line 120. I wonder if that is what is 
> causing the problem?
> 
> According to the CVS browser, they've been in there since the 
> original check-in of the file (4 years ago, but Curt).
> 
> Anyone any idea why they are there?
> 
> If there isn't any particular reason for them to be there, 
> could someone with CVS access remove them? I'd provide a 
> patch, but it looks like that doesn't work particularly well :)
> 

Yes, I guessed that the ^Ls might be the culprit, but couldn't prove it.

And the rest of the patch was fine, just simgear.patch failed

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] trees

[Vivian Meazza]

Stuart wrote

> Sent: 26 January 2008 21:18
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] trees
> 
> 
> --- Stuart Buchanan  wrote:
> > 
> > --- Stuart Buchanan wrote:
> > > Hi All,
> > > 
> > > Just a quick note to mention that I've now implemented 
> random tree 
> > > height,
> > and
> > > multiple textures as suggested by Curt. Screenshot here:
> > > 
> > > http://www.nanjika.co.uk/flightgear/forest2.jpg
> > > 
> > > Still some work to be done, but it is looking more realistic.
> > > 
> > > Tim - I've been cleaning up my code a bit, so unless 
> you've already 
> > > started, I'd hold off trying to kick my previous patch into shape 
> > > for CVS. I should have a new
> > > patch fairly soon.
> > 
> > A patch for this is now available from 
> > http:/www.nanjika.co.uk/flightgear/trees.tar.gz.
> > 
> > Note that there are some additional new files for the tree textures 
> > and some re-organizing of the code - see the included README.
> 
> Doh! I didn't notice that I had changed the FlightGear source too...
> 
> The patch below adds the appropriate property value check, 
> and I've updated the tarball and README to include it.
> 
> At some point I'll need to add a setting to the 
> preferences.xml file too, but first we need to decide whether 
> the trees should be on by default (like the random objects) or not.
> 
> Any opinions?
> 

The patch is broken here - there is some corruption in simgear.patch which
causes the file to appear empty when it is read by the patch utility, or by
Vi etc. Csaba provided me with a complete patched Simgear source (thanks) so
I was able to compile and run fg. The trees look very nice, and, at least in
the numbers I saw, have a minimal impact on frame rate (2-3). I would think
that "on" could be the default mode.

Vivian 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] BIG movie

[Vivian Meazza]

No - I need to fix that
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Olson
Sent: 24 January 2008 16:39
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] BIG movie


On Jan 24, 2008 10:27 AM, Vivian Meazza <[EMAIL PROTECTED]> wrote:


Nice movie Curt, did you really land with the airbrake out? It's meant to be
interlocked with the gear. 


If you lower the gear with the airbrake extended, it appears you can't
retract the airbrake.  Is that the correct behavior for the aircraft?  This
is with the OSG version. 

Thanks,

Curt.

-- 
Curtis Olson: http://baron.flightgear.org/~curt/ 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] BIG movie

[Vivian Meazza]

Nice movie Curt, did you really land with the airbrake out? It's meant to be
interlocked with the gear. 
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Olson
Sent: 24 January 2008 15:22
To: FlightGear developers discussions
Subject: [Flightgear-devel] BIG movie


If anyone has 300Mb of download capacity to burn ...

http://baron.flightgear.org/~curt/tmp/Hunter-PHNL.avi

This is a reprise of an old movie I uploaded to youtube which for some
reason has been viewed *way* more times than any other movie I've uploaded. 

This time I captured the movie with my digital camera with 640x480
resolution @ 30fps so the frame rates are smooth ... much better resolution,
***much*** smoother frame rates, looks great at full screen, just a tiny bit
bigger download :-) and this time with the shader based trees which are
still very cool. 

I was feeling like a dummy last night because I was trying to get the movie
down under 100Mb so I could upload to youtube.  But I can't get the audio
drivers to work on my windows machine (and Movie Maker claims it won't run
without audio drivers for some reason.)  I tried ffmpeg on my linux box, but
couldn't find the magic incantation to make it do anything ... even ffmpeg
-i in.avi out.avi (which I assume is basically a copy operation) refuses to
work.  If anyone out there wants to play with reducing the size so I can
upload to youtube, I'd appreciate it ... 300Mb is kind of a big chunk ...
but it's hosted on a fat pipe so I'm not worried about my end. 

Thanks,

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/ 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nasal error with YASim aircraft having < 4fuel tanks

[Vivian Meazza]

Lee wrote

> Subject: Re: [Flightgear-devel] Nasal error with YASim 
> aircraft having < 4fuel tanks
> 
> 
> On Friday 04 January 2008 19:59, LeeE wrote:
> > Hi all,
> >
> > I just noticed I was getting a Nasal error with a YASim 
> aircraft I was 
> > working on that had only three fuel tanks.  The error is:
> >
> > Nasal runtime error: props.setDoubleValue() with non-number
> >   at /usr/local/share/FlightGear/Nasal/props.nas, line 26
> >   called from: /usr/local/share/FlightGear/Nasal/fuel.nas, line 93 
> > called from: /usr/local/share/FlightGear/Nasal/fuel.nas, line 125
> >
> > I also got the same error when I tried an aircraft that has 
> only one 
> > fuel tank.
> >
> > I don't think that the problem is actually with the Nasal 
> scripts but 
> > with something else that creates four incomplete fuel tank nodes by 
> > default at start-up.  If there are < 4 fuel tank elements 
> in the YASim 
> > config the last tank's details are left incomplete and I think that 
> > this is what the Nasal script is borking on.
> >
> > With a zero capacity dummy tank in the YASim config the problem 
> > doesn't occur.
> >
> > I had a quick look in options.xml & preferences.xml, aw well as my 
> > .fgfsrc but didn't find anything - can't think of anywhere else to 
> > look:(
> >
> > LeeE
> 
> I thought I'd re-post this as no-one seems to have noticed it and it 
> seems like quite a big problem to me.
> 
> I also started testing the FG aircraft that have < 3 fuel tanks 
> defined and found the same problem with the following aircraft 
> before I decided that there wasn't any point in testing all of 
> them:
> 
> 737-300
> 747
> a24-yasim (A24-Viking)
> A320
> a4
> A6M2
> ...
> 
> Out of the candidates I tested only the a4f, which appears to be 
> based on the a4, didn't have the problem - I haven't looked into 
> this discrepancy yet.
> 
> That isn't even all of the 'A's though and one of them, the A320, is 
> a JSBSim aircraft.  With these aircraft it's not possible to change 
> the initial fuel loads via the menu and there are no values in the 
> tree for the /consumables/fuel/total-* nodes.
> 
> Can anyone else confirm this problem on the OSG cvs branch?
> 

The A4F doesn't use the generic fuel script (or didn't last time I looked)
so that might explain why it still works.

Vivian


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgrun future

[Vivian Meazza]

Fred

> Sent: 06 January 2008 15:22
> 
> Hello,
> 
> I am in the process of internationalizing fgrun. Here is an 
> example screenshot with a french localization :
> 
> http://frbouvi.free.fr/flightsim/fgrun-i18n.jpg
> 
> I had to resize the window to make room to longer localized 
> string but now we have a lot of room to add new options that 
> are currently only available in the advanced section. So I 
> would like to start an informal poll on what is the most 
> judicious to put on this page.
> 
> Thanks for your input.
> 
> -Fred
> 
> PS: there is a template file to translate here : 
> http://fgrun.svn.sourceforge.net/viewvc/fgrun/trunk/fgrun/po/f
grun.pot?view=markup
If there are wannabe translators here they can start to exercise their skill
;-) The french ( unfinished ) translation can serve as an example :
http://fgrun.svn.sourceforge.net/viewvc/fgrun/trunk/fgrun/po/fr.po?view=mark
up

I'm going to be a lone voice here Fred, I like it just the way it is :-)

Vivian


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Vivian Meazza]

Maik Justus

> Subject: Re: [Flightgear-devel] External Cargo, was: Re: 
> screenshots (and "snapshots")
> 
> 
> Hi Vivian,
> Vivian Meazza schrieb am 06.01.2008 01:01:
> > Maik Justus wrote:
> >
> >  
> >   
> >> Hi Vivian,
> >> Vivian Meazza schrieb am 21.12.2007 00:11:
> >> 
> >>> Christmas has arrived slightly early! I've got something which:
> >>>
> >>> A. runs
> >>>
> >>> B. looks OK with limited testing
> >>>
> >>> The ballistic object aligns with the direction of flight in
> >>>   
> >> pitch and
> >> 
> >>> heading with an external force applied. It would be
> >>>   
> >> possible to align
> >> 
> >>> it with the direction of the external force, but I think 
> that would
> >>> need roll as well. I'm not sure which one would look best.
> >>>
> >>> The external force is defined in terms of:
> >>>
> >>> Magnitude (lbf)
> >>> Azimuth (deg, North = O)
> >>> Elevation (deg, up = 90)
> >>>
> >>> In a user-defined property. Of course, some external
> >>>   
> >> program needs to
> >> 
> >>> set the external force data.
> >>>
> >>> This all now needs testing in a more realistic 
> environment. I'm not
> >>> totally convinced that the ballistic object won't disappear into 
> >>> space/to the centre of the earth, or oscillate like a 
> >>>   
> >> deranged spring.
> >> 
> >>> Vivian
> >>>   
> >>>   
> >> Thank you for the enhancement of AIBallistic. The external 
> load works
> >> here, but not perfectly. I need to limit the force to approx 
> >> 1000 lbf  
> >> (which is not enough to simulate it properly). If I do not 
> limit the 
> >> force, the load (the 3d-model) disappears, but it is still in the 
> >> property tree and reacts on forces (maybe not correct, not 
> >> sure, but it 
> >> is still there). Any idea, what could cause this?
> >>
> >> 
> >
> > Hmm - the mass of the load in load_demo is only 170 lbs - applying 
> > 1000lbf could well send it into orbit! Note your mass is in 
> slugs, and 
> > you need a realistic Cd and eda. I _think_ the math is correct, but 
> > I'll look at it again
> >
> > Vivian
> >
> >   
> Sorry, I limited the force to 1000N (about 200lbs).
> 200lbs are enough to lift the load. Lifting works. Therefore the math 
> itself is correct. But something strange happens, if I do not 
> limit the 
> force. (and sometimes forces greater than 200lbs are needed )
> 
> 

That sounds better, phew. There is a small "dead zone" when the load is on
the ground, so you need a bit more force than you might expect to get it off
the ground (this is to prevent oscillation, but is not totally unrealistic)
I can reduce or eliminate this. Beyond that I would need a better
explanation of what you are doing, and of the problem to speculate on a bug
or a fix.

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Vivian Meazza]

Maik Justus wrote:

 
> Hi Vivian,
> Vivian Meazza schrieb am 21.12.2007 00:11:
> > Christmas has arrived slightly early! I've got something which:
> >
> > A. runs
> >
> > B. looks OK with limited testing
> >
> > The ballistic object aligns with the direction of flight in 
> pitch and 
> > heading with an external force applied. It would be 
> possible to align 
> > it with the direction of the external force, but I think that would 
> > need roll as well. I'm not sure which one would look best.
> >
> > The external force is defined in terms of:
> >
> > Magnitude (lbf)
> > Azimuth (deg, North = O)
> > Elevation (deg, up = 90)
> >
> > In a user-defined property. Of course, some external 
> program needs to 
> > set the external force data.
> >
> > This all now needs testing in a more realistic environment. I'm not 
> > totally convinced that the ballistic object won't disappear into 
> > space/to the centre of the earth, or oscillate like a 
> deranged spring.
> >
> > Vivian
> >   
> Thank you for the enhancement of AIBallistic. The external load works 
> here, but not perfectly. I need to limit the force to approx 
> 1000 lbf  
> (which is not enough to simulate it properly). If I do not limit the 
> force, the load (the 3d-model) disappears, but it is still in the 
> property tree and reacts on forces (maybe not correct, not 
> sure, but it 
> is still there). Any idea, what could cause this?
> 

Hmm - the mass of the load in load_demo is only 170 lbs - applying 1000lbf
could well send it into orbit! Note your mass is in slugs, and you need a
realistic Cd and eda. I _think_ the math is correct, but I'll look at it
again

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]

[Vivian Meazza]

Georg Vollnhals wrote:

> -Original Message-
>-cvslogs] 
> CVS: data/AIload_demo.xml, NONE, 1.1]
> 
> 
> 
> 
>  Original-Nachricht 
> Betreff:  Re: [Flightgear-cvslogs] CVS: data/AI 
> load_demo.xml,NONE,1.1
> Datum:Sat, 05 Jan 2008 02:25:13 +0100
> Von:  Georg Vollnhals <[EMAIL PROTECTED]>
> An:   Vivian Meazza <[EMAIL PROTECTED]>
> Referenzen:   <[EMAIL PROTECTED]>
> 
> 
> 
> Vivian Meazza schrieb:
> > 
> >
> > 
> > This scenario places an underslung load 
> ready to be picked up at the
> > designated position. It assumes a cubic 
> shape whose centre is specified
> > by the z-offset.
> >          
> > Note: Units are ft, lbs, deg. Mass is in slugs
> >
> > Vivian Meazza
> >   
> Hi Vivian,
> 
> very nice to notice that there is activity around the 
> external load development.
> 
> I activated your scenario after compiling Tim Moore's 
> additional source code. The load is visible at KSFO - even at 
> night with luminescend arrows!!! - but I could not "catch" it 
> with a helicopter. So I think some additional nasal code has 
> to be written like for the banner catching with the 
> Dragonfly. Or is there a "trick" I should know?
> 
> Anyway, thank you very much Tim and Vivian for your work. 
> Once it is fully established and working I am very interested 
> in creating some "adventures" as with SearchAndRescue.
> 
>

Good to know that it works so far! The arrows are so that Maik knows which
way is up:-). We have a little more work to do to make it pick-up-able. But
you can make the load move around by altering the settings in
sim/ai/ballistic/force[2].

And it's good that you are interested in using the finished article.

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Beech 99 renewed

[Vivian Meazza]

Georg Vollnhals wrote

> Subject: Re: [Flightgear-devel] Beech 99 renewed
> 
> 
> D M schrieb:
> > Dear people,
> >  
> > The development of the new Beech 99 is going nicely.
> Hi Dick,
> yes I tried the new Beech 99 and you did a nice job until now :-)
> > I've uploaded the latest version to: 
> > http://download.35mb.com/kcid/beech99.zip
> But this site does not work for me, I got it from Ron Jensen, 
> thank you!
> > Tell me what you think about the new model.
> Please don't misunderstand me here. Every work for flightgear 
> is good work. Normally I would not comment such things 
> anymore due to a unpleasant misconception in the past. But 
> you asked, I will tell you my opinion, don't shoot on me: The 
> major one: With FG OSG (!) there are a lot transparency 
> problems. Not only the roof and the instruments shining 
> through but also some other parts of the a/c (ie if you look 
> through the windows of one side there is no cabin on the 
> other side (depending on the view angle) but you look 
> straight on the engine nacelles.) I think you use the PLIB 
> version for development, so you might not realize this. This 
> is really a big task to correct this. If you want some 
> screenshots, please tell me. The minor one: Thank you for 
> making the tires round! This looks much better than your 
> first version. When looking on the very prominent nose 
> section of this aircraft I get some hard rims (edges) whereas 
> the aircraft is nice smooth round, so one would like to 
> polish this section all the day :-). Could you spend some 
> more vertices there and smooth it a little more? This is not 
> important, just eye candy. The interior looks already very 
> good. A second version (for freight) would be an option.
> > By the way it's panel is not finished yet so bear with me, most 
> > instruments are on. The interior will be based on a Para 
> jumper so if 
> > this option will come in the future that para's can jump 
> from a plane, 
> > this interior will be ready for that.
> >  
> There are two alternatives how to understand this
> a) if you mean just deloy parachuters, look at the existing 
> Lockheed Hercules C130, I made some quick screenshots for you 
> - not so nice but you will see what I mean - not just 
> dropping to earth but a nice "flightmodel" for these deployed 
> "objects".
> 
> http://home.arcor.de/vollnhals-bremen/Parachuter/
> 
> b) if you are referencing to a multiplayer option so that one 
> can fly the Beech 99 and some other people log in as 
> parachuters and jump from your aircraft - this really would 
> be a nice option for the future :-)

This is almost possible right now, or at least with some small
modifications. You can already ride in the back of someone else's Buccaneer,
so you can ride in the back of the Beech 99. Atm this is limited to one at a
time, but that's easily fixed. A parachutist jumping out with a suitable FDM
will take a bit more work. Hmm - challenge for Andreas perhaps when he's
back from hols?

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: Multiplayer port number

[Vivian Meazza]

Er ... do we? Port 5002 was originally intended for development activities.
I take it that remains the intention, and remains available?
 
Regards 
 
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Olson
Sent: 30 December 2007 23:46
To: FlightGear developers discussions
Subject: [Flightgear-devel] Fwd: Multiplayer port number


Martin just wanted me to remind everyone that now that all the latest MP
code is in an official release, it makes the most sense to have everyone
point at port 5000 on the MP servers so we can all participate together.
This is the port we should concentrate on with maps and trackers and other
external tools. 

Best regards,

Curt.



-- Forwarded message --
From: Martin Spott <>
Date: Dec 30, 2007 10:16 AM
Subject: Multiplayer port number 
To: Stuart Buchanan <>, "Curtis L. Olson" <>


Hi both,
As we now have a release that comes with the most recent multiplayer
code, I just removed the mentioning of port 5002 for multiplayer use 
from the Wiki Multiplayer HOWTO and the Soaring page. We want everyone
to use FlightGear-release with the Multiplayer servers, don't we ?  ;-)

I removed the respective references from The Manual as well - 
unfortunatey nobody realized this Multiplayer port number issue before
The Release so we didn't track it in any our documentation, neither
Manual nor Wiki nor README's 

Would someone bother contacting the list so that even developers focus 
on 5000 as the sole MP port - for the MP online map and the tracker
for example ?

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




-- 
Curtis Olson: http://baron.flightgear.org/~curt/ 
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Vivian Meazza]

I wrote

> Sent: 20 December 2007 23:11
> To: 'FlightGear developers discussions'
> Subject: Re: [Flightgear-devel] External Cargo,was: Re: 
> screenshots (and "snapshots")
> 

 ... Snip ...

> I wrote:
> 
> > Sent: 19 December 2007 09:17
> > To: 'FlightGear developers discussions'
> > Subject: RE: [Flightgear-devel] External Cargo, was: Re:
> > screenshots (and "snapshots")
> > 
> > 
> > 
> > 
> Christmas has arrived slightly early! I've got something which:
> 
> A. runs
> 
> B. looks OK with limited testing
> 
> The ballistic object aligns with the direction of flight in pitch and
> heading with an external force applied. It would be possible 
> to align it
> with the direction of the external force, but I think that 
> would need roll
> as well. I'm not sure which one would look best.
> 
> The external force is defined in terms of:
> 
> Magnitude (lbf)
> Azimuth (deg, North = O)
> Elevation (deg, up = 90)
> 
> In a user-defined property. Of course, some external program 
> needs to set
> the external force data.
> 
> This all now needs testing in a more realistic environment. 
> I'm not totally
> convinced that the ballistic object won't disappear into 
> space/to the centre
> of the earth, or oscillate like a deranged spring.
> 

I've added a small utility to ensure that the ballistic object always turns
the short way to align with the external force (in cvs). This facility would
do nicely for anyone who wanted to animate ejection seats.

I think an underslung load ought to "sense" the ground, so I'm now tinkering
with adding some simplistic ground reactions to ballistic objects, but I'm
trying to avoid constructing another FDM.

I hope that I have guessed Maik's requirements correctly.

Vivian 

 



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] heading indicator

[Vivian Meazza]

Yurik V. Nikiforoff wrote

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of 
> Sent: 27 December 2007 05:15
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] heading indicator
> 
> 
> Hi All!
> 
> It seems, there is error in heading_indicator.cxx, OSG around 
> month ago line 84 : === dt -= dt * (0.25/60); // 360 deg/day 
> === But, IMHO, it's should be
> 
> ===
> double current_lat = getDoubleValue(/* here latitude property 
> */) dt -= dt * (0.25/60) * sin( current_lat ); // time-based 
> precession on this 
> latitude
> ===
> 
> There is not time-based precession in mrg.cxx, so we have not 
> poperly heading 
> gyro at all.
> 
> Second question. In mrg.cxx, we have movement-induced error - 
> gyro have some 
> deviation by plane orientation changes and accelerations.
> 
> Can we do property for switch this deviation? Real compass 
> systems have 
> stabilizers for body of reference gyro, and it's eliminate 
> orientation errors  
> ( introduceed by roll and roll rate, etc ). So, if we have ability of 
> controls of orientation errors - we can simulate compass 
> systems more clear, 
> and simulate failures of stabilizers of gyro...
> 

The mrg (or Master Reference Gyro) is a particular instrument fitted to UK
military ac of the late 1950s/early 1960s (such as the Lightning, Sea Vixen,
and Buccaneer), and continued in service until the 1990s. The azimuth gyro
axis was automatically maintained relative to the magnetic North, and the
vertical gyro to the earth vertical. Time-based precession is inappropriate
in normal operation. I have yet to provide either a Fast Erection utility or
to investigate plausible failure modes. Of course, if the automatic
alignment failed, then time-based precession would apply.

Vivian




-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RE water crashes or landing - a changein design principle and default is suggested

[Vivian Meazza]

Detlef Faber wrote

> Sent: 26 December 2007 10:21
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] RE water crashes or landing -
> a changein design principle and default is suggested
> 
> 
> Am Dienstag, den 25.12.2007, 22:24 +0100 schrieb R. van Steenbergen:
> > gerard robin schreef:
> > >  With an aircraft which has gears  retractable , the "landing" on
> > > sea can be  done  smoothly on the belly.  TableData  "drag" (and 
> > > "lift") can be given with the best values according  to the water 
> > > reaction.  The values regarding landing on ground remains right.
> > >  We have, only, to select the right TableData according 
> to terrain type,
> > >  which is easy to do.
> > >   
> > The possibility of belly landing an aircraft depends on the aircraft 
> > type -- an A/C with underwing mounted engines and a low wing is 
> > impossible to make a graceful belly-ditch (like the 737) since the 
> > engines would scoop up all the water and cause a huge
> amount of drag
> > (and pitch the nose forward).
> 
> In this case the pilot approaches the water with a slight
> bank, so only one engines hits the water. The drag will cause 
> the aircraft to make a strong yaw-movement, thereby loosing 
> speed and reducing the tendency to dive nose over. 
> 
> This is a standard procedure for emergency landing and has
> been successfully (without loss of lives) conducted in the past.
> 
> >  IMO, the aircraft's fuselage, engines, and
> > wings could also be considered contact points, albeit
> higher situated
> > than an extended landing gear. For example, when you land a
> 737 or 747
> > over its recommended landing weight, you run the risk of
> either breaking
> > the gear struts or causing enough gear compression to
> impact the engines
> > on the runway. And of course, belly-landing an A/C on
> tarmac or grass is
> > just as possible as ditching on water, but those methods
> could only be
> > considered in an extreme emergency (like a jammed landing
> gear). Even
> > MSFS can be fooled into doing it: I once bellied a Learjet
> 45 on the
> > runway at Malaga in FS2004, only noticing that I made a
> fuselage landing
> > when I tried to taxi off the runway and the aircraft didn't
> move (and I
> > switched to external camera, realizing I forgot to lower
> the gear before
> > landing. Next time: THREE GREENS! :))
> > 
> > 

And IIRC Boeing engine pylons are designed to detach if they are subject to
rearward forces.

I'm quite happy with the appearance of a water "landing" for the Seahawk: it
sinks nicely by about the right amount. Of course we haven't modelled the
disintegration for a high speed impact, but we are a flight simulator not a
crash simulator.

Happy Christmas

Regards

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Terrasync for Windows

[Vivian Meazza]

 Shad Young

> Sent: 21 December 2007 20:14
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] Terrasync for Windows
> 
> 
> I have read through the archives about Terrasync. While I understand 
> Curt's motivation behind it, it does leave the vast majority of 
> potential users (I.E. Windows users) with the necessity to manually 
> download the scenery files.
> 
> Has anybody looked into this recently or have plans to? Both 
> Rsync (in 
> the form of DeltaSync) and mkdir (Windows native 'md') are 
> available for 
> the Windows platform - though TerraSync is a 
> Tradmark/Brandname of a GIS 
> company's software, so it might need to be renamed.
> 
> There is a growing body of open source applications for 
> Windows, and the 
> more Windows users that we attract to FSF/Open Source 
> software the more 
> we can get our message across (even MSFS has a large open 
> source base), 
> and perhaps attract more volunteer developers.
> 
> (I could look into this if I can after my current project is 
> completed, 
> but like most of you, I am swamped with too much to do and 
> too little time)
> 
>

I never made rsync work under windows, so I do it under Cygwin instead -
works fine.

Not elegant, but practical

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07

[Vivian Meazza]

Melchior

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of  FRANZ
> Sent: 20 December 2007 22:34
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
> 
> 
> The problem was acknowleged by nVidia for the beta 169.04!
> WTF didn't they fix it for the release?! (Ok, ok, some say
> that about our bugs ... :-)
> 
>   http://www.nvnews.net/vbulletin/showthread.php?t=104363
> 
> (And no, removing ~/.nvidia-settings-rc doesn't help.)

Windows driver is similarly afflicted.

Vivian



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Vivian Meazza]

I wrote:

> Sent: 19 December 2007 09:17
> To: 'FlightGear developers discussions'
> Subject: RE: [Flightgear-devel] External Cargo, was: Re: 
> screenshots (and "snapshots")
> 
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Maik Justus
> > Sent: 18 December 2007 23:12
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] External Cargo, was: Re: 
> > screenshots (and "snapshots")
> > 
> > 
> > Hi Viviam,
> > Vivian Meazza schrieb am 18.12.2007 23:41:
> > > I've just a few moments ago added a few lines of code to
> > AIBallistic
> > > which apply an external force (using the same math as
> > above). The rest
> > > works as before. I just need few properties to set the
> > magnitude and
> > > vector of the external force and it will be done, at least for
> > > testing.
> > Thank you, very good. Is it possible to pass the forces in the earth
> > fixed coordinates axes base? (in Newton or pof)?
> 
> I'm planning, and have tested the passing of the force in 
> terms of magnitude (pound force), azimuth (degrees, north = 
> 0) and elevation (degrees, horizontal = 0, up = 90). I hope 
> this is what you need, and can work with.
> 
> > > It's trivial
> > > really, but I'm assuming that the external force applies no
> > rotational
> > > force to the object.
> > I think this could be easily faked. e.g. new_roll = old_roll +
> > cos(old_roll) * force_in_y_direction * a_magic_constant * dt 
> > but i f I read the code correctly, yaw and hdg are pointing 
> > at the speed 
> > direction (slightly filtered)? Therefore we need something 
> > like _elevation = atan2(force_in_z_direction,force_in_x_direction)
> > and then your filter to add some inertia?
> 
> Right now there are 2 options - 1, the ballistic object 
> aligns with the velocity vector (damped), or 2, it remains 
> static. These options both work with the new code. I think 
> option 1 will do for an under slung load?
>  
> > > I haven't a great deal of time available in the run up to
> > Christmas so
> > > no promises on completion.
> > >   
> > Same here. I will have very limited access to my computer (family
> > visiting tour). Fortunately my computer is a notebook, but I 
> > am not sure 
> > if there is any space in the car for my joystick.
> 
> We have a horde of family visitors over the coming days - all 
> competing for my time and the computer. We'll see how much 
> can be done (not a lot I expect).
> 

Christmas has arrived slightly early! I've got something which:

A. runs

B. looks OK with limited testing

The ballistic object aligns with the direction of flight in pitch and
heading with an external force applied. It would be possible to align it
with the direction of the external force, but I think that would need roll
as well. I'm not sure which one would look best.

The external force is defined in terms of:

Magnitude (lbf)
Azimuth (deg, North = O)
Elevation (deg, up = 90)

In a user-defined property. Of course, some external program needs to set
the external force data.

This all now needs testing in a more realistic environment. I'm not totally
convinced that the ballistic object won't disappear into space/to the centre
of the earth, or oscillate like a deranged spring.

Vivian

  



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Vivian Meazza]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Maik Justus
> Sent: 18 December 2007 23:12
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] External Cargo, was: Re: 
> screenshots (and "snapshots")
> 
> 
> Hi Viviam,
> Vivian Meazza schrieb am 18.12.2007 23:41:
> > I've just a few moments ago added a few lines of code to 
> AIBallistic 
> > which apply an external force (using the same math as 
> above). The rest 
> > works as before. I just need few properties to set the 
> magnitude and 
> > vector of the external force and it will be done, at least for 
> > testing.
> Thank you, very good. Is it possible to pass the forces in the earth 
> fixed coordinates axes base? (in Newton or pof)?

I'm planning, and have tested the passing of the force in terms of magnitude
(pound force), azimuth (degrees, north = 0) and elevation (degrees,
horizontal = 0, up = 90). I hope this is what you need, and can work with.

> > It's trivial
> > really, but I'm assuming that the external force applies no 
> rotational 
> > force to the object.
> I think this could be easily faked. e.g. new_roll = old_roll + 
> cos(old_roll) * force_in_y_direction * a_magic_constant * dt 
> but i f I read the code correctly, yaw and hdg are pointing 
> at the speed 
> direction (slightly filtered)? Therefore we need something 
> like _elevation = atan2(force_in_z_direction,force_in_x_direction)
> and then your filter to add some inertia?

Right now there are 2 options - 1, the ballistic object aligns with the
velocity vector (damped), or 2, it remains static. These options both work
with the new code. I think option 1 will do for an under slung load?
 
> > I haven't a great deal of time available in the run up to 
> Christmas so 
> > no promises on completion.
> >   
> Same here. I will have very limited access to my computer (family 
> visiting tour). Fortunately my computer is a notebook, but I 
> am not sure 
> if there is any space in the car for my joystick.

We have a horde of family visitors over the coming days - all competing for
my time and the computer. We'll see how much can be done (not a lot I
expect).

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")

[Vivian Meazza]

Maik Justus

> Sent: 18 December 2007 21:02
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] External Cargo,was: Re: 
> screenshots (and "snapshots")
> 
> 
> Hi,
> Vivian Meazza schrieb am 18.12.2007 00:27:
> >  Maik wrote
> >   
> >> Hi,
> >> Melchior FRANZ schrieb am 17.12.2007 02:18:
> >> 
> >>> * Georg Vollnhals -- Monday 17 December 2007:
> >>>   
> >>>   
> >>>> Just now (!!!) remembering Torsten's Dragonfly banner-trick (!!!)
> >>>> which is pretty similar:
> >>>> 
> >>>> 
> >>> Yes, it's clearly a job for Maik's winch/anchor feature. He has
> >>> already lifted me via MP: I was in a sgs233, and Maik 
> >>>   
> >> lifted me with a
> >> 
> >>> bo105. There's just no visible rope (yet).
> >>>
> >>>   
> >>>   
> >> Can an external force be added to the AIBallistic Objects?
> >> 
> >
> > I don't see why not. Just designing on the back of an envelope - we 
> > already have one - wind. So in principle we add something 
> like another 
> > wind.
> >
> > Not in the next few days though.
> >
> > Vivian
> >   
> I had a look to AIBase.?xx and AIBallisitic.?xx. I think all 
> we need is 
> already there. The objects speed can be modified by a Nasal script. 
> YASims winch/aerotow/anchor can be connected directly to any 
> AI object 
> and (with some Nasal code, which copies the location) to 
> anything else. 
> The force on the other object is calculated and stored in the 
> property 
> tree. Some Nasal code only need to take this force, multiply it by dt 
> and divide it by the objects mass and add the result to the objects 
> speed (which need to be converted to (and afterwards back from) the 
> earth-coordinate system). If we use a AIBallistic object, the gravity 
> and drag effects would be calculated automatically.
> Therefore external cargo missions, SAR missions or even banner-towing 
> with realistic forces on the aircraft should be possible with fg1.0.0
> 

I've just a few moments ago added a few lines of code to AIBallistic which
apply an external force (using the same math as above). The rest works as
before. I just need few properties to set the magnitude and vector of the
external force and it will be done, at least for testing. It's trivial
really, but I'm assuming that the external force applies no rotational force
to the object. I haven't a great deal of time available in the run up to
Christmas so no promises on completion.

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] screenshots (and "snapshots")

[Vivian Meazza]

 Maik wrote

us
> Sent: 17 December 2007 19:31
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] screenshots (and "snapshots")
> 
> 
> Hi,
> Melchior FRANZ schrieb am 17.12.2007 02:18:
> > * Georg Vollnhals -- Monday 17 December 2007:
> >   
> >> Just now (!!!) remembering Torsten's Dragonfly banner-trick (!!!) 
> >> which is pretty similar:
> >> 
> >
> > Yes, it's clearly a job for Maik's winch/anchor feature. He has 
> > already lifted me via MP: I was in a sgs233, and Maik 
> lifted me with a 
> > bo105. There's just no visible rope (yet).
> >
> >   
> Can an external force be added to the AIBallistic Objects?

I don't see why not. Just designing on the back of an envelope - we already
have one - wind. So in principle we add something like another wind.

Not in the next few days though.

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] missing fsfgdb files in base package?

[Vivian Meazza]

Durk Talsma

> Sent: 16 December 2007 06:20
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] missing fsfgdb files in base package?
> 
> 
> On Sunday 16 December 2007 05:51, Curtis Olson wrote:
> >
> > Perhaps a short term fix would be to simply move the lights so they 
> > align properly with the existing terminal building.  An 
> even simpler 
> > fix would be to temporarily remove them until after the 
> release.  I've 
> > only had a chance to take a brief look around the new scenery so I 
> > hope there aren't other significant issues as well.  I did notice 2 
> > doubled up glide slope structures between the ends of 28L and 28R.
> >
> For now, I've commented-out all references to the light-pole 
> in the default 
> scenery related stg files. While at it, I also took the 
> liberty of commenting 
> out the static aircraft, as they (at least the 747) were 
> occasionally overrun 
> by AI traffic. I hope these changes are acceptable to 
> everyone. If not, it's 
> fairly easy to undo them. For that reason, I decided to go 
> ahead and commit 
> these changes to the base package, so everybody will have a 
> chance to look. 
> 
> In general, I do consider the new scenery an improvement, and 
> considering that 
> this release will ship under the V1.0 number a good argument 
> for trying to 
> get as many aspects of the program up to date as possible. 
> For now, I really 
> hope that the seahawk missing texture file really is the only 
> correction 
> we're waiting for.
> 
> FWIW, I'm probably out of email contact until tonight, as my 
> father and my 
> sister (along with her family) will be visiting today. 
> Hopefully we can roll 
> up the base package tonight.
> 

As I have already said, I have no missing Seahawk file here, but if someone
would please just say which one is missing I'll upload it immediately. 

Vivian 



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Release in progress

[Vivian Meazza]

Durk Talsma

> Sent: 15 December 2007 20:07
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Release in progress
> 
> 
> On Saturday 15 December 2007 20:46, Melchior FRANZ wrote:
> > * AnMaster -- Saturday 15 December 2007:
> > > Yes but tar ball have been made [...]
> >
> > But they aren't released. Can still be fixed.
> >
> 
> Agreed. The missing file has already been committed by Syd 
> Adams. Now I'm 
> getting the following: 
> 
> WARNING: ssgSGIHeader::: Failed to 
> open 
> '/home/durk/src/FlightGear-0.9/data/Aircraft/dhc2/Models/chrome1.rgb' 
> for reading.
> Object RLHFdoor.glass not found
> 
> Doesn't seem to be a major problem, because I don't see 
> anything obviously 
> wrong with the model. Might be good if Syd could check.
> 
> Assuming that the error above points to only a very minor 
> problem, I guess the 
> only issue is one missing file on the seahawk. 
> 

Hmm - if I could find a missing file in the Seahawk, I'd fix it

And there is a major issue with the chrome shader in the Camel - seems as if
it makes the windscreen opaque in some systems - but not here.

Vivian 



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] BUG(S) with new(?) KSFO scenery in cvs

[Vivian Meazza]

Durk Talsma

> Sent: 14 December 2007 07:54
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] BUG(S) with new(?) KSFO scenery in cvs
> 
> 
> On Friday 14 December 2007 00:02, Stewart Andreason wrote:
> > Also, at KOAK Oakland, looking at the AI Traffic 
> congregating around 
> > the terminal, would look better if the building were there. Perhaps 
> > nobody has built it yet?
> >
> > I have also seen a 747 sitting on top of a 737 on top of some third 
> > plane at N37*43.34 W122*13.12 but since it is not always there, I 
> > assume it is another AI traffic bug. Also, I have seen up to 4 
> > airplanes at the NW terminal at KSFO sitting 50 feet off the ground.
> >
> 
> I just committed a first set of changes that makes the ground 
> network more 
> consistent with the new airport layout. But I still need to 
> do a second pass 
> and update the parking locations, so they're not partially 
> overlayinig the 
> terminal building. I'll try to get that done before the release.
> 
> When you see stacked aircraft, that's usually a sign of 
> overflow (i.e. more 
> aircraft present than there are parkings available. If you 
> see it, can you 
> let me know around what time of day it occurs? So that I can 
> have a look and 
> see what kind of parkings need to be added. I assume that 
> this is at KSFO?
> 
> I'm off to a conference in a few minutes, and probably won't 
> be in email 
> contact for today and much of tomorrow. Assuming Vivian 
> manages to update the 
> remaining Sopwith Camel animations, and I manage to get the 
> groundnetworks 
> updated, I think we're ready to roll on Saturday.
> 

There is lots I would like to do on the Camel, but these can wait. It's now
fit for plib release, but in making it so it's now broken in OSG. Over the
next couple of days I will try and make it work in both, and see what else
can be improved. Meanwhile, as I said, it is ready to go.

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] screenshots (and "snapshots")

[Vivian Meazza]

gerard robin

> Sent: 14 December 2007 15:31
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] screenshots (and "snapshots")
> 
> 
> On ven 14 décembre 2007, Melchior FRANZ wrote:
> > For a new release, especially one with version number 1.0, 
> we should 
> > provide some new screenshots for the website. Normally, 
> Curt would ask 
> > for that, but as he is/was away for a few days, I start with this 
> > reminder. Screenshots should ...
> >
> SNIP
> >
> > Here's the result of a quick test with the A-10 near KNID. It isn't 
> > spectacular, but you can see that there's full antialiasing 
> and still 
> > a nice shadow effect. This would have been quite hard (though 
> > possible!) with a real A-10 flight.
> >
> >   http://members.aon.at/mfranz/a10.jpg  [32.9 kB]
> >
> > m.
> 
> yeah, i have one,:)   
> It could be a tale "the Alouette and the Cow" 
> http://pagesperso-orange.fr/GRTux/Alouette_III-img4.jpg
> 
> (only a joke)
> 

Hey - a cow!!! First time I've seen one. Not bad at all :-)

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bleriot -> Sopwith Camel?

[Vivian Meazza]

Durk 

> Sent: 13 December 2007 22:34
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Bleriot -> Sopwith Camel?
> 
> 
> On Thursday 13 December 2007 23:13, Vivian Meazza wrote:
> >
> > If Durk can give us a little time?
> >
> 
> Sure, no problem.
> 
 
OK - I've fixed the main issue - the control stick - in cvs. Now for the
minor ones.

V.




-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Bleriot -> Sopwith Camel?

[Vivian Meazza]

AJ MacLeod wrote:

> Sent: 13 December 2007 20:19
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Bleriot -> Sopwith Camel?
> 
> 
> On Thursday 13 December 2007 19:52:18 Durk Talsma wrote:
> > In light of some recently uncovered problems related to the 
> bleriot, 
> > how about making a last minute decision to replace it with 
> the sopwith 
> > camel? I just checked the aircraft, and can confirm that it doesn't 
> > segfault by switching on aircraft shadows.
> 
> Hi Durk,
> 
> I'd be very happy to see the Camel getting some exposure, but 
> my only worry is 
> that it was developed for OSG... it doesn't use any 
> particularly special 
> OSG-only effects, but last time I looked some of the control 
> animations were 
> broken in PLIB.
> 
> They work perfectly in OSG, and of course we could probably 
> rewrite them for 
> plib, but I don't think I'll have time in the next day or two 
> :-(  Unless 
> Vivian can?
> 

Needs a bit of work to make the animations right. Hmm - don't know what's
required right now - but I could perhaps do it tomorrow sometime.

Lot's and lots of vertices, and no easier to fly than the original!

If Durk can give us a little time?

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Release update

[Vivian Meazza]

Anders Gidenstam

> Sent: 12 December 2007 14:59
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Release update
> 
> 
> On Wed, 12 Dec 2007, Vivian Meazza wrote:
> 
> > I've just updated the Seahawk in preparation for the release, and 
> > noticed a couple of thing:
> >
> > 1. Nav-lights seem to be broken across MP. I haven't been 
> able to fix 
> > it, but I note that in multiplaymgr.cxx it's a "float", but 
> everywhere 
> > else it's a "bool". I don't know if this is the cause, but 
> anyway I've 
> > put a workaround into the Seahawk.
> 
> Hi,
> 
> I'm pretty sure the types have to match for the property to 
> be sent over MP. 
> If most aircraft use bool for nav lights it is probably a 
> good idea to 
> change the type in multiplaymgr.cxx. (Bool does sound more 
> logical to me, 
> but none of my aircraft include proper nav lights yet so I 
> don't know much 
> about these.. :)
> 

Yes, I think that's the case, but I've changed the type in multiplaymgr.cxx
to bool, and that doesn't fix it. I'm not sure what to do next.

Vivian 


-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Release update

[Vivian Meazza]

Durk 

> Sent: 11 December 2007 19:16
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Release update
> 
> 
> On Tuesday 11 December 2007 14:48, Melchior FRANZ wrote:
> > * Durk Talsma -- Tuesday 11 December 2007:
> > > As it looks right now, either tonight, or Thursday 
> evening will be 
> > > my two windows of opportunity this week.
> >
> > I would rather go for Thursday, then. It's only known for a 
> short time 
> > which aircraft are planned to go in, and even today and yesterday 
> > there were commits made to them. I could imagine that some want to 
> > make some last fixes and improvements. A release number of 
> 1.0 may not 
> > mean much to some people here, but it *does* mean something 
> for a lot 
> > of the people out there, and I expect a lot more attention to a 
> > FlightGear v1.0 release than to a 0.9.11 one. We might get more 
> > reviews in more important places, and it can't hurt to polish some 
> > more. (And I committed a code change yesterday that could 
> still turn 
> > out to have broken something. It would be a disaster if we had to 
> > release 1.1 a week after 1.0.  :-)
> >
> 
> Okay, since I've gotten a few requests to roll up the tar 
> files on Thursday, 
> let's do that. I usually try to make sure that I'm around for 
> a little while 
> after a major commit, in case something goes wrong. 
> Therefore, I will commit 
> all the required changes to make the release happen today 
> (makefile, and 
> configure stuff), but wait with tagging CVS and rolling up 
> the tar files on 
> Thursday.
> 

I've just updated the Seahawk in preparation for the release, and noticed a
couple of thing:

1. Nav-lights seem to be broken across MP. I haven't been able to fix it,
but I note that in multiplaymgr.cxx it's a "float", but everywhere else it's
a "bool". I don't know if this is the cause, but anyway I've put a
workaround into the Seahawk.

2. I still have stepping clouds here on start-up or when changing weather
scenarios. The fix is trivial - I've worked with Tim Moore on a patch.

Finally, I still get a crash if FG runs long enough. It _seems_ as if this
can be avoided if I disable Traffic Manager, but it might just be hastening
the inevitable end.

Regards

Vivian 


-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Release update

[Vivian Meazza]

Melchior wrote:

> -Original Message-
> Sent: 11 December 2007 13:49

> Subject: Re: [Flightgear-devel] Release update
> 
> 
> * Durk Talsma -- Tuesday 11 December 2007:
> > As it looks right now, either tonight, or Thursday evening 
> will be my 
> > two windows of opportunity this week.
> 
> I would rather go for Thursday, then. It's only known for a 
> short time which aircraft are planned to go in, and even 
> today and yesterday there were commits made to them. I could 
> imagine that some want to make some last fixes and 
> improvements. A release number of 1.0 may not mean much to 
> some people here, but it *does* mean something for a lot of 
> the people out there, and I expect a lot more attention to a 
> FlightGear v1.0 release than to a 0.9.11 one. We might get 
> more reviews in more important places, and it can't hurt to 
> polish some more. (And I committed a code change yesterday 
> that could still turn out to have broken something. It would 
> be a disaster if we had to release 1.1 a week after 1.0.  :-)
> 


I still have some tinkering to do on the Seahawk, since it's the first time
this has appeared in the base package - Thursday please.

Vivian


-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Building FlightGear, once again

[Vivian Meazza]

Jon S. Berndt

> Sent: 10 December 2007 01:28
> To: Flightgear-Devel
> Subject: [Flightgear-devel] Building FlightGear, once again
> 
> 
> For the first time in a very long time, I have a system on 
> which I should be able to build and run FlightGear. I had a 
> script some time ago that handled updating plib, simgear, and 
> flightgear from cvs, and then built compiled that. I think 
> things have changed quite a bit.
> 
> I've got Cygwin and MS Visual C++ Express 2005. Which one 
> would be better for me to use? How different is the build 
> process at this time from what is was a few years ago?
> 
> Where is the best resource on the FlightGear web site for me 
> to refer to for building FlightGear on Windows?
> 

Last time I tried (some time earlier this year) OSG wouldn't compile under
Cygwin due to compiler version incompatibilities. I was forced to change to
MSVC8, and haven't regretted it - the necessary project files for FG are
supplied in cvs (although they aren't always up to date), and MSVC8 has a
nice editor for xml and C++ (works quite well for Nasal too). Running FG
under Cygwin has a performance penalty. On the other hand Cygwin is still
needed for terrasync, and I have not found a method of applying patches
under Windows, not that I've looked very hard - Cygwin does just fine.

HTH

Vivian 



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Google Earth scenery

[Vivian Meazza]

AnMaster wrote

> Sent: 09 December 2007 21:21
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Google Earth scenery
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Gijs de Rooy wrote:
> > Hi,
> >  
> > I know there was/is a discussion about using real photo's as 
> > FlightGear textures. Google Earth was one of the softwares that are 
> > usable for our scenery. We know the pictures are 
> copyrighted, but we 
> > may use them in FlightGear because:
> >  
> > - FlightGear is non commercial software (non paid).
> >  
> > And when we read this Google-quote we got the idea we may use the 
> > pics...
> >  
> > "You can personally use an image from the application (for 
> example on 
> > your website,
> > on a blog or in a word document) as long as you preserve 
> the copyrights and attributions 
> > including the Google logo attribution. However, you cannot 
> sell these to others, provide 
> > them as part of a service, or use them in a commercial 
> product such as a book or TV 
> > show without first getting a rights clearance from Google."
> 
> As you can sell GPL software (for example sell CDs with it 
> on) google's license would not be GPL compatible I belive. 
> But I'm not a lawyer.
> >  
> > My English is not perfect so I may read these sentences on a wrong 
> > way. Please tell me if so.
> >  
> > After all we just need someone who write Google to ask permission. 
> > Here's the aplication form: 
> > http://services.google.com/permissions/application :)
> > 

We have already asked permission, altough soemtime ago now, and were
refused. 

Regards

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [PATCH] wxradar bug fix and added feature

[Vivian Meazza]

Melchior FRANZ wrote

> Subject: Re: [Flightgear-devel] [PATCH] wxradar bug fix and 
> added feature
> 
> 
> * Csaba Halász -- Sunday 09 December 2007:
> > Any ideas? Should we put in a comma-separated list of 
> symbolic names?
> 
> Not comma, but yes, I think that's the best thing. There 
> should IMHO already be a name/number list in AIBase.hxx. Then 
> the property could do what we do with logging classes:
> 
>   /sim/logging/classes {STRING} = terrain|astro|flight|input|gl[...]
> 
> Of course, these names can also change between releases, but 
> they are at least readable and consistent in all of fgfs. The 
> question is, should there be shared flags, as in:
> 
>   { "ship",  0x0001, }
>   { "aircraft",  0x0002, }
>   { "seaplane",  0x0003, }   // ship and aircraft?
>   { "carrier",   0x0005, }
> 
> I wouldn't mind committing your patch as a temporary 
> solution, if you want to make sure that the functionality is 
> in the release. But I think this should be fixed in the long run.
> 

I'm not cleat what type of radar we are modelling that can distinguish
between ships and carriers or seaplanes and aircraft, or even want to. There
are radars which can distinguish between carrier/ships and
seaplanes/aircraft. Mind you I have spent even less time than anyone
thinking about this. So far.

Vivian 



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Chat Menu and fix for chat repetition bug

[Vivian Meazza]

Stuart Buchanan

> Sent: 05 December 2007 08:19
> To: FlightGear Dev
> Subject: [Flightgear-devel] Chat Menu and fix for chat repetition bug
> 
> 
> Hi All,
> 
> The latest and greatest chat menu system is now available. I 
> have added a couple of new features and fixed a number of bugs:
> 
> - The chat menu automagically creates messages that include 
> the nearest airport, the current runway in use (based on the 
> current weather conditions), and information about your 
> aircraft and location. For example "Half Moon Bay Traffic, 
> G-FGFS is type Cessna, inbound from the south-west at 
> 4,000ft, straight in approach runway 30, 4 miles to run". 
> - The chat repetition bug should now be completely fixed 
> (though I have only seen it twice, so I can't be 100% certain).
> - Going backwards and forwards through the message tree is 
> now more reliable.
> 
> The patch consists of a number of files (from
> http://www.nanjika.co.uk/flightgear/chatmenu.tar.gz):
> - multiplayer.nas: a complete replacement for Nasal/multiplayer.nas
> - chat-menu.xml: a new dialog to be placed under gui/dialogs
> - chat-menu-entries: an XML file defining the various chat 
> messages, based on CAP-143 (UK standard radio phraseology). 
> To be placed under ATC/
> 
> The patch also changes a small number of other files, for 
> which diffs are included below.
> 
> As Melchior doesn't spend much time using Multiplayer, he has 
> asked that I post to the list, so someone with more MP 
> experience can review and commit it to CVS.
> 
> I think this is a big improvement over the current broken 
> chat implementation and improves the MP experience 
> significantly. I'd therefore ideally like it to be included 
> in the release. As the patch is non-trivial, I'd appreciate 
> it if it could be committed so that plenty of people can have 
> the chance to try it out before the release.
> 
> Thanks
> 
> -Stuart
> 
> Index: preferences.xml 
> ===
> RCS file: /var/cvs/FlightGear-0.9/data/preferences.xml,v
> retrieving revision 1.256
> diff -u -r1.256 preferences.xml
> --- preferences.xml   4 Dec 2007 13:12:15 -   1.256
> +++ preferences.xml   5 Dec 2007 07:58:48 -
> @@ -472,6 +472,7 @@
> Hello
>  type="string">11850
> true
> +   
>
>  
>
> 
> Index: menubar.xml 
> ===
> RCS file: /var/cvs/FlightGear-0.9/data/gui/menubar.xml,v
> retrieving revision 1.68
> diff -u -r1.68 menubar.xml
> --- menubar.xml   4 Dec 2007 10:51:45 -   1.68
> +++ menubar.xml   5 Dec 2007 07:57:44 -
> @@ -162,6 +162,14 @@
> 
>
>  
> +  
> +   Chat Menu
> +   
> +dialog-show
> +chat-menu
> +   
> +  
> +
>   
>  
>   
> 
> Index: keyboard.xml 
> ===
> RCS file: /var/cvs/FlightGear-0.9/data/keyboard.xml,v
> retrieving revision 1.103
> diff -u -r1.103 keyboard.xml
> --- keyboard.xml  26 Nov 2007 17:55:28 -  1.103
> +++ keyboard.xml  1 Dec 2007 10:08:51 -
> @@ -352,7 +352,17 @@
>
>   
>  
> - 
> +  
> +-
> +false
> +Compose Chat
> +
> +   dialog-show
> +   chat-menu
> +
> +  
> +
> +  
>.
>Right brake
>
> @@ -773,6 +783,16 @@
>
>   
>  
> +  
> +_
> +false
> +Compose Chat
> +
> +  nasal
> +  multiplayer.compose_message()
> +
> +  
> +
>   
>a
>Increase speed-up.
> 
> 

I've tested this all with Start, and after some changes and bug fixes it is
now in cvs-head. Unfortunately, my cvs client has crashed, and I can't
backport it to plib until tomorrow.

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] multiplayer generic properties

[Vivian Meazza]

AnMaster

> Sent: 08 December 2007 14:02
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] multiplayer generic properties
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Vivian Meazza wrote:
> > Anders has a really neat bit-mask utility which allows the 
> > transmission of up to 32 bools in one int property - much 
> neater for 
> > light switches and the like.
> > 
> > Vivian
> > 
> > P.S. - by tradition we bottom-post on the devel list
> 
> However for those aircrafts that I considered for lights they 
> were not on/off but had birghtness setting too, check the 
> A-10 and A-6E for example.
> 

Even better - for that there's nice slow signal interface using TDM - needs
a pair of properties, preferably int. Panel light, nav lights, etc etc. In
theory unlimited, but about 8 is practical.

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] multiplayer generic properties

[Vivian Meazza]

AnMaster

> Sent: 08 December 2007 11:55
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] multiplayer generic properties
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Yes, I already made a patch (see "[Flightgear-devel] Patch 
> for Harrier: making it's thrust vector work over mp") for the 
> harrier that makes use of this :)
> 
> And I can think of several other aircrafts that could make 
> use of this. For example position lights/anti-collision 
> lights of some aircrafts. Would make formation flying in the 
> dark over mp simpler.
> 
> Regards,
> 
> Arvid Norlander
> 
> Melchior FRANZ wrote:
> > After Maik has clued me up about multiplayer properties -- 
> that only 
> > those are transmitted, which actually exist at init time 
> (which is why 
> > they need to be defined in the *-set.xml file), it was time to add 
> > some generic properties for "internal communication". That is: 
> > properties which aren't dedicated to a particular function, 
> but can be 
> > used by an aircraft to send data to its mirror instances over MP.
> > 
> > There are for now:
> >   /sim/multiplay/generic/string[0-9]
> >   /sim/multiplay/generic/float[0-9]
> >   /sim/multiplay/generic/int[0-9]
> > 
> > Of course, this should be used sparingly. If you need to transmit a 
> > path, don't transmit the full path, but only the parts that 
> are really 
> > necessary. For example, the bo105 will only transmit "foo", when it 
> > actually means "Aircraft/bo105/Models/Variants/foo.xml".
> > The prefix and the ".xml" postfix will be stripped. There's 
> still the 
> > possibility to transmit "../../foo" if for some reason I 
> want to refer 
> > to a file elsewhere. (I didn't add double/long/bool, as 
> they would be 
> > transmitted as float/int/int, anyway.)
> > 
> > In one of the next protocol revisions, we won't have to 
> transmit these 
> > "single-shot" properties in every package (, I hope :-).
> > 
> > m.

Anders has a really neat bit-mask utility which allows the transmission of
up to 32 bools in one int property - much neater for light switches and the
like.

Vivian

P.S. - by tradition we bottom-post on the devel list



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear prerelease

[Vivian Meazza]

Georg Vollnhals

> Sent: 07 December 2007 16:10
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] FlightGear prerelease
> 
... Snip ... 
>
> > 2. Aircraft shows up under a carrier on reset
> > This happens when I reset FlightGear (Shift-ESC) on Nimitz.
> >   

This is a bug which we never got around to fixing, so I guess we should call
it a feature now.

Vivian  



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aircraft Downloading and Quality

[Vivian Meazza]

Gerard robin wrote

> Sent: 07 December 2007 15:44
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Aircraft Downloading and Quality
> 
> 
> On ven 7 décembre 2007, Heiko Schulz wrote:
> > > Yes we must not talk about artistic competences
> > > (here the "msfs" models are
> > > better  :(  ), only to answer the question: does the
> > > model simulate the  real
> > > one ?which degree of simulation ?
> >
> > Right I think- eye candies are only one small part of
> > being realistic, but if we want to be serious, we
> > should attend this.
> >
> > Problem: how should we find out how realistic a
> > aircraft is? Not all aircrafts here are based on save
> > datas or have a real pilot as developer?!
> >
> > Regards
> > HHS
> >
> An answer only for fun:
> 
> Yes the f16 is based on save data  ( partly yes , however,  it is )
> 


Sorry, run that hog by me again - what is "save data"?

Vivian



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aircraft Downloading and Quality

[Vivian Meazza]

Err ... there's a 2D exterior?
 
And a 3D cockpit is not necessarily better than a 2D. 2D is less demanding
on frame rate, and can be just as effective as a 3D cockpit. And some of
those are by no means brilliant. Horses for courses.
 
Our most detailed ac need high end computers to run on, with good graphics
cards. Not everyone has such a machine, and we have to have regard for them.
 
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gijs de
Rooy
Sent: 07 December 2007 14:30
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Aircraft Downloading and Quality


> Nice idea!
> 
> Why not add a system like: 5 stars for a very complete
> aircraft like the Senecca II or one for the not so
> goog like the fokker 70/100?
> 
> So everyone can see, where is potential to develop?!
> 
> Regards
> HHS
> --- Hans Fugal <[EMAIL PROTECTED]> schrieb:
We could give a star for every single part of the development stadia. One
start for the 3D Cockpit, one star for the Painting, One star for the 3D
Model, One star for the flying performances etc. So if a plane has a 3D
Cockpit and an 3d exterior model it gets 2 start by example.
 
PS: If this is added, we may add also something wich let users rate the
aircraft?


  _  

Windows Live Messenger het beste van de toekomst Download NU! Windows Live
Messenger!
  

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aircraft selection summary

[Vivian Meazza]

Durk Talsma wrote:

> Sent: 06 December 2007 08:31
> To: flightgear-devel@lists.sourceforge.net
> Subject: [Flightgear-devel] Aircraft selection summary
> 
> 
> I wasn't able to jump in yesterday, but I've been following 
> the aircraft 
> selection disscussion closely. Below is a first attempt at 
> compiling a new 
> list based on the various suggestion made by everybody, and 
> weighted by me 
> based on my general impression of consensus. 
> 
> 737-300             -> 787
> 
> I think Jon Berndt suggested keeping the 737, but a few 
> people suggested 
> replacing it by the 787, which seems to be our most complete 
> jetliner. I like 
> to follow that suggestion. 
> 
> A-10
> 
> As far as I can see, nobody suggested replacing this 
> aircraft. So I guess we 
> keep it.
> 
> bf109               -> A6M2 (Zero)
> Suggested by Melchior, for ease of operations use. I think 
> this is a good 
> point. The release will be the first FlightGear hands-on 
> experience for many 
> people and we want to make sure that that first experience is 
> as positive as 
> possible by providing aircraft that have reasonably easy handling 
> characteristics. Not including the bf109 for that reason is 
> by no means a 
> quality judgment of the aircraft itself. 
> 
> bo105
> c172
> c172p
> 
> Everybody seems to agree we keep these ones. 
> 
> c310                -> SenecaII
> c310u3a             -> Beaver
> 
> I haven't been able to check whether the c310 and c310u3a are 
> really two 
> separate aircraft, or just two different directories with 
> shared components. 
> Anyhow, we unanimously agree that the c310 should be replaced 
> by the Seneca. 
> The suggested replacement above seems to satisfy a few 
> additional requests to 
> have the Beaver included as well. 
> 
> Citation-Bravo      -> B1900D
> 
> This seems a reasonable replacement, in particular since the 
> author of the 
> Citation has indicated preferring that is is not part of the 
> base aircraft 
> selection. One minor concern is the ease-of-use issue. IIRC, 
> the B1900D is 
> fired up in "cold" configuration, and has quite a complicated 
> start-up 
> procedure (things may have changed since I last checked). 
> Complex procedures 
> like these may intimidate first time users. 
> 
> f16                 -> Lightning
> 
> Melchior reported that the f16 is broken. I haven't been able to test 
> recently, but seem to recall similar problems about a year 
> ago. Jon Berndt 
> reported finding a possible cause, so chances are the 
> reported problems might 
> get fixed in time. Still, I would like to replace the F16 for 
> other reasons: 
> We need at least an AAR ready aircraft in the base package, 
> and a carrier 
> ready aircraft (these are two very prominent new AI features 
> in this release 
> that we want to showcase). So, how about replacing the f16 
> with the Ligntning 
> (for AAR scenarios)?
> 
> j3cub
> 
> A few people have a suggested dropping the cub, but given its various 
> qualities, I'd like to keep it. 
> 
> Hunter              -> SeaHawk
> 
> As a few people suggested, we probably need a carrier ready 
> aircraft, and the 
> seahawk is advertised by the wiki carrier HOWTO as the 
> easiest to master (and 
> I can confirm that its doable. :-) ). 
> 
> p51d                -> ()
> 
> We already have one other WWII fighter. Do we really want to 
> have two, or do 
> we want to have some other category of aircraft represented?
> 
> pa28-161            -> pa24-250
> 
> A few people have suggested replacing the pa28-161 with the 
> pa24-250. I 
> haven't tried any of those recently, but would be open to the 
> suggestion. 
> 
> Rascal              -> Bochian  (or another glider)
> 
> Many people have suggested dropping the Rascal, for being too 
> specific, and 
> suggested we add a glider.
> 
> T38                 -> Concorde ()
> 
> Even though the T38 is probably a category of its own, my 
> general impression 
> is that the broader class this aircraft belongs to (let's say: small 
> high-powered jet powered and highy manouvreable) is a bit 
> overrepresented 
> (with the A10, [f16/lightning], and [Hunter/SeaHawk] being present.
> 
> Gerard Robin suggested adding the concorde, and there are 
> some aspects of this 
> proposal I like, asit is an altogether different category. 
> However, when 
> trying the condorde yesterday, I saw some performance issues 
> (need to check 
> again), and also found the 3D cockpit instruments to be a bit 
> cartoonesque. 
> This is probably a good candidate for future inclusion, but 
> not quite there 
> yet. 
> 
> ufo
> 
> Keep as a general exploration tool. Its fun as such. I think 
> everybody 
> agrees. :-)
> 
> wrightFlyer1903     -> Osprey/ DragonFly/maybe another 
> historic aircraft.
> 
> Most people suggested dropping the wright flyer. A few people 
> suggested adding 
> an ultralight. it would be nice to have a historic aircraft 
> (as in a really 
> old one). During the version number discussion, s

Re: [Flightgear-devel] control trim reset

[Vivian Meazza]

John Denker


> Sent: 05 December 2007 16:43
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] control trim reset
> 
> 
> On 12/04/2007 11:26 PM, Syd&Sandy wrote:
> > Hi all , I've added the elevator, aileron and rudder trim to the 
> > control-centering function - keypad  ( 5 ). Should this be added 
> > before the release ? Or is there a particular reason that the trims 
> > aren't reset ?
> 
> There is _some_ merit to this idea, but it needs refinement;  
> see below for details.
> 
> > developed the habit of hitting the 5 key before releasing the brakes
> 
> As Curt pointed out, simply zeroing the trims is a Bad Idea.
> In most airplanes -- simulated and real-life -- zeroing the 
> trim is not the right answer.
> 
> In the C182 for instance -- FG and RL -- you would be well 
> advised to apply significantly nonzero elevator and rudder 
> trim before takeoff.  A certain nonpilot on this list dismissed 
> this as "probably not that much help" but every RL pilot I 
> know does it anyway.
> 
> The general problem of setting the trim to the "desired" 
> value is ESP-complete;  that is, it requires reading the 
> pilot's mind to ascertain his intentions.  As an extreme 
> example of this, suppose I am buzzing along upside down in my 
> Decathlon, trimmed for straight-and-level inverted flight.  
> If I push "5" to center the primary flight controls, I definitely do 
> not want the trim set to zero, nor set to the level-flight 
> values.
> 
> So, all evidence suggests that there is a need for a "5" 
> command that does /not/ mess with the trim.
> 
> You could *also* implement something that does set the
> trim automagically.  I know a simple way to do this, if 
> anybody is interested.  However, I don't recommend it,
> because it is both unnecessary and unrealistic.
> This sort of automation appeals to people who drive cars,
> and expect to be able to jump in and drive away.  It is,
> alas, highly unrealistic in present-day general-aviation 
> aircraft, where the pilot expects to spend quite a long time 
> running the preflight checklists, including setting the trim.
> 
> One problem is that many aircraft in the FG fleet lack
> usable trim-position indicators.  That is why the Sport
> Model contains a popup that provides the necessary
> information.  (The popup is only a workaround, it is
> not meant as a long-term replacement for a proper 
> realistic trim-position indicator.)
> 
>   http://www.av8n.com/fly/fgfs/README.sport.model
>   http://www.av8n.com/fly/fgfs/git-overview


I use t to autotrim the Buccaneer, and T to remove all trims when I get it
wrong and need to retrim. No need to touch 5 - it centres the controls,
that's enough (not that I use it very often). Autotrim is quite a handy
function. I don't think it's used much. It kind of simulates the way trim
can be used to remove stick pressure.

Vivian



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] patch to use OpenSceneGraph database pager

[Vivian Meazza]

Tim Moore

>
> Sent: 04 December 2007 23:01
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] patch to use OpenSceneGraph database pager
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello, 
> http://www.bricoworks.com/moore/0001-OSG-pager-megapatch.patch
>  is a patch against current flightgear that uses the OSG 
> database pager to load scenery tiles instead of the old tile 
> loader. The main advantage of the database pager is that it 
> schedules texture loading and display list compilation in a 
> way that doesn't hammer the frame rate. Currently we don't do 
> anything at all about compiling OpenGL resources, so you can 
> get terrible stutter the first time you look at parts of a 
> scene. With this patch, that's gone. Also, old tiles are 
> deleted in the database pager thread, eliminating another 
> potential cause of stutter.
> 
> This will be checked into CVS soon, but I've been hesitating 
> for three reasons:
> 
> * It breaks the GLUT version;
> 
> * Some bugs turned up with multiplayer play. I think I've 
> fixed these, but some more testing would be good;
> 
> * Without patches to OSG that have been submitted to 
> osg-submissions, startup time is noticeably longer.
> 
> Nevertheless, the patch is quite usable with OSG 2.2. Give it 
> a try if you're feeling adventurous.
> 

I've been running with this patch for a while now with OSG 2.2. The load
time isn't too excessive. It provides enhanced smoothness, but the stutters
around KSFO are still apparent here. Overall, the advantages outweigh the
small disadvantge of increased laoding time. I certianly won't be reverting
the patch, and look forward to it being in cvs, and osg taking the changes
aboard.

Vivian 



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear prerelease

[Vivian Meazza]

Stuart wrote:

>
> Sent: 04 December 2007 22:16
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] FlightGear prerelease
> 
> 
> 
> --- Durk Talsma wrote:
> > Another question: we always have a limited number of 
> aircraft that are 
> > in the distribution, with the rest being available as separate 
> > downloads. We like to
> > keep the number of aircraft constant, and representative of the many
> > types of 
> > aircraft supported by FlightGear. Is there any pressing 
> reason to swap
> > one 
> > aircraft for another one? IIRC, there have been some suggestions of
> > replacing 
> > the 737 by the 787. FWIW, we currently have the following 
> selection of 
> > aircraft (Taken from Makefile.am):
> > 
> 
> > data/Aircraft/UIUC \
> 
> Ditch this - I don't think we have any UIUC aircraft in 
> common use (though the Wright Flyer might be)
> 
> > data/Aircraft/c172 \
> > data/Aircraft/c172p \
> 
> c172p should be included as it is mentioned extensively in 
> the docs and has basic tutorials.
> 
> > data/Aircraft/c310 \
> > data/Aircraft/c310u3a \
> 
> Much as I like the c310 - it's now very primitive compared 
> with recent aircraft. Replace with the Seneca II.
> 
> 
> 
> > data/Aircraft/j3cub \
> 
> Include as a nice easy taildragger.
> 
> > data/Aircraft/Hunter \
> > data/Aircraft/p51d \
> 
> > data/Aircraft/pa28-161 \
> 
> I'd suggest replacing this with a complex single, say the 
> pa24-250. Then we have a nice progression from training to 
> complex twin.
> 
> > data/Aircraft/Rascal \
> 
> Does anyone actually use this?
> 
> > data/Aircraft/T38 \
> 
> I'm sure that there are better jets, but I'm not familiar 
> with them in enough detail to suggest a replacement.
> 
> > data/Aircraft/ufo \
> > data/Aircraft/wrightFlyer1903 \
> 
> As Melchior says - ditch as no-one uses it.
> 
> I'd also suggest that we include a carrier-capable jet as 
> well - seahawk?
> 

The Seahawk is the most complete carrier-capable ac that we have, so if we
want to include that capability that the one to have. On the Other hand the
Hunter is probably the easiest ac to fly that we have in the inventory.

I'd like to see the Lightning included - it is very complete, it has a nice
tutorial, and demonstrates the aar capability.

Vivian 



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: Control surface position damping

[Vivian Meazza]

Maik 

> Sent: 02 December 2007 13:49
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] RFC: Control surface position damping
> 
> 
> Hi Roy,
> Roy Vegard Ovesen schrieb am 02.12.2007 14:13:
> > When prssing the 5 key on the numeric keypad to reset the 
> controls to 
> > zero,
> > the control surfaces instantly move to their origin. 
> Similar effects can also 
> > happen when an autopilot controller is activated, and when 
> a noisy joystick 
> > is interfering with an autopilot controller.
> >
> > I think moving a control surface, like for example the rudder, from 
> > full left
> > deflection to rull right deflection in an instant is 
> unrealistic. To make 
> > this more realistic I think we should put in a low pass 
> filter somewhere in 
> > the chain from crontrol device to FDM. My first thought 
> would be to do the 
> > filtering just befir handing the value over to the FDM.
> >
> > Does anyone on the list have comments on this?
> >
> >   
> With YASim you can limit the speed of any control surface, 
> mostly used 
> for flaps.
> 

I use it for all control surfaces where appropriate to simulate servo
response time. I would not like key 5 to muck about with this in some
pre-cooked and inappropriate way. Key 5 should be just centre the controls -
that and no more. If individual aircraft designers want to modulate it in
some way, that's down to them.

This is a bad idea.

Vivian



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Informal version number poll

[Vivian Meazza]

 I think that the juxtaposition of 9.11 and "Flight Simulator" would be
unfortunate, to say the least. I'm not sure how strongly I feel about that
personally, but I recognise that there are those, particularly the other
side of the pond, who do or might. Why give gratuitous and unnecessary
offence? 
 
On the other hand Version 1.0. But we have OSG waiting in the wings, don;t
we?. This is just a temporary release isn't it? perhaps 9.12 or something
would be more appropriate.
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf OfOlson
Sent: 30 November 2007 15:29
To: FlightGear developers discussions
Subject: [Flightgear-devel] Informal version number poll


How about a quick, friendly, positive, informal thread here to do a poll on
what what folks are thinking for the next version number.

I don't intend to slant the discussion, but here is what I'm thinking.

0.9.11 is the next in the logical sequence.  But I'd like to avoid possible
unintended connections that end users might interpret from such a version
number.  This has nothing to do with terrorism, they don't care what version
numbers we use or don't use.  There is no "fear" involved in wanting to
avoid using this number.  Try "respect".  It might have something to do with
showing respect to those that were affected by 9/11 and those many heros
that gave up their lives without hesitation to try to save the lives of
others.  I don't fault people who live outside of the USA or who have never
been to New York or were never near ground zero for not "getting it",
there's an awful lot of stuff outside my little sphere of vision that I will
never understand.  But give me a break, what's the problem with yielding a
small amount of leeway and respect to those that were affected by 9/11 or
had connections there? 

We could skip over to 0.9.12, but then we are staring in the face of 0.9.13
and are we going to run into problems if we pick a version # 13?  I wore
number 13 in my soccer (err futbol) game the other evening and missed all my
shots.  I wore a different number last night and scored two goals.  These
facts cannot be ignored! 

We could go with 0.10.0, but then all the odd/even version number proponents
are going to come out of the woodwork, and that is going to mire in it's own
set of politics.

We could go with v1.0 ... we've been at this 10 years, and averaging 0.1
versions a year isn't so bad.  This is my preference.  FlightGear is
developing at a rapid rate, but if we stick with 0.9.12, 0.9.13, 0.9.14 it
seems like we are bumping along with very minor increments every few (or
many) months. 

Of course this all boils down to marketing.  Who cares what the actual
numbers are really, as long as they increment in a sensible way.  But what
image do we want to project to the world?

Are we a bunch of old cranky developers (it looks that way sometimes!) :-)
inching along at a snails pace, or are we a dynamic exciting group with fast
paced development continually adding new and exciting features and aircraft?
We've been at this 10 years, have we really only managed a 0.9.x release in
all that time?  Again, not that version number really mean anything, other
than to project our image to the world.

I say it's "go time". :-)

Curt.
-- 
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d 

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flightgear-devel Digest, Vol 19, Issue 25

[Vivian Meazza]

LeeE wrote

> Sent: 30 November 2007 00:13
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Flightgear-devel Digest, Vol 
> 19, Issue 25
> 
> 
> On Thursday 29 November 2007 21:55, Melchior FRANZ wrote:
> > Hey,
> >
> > * BARANGER Emmanuel -- Thursday 29 November 2007:
> > > > Also, file names with spaces in them are garbage. There 
> should be 
> > > > none of those in CVS.
> > >
> > > AAAHHHRRGGG ! The suprises CVS files which do not for the 
> drive :( I 
> > > erased now. Sorry.
> >
> > No problem. Not a big one, anyway. I'm happy about every new, great 
> > aircraft. (Especially the AlouetteII -- we've had some of 
> them in our 
> > army, too, -- or the BV141).
> >
> > It's only natural that we use more disk space with every 
> new one, but 
> > we have to make sure that we don't just waste it. 
> Compressing textures 
> > is one thing to consider, not committing unnecessary files 
> is another, 
> > such as *.bak, *.blend, *~ files. Or a few
> > of those:   :-}
> >
> >   $ l SeaHawk* Models/SeaHawk-FGA6-WV859.ac
> > -rw-r--r-- 1 m m 1453387 2007-09-28 01:18
> > Models/SeaHawk-FGA6-WV859.ac
> > -rw--- 1 m m  707301 2003-04-21 22:29
> > Models/SeaHawk-WV908.ac
> > -rw--- 1 m m  113282 2003-01-03 17:58
> > Models/SeaHawk.3ds
> > -rw--- 1 m m  715739 2003-02-14 16:29
> > Models/SeaHawk.ac 
> > -rw--- 1 m m  226548 2003-01-09 16:04
> > Models/SeaHawkpair.3ds
> >
> > m.
> 
> I'm pretty sure that the SeaHawk.ac, SeaHawk.3ds & 
> SeaHawkpair.3ds can 
> be done away with right now.
> 
> I think Vivian is doing all his development on WV859 and I'd like to 
> keep WV908, if only as a placeholder and reminder, as it's the RNHF 
> aircraft - afaik it's currently the only flying example.  At 
> some point 
> I'd like to refine the 3d model geometry and then unify the two 
> versions (perhaps it will only need different skins), 
> incorporating all 
> the development that Vivian has done...
> 
> ...or Vivian might decide to do it before I do :)
> 
> Ok with you Vivian?
> 

Yes, we must have WV908, but I don't think we would want to retain more then
the textures for that longer term: doing an alternate livery is on my todo
list. Otherwise the rest is all your stuff, and if you are content to have
it removed, I'll do that. Your call.

Hmm Mathias wanted to do a wingman using AI techniques ages ago, and it's
always in the back of my mind. One of these days ...

Vivian



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nimitz operation menu items

[Vivian Meazza]

Hi Paul,
 
I'm afraid I cannot add the items you ask for as they stand. The code only
works with the existing Nimitz_demo.xml. If any other carrier demo is used,
this carrier will be placed in the default Nimitz location by the use of
this dialog. A dialog must be generally applicable, not apply to just one
situation, and must most definitely not break anything.
 
The idea is sound, and I encourage you to work the code up into something
that works properly.
 
Regards,
 
Vivian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bohnert
Paul
Sent: 22 November 2007 03:54
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Nimitz operation menu items


Hi All,

For now please add the two items I asked for.

I'll work on a new and improved stand alone carrier menu.

It might take some time.  I'm learning as I go.

Best Regards,
Paul B


gerard robin <[EMAIL PROTECTED]> wrote: 

On mer 21 novembre 2007, Mike Schuh wrote:
> On Wed, 21 Nov 2007, Stuart Buchanan wrote:
> >1) I think splitting the dialog into two - one for AI/ATC and one for
> >carrier settings would be a good idea. From the user's perspective, they
> >are really two separate functions and there are now sufficient carrier
> >functions to make this worthwhile.
>
> I agree.
>
> >It might also be worth including buttons for engaging the launchbar, and
> >even firing the catapult.
>
> I think it would be valuable to add a configurable time delay to the
firing
> of the catapult. This would allow the user to click "fire", close/dismiss
> the dialog window/box, and prepare to fly the plane. The default could be,
> say, 5 seconds, and there could be a separate dialog window/box that shows
> the time remaining before the catapult is fired (this separate dialog
would
> automagically disappear when done). I suppose there should be an option to
> not show this countdown timer (or rather, showing it requires checking a
> box in the carrier dialog).

Yes, you are right, 
for instance, I did include some delay (with a nasal script) , mainly to get

a nice animation within my Air Navy Aircrafts, unfortunately up today it 
is only a private use ( you cannot get profit of it since these models can 
fly only with a specific carrier patched JSBsim FDM, .. old sad 
history ).
However, the keys are necessary, to activate these features

>
> >2) The dialog currently is very specific to the Nimitz and its current
> >location. I think it would be a good idea to instead provide controls for
> >any number of carriers...
>
> I agree.
>

Regards,


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


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel





  _  

Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try
 it now.

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Keyboard reorg

[Vivian Meazza]

Stuart wrote

> Sent: 28 November 2007 10:18
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Keyboard reorg
> 
> 
> Hi All,
> 
> I've added the key assignments currently defined in 
> keyboard.xml to the wiki page, so that we can easily see what 
> assignments people think are missing, and any inconsistencies:
> 
> http://wiki.flightgear.org/flightgear_wiki/index.php?title=Key
> board_function_priority_list
> 
> Note that this only lists the key assignments for the 
> functions that people have added to the wiki. It doesn't list 
> all the current key assignments so shouldn't be used to work 
> out which keys are available :)
> 
> I think it might be worth making a couple of small changes 
> for the 0.9.11 release to make the key assignments more 
> consistent, and to define which blocks of keys we want to 
> reserve for aircraft designers, and which we will reserver 
> for user's own custom assignments. That way we have a 
> strategy going forwards, and designers of new aircraft will 
> have some confidence that they will not be treading on other 
> peoples toes.
> 
> >From looking at the list, one thing that looks worth 
> resolving are the 
> >speedbrakes, spoilers and slats assignments. The current key 
> assignment 
> >for Speedbrakes assumes that the brakes are on/off, and at 
> least in the 
> >case of the Vulcan, they have multiple positions. I don't 
> fly big iron 
> >much, but I'd guess that slats can similarly have multiple 
> positions. 
> >Anyone care to comment?

A similar situation to the Buccaneer - I retained ctrl B to toggle the
airbrake (aka speedbrake) but also use j/k to step the airbrake through
predefined detents. Luckily, it doesn't have spoilers as well. The A4F does,
so that option wasn't available, so I stuck with the default keys. Hmm - the
A4F has an automatic deployment option for the spoilers - must do that
sometime. 

But how will I do the wing/flap/aileron blowing system? Haven't even thought
about that yet.
 
> It might be worth adding a new list to the wiki page of the 
> current functions for which there is a keyboard assignment we 
> no-longer need. For example, the time warp and simulation 
> rate key assignments which we will no-longer need once 
> someone commits my Time of Day dialog changes ;)


I've already re-used t/T for the auto-trim facility in the Buccaneer - but
there's no reason to make that a permanent or default assignment

Vivian



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Nimitz operation menu items

[Vivian Meazza]

Stuart

> Sent: 21 November 2007 10:11
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Nimitz operation menu items
> 
> 
> > Bohnert Paul wrote
> >I propose adding two items to the ATC/AI Options menu.
> 
> 
> >
> >The first one will enable users to set the speed of carrier Nimitz.
> 
> 
> >
> >The second will set Nimitz speed to 0 and place it at the 
> it's start up 
> >location. This will allow MP players to >place Nimitz at the same 
> >location without editing configuration files.
> 
> 
> Hi Paul,
> 
> Providing an easy way to make the Nimitz more MP-compatible 
> is an excellent idea. However, I have two comments on the 
> implementation:
> 
> 1) I think splitting the dialog into two - one for AI/ATC and 
> one for carrier settings would be a good idea. From the 
> user's perspective, they are really two separate functions 
> and there are now sufficient carrier functions to make this 
> worthwhile. It might also be worth including buttons for 
> engaging the launchbar, and even firing the catapult. This 
> will also allow us to hide the carrier menu if the carriers 
> are not enabled.

> 2) The dialog currently is very specific to the Nimitz and 
> its current location. I think it would be a good idea to 
> instead provide controls for any number of carriers, or at 
> least controls that will reset _all_ carriers to their 
> default position. This may require a bit of re-jigging of the 
> carrier scenarios so that their initial positions etc are 
> accessible, but will give a lot more flexibility as the 
> number of carriers increase.
> 
> I realize that this has just trebled the workload for your 
> enhancement, but I think that both these things will make it 
> much more useful.
> 
> Best regards,
> 
> -Stuart
> 

As an ergonomic issue here - I would prefer not to try to juggle with mouse
and joystick to either engage the launchbar or fire the catapult - the
keyboard is a better option. I know there are some who can manage that, but
I'm not one of them.

Otherwise, this is all good stuff, and as the co-author of the original
carrier stuff would be very willing to add the final version to cvs.

Only temporarily, mind. We have been talking about doing the carrier (and
other ai objects) over mp for years now. Perhaps some time soon ...


Vivian 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] CVS: data/Aircraft/Buccaneerbuccaneer-obs-set.xml, 1.2, 1.3 buccaneer-set.xml, 1.23, 1.24

[Vivian Meazza]

 Melchior

> Sent: 19 November 2007 21:55
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] CVS: 
> data/Aircraft/Buccaneerbuccaneer-obs-set.xml, 1.2, 1.3 
> buccaneer-set.xml, 1.23, 1.24
> 
> 
> * Vivian Meazza -- Monday 19 November 2007:
> > Log Message:
> > Modify Buccaneer "Observer" to comply with Melchior's latest diktat
> 
> Anyone else unhappy with my fgfs performance? Just say it!
> 
> I've stated at least four times that views 0 to 99 are 
> reserved for the "system", that is: are to be avoided by 
> aircraft files. I have explained why. I've asked three 
> people, to *please* comply with this rule. Everyone did. 
> Except one who doesn't think he has to play by the rules. 
> This pisses me off, and I hereby stop working in this area.
> 

Just pulling your leg, Melchior. It's been hard enough getting Anders' stuff
to work without changing View numbers, and I was waiting to see which way
was best before doing nugatory work. And it's now all done.

I think what you have done so far is very nice.

Sorry you were offended, and no Latin I promise :-)

Vivian 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Default glider model

[Vivian Meazza]

John Wojnaroski

> Sent: 18 November 2007 16:15
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] Default glider model
> 
> 
> Hi,
> 
> Running OSG-2.2 and FG cvs...
> 
> After turning off all the models, panels, views, etc, I'm 
> left with the 
> default yellow-green glider model in the scene.  Does one have to set 
> the view or eyepoint in front of the model to make it disappear or is 
> there a more "correct" way to eliminate the aircraft model from the 
> scene graph?
> 
> Regards
> John W.
> 

I don't know exactly what you are trying to do, but if you use this in your
-set.xml
file you will get no model, and no yellow/BLUE glider

Models/Geometry/null.ac


Not sure how you get rid of yellow/green ones


Vivian 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Keyboard reorg

[Vivian Meazza]

 AJ MacLeod wrote

> Sent: 12 November 2007 12:09
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Keyboard reorg
> 
> 
> On Monday 12 November 2007 06:31:26 John Denker wrote:
> > Agreed!  I've thought for ages that a top-to-bottom reorg would be 
> > helpful. The starting point for me was the realization that there
> > are far more aircraft functions that need to be controlled
> > than there are keys on the keyboard
> 
> Which is why we have cockpit hotspots.  The simple fact of 
> the matter is this; 
> we model a vast array of aircraft, of almost every type 
> imaginable.  We are 
> modelling them in an ever more detailed way, and each 
> aircraft really is very 
> different; far too different to provide enough key bindings 
> to make each 
> aircraft controllable by the keyboard alone.
> 
> For those who never fly or model anything other than single engine 
> light "training" type fixed-wing aircraft, perhaps the 
> problem isn't so 
> noticeable; these are comparatively simple and probably have 
> a reasonable 
> degree of commonality of functions between aircraft.
> 
> There are, IMHO, very few functions indeed which really 
> _require_ a keyboard 
> binding by default.  Why try and squeeze every aircraft type 
> and function 
> into one cramped mould?
> 
> > In situations such as this, the time-honored solution is
> > to come up with a _language_.
> > A good language has
> >  *) some orthogonality, and
> >  *) some mnemonic value.
> 
> And will be detested (indeed, completely shunned) by the 
> "average user".  
> While I can see your point, and some possible advantages with 
> your idea, it's 
> a complete non-starter from the point of view of the 
> non-programmer "normal" 
> user.
> 
> Maybe most of us on this list find it natural to think in 
> such terms, but I 
> can assure you (from dealing with typical "users" every day) 
> that most people 
> don't.
> 

I would add that the current assignments have evolved over the best part of
a decade, and are the results of a degree of consensus. It is likely that
any review will:

A. Only tinker round the edges.

B. Be different rather than better, and quite likely worse.

Consensus is unlikely, other than more or less around what we have already.
Any major change would require our users (and developers) to unlearn the old
and relearn the new. Unlikely to win many friends.

Evolution is usually better than revolution.


Vivian

  


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml, 1.99, 1.100

[Vivian Meazza]

gerard robin

> Sent: 11 November 2007 13:18
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: 
> data keyboard.xml,1.99, 1.100
> 
> 
> On sam 10 novembre 2007, Vivian Meazza wrote:
> > gerard robin
> >
> > > Sent: 10 November 2007 18:37
> > > To: FlightGear developers discussions
> > > Subject: Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data 
> > > keyboard.xml,1.99, 1.100
> > >
> > 
> > > wonder if it would not have been  better to find a global 
> agreement 
> > > on which "key" can do what, before to make that update.
> > >
> > > There is some  aircraft within CVS which are  carrier compatible.
> > >
> > > With that update the launchbar  will not work now.
> >
> > Should be OK, the carrier bindings will over-write the keyboard 
> > bindings. It will be a problem if there is an aircraft with 
> both tail 
> > wheel lock _and_ carrier launch bar (F4U?) I haven't checked that.
> >
> > And perhaps we can come up with a long term solution. I'm sure 
> > Melchior's little grey cells are working overtime.
> >
> > Still, perhaps we shouldn't be making changes until we are clearer 
> > about the consequences.
> >
> > Vivian
> >
> >
> 
> I did not check it , but your Seafire has both Launchbar and 
> tailwheel lock, What is the matter now with the keyboard updated ? 
> 
> Regard
> 

Not really, later on in the YASim config, it's ignored.

Vivian


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [ANN] - Buccaneer - Back seat ride

[Vivian Meazza]

I wrote:

> -Original Message-
> From: Vivian Meazza [mailto:[EMAIL PROTECTED] 
> Sent: 10 November 2007 23:20
> To: 'FlightGear developers discussions'
> Subject: [ANN] - Buccaneer - Back seat ride
> 
> 
> Hi, 
> 
> Tonight we carried out our first ride in the backseat of a 
> Buccaneer over MP, thanks to some excellent recent work by 
> Melchior and Anders. AJ was the intrepid Observer/passenger, 
> and reported himself well pleased with the experience.
> 
> To try it you need the Pilot and Observer on MP in the 
> Buccaneer, and then the Observer selects the Model Cockpit 
> View (V/v), then cycles through the cockpit views (Q/q) until 
> he reaches the back seat of the Buccaneer. That's it - the 
> Pilot can then fly with his Observer aboard. Sick bag might 
> be necessary :-).
> 
> Only available in cvs, of course, and there's much work to be 
> done to both generalise this to all mp aircraft, and to 
> provide the appropriate facilities and connectivity in the 
> backseat so that the Observer can be more than just a 
> passenger. AJ was navigating using the MPMap, so that's a start. 
> 
> Anders is hard at work extending this into a co-pilot 
> facility - watch this space. Meanwhile - if you are on MP 
> we're aboard and watching you :-).
> 
> Regards
> 
> Vivian 
> 


P.S. Clipping plane problems mean that this only works properly in OSG. We
can probably fix it quite quickly in plib, but haven't thought through the
consequences yet.

V.



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] [ANN] - Buccaneer - Back seat ride

[Vivian Meazza]

Hi, 

Tonight we carried out our first ride in the backseat of a Buccaneer over
MP, thanks to some excellent recent work by Melchior and Anders. AJ was the
intrepid Observer/passenger, and reported himself well pleased with the
experience.

To try it you need the Pilot and Observer on MP in the Buccaneer, and then
the Observer selects the Model Cockpit View (V/v), then cycles through the
cockpit views (Q/q) until he reaches the back seat of the Buccaneer. That's
it - the Pilot can then fly with his Observer aboard. Sick bag might be
necessary :-).

Only available in cvs, of course, and there's much work to be done to both
generalise this to all mp aircraft, and to provide the appropriate
facilities and connectivity in the backseat so that the Observer can be more
than just a passenger. AJ was navigating using the MPMap, so that's a start.


Anders is hard at work extending this into a co-pilot facility - watch this
space. Meanwhile - if you are on MP we're aboard and watching you :-).

Regards

Vivian 



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml, 1.99, 1.100

[Vivian Meazza]

gerard robin

> Sent: 10 November 2007 18:37
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: 
> data keyboard.xml,1.99, 1.100
> 
> 
> On sam 10 novembre 2007, David Megginson wrote:
> > On 10/11/2007, gerard robin <[EMAIL PROTECTED]> wrote:
> > > I can notice the update has been done , before we could give any 
> > > opinion on the topic. Does it mean , that there is not any other 
> > > alternative, and the CHOICE is that way nothing else  :) :) :)
> > >
> > >From my original message:
> >
> > 
> > I just moved tailwheel-lock from lowercase 'l' to uppercase 
> 'L', and 
> > reassigned lowercase 'l' to toggle lighting (for easy night starts 
> > without searching for switches).  I assigned lighting to 
> the lowercase 
> > 'l' because I think it would be much more commonly used 
> than tailwheel 
> > lock, but if there are general objections (from DC-3 users?) I can 
> > swap the two around so that tailwheel lock goes back to 'l'.
> >
> > Let me know what you think.
> > 
> >
> > I or anyone else with access can change it again once there's a 
> > consensus -- remember that CVS is the experimentation 
> branch, not the 
> > release branch.
> >
> >
> > All the best,
> >
> >
> > David
> >
> Oh, i am only like the dog which try to catch his tail.
> 
> Since we had the 'L" used with carrier , (this was talked 
> before), i only 
> wonder if it would not have been  better to find a global 
> agreement on 
> which "key" can do what, before to make that update.
> 
> There is some  aircraft within CVS which are  carrier compatible.
> 
> With that update the launchbar  will not work now.
> 

Should be OK, the carrier bindings will over-write the keyboard bindings. It
will be a problem if there is an aircraft with both tail wheel lock _and_
carrier launch bar (F4U?) I haven't checked that.

And perhaps we can come up with a long term solution. I'm sure Melchior's
little grey cells are working overtime.

Still, perhaps we shouldn't be making changes until we are clearer about the
consequences.

Vivian 


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Minor keyboard reassignment

[Vivian Meazza]

Melchior FRANZ

> Sent: 10 November 2007 10:00
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Minor keyboard reassignment
> 
> 
> * Vivian Meazza -- Saturday 10 November 2007:
> > Gerard robin wrote
> > > There is only a the little number of persons who use and like the 
> > > carriers,
> 
> I'm not even sure about that. It's one of the frequently 
> asked questions, and it seems as if everyone of the IRC 
> regulars uses the carrier once in a while. I do pretty often. 
> 
> 
> 
> > > The L   is very useful , i mean a key on the keyboard (not a 
> > > "like ATC dialog").
> 
> > And I don't think a dialog would be a good way to fire the catapult.
> 
> Hmm ... ok. I'm just not sure if having two separate keys is
> a good thing. Maybe we should standardize on
> 
>   c  ... toggle canopy
>   C  ... engage & disengage (toggle) catapult  \__"c" as 
> in "carrier"
>   Ctrl-c ... launch catapult   /  control 
> the crew :-)
> 
> 
>   l  ... lights  (though most are operated via 3D cockpit 
> switches!)
>   L  ... tail wheel lock
>   Ctrl-l ... liveries  (l for liveries is a bit exaggerated, anyway)
> 

Sounds reasonable to me.

V.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Minor keyboard reassignment

[Vivian Meazza]

Gerard robin wrote

> Sent: 10 November 2007 09:29
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Minor keyboard reassignment
> 
> 
> On sam 10 novembre 2007, Melchior FRANZ wrote:
> > * Melchior FRANZ -- Saturday 10 November 2007:
> > > L is used to engage in the aircraft carrier's catapult
> > > (see $FG_ROOT/Input/Keyboard/carrier-bindings.xml). So around 10 
> > > aircraft will overwrite the new lighting binding anyway.
> >
> > err ... the tailwheel lock binding. (I didn't even know that it was 
> > there. I have that on my js.) We have still several keys globally 
> > unassigned, but it's increasingly hard to find one that 
> isn't used by 
> > at least one aircraft. In the long run we'll have to 
> reorganize a bit. 
> > We waste a lot of keys for obscure features that a typical 
> simulator 
> > user will never need and/or that are too easy to press by accident 
> > (a/A, t/T, r, ...). The carrier bindings could IMHO be in a small 
> > popup dialog (like the ATC dialog). They aren't for controlling the
> > aircraft after all, but to give orders to the carrier crew.
> >
> > m.
> >
> >
> 
> Anyhow, I am not sure it would be a good idea to use the 
> "reserved" carrier KEYS. There is only a the little number of 
> persons who use and like the carriers, 
> which is not the majority of the FG community :(, so i can 
> understand that 
> many persons don't mind about carrier, and i worry it.
> The L   is very useful , i mean a key on the keyboard (not a 
> "like ATC 
> dialog").
> 
> Please keep it.
> 

And I don't think a dialog would be a good way to fire the catapult.

Regards

Vivian


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] view handling news

[Vivian Meazza]

Melchior

> Sent: 08 November 2007 11:48
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] view handling news
> 
> 
> * Vivian Meazza -- Thursday 08 November 2007:
> > The model-view with multiplayer has been tested here and works very 
> > well.
> 
> What doesn't work well yet is Nasal based chase view in 
> replay mode (fixed on my disk), and model view in fg/osg 
> (fixed on my disk). 
 
Replay is firmly off here (creates too much jitter - I can live without it),
and I haven't tested the new chase view. FG/OSG is barely usable here, and
the jitter fixes which work so well in pilb seem to have no effect on osg,
but I haven't given it a fair test yet. 
 
> > Well done Melchior
> 
> Thanks. That's just the beginning. Once the remaining jitter 
> problems are solved the only limiting factor is our fantasy.  ;-) 
> 

Just a back-seat view would do me for starters - I can come up with more I
expect.

V.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] view handling news

[Vivian Meazza]

I wrote: 

> Sent: 08 November 2007 08:16
> To: 'FlightGear developers discussions'
> Subject: Re: [Flightgear-devel] view handling news
> 
> 
> Melchior wrote
> 
> 
> > Sent: 07 November 2007 23:14
> > To: flightgear-devel@lists.sourceforge.net
> > Subject: [Flightgear-devel] view handling news
> > 
> > 
> > Since David complained about the damping mechanism in
> > viewer.cxx, I wanted to check whether the same feature could 
> > also be done in Nasal. (Damping is at the moment only used in 
> > the "Chase View". It's just lowpass filters on the 
> > heading/pitch/roll angles, which make the viewer follow the 
> > aircraft with a slight delay.)
> > 
> > I had to fix a jitter problem in the main loop, and there's 
> one more 
> > to fix for replay (already done on my HD), but most of the work is 
> > done. There's now a manager in $FG_ROOT/Nasal/view.nas 
> where one can 
> > register Nasal view handlers. This is by default only done for the 
> > Fly-By-View.
> > 
> > Here are two more examples. Each of them is an XML file with
> > some settings and embedded Nasal code, and implements a new 
> > "view". You can try them out at once:
> > 
> >   $ fgfs --aircraft=j3cub ~/chase-view-II.xml ~/model-view.xml
> > 
> > Use full paths for the files. (~ expands to a full path :-)
> > 
> > chase-view-II.xml is a proof of concept. It's a slightly
> > extended chase view, where also latitude/longitude/altitude
> > are lowpass filtered. This is nice to see how far an aircraft
> > drops in a barrel roll. Might also be nice for movies.
> > 
> > model-view.xml allows to cycle through all carriers, tankers,
> > aircraft, multiplayer (untested) with the q/Q keys.
> > 
> 
> The jitter in plib has pretty well been fixed here by these 
> modifications. There remains some low frequency and 
> relatively long pauses around KSFO and other texture/model 
> rich environments. The sound bug has been fixed. 
> 
> The model-view with multiplayer has been tested here and 
> works very well. This facility is a very nice add-on to FG. 
> Pity it wasn't available for the FSWeekend event in Lelystad, 
> because it is particularly applicable to this kind of event.
> 

P.S.

We get views like this:

ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/Model-viewer.jpg

V.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] view handling news

[Vivian Meazza]

Melchior wrote


> Sent: 07 November 2007 23:14
> To: flightgear-devel@lists.sourceforge.net
> Subject: [Flightgear-devel] view handling news
> 
> 
> Since David complained about the damping mechanism in 
> viewer.cxx, I wanted to check whether the same feature could 
> also be done in Nasal. (Damping is at the moment only used in 
> the "Chase View". It's just lowpass filters on the 
> heading/pitch/roll angles, which make the viewer follow the 
> aircraft with a slight delay.)
> 
> I had to fix a jitter problem in the main loop, and there's
> one more to fix for replay (already done on my HD), but most 
> of the work is done. There's now a manager in 
> $FG_ROOT/Nasal/view.nas where one can register Nasal view 
> handlers. This is by default only done for the Fly-By-View. 
> 
> Here are two more examples. Each of them is an XML file with 
> some settings and embedded Nasal code, and implements a new 
> "view". You can try them out at once:
> 
>   $ fgfs --aircraft=j3cub ~/chase-view-II.xml ~/model-view.xml
> 
> Use full paths for the files. (~ expands to a full path :-)
> 
> chase-view-II.xml is a proof of concept. It's a slightly
> extended chase view, where also latitude/longitude/altitude
> are lowpass filtered. This is nice to see how far an aircraft
> drops in a barrel roll. Might also be nice for movies.
> 
> model-view.xml allows to cycle through all carriers, tankers,
> aircraft, multiplayer (untested) with the q/Q keys.
> 

The jitter in plib has pretty well been fixed here by these modifications.
There remains some low frequency and relatively long pauses around KSFO and
other texture/model rich environments. The sound bug has been fixed. 

The model-view with multiplayer has been tested here and works very well.
This facility is a very nice add-on to FG. Pity it wasn't available for the
FSWeekend event in Lelystad, because it is particularly applicable to this
kind of event.

Well done Melchior

Regards

Vivian


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] compilation problems with MSVC 2005

[Vivian Meazza]

Sergey

> Sent: 05 November 2007 15:38
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] compilation problems with MSVC 2005
> 
> 
> Hello Georgi,
> 
> you might want to replace your version of plib with that on 
> my site in archive
> 
> http://www.sim-ai.org/FlightGear0.9.11beta1completecode.zip
> 
> from http://www.sim-ai.org/FlightGearlesson.htm
> 
> the problem is in plib ac reader where wrong open file option is set.

I don't think so
 
> ( the only difference with you - I used beta of vs2008 so you 
> will need to keep your project files)
> 
> On 11/5/07, Georgi Ivanov <> wrote:
> > Hi
> > I am trying to compile FlightGear 0.9.10 with Visual Studio 2005. 
> > However, in fg_os.c line 141 when the following code 
> executes I get an 
> > error.
> >

Hmmm, no need for modified plib here with MSVC8. You do need the right
version of Simgear though, and then make sure that your MSVC8 is configured
correctly. Plib 1.8.4 works with 0.9.10. plib-cvs is better with 0.9.11.

Vivian 

  


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] [ANN] Buccaneer

[Vivian Meazza]

Hi,

I've just added a fuel dump facility to the Buccaneer. A screenshot is here:

ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-fuel-jettison.jpg

Looks nice? Don't be fooled: the particles are firmly tied to the aircraft.
There is much work to be done to integrate particles into FG. Not least the
right frame of reference, and the proper wind.

Regards

Vivian  


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] 3d file formats and "crease angles"

[Vivian Meazza]

Roberto

> Sent: 04 November 2007 09:55
> 
> Hi,
>  I've been modeling for fgfs a few objects around the world. 
> I'm used to 
> output everything as .AC files since it looks to me it's the 
> most used 
> format in FGFS but that has a few limitations that I'd like 
> not having.
> 
> The one I'm concerned now is the "crease angle" limitation. 
> AC3D makes me set a crease angle for an entire object and 
> does not let 
> me choose to set different crease angles to each surface 
> inside the same 
> object. That's why I have to break the object in pieces when 
> I want some 
> of it's surfaces to have different crease angles than others. 
> That's a 
> pain :-( I don't know if that's a limitation of the .ac file 
> format or 
> of AC3D editor. I wonder if you can suggest me a way to avoid this 
> limitation in AC3D.
> 
> I also think I could switch to other 3d file formats, any 
> suggestions? 
> What 3d file formats does FGFS support other than .AC? I'd prefer 
> working with plain ascii files if possible but I will consider other 
> more obscure ones if they provide more flexibility and fewer 
> limitations.
> 

You are quite right AC3D has crease angle set on a per-object basis, and
AFAIK, there is no way round this. I have not found it a limitation - it is
a transition value between crease and smooth. Like you, if there isn't a
convenient value I break the object. There's no penalty for that - numbers
of objects and groups have no performance penalty.

Vivian 


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[Vivian Meazza]

David

> Sent: 03 November 2007 19:19
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Fixing head lag
> 
> 
> On 03/11/2007, Vivian Meazza <[EMAIL PROTECTED]> wrote:
> 
> > As I said before, but perhaps you didn't notice, we already have a 
> > force based system working on the input of pilot g. It moves the 
> > pilot's eye position according to this input. And as 
> Melchior pointed 
> > out, we probably need to stabilise the point at which the 
> pilot looks 
> > to make this totally realistic.
> 
> Is there a way to enable it in general, without tying to a 
> specific aircraft model?
> 
> 

I'm afraid not - it's in all my models, but it has not been picked up as
something we want as a generic feature. It's only a moderate number of Nasal
lines of code. Wouldn't take much to do make it generic. I think would like
to tidy up the code first, but ...

Vivian 


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[Vivian Meazza]

David

> Sent: 03 November 2007 15:58
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Fixing head lag
> 
> 
> On 03/11/2007, Melchior FRANZ <[EMAIL PROTECTED]> wrote:
> 
> > I should do something similar for planes. Of course, this is still 
> > configurable per aircraft, too. Just not via properties, but by 
> > defining a Nasal handler. I'll review that.
> >
> > And again: I appreciate suggestions for improvements or 
> patches. Just 
> > not commits to that nasal file. You don't know how picky I am!  ;-)
> 
> Now that I understand what it's for (and the fact that it's 
> not enabled by default), I don't plan to touch it -- and as I 
> mentioned, it is a cool idea.  I would like to get some kind 
> of force-based head lag working, through.
> 
> 

As I said before, but perhaps you didn't notice, we already have a force
based system working on the input of pilot g. It moves the pilot's eye
position according to this input. And as Melchior pointed out, we probably
need to stabilise the point at which the pilot looks to make this totally
realistic.

Try the Hunter to see it in action (together with black/redout).

Vivian 


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fixing head lag

[Vivian Meazza]

David

> Sent: 03 November 2007 02:25
> To: FlightGear developers discussions
> Subject: [Flightgear-devel] Fixing head lag
> 
> 
> I think it's great that FlightGear added head lag to the sim 
> -- it's a good alternative when the pilot can't feel forces 
> -- but I think we'd do better to model it based on perceived 
> forces, not on roll/yaw/pitch damping. For example, simply 
> entering a coordinated bank gently shouldn't cause any head 
> movement at all, but flying straight in a forward slip 
> should, because there's a yaw force pulling the head slightly 
> sideways.  Likewise, while the pilot is perceiving < 1G the 
> head should move up a bit, and while the pilot is perceiving 
> > 1G, the head should move down a bit.
> 
> Would anyone object to my checking in some changes over the 
> next week or two to change this?  We can always roll them 
> back if they don't work.
> 
> 

As Melchior said, the head-shake mechanism does indeed regard the head as a
mass and a (damped) spring, but it's a bit more sophisticated than that -
the resistance of the neck muscles are modelled as well. (The distance moved
in various directions are measured from my own body strapped into a 4 point
harness - YMMV). I think that aspect is quite well simulated. The original
code was written by Josh Babcock, but the math was heavily modified by me.
The code structure could do with review and revision. I keep on meaning to
make this more sophisticated by stabilizing the eye viewpoint, but never got
around to it. While theoretically necessary, I'm not absolutely sure that
would improve the appearance of the simulation much.

Regards,

Vivian



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] frame rates...

[Vivian Meazza]

Syd&Sandy

> Sent: 27 October 2007 01:08
> To: flightgear-devel@lists.sourceforge.net
> Subject: [Flightgear-devel] frame rates...
> 
> 
> With a pending PLIB release come up 
> Would now be a good to push for setting (again) ...
> 
> 
>   30
> 
> 
> as default in the preference file ?
> 
> I picked 30 because I argee that anyrhing over 30 is a waste 
> ...unless bragging about computer speed, of course, :)... 
> It makes autopilot behavior and tuning much easier (for me at 
> least ) , and can be easily changed if a user doesn't like it ...

Hmm. That seems to make the stuttering worse here, even at 50hz. But perhaps
the interdependence of the autopilot and the frame rate needs fixing. 

> And , of course , I'm still hoping for a multiplayer 
> sim/model/texture property  putting that on my Xmas wish list :)

Yup, I'm with you on this one.

Regards

Vivian


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Unknown failure while Initializingsubsystems onwin32 and Fedora 7 x86_64

[Vivian Meazza]

Heiko

> Sent: 25 October 2007 23:01
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Unknown failure while 
> Initializingsubsystems onwin32 and Fedora 7 x86_64
> 
> 
> Hi,
> 
> I'm not sure but I'm think the problem is maybe in
> WinCVS. Today I noticed that the CH47 was not quite
> uploaded. The ac.model was missing though Syd had
> uploaded 3h before
> 
> Maybe I have to try the TortoiseCVS...
> 

... Snip ...

I have used both WinCVS and Tortoise for years, and the only problem has
been my finger trouble. Did you forget to use -d? Don't forget that you can
force Unix line endings by checking the appropriate box in WinCVS
preferences.

Vivian 


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Unknown failure while Initializingsubsystems on win32 and Fedora 7 x86_64

[Vivian Meazza]

Durk, 

> Sent: 26 October 2007 07:18
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Unknown failure while 
> Initializingsubsystems on win32 and Fedora 7 x86_64
> 
> 
> On Thursday 25 October 2007 21:39, Melchior FRANZ wrote:
> > * Durk Talsma -- Thursday 25 October 2007:
> > > Probably the best course of action is to send a friendly 
> reminder to 
> > > the plib list, and if it doesn't happen again, stick to plan B.
> >
> > Yes, but I won't do that. I did it on 2007/04/02, and the question 
> > remained unanswered. The last posting before that was two 
> and a half 
> > months earlier, and the next was two months later. There are nicer 
> > places to be ignored.
> 
> I'll ask. FWIW, I am also very skeptical that it will lead to 
> anything, as I'm 
> afraid plib is close to dying. Nevertheless, I'd like to ask, 
> as courtesy to 
> the well intended people over there (in particular John Fay, 
> who's put a lot 
> of effort into keeping plib going).
> 
> >
> > I'm a bit impatient with plib, and I think that integrating 
> the code 
> > into fgfs becomes more and more desirable. Which is also a 
> reason why 
> > I would like to have the fgfs code cleaned up w.r.t. to the 
> GUI parts. 
> > But I can commit my one year old patch right after the 
> release, too. 
> > It would just be a pity if people continued to use the broken plib 
> > version out of laziness (and because we don't force them to use the 
> > fixed one. :-)
> >
> IIRC, my plan B was something like, If plib manages to do a 
> new release before 
> we're ready for 0.9.11, we use that one. If not, we still use 
> 1.8.4, and give 
> them until the release of 0.9.12 (or whatever FG version 
> number is next). If 
> by then, we still haven't seen a new release, we fork our own 
> versions of the 
> relevant libraries.
> 
> Assuming we stick to the plan of releasing one more plib 
> version and then 
> switch over to OSG, how much of plib do we still depend upon? 
> The scene graph 
> and the audio lib are already replaced by OSG and openal, so 
> I guess it's 
> joystick code and pui? Anything else?
> 

The problem with this plan is that OSG is simply not fit for purpose, at
least not here. If you think the stuttering was a problem in plib, it's
twice the problem in osg. Yes, the animations are better implemented, and
the pick animation is particularly good, but frame rates are about 2/3rds
that of plib, and we still lack random objects, 3d clouds, shadows, and the
ordinary clouds aren't anything to write home about either. Even the
much-vaunted particles are broken if you look at them closely.

Of particular concern is that there has been no real progress for 12 months
now.

I'm sure we all know all of this, but perhaps it was worth restating.

Regards,

Vivian



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel