RE: [Flightgear-devel] Reasonable vertex count for ground static?

2004-12-20 Thread Innis Cunningham
Hi Dave
 Dave Martin writes
I've made the model look near to the normal model in quality unless you go
right up and look closely (interior textures, controls etc are gone) The
seats are still in but I've cropped a lot of vertices from the fusealage 
and
wings and re-orientated the model nose-up to simulate an empty cabin. (I 
made
some 'line' tie-downs too just for show.

The vertex count is down from near 1800 to 1200 and the number of 512x512
textures is halved.
The static 747 and 737 at KSFO are 1100 and 400 vertices respectivley.So 
that
may give you an idea how complex you think the 172 should be.
Dave Martin
Cheers
Innis

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Frederic Bouvier
Drew wrote :
I'm getting the following errors (most of them several times)
Cannot open include files:
FL/Fl.h
FL/Fl_File_Chooser.h
 

FLTK 1.1.x, only needed to build fgadmin. Remove the project from the 
solution if you don't want to build it

GL/glut.h
 

GLUT, mandatory
plib/ssg.h
sg.h
 

PLIB, mandatory
Cannot open source files:
.\majik_demo.cxx
 

PLIB demo, optional
.\simgear\scene\sky\clouds3d\camdisplay.cpp
.\src\AIModel\AICarrier.cxx
.\src\AIModel\submodel.cxx
.\src\Cockpit\hud_rwy.cxx
.\src\Fdm\groundcache.cxx
.\src\fdm\sp\ACMS.cxx
.\src\fdm\sp\ADA.cxx
.\src\Instrumentation\encoder.cxx
.\src\Instrumentation\kr_87.cxx
.\src\Instrumentation\kt_70.cxx
.\src\Instrumentation\marker_beacon.cxx
.\src\Instrumentation\navradio.cxx
.\src\Instrumentation\transponder.cxx
.\src\Network\ATC-Inputs.cxx
 

New, CVS only, ( or wait 0.9.8 ), files - remove them from the solution 
if you really want to compile 0.9.6

.\ssgLoadASC.cxx
.\ssgSaveIV.cxx
 

CVS plib files. same as above
.\tux_example.cxx
 

Plib demo, optional
There are a bunch of warnings as well, but I won't worry about them yet.
 

-Fred

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] C172P Model Year?

2004-12-20 Thread Jon Berndt
> Hmm, I thought I already had, but it seems I'm mistaken.  It's in the
> LaRCsim code (IO360.cxx), but never made it over to JSBSim's FGPiston.cpp.
> I believe I was gunning for about 25 rpm drop on one vs. two magnetos in
> the original code.  I'll port it over...
>

Dave:

There are two active branches, now: the main branch and JSBSim_NEW_XML (IIRC). 
If the
changes are small, let me know what they are and I can copy it to the new XML 
branch
unless you want to do that, too. The engine execution code has not changed 
much, if at
all. Only the loading code.

Jon


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] C172P Model Year?

2004-12-20 Thread David Luff


On 12/20/04 at 11:41 PM David Luff wrote:
>Of course, oversights like this would get picked up more easily if an
adept
>3D modeller added a magneto switch to the 3d C172 

Oops, found it, bottom left!

and pa28-161 :-)  

It is missing from that though.

Cheers - Dave




This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Reasonable vertex count for ground static?

2004-12-20 Thread Dave Martin
I've just had a crown fitted to my tooth and I'm a bit off-song so I decided 
to make a 'rip-down' version of the C172P that I was working on for 
ground-static (pure scenery display).

I've made the model look near to the normal model in quality unless you go 
right up and look closely (interior textures, controls etc are gone) The 
seats are still in but I've cropped a lot of vertices from the fusealage and 
wings and re-orientated the model nose-up to simulate an empty cabin. (I made 
some 'line' tie-downs too just for show.

The vertex count is down from near 1800 to 1200 and the number of 512x512 
textures is halved.

Is this low enough to be reasonable as a ground-static aircraft? (I have a 
behemoth of a gpu that loves vertices so I'm not much use as a tester).

Can anyone up to speed which scenery placement who could have a go with 
placing a few duplicates of the model and then taxying past a few times to 
gauge whether the frame-rate takes a big hit?

Thanks

Dave Martin

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] C172P Model Year?

2004-12-20 Thread David Luff


On 12/18/04 at 7:15 PM Dave Martin wrote:

>While you're there, is there any chance of a magneto-related performance
>loss?
>
>ie: when you run left mags only you get a power loss.
>
>Cheers :)
>

Hmm, I thought I already had, but it seems I'm mistaken.  It's in the
LaRCsim code (IO360.cxx), but never made it over to JSBSim's FGPiston.cpp.
I believe I was gunning for about 25 rpm drop on one vs. two magnetos in
the original code.  I'll port it over...

Of course, oversights like this would get picked up more easily if an adept
3D modeller added a magneto switch to the 3d C172 and pa28-161 :-)  A
master-on switch would be great as well :-))

Cheers - Dave


This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Drew
I'm getting the following errors (most of them several times)

Cannot open include files:

FL/Fl.h
FL/Fl_File_Chooser.h
GL/glut.h
plib/ssg.h
sg.h

Cannot open source files:

.\majik_demo.cxx
.\simgear\scene\sky\clouds3d\camdisplay.cpp
.\src\AIModel\AICarrier.cxx
.\src\AIModel\submodel.cxx
.\src\Cockpit\hud_rwy.cxx
.\src\Fdm\groundcache.cxx
.\src\fdm\sp\ACMS.cxx
.\src\fdm\sp\ADA.cxx
.\src\Instrumentation\encoder.cxx
.\src\Instrumentation\kr_87.cxx
.\src\Instrumentation\kt_70.cxx
.\src\Instrumentation\marker_beacon.cxx
.\src\Instrumentation\navradio.cxx
.\src\Instrumentation\transponder.cxx
.\src\Network\ATC-Inputs.cxx
.\ssgLoadASC.cxx
.\ssgSaveIV.cxx
.\tux_example.cxx

There are a bunch of warnings as well, but I won't worry about them yet.

Drew


On Mon, 20 Dec 2004 23:02:58 +0100, Frederic Bouvier <[EMAIL PROTECTED]> wrote:
> Drew a écrit :
> 
> >I haven't overwritten any files...I'm just trying to understand what
> >goes where.  I have a directory structure called
> >FG-ProjectFiles-msvc71, which does not contain the FlightGear source.
> >I have another directory, which I downloaded separately, called
> >Flightgear-0.9.6.  Where do I put it?  Should I have a directory as
> >follows?
> >
> >FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6
> >
> >
> my layout is (I have a drive named I: ) :
> 
> I:\FlightGear\cvs\FlightGear
> I:\FlightGear\cvs\FlightGear\src
> I:\FlightGear\cvs\FlightGear\src\Main
> ...
> 
> The path of the files located in the project files should have helped you.
> 
> >Or do I need to do something different?  There are no instructions.
> >FlightGear/cvs/FlightGear <= FlightGear  isn't explicit to me.
> >
> >
> the directory 'cvs' could imply that the projects are for the cvs
> version. If you want to use them for the 0.9.6 version, you would have
> to adapt it because few files were added, other removed and some moved.
> 
> The file to load is the solution file, named FlightGear-2.sln, .vcproj
> files are the project files and hold path to source files and compile
> options. They are xml files.
> 
> -Fred
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Frederic Bouvier
Drew a écrit :
I haven't overwritten any files...I'm just trying to understand what
goes where.  I have a directory structure called
FG-ProjectFiles-msvc71, which does not contain the FlightGear source. 
I have another directory, which I downloaded separately, called
Flightgear-0.9.6.  Where do I put it?  Should I have a directory as
follows?

FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6
 

my layout is (I have a drive named I: ) :
I:\FlightGear\cvs\FlightGear
I:\FlightGear\cvs\FlightGear\src
I:\FlightGear\cvs\FlightGear\src\Main
...
The path of the files located in the project files should have helped you.
Or do I need to do something different?  There are no instructions. 
FlightGear/cvs/FlightGear <= FlightGear  isn't explicit to me.
 

the directory 'cvs' could imply that the projects are for the cvs 
version. If you want to use them for the 0.9.6 version, you would have 
to adapt it because few files were added, other removed and some moved.

The file to load is the solution file, named FlightGear-2.sln, .vcproj 
files are the project files and hold path to source files and compile 
options. They are xml files.

-Fred

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Jorge Van Hemelryck
On Mon, 20 Dec 2004 13:04:47 -0600
Curtis L. Olson wrote:


> That certainly sounds doable, although the particular details of how to 
> launch, and kill, and detect if the child process is running will 
> probably vary wildly from platform to platform.

The only OS where I could do it would be Linux (I have done some
programming on Windows in the past, but not enough to be able to do
that). I thought that the way to do this would be the same on UNIX-like
systems, and that it would differ only on Windows...

Here are the ways of launching the simulator and the "FlightGear
Control" app I can think of:

1- the Control app launches and communicates with FlightGear, the latter
being for instance a child process (or fgrun could be extended to
communicate with FlightGear in this way)

2- FlightGear is launched at the same time as the Control app

3- FlightGear and the Control app can be run independently

With option 1, there are issues such as how to ensure that when FlightGear
exits, the Control app reverts to a launcher app. 

Does option 2 mean that they have to be launched at the same time ?
Could we benefit from this ? 

What is already clear is that FlightGear should not depend on this
Control app. It must be possible to run FlightGear from the command-line
without anything else. That is why I would be in favor of option 3.

Here is what is already possible with what we presently have. The
FlightGear telnet protocol allows an external program to get and set
properties. This already allows for environment / position / time /
radio / gps / view settings, to name a few.

The current gui (menubar) can do more than that, and in the future it
would probably a good thing to use the same API, in order for instance
to be able to launch a nasal command from the Control app.

As we said before, the main problem would be to change aircraft (and
therefore reinit FDM, 3D model, systems) without restarting FG. I'll try
and have a look at the initialization code as soon as I find some time.

-- 
Jorge Van Hemelryck


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Adam Dershowitz
I realize that.  I just meant that the more the source code forks into
different applications the harder it will be to keep it all working across
platforms.  Each person who is working on their own particular app. Will
make sure that it works on their own platform.  While if there is one
"FlightGear" app.  Then there is a joint effort, with each change in source,
to get it to work across many platforms.

-- Adam




> From: Martin Spott <[EMAIL PROTECTED]>
> Organization: home
> Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]>
> Newsgroups: list.flightgear-devel
> Date: Mon, 20 Dec 2004 20:34:15 + (UTC)
> To: <[EMAIL PROTECTED]>
> Subject: Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
> 
> Adam Dershowitz wrote:
> 
>> But cross platform support gets more difficult.  This is somewhat
>> demonstrated by the issues that someone is having right now getting fgrun to
>> compile and build.
> 
> Well, David Luff has proven that cross-platform-portability is not a
> miracle, his "TaxiDraw" compiles at least on Windows and five different
> Unices just with some small Makefile changes   allthough he didn't
> tell us how much effort he had to spend in order to achieve this
> portability  ;-)
> 
> Cheers,
> Martin.
> -- 
>  Unix _IS_ user friendly - it's just selective about who its friends are !
> --
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] UI (was no subject)

2004-12-20 Thread Alex Perry
I think the existing external telnet access is an excellent feature.
It would be nice to put some effort into making the underlying code
more efficient so that the simulator doesn't mind it being used a lot.

On a separate note, I propose the following feature (if not present):
1.  A command on the telnet interface for adding menu items to the PUI.
2.  When the associated telnet session closes, the menu items disappear.
3.  A telnet command to put up a PUI dialog and return the results.

We could create a python class that uses the existing telnet module
and makes the menu item addition and PUI dialog invocation accessible.
A separate class can offer the same services but use a GTK backend.

That would let us all write nice features as python scripts which,
for single user, attach to the main FlightGear PUI interface or,
for training use, interact directly with the instructor's console.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Martin Spott
Adam Dershowitz wrote:

> But cross platform support gets more difficult.  This is somewhat
> demonstrated by the issues that someone is having right now getting fgrun to
> compile and build.

Well, David Luff has proven that cross-platform-portability is not a
miracle, his "TaxiDraw" compiles at least on Windows and five different
Unices just with some small Makefile changes   allthough he didn't
tell us how much effort he had to spend in order to achieve this
portability  ;-)

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

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Drew
I haven't overwritten any files...I'm just trying to understand what
goes where.  I have a directory structure called
FG-ProjectFiles-msvc71, which does not contain the FlightGear source. 
I have another directory, which I downloaded separately, called
Flightgear-0.9.6.  Where do I put it?  Should I have a directory as
follows?

FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear\FlightGear-0.9.6

Or do I need to do something different?  There are no instructions. 
FlightGear/cvs/FlightGear <= FlightGear  isn't explicit to me.

Thanks,
Drew


On Mon, 20 Dec 2004 21:15:44 +0100, Frederic Bouvier <[EMAIL PROTECTED]> wrote:
> Andy messier wrote :
> 
> >Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1).  Now,
> >when I download the FlightGear source, should I REPLACE the
> >FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the
> >source, or put the source inside this directory?  Same with SimGear
> >and plib?  I can't find any instructions among those project files.
> >
> >
> I would be you, I wouldn't overwrite the files I've just downloaded, but
> I guess you would not find the project files in the official
> distribution, so it is really up to you.
> 
> >Also, which file should I open in VisualStudio to build the source?
> >Sorry for the basic questions...I'm new to Visual Studio.
> >
> >
> You should read this one :
> http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032478.html
> 
> -Fred
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Frederic Bouvier
Andy messier wrote :
Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1).  Now,
when I download the FlightGear source, should I REPLACE the
FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the
source, or put the source inside this directory?  Same with SimGear
and plib?  I can't find any instructions among those project files.
 

I would be you, I wouldn't overwrite the files I've just downloaded, but 
I guess you would not find the project files in the official 
distribution, so it is really up to you.

Also, which file should I open in VisualStudio to build the source? 
Sorry for the basic questions...I'm new to Visual Studio.
 

You should read this one :
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032478.html
-Fred

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Andy messier
Ok, I downloaded FG-ProjectFiles-msvc71 (I have version 7.1).  Now,
when I download the FlightGear source, should I REPLACE the
FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear directory with the
source, or put the source inside this directory?  Same with SimGear
and plib?  I can't find any instructions among those project files.

Also, which file should I open in VisualStudio to build the source? 
Sorry for the basic questions...I'm new to Visual Studio.

Thanks,
Drew


On Mon, 20 Dec 2004 20:17:40 +0100, Frederic Bouvier <[EMAIL PROTECTED]> wrote:
> Frederic Bouvier a écrit :
> 
> > Andy messier wrote :
> >
> >> Hey All,
> >>
> >> Are there step-by-step instructions on how to build the FlightGear
> >> source using Visual Studio?  I've been fighting with this build all
> >> weekend, and am getting nowhere.  I finally got all of the libraries
> >> and headers in the right places, and now it returns thousands of
> >> "invalid external symbol" errors.  Are the Microsoft build files in
> >> there legit, or is this just someone's wishful thinking?
> >>
> >>
> > It has been discussed very recently :
> >
> > http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470
> >
> 
> see also :
> 
> http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32556
> http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32570
> http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32600
> 
> -Fred
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Frederic Bouvier
Frederic Bouvier a écrit :
Andy messier wrote :
Hey All,
Are there step-by-step instructions on how to build the FlightGear
source using Visual Studio?  I've been fighting with this build all
weekend, and am getting nowhere.  I finally got all of the libraries
and headers in the right places, and now it returns thousands of
"invalid external symbol" errors.  Are the Microsoft build files in
there legit, or is this just someone's wishful thinking?
 

It has been discussed very recently :
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470 

see also :
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32556
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32570
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32600
-Fred

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Frederic Bouvier
Andy messier wrote :
Hey All,
Are there step-by-step instructions on how to build the FlightGear
source using Visual Studio?  I've been fighting with this build all
weekend, and am getting nowhere.  I finally got all of the libraries
and headers in the right places, and now it returns thousands of
"invalid external symbol" errors.  Are the Microsoft build files in
there legit, or is this just someone's wishful thinking?
 

It has been discussed very recently :
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/thread.html#32470
-Fred

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Curtis L. Olson
Paul Surgeon wrote:
It still needs a bit of work though.
One cannot change the aircraft or location at the moment through an external 
app.
 

You can't change aircraft through the internal or external gui right 
now.  You can change position just fine, as well as setup things like 7 
mile final, on a 3 deg. glideslope, at 90 kts.

I also noticed that connections have a direction associated (in/out).
To have a bi-directional connection does one have to use two seperate 
connections?
 

No, not with the "telnet" interface.
Also is the hz parameter required? Isn't it event driven?
Polling is evil!  ;-)
 

I've seen some event driven gui/socket code that was (of all things) 
written in MSVC.  There are plenty of messes already in FG so that's one 
direction I'd really rather not go.

The way I see it is we can have a GUI that the user launches that in turn 
loads FG in the background. Similar to fgrun but with a live connection like 
the flight instructor type setup.
When the user is done configuring aircraft, weather, etc  they press a "SYNC" 
or "FLY" button and the changes are sent to FG and FG is told to pop up 
(brought to the foreground).
 

That certainly sounds doable, although the particular details of how to 
launch, and kill, and detect if the child process is running will 
probably vary wildly from platform to platform.

Regards,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Compiling with Visual Studio 2003.net

2004-12-20 Thread Andy messier
Hey All,

Are there step-by-step instructions on how to build the FlightGear
source using Visual Studio?  I've been fighting with this build all
weekend, and am getting nowhere.  I finally got all of the libraries
and headers in the right places, and now it returns thousands of
"invalid external symbol" errors.  Are the Microsoft build files in
there legit, or is this just someone's wishful thinking?

Thanks,
Drew

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Not safe let loose with ac3d :-)

2004-12-20 Thread Dave Martin
Just had a go at my first building.

Its a (not too accurate) rendition of the tower at Wellesbourne Mountford 
(EGBW)

The tower consists of 2 container units stacked on top of each other and a 
glass house.

My go: http://www.cyfinity.com/fgfs/welltower.jpg
http://www.cyfinity.com/fgfs/welltower2.jpg

The real thing: http://www.wellesbourneairfield.com/tower001.jpg

Yes, I know its on a runway in America right now (I loaded it the 'quick' way) 
and yes, I did take it for a little flight ;-)


While being a commercial package, ac3d should make it quite easy to produce 
reasonably good building for specific locations en-mass. :-)

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Paul Surgeon
On Monday, 20 December 2004 14:08, Curtis L. Olson wrote:
> For what it's worth, I think that some sort of minimal built in gui for
> FG is still a good idea.  FG already provides a lot of support for
> developing an external gui

It still needs a bit of work though.
One cannot change the aircraft or location at the moment through an external 
app.
I also noticed that connections have a direction associated (in/out).
To have a bi-directional connection does one have to use two seperate 
connections?
Also is the hz parameter required? Isn't it event driven?
Polling is evil!  ;-)

> The only issue is that for single PC, home users who aren't immensely
> computer savey, starting up multiple apps concurrently can be a bit
> tricky ... especially in a multiplatform / portable context.

The way I see it is we can have a GUI that the user launches that in turn 
loads FG in the background. Similar to fgrun but with a live connection like 
the flight instructor type setup.
When the user is done configuring aircraft, weather, etc  they press a "SYNC" 
or "FLY" button and the changes are sent to FG and FG is told to pop up 
(brought to the foreground).

Paul

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Curtis L. Olson
Thomas Förster wrote:
Is there documentation on this (writing external UI's) somewhere?
 

Thomas,
There's no specific documentation, but what I did was leverage the 
"telnet" interface which gives you a convenient way to interact with the 
FG property system.  It's relatively "low bandwith" but that's generally 
fine for a gui.  The "telnet" interface also provides some higher level 
"commands" which are convenient for remotely controlling the app.  It's 
an approach that works quite well (at least on linux.)  I have control 
over the machine so I can set all the various apps to startup the way I 
like and can have complete control.  I'd shudder to try to roll multiple 
concurrent apps into a user release though because it's a fragile house 
of cards.  I can get it setup on my own system, but any little change or 
difference can bring the whole thing crashing down, and for users that 
don't understand how it all goes together, they may not be able to 
easily modify the scripts to make it all work.

But if we can work through the 
management/distribution/platform/usability issues, I think it would be a 
great thing to have.  You can do so much more, so much more easily with 
a real gui tool kit than you can do in pui.

Regards,
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt 
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Adam Dershowitz


> From: "Curtis L. Olson" <[EMAIL PROTECTED]>
> Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]>
> Date: Mon, 20 Dec 2004 06:08:51 -0600
> To: FlightGear developers discussions <[EMAIL PROTECTED]>
> Subject: Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
> 
> Jon Stockill wrote:
> 
>> Thomas Förster wrote:
>> 
>>> I also thought about this as an option for a GUI. The main advantage
>>> would be that this approach ensures there's no GUI code in FG and
>>> there is a well designed API/Protocol to it. Writing alternative
>>> GUI's should be easy using that API/Protocol. Having the GUI
>>> seperated also makes it easy to distribute the apps across machines,
>>> i.e. having a simulator with an instructors workplace (changing
>>> weather, fail engines...)
>> 
>> 
>> With the added advantage of not bloating the simulator - gets my vote.
>> 
> 
> For what it's worth, I think that some sort of minimal built in gui for
> FG is still a good idea.  FG already provides a lot of support for
> developing an external gui (i.e. for an operator/instructor station.)
> I have done exactly this for the ATC flight sim single engine trainer
> and it works quite well.
> 
> The only issue is that for single PC, home users who aren't immensely
> computer savey, starting up multiple apps concurrently can be a bit
> tricky ... especially in a multiplatform / portable context.
> 
> Curt.
> 
> -- 
> Curtis Olsonhttp://www.flightgear.org/~curt
> HumanFIRST Program  http://www.humanfirst.umn.edu/
> FlightGear Project  http://www.flightgear.org
> Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
> 
> 
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d

But cross platform support gets more difficult.  This is somewhat
demonstrated by the issues that someone is having right now getting fgrun to
compile and build.  By keeping a single application there is a bunch of
support, and a bunch of drive to keep the code base working across
platforms.  If the code splits into a bunch of different applications then
people are needed to build/test/support each separate app. on each platform.
In theory that should not be that hard, but in reality, I believe, no one
has yet built fgrun for the Mac...

--Adam



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Ann: blender source for aircraft models

2004-12-20 Thread David Megginson
Since there are so many talented 3D modellers around the project now,
I've put online the Blender source for the mostly crude 3D models I've
developed.  Note that this is not, yet, a permanent location; I'll
think of a better URL later, or better yet, we'll set up a directory
on the main FlightGear site for 3D model source files.

  http://www.megginson.com/Private/Models/

All of these models are hereby released into the Public Domain.  Note
that these are undocumented, raw directory dumps, not nicely packaged
distributions.  You'll almost certainly have to fix the texture paths,
if nothing else.


All the best,


David

-- 
http://www.megginson.com/

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] My 172P work for appraisal

2004-12-20 Thread Dave Martin
On Monday 20 Dec 2004 09:58, Martin Spott wrote:
> Dave Martin wrote:
> > Here we are: (screenshots)
>
> Well, after looking at the first shot:
> > http://www.cyfinity.com/fgfs/c172p1.jpg
>
>  I thought: Oh, how nice, someone added a C150 to the hangar, but
>
> after looking at the last one:
> > http://www.cyfinity.com/fgfs/c172p7.jpg
>
>  I am pretty much pleased  ;-)
>
> Thanks,
>   Martin.

As it happens I'd quite like to make a 150/152 model from scratch as a fairly 
high-poly example which would be 'comfortably' realistic.

However, I'm watching the development of the PA28-161 for now so I can get 
some tips on setting up 3d panels etc.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Software Patents.

2004-12-20 Thread Martin Spott
Dave Martin wrote:
> I am led to understand that the EU Parliament can only vote down elements of 
> the proposal at the second hearing if this is allowed at the Fisheries 
> commission meeting - is this correct.

Hmmm, I wouldn't bet on this but my understanding is that parliament
can vote against the directive as a whole,

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

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Software Patents.

2004-12-20 Thread Dave Martin
I am led to understand that the EU Parliament can only vote down elements of 
the proposal at the second hearing if this is allowed at the Fisheries 
commission meeting - is this correct.

It is pleasing to see that there are already over 1,700 signatories to the 
support wiki. When I signed late last night there were only 31.

On Monday 20 Dec 2004 15:18, Martin Spott wrote:
> Dave Martin wrote:
> > Many of you are probably aware that the EU Council is trying to press
> > through a draconian directive on EU software patents on Tuesday during a
> > meeting of the Agriculture and Fisheries commision of all things.
>
> It's good to mention this topic - fortunately we still have yet another
> chance when the directive has to pass the European parliament in the
> second reading,
>
> Martin.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Software Patents.

2004-12-20 Thread Martin Spott
Dave Martin wrote:
> Many of you are probably aware that the EU Council is trying to press through 
> a draconian directive on EU software patents on Tuesday during a meeting of 
> the Agriculture and Fisheries commision of all things.

It's good to mention this topic - fortunately we still have yet another
chance when the directive has to pass the European parliament in the
second reading,

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

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Thomas Förster
Am Montag 20 Dezember 2004 13:08 schrieb Curtis L. Olson:
> Jon Stockill wrote:
> > Thomas Förster wrote:
> ...
> For what it's worth, I think that some sort of minimal built in gui for
> FG is still a good idea.  FG already provides a lot of support for
> developing an external gui (i.e. for an operator/instructor station.)
> I have done exactly this for the ATC flight sim single engine trainer
> and it works quite well.

Is there documentation on this (writing external UI's) somewhere?

Thomas

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Thomas Förster
> The only issue is that for single PC, home users who aren't immensely
> computer savey, starting up multiple apps concurrently can be a bit
> tricky ... especially in a multiplatform / portable context.

Wrap that in a script/launcher app/... KDE starts some 10-15 apps/demons on 
initialization, the whole Gnome desktop is based on networked components 
(CORBA). Yet both aren't normally counted as apps that aren't friendly to the 
end user.

Thomas

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Jon Stockill
Curtis L. Olson wrote:
Jon Stockill wrote:
Thomas Förster wrote:
I also thought about this as an option for a GUI. The main advantage 
would be that this approach ensures there's no GUI code in FG and 
there is a well designed API/Protocol to it. Writing alternative 
GUI's should be easy using that API/Protocol. Having the GUI 
seperated also makes it easy to distribute the apps across machines, 
i.e. having a simulator with an instructors workplace (changing 
weather, fail engines...)

With the added advantage of not bloating the simulator - gets my vote.
For what it's worth, I think that some sort of minimal built in gui for 
FG is still a good idea.  FG already provides a lot of support for 
developing an external gui (i.e. for an operator/instructor station.)   
I have done exactly this for the ATC flight sim single engine trainer 
and it works quite well.
Agreed - the internal GUI we have at the moment, while not the prettiest 
 available certainly gets the job done, and can be configured without 
having to resort to coding - it's perfectly adequate for the job. What I 
was against was multiple GUIs util different toolkits, as that would 
significantly increase the bloat, and make packaging flightgear an awful 
lot more complicated.

--
Jon Stockill
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Curtis L. Olson
Jon Stockill wrote:
Thomas Förster wrote:
I also thought about this as an option for a GUI. The main advantage 
would be that this approach ensures there's no GUI code in FG and 
there is a well designed API/Protocol to it. Writing alternative 
GUI's should be easy using that API/Protocol. Having the GUI 
seperated also makes it easy to distribute the apps across machines, 
i.e. having a simulator with an instructors workplace (changing 
weather, fail engines...)

With the added advantage of not bloating the simulator - gets my vote.
For what it's worth, I think that some sort of minimal built in gui for 
FG is still a good idea.  FG already provides a lot of support for 
developing an external gui (i.e. for an operator/instructor station.)   
I have done exactly this for the ATC flight sim single engine trainer 
and it works quite well.

The only issue is that for single PC, home users who aren't immensely 
computer savey, starting up multiple apps concurrently can be a bit 
tricky ... especially in a multiplatform / portable context. 

Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt 
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Jon Stockill
Thomas Förster wrote:
I also thought about this as an option for a GUI. The main advantage would be 
that this approach ensures there's no GUI code in FG and there is a well 
designed API/Protocol to it. Writing alternative GUI's should be easy using 
that API/Protocol. Having the GUI seperated also makes it easy to distribute 
the apps across machines, i.e. having a simulator with an instructors 
workplace (changing weather, fail engines...)
With the added advantage of not bloating the simulator - gets my vote.
--
Jon Stockill
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] My 172P work for appraisal

2004-12-20 Thread Martin Spott
Dave Martin wrote:

> Here we are: (screenshots)

Well, after looking at the first shot:

> http://www.cyfinity.com/fgfs/c172p1.jpg

 I thought: Oh, how nice, someone added a C150 to the hangar, but
after looking at the last one:

> http://www.cyfinity.com/fgfs/c172p7.jpg

 I am pretty much pleased  ;-)

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

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-20 Thread Thomas Förster
> Here are a few ideas:
>
> - we could extend fgrun (to add such features as flight planning, AI
> objects editing),
>
> - we could create another app, which would be meant to communicate with
> FlightGear in realtime (probably via the telnet interface), something
> more elaborate than the http interface, in the same way that fgrun does
> for command-line options

I also thought about this as an option for a GUI. The main advantage would be 
that this approach ensures there's no GUI code in FG and there is a well 
designed API/Protocol to it. Writing alternative GUI's should be easy using 
that API/Protocol. Having the GUI seperated also makes it easy to distribute 
the apps across machines, i.e. having a simulator with an instructors 
workplace (changing weather, fail engines...)

> - in any case, it would be best to make sure that FG is able to change
> aircraft (FDM, 3D model, systems) on the fly, because that is probably
> the only start-up-time setting that can't be changed so far once
> FlightGear is running.

That would be a great improvement.

Having spend most of the weekend trying to install CVS versions of all the FG 
dependencies I only spent a few hours designing a new order/labeling in the 
menu (using QT Designer just because it's a graphical UI Designer). From that 
I think easy improvements  can be made just by renaming things. For example 
the difference between 'Adjust view distance' and 'Adjust LOD ranges' is not 
obvious. It's only after you click one you notice it was the wrong :-)

Thomas

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: CVS error msg

2004-12-20 Thread Erik Hofman
Frederic Bouvier wrote:
I tried the patch below with MSVC and it also compiles without any 
problem, so if it works with gcc 3.x and other compilers, I am to apply it.

It works for the MIPSpro compiler, so I've committed this patch.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: CVS error msg

2004-12-20 Thread Frederic Bouvier
John Wojnaroski a écrit :

Curtis L. Olson wrote:
John Wojnaroski wrote:
Hi Curtis,
When you have a moment. I may have sent this to you yesterday from 
one of my other machines, but can't find a copy. If a dup, my 
apologies.

In file included from ../../src/Cockpit/panel.hxx:50,
from ../../src/Cockpit/cockpit.hxx:36,
from main.cxx:61:
../../src/Input/input.hxx: In method `const class SGPropertyNode * 
FGBinding::getArg()':
../../src/Input/input.hxx:123: warning: choosing 
`SGPropertyNode_ptr::operator SGPropertyNode *()' over 
`SGPropertyNode_ptr::operator const SGPropertyNode *() const'
../../src/Input/input.hxx:123: warning:   for conversion from 
`SGPropertyNode_ptr' to `const SGPropertyNode *'
../../src/Input/input.hxx:123: warning:   because conversion 
sequence for the argument is better
main.cxx: In function `bool fgMainInit(int, char **)':
main.cxx:759: assuming & on overloaded member function
make[2]: *** [main.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Kind of lost on this one...


Kind of lost on this one too ... I think this might be Andy Ross's 
code so he might be a good one to ask.  What compiler version are you 
using?

Curt.
Running 2.95.4...
Andy, if you're listening, any ideas.  If this is due to using an 
older compiler, should there be a test in to check for that?

I tried the patch below with MSVC and it also compiles without any 
problem, so if it works with gcc 3.x and other compilers, I am to apply it.

-Fred
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.190
diff -u -r1.190 main.cxx
--- main.cxx16 Dec 2004 13:19:01 -1.190
+++ main.cxx20 Dec 2004 07:55:10 -
@@ -754,9 +754,9 @@
_bootstrap_OSInit++;
#endif
-fgRegisterWindowResizeHandler( FGRenderer::resize );
-fgRegisterIdleHandler( fgIdleFunction );
-fgRegisterDrawHandler( FGRenderer::update );
+fgRegisterWindowResizeHandler( &FGRenderer::resize );
+fgRegisterIdleHandler( &fgIdleFunction );
+fgRegisterDrawHandler( &FGRenderer::update );
#ifdef FG_ENABLE_MULTIPASS_CLOUDS
bool get_stencil_buffer = true;

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d