FlightGear - Flight Simulator

Hi all

I sent a small merge request to fgdata repo
http://gitorious.org/fg/fgdata/merge_requests/38

I was looking to the c172p directories and found some unused files and 
some wrong paths coming from last commit (?).

- effects in models had wrong paths, (re-?)created a folder Effects
- removed unused graphic files in top models directory
- changed some .rgb-graphic files to .png (-50 % data)

I did not change any of the graphics or any other code. It is just a 
small clean up and I checked the log well after this changes.

Feel free to merge in, or not.

Thanks, Yves

BTW. Meantime I am checking some other 'real' issues of c172p graphics. 
Can someone tell me why looking to the c172p from the left in helicopter 
or chase view decrease framerate about -15 fps and from the right 
nothing at all? Interesting.

Hi All,

I just committed a small patch to gitorious that allows the traffic manager to 
collect aircraft usage information for a given airport. The reason for this is 
the following: The traffic manager itself is a rather slow, low priority 
process, that updates positional information at a very slow rate. As a 
consequence. It may take a few seconds, up to a couple of minutes before all 
the traffic near one's current position has been initialized. The current 
patch collects aircraft usage information, such that one point is awarded to 
each aircraft that is found to be parked at the airport where the user's 
aircraft is located. When FlightGear is shut down, the collected statistics 
are saved into a cache file (currently a simple plain text file, but I'm open 
to other suggestions).

When flightgear is started a second time at the same airport, the already 
collected statistics are read, and the the aircraft with the highest point 
scores are loaded with priority.  During the next session, additional 
statistics are collected, and added to the existing ones, so that we get 
increasingly more effective loading times.

Admittedly, I only tested this feature only very briefly, but felt that the 
improvement in initialization was dramatic enough to outweigh possible 
problems. If you do run into anything, please a) let me know, so that I can 
fix it ASAP, and b) run flightgear by using the --prop:/sim/traffic-
manager/heuristics=0 command line option. 

Cheers,
Durk

jean pellotier wrote:

 
> currently we can only refuel by mp behing a "MOBIL" plane, with a plane
> having the "multiplay/tanker" set.
> 
> here's a proposal that permit to use any callsign (yes i know in this
> case the tanker will not have a tacan working), and any plane,  for
> exemple the tanker pilot can cut the probe/drogue alimentation, or with
> adding a refueling pod any plane can become a tanker ....
> 
> if a c++ guru can have a look and commit (any comment welcome, my c++
> skills are just at a beguinner state).
> 
> the victor is waiting for this (or something similar), with a refuelling
> available by mp only when the drogue is out .
> 

It is already the case that any aircraft can become a tanker simply by using
a callsign starting "MOBIL".

I'm not quite sure what you want here. Would I be correct in saying that you
want to be able to switch the tanker status on and off over MP? If so - I
think that is a good idea, and one that was intended from the outset, but
never got implemented. (I cant remember why - I think it just got lost).

If so I'll get on the case.

Vivian

Hello Woods

I tried to change tree textures setting in materials.xml. When I change 
a tree texture nothing happens. SG/FG takes always the same texture 
(almost, see below). I deleted the <tree-texture> tag and it takes still 
the same old standard texture (mixed-summer.png).

When I delete all tree-per material there are no trees and no textures 
of course. When I set only a tag wood-coverage it shows mixed-summer 
again. Is mixed-summer the default texture at all?

Now when I delete all the files in Textures/Trees and 
Textures.high/Trees except of mixed-summer.png I see trees on most 
terrain and on some terrain I see white squares.

Hey, this is to much for me. Can someone help? (I apologize in advance 
if this is a known issue and tree code is not finished yet, I couldn’t 
find any postings about.)

Thanks, Yves

Frederic Bouvier wrote:

> 13. Get the data from Gitorious too : git clone git://gitorious.org/fg/fgdata.git fgdata

Or, to those who think the forementioned service responds too slowly:

  git clone git://mapserver.flightgear.org/fgdata/

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

I forgot :
 13. Get the data from Gitorious too : git clone git://gitorious.org/fg/fgdata.git fgdata

----- "Jon S. Berndt" <jonsberndt@...> a écrit :

> The cygwin git worked as expected. :-)
> 
> I don't have previous experience with git. What is the git command to
> get the base packed? Or, is there a page that explains the git
> packages somewhere? Thanks - and again, I was pleasantly surpised by
> how well the process went. It was a big help.
> 
> Jon
> 
> 
> -----Original Message-----
> From: Frederic Bouvier <fredfgfs01@...>
> Sent: Sunday, August 29, 2010 9:50 AM
> To: FlightGear developers discussions
> <flightgear-devel@...>
> Subject: Re: [Flightgear-devel] Building FlightGear under Vista
> 
> 
> ----- "Jon S. Berndt" a écrit :
> 
> > > Also, what's the best way to get the base package? From the
> > FlightGear
> > > page?
> > > Is there a git checkout for that, as well?
> > >
> > > Jon
> >
> >
> > Speaking of git, you might mention in your install procedure that
> for
> > those developers who are using Cygwin, they can install git using
> the cygwin
> > setup process at cygwin.com. Then they can use git from the command
> line.
> > The msysGit install is not required, then.
> 
> I don't have an experience with cygwin git. I found that I have best
> results with
> autoctrl=false (see git-config) using msysGit with the base package.
> Otherwise I
> have often unexplained file changes that I can't cancel with
> git-checkout.
> 
> -Fred
> 
> --
> Frédéric Bouvier
> http://my.fotolia.com/frfoto/              Photo gallery - album photo
> http://www.youtube.com/user/fgfred64       Videos
> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook
> users
> worldwide. Take advantage of special opportunities to increase revenue
> and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook
> users
> worldwide. Take advantage of special opportunities to increase revenue
> and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/              Photo gallery - album photo
http://www.youtube.com/user/fgfred64       Videos

The cygwin git worked as expected. :-)

I don't have previous experience with git. What is the git command to get the base packed? Or, is there a page that explains the git packages somewhere? Thanks - and again, I was pleasantly surpised by how well the process went. It was a big help.

Jon


-----Original Message-----
From: Frederic Bouvier <fredfgfs01@...>
Sent: Sunday, August 29, 2010 9:50 AM
To: FlightGear developers discussions <flightgear-devel@...>
Subject: Re: [Flightgear-devel] Building FlightGear under Vista


----- "Jon S. Berndt" a écrit :

> > Also, what's the best way to get the base package? From the
> FlightGear
> > page?
> > Is there a git checkout for that, as well?
> > 
> > Jon
> 
> 
> Speaking of git, you might mention in your install procedure that for
> those developers who are using Cygwin, they can install git using the cygwin
> setup process at cygwin.com. Then they can use git from the command line.
> The msysGit install is not required, then.

I don't have an experience with cygwin git. I found that I have best results with
autoctrl=false (see git-config) using msysGit with the base package. Otherwise I 
have often unexplained file changes that I can't cancel with git-checkout.

-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/              Photo gallery - album photo
http://www.youtube.com/user/fgfred64       Videos


------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@...
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

> I updated this document recently :
> http://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC
> 
> I tested the described procedure in a blank virtual machine, so you
> have good chances to succeed ;-) All the prerequisites are available
> already compiled from the provided links
> 
> Anyway, VS2010 is too early for OSG, so stay with 2008 for the moment.
> 
> Regards,
> -Fred

This is a great process, and I ended up with an executable. However, it won't run by double-clicking on the application icon because it can't find OSG. I think I know what this is about. The OSG libraries are part of the 3rd party zip file I downloaded, right? But, I didn't see anything about how/where to install those files. What do I do with those, so that the .exe sees the libraries/dlls?

Thanks,

Jon

Hi Jon,

----- "Jon S. Berndt" a écrit :

> > I updated this document recently :
> > http://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC
> > 
> > I tested the described procedure in a blank virtual machine, so you
> > have good chances to succeed ;-) All the prerequisites are
> available
> > already compiled from the provided links
> > 
> > Anyway, VS2010 is too early for OSG, so stay with 2008 for the
> moment.
> > 
> > Regards,
> > -Fred
> 
> This is a great process, and I ended up with an executable. However,
> it won't run by double-clicking on the application icon because it
> can't find OSG. I think I know what this is about. The OSG libraries
> are part of the 3rd party zip file I downloaded, right? But, I didn't
> see anything about how/where to install those files. What do I do with
> those, so that the .exe sees the libraries/dlls?

Procedure above has been updated. Changes are :

--- a/docs-mini/README.MSVC
+++ b/docs-mini/README.MSVC
@@ -84,11 +84,15 @@ Typical setup should decompose into the following steps :
  11. Save file as version.h in the same directory
  12. Start build (usually F7)
  13. Wait...
- 14. Enjoy - programs are in D:\FGFSDevel\FlightGear\projects\VC90\Win32\Release
+ 14. Add <any_directory_on_any_drive>/install/msvc90/OpenSceneGraph/bin and <any_directory_on_any_drive>/3rdParty/bin to your PATH environ
+ 15. Enjoy - programs are in D:\FGFSDevel\FlightGear\projects\VC90\Win32\Release

 It is also possible to compile a Debug version. This is only useful when hacking the code because
 a Debug version is way slower than the Release one.

+The 64bit build is only available to people having the Professional edition of Visual Studio 2008. In that case, 14. above should be :
+ 14. Add <any_directory_on_any_drive>/install/msvc90-64/OpenSceneGraph/bin and <any_directory_on_any_drive>/3rdParty.x64/bin to your PATH 
+
 When the manual build works, it is possible to start it from the command line. This is useful
 when setting up a build server or automating the process of retrieving the code and building
 it in a scheduled task. To do that :

------
So What you have to do now is to update your User or System PATH variable and add <any_directory_on_any_drive>/install/msvc90/OpenSceneGraph/bin and <any_directory_on_any_drive>/3rdParty/bin to it.

Regards,
-Fred

-- 
Frédéric Bouvier
http://my.fotolia.com/frfoto/              Photo gallery - album photo
http://www.youtube.com/user/fgfred64       Videos

Hi All,

Thanks to the combination of vacation and a record amount of rainfall in the 
last four days, I've been able to rework a major section of the AI traffic 
code. One of the weakest aspects of the AI traffic system was that aircraft 
never performed a reasonable approach, but basically just plummeted out of the 
skies, only to pretend making a reasonable landing (and usually ending up 
several miles short of the runway).

The new code generates a more realistic approach path, and ensures that 
arrivals will start almost instantly after program start. The approach paths 
are set up in such a way that aircraft will be lined up with 90 seconds of 
flight time (or more) between them. This is done by using small changes in 
length of the final approach path, combined with an approach controller / 
pilot that commands small changes in descent speed, to ensure that each 
aircraft will arrive at the final approach fix at the slotted time. 

Note that there are still a few issues remaining, but I'm planning to fix 
those later (most notably, there's still a rather sharp drop onto the runway 
at the end of the landing phase, but I'll work on that later. 

I'm planning to push this onto gitorious towards late afternoon / early 
evening today. I'd like to let it run for a few more hours, and still need to 
remove a couple of dozens of debug messages, but other than that, I think that 
the code is ready for more general testing. 

Please let me know if you find any issues (once committed). I'm currently 
having vacation, so I should be able to address any issues withing reasonable 
time.

Cheers,
Durk

Hi Roberto,

Thanks for the reply and the suggestions.  I'm very nervous about giving
myself a threading waver too! :-)

I am leaning towards an independent process/app to handle just the serial
comms and exchange that will communicate via some IPC mechanism with my main
application.

There are some messy aspects no matter how I proceed.

- If I leave things as is, I have to live with some long program pauses and
because this is a real time sensing and control application, that leads to
some less than optimal results at time.  On the plus side I keep a straight
linear application that is easy to understand and maintain.

- If I go with a threaded solution I maintain potential portability to
embedded systems that are not unix based and perhaps only support a single
process (with multiple threads.)  But of course all the pitfalls of threads
and long term maintainability apply.  And there are many misunderstandings
of threads and what they can do.  I've seen times that a thread blocking on
IO can block the entire application anyway.  Certainly a thread that crashes
or executes a bad instruction will kill the entire application.

- If I go with a separate application, I push myself towards linux based
systems only, or systems with advanced kernels that support multiple
concurrent processes.  There are also so possible messy startup issues to
think through (I have to start multiple processes rather than a single
process, although one process could launch the other I suppose.)

I also have to decide what IPC mechanism to use ... I like the idea of using
sockets, partially due to existing available socket communication mechanisms
already built into my code and it fits the FIFO nature of my task pretty
well.  I spew data packets out and I don't care if random packets are
dropped or corrupted (as long as an appropriate amount get through for the
bandwidth of my serial link.)  And the return data is infrequent "commands"
which might be more appropriate as a stream socket connection (which I
already have support for in my code.)

Best regards,

Curt.


On Sat, Aug 28, 2010 at 7:23 AM, Roberto Waltman <fsim@...> wrote:

> Curtis Olson wrote:
>  > This is a little off topic, but I don't know where else I can find a
>  > stronger knowledge pool. :-)
>  >
>  > I am working on some code that needs to read and write from a serial
>  > port and has to write vast quantities of data ...
>
> Curtis,
>
> I wouldn't use threads, but a whole separated process.
> Use circular buffers in shared memory to transfer data, and semaphores
> to coordinate data transfers in/from these buffers.
> That way your main process only needs to do non-blocking memory to
> memory transfers.
> The serial coms process can handle all the quirks of the protocol,
> create separate Tx and Rx threads if necessary, decide when to drop
> data, block itself when needed etc.
> One of the advantages of using a separate process vs threads in the main
> application is fault isolation. (1)
> The unavoidable crashes during development may bring down only this
> process, allowing you to continue by restarting only this part and not
> the whole application.
> The same applies if you want to try a different version. Stop the
> subprocess, start a new one.
>
> Hope this helps,
>
> Roberto Waltman.
>
> (1) I worked for a company whose coding standards required a manager's
> waiver to use threads, because of the difficulties of debugging complex
> multi-thread applications where every thread can corrupt global data.
> And the fault isolation.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



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