For what it's worth, FlightGear 0.9.5 for IRIX is available at:
http://www.1stweb.nl/~ehofman/fgfs/
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Arnt Karlsen wrote:
On Wed, 28 Jul 2004 21:42:48 -0400, Ampere wrote in message
[EMAIL PROTECTED]:
On July 28, 2004 03:06 pm, Jon S Berndt wrote:
So, from the point of view of the horizontal stabilizor, that pesky
downwash happens because wings really suck. ;-)
I guess that's one of the reasons
Arnt Karlsen wrote:
Erik
(Ever used the bicycle to cycle up a steep hill?)
..is overhang steep enough? ;-)
On a bicycle?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon Stockill wrote:
Erik Hofman wrote:
My personal opinion would be to get everything at one place,
preferably (but not necessarily) in a separate CVS branch at
flightgear.org just like the world wide scenery right now. That would
be easiest for everybody (and provides mirror sites
Jon S Berndt wrote:
On Wed, 28 Jul 2004 23:55:09 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:
That's because it's _mostly_ (or entirely) the sucking action above
the wing that contributes the most to lift.
No, that is the *result* of lift, not the *cause*.
No, you're mixing up
Jon Berndt wrote:
One more thing: think of a baseball or better yet a lightweight ball. How do those
things
curve?
I wouldn't know. I haven't thought about that one yet. My first
impression would be that of the cohesive and adhesive forces again.
Erik
Tony Peden wrote:
I hope you guys realize that this is an ages old debate that still goes
on in the relevant academic circles.
Yes. There is nothing wrong with fixing this for once and for all isn't
there? :-D
Erik
___
Flightgear-devel mailing list
Jim Wilson wrote:
Curtis L. Olson said:
Sounds fine, I wasn't planning on rolling out the official release today
anyway. Tomorrow is probably the earliest ... more likely friday.
Just a heads up: there is a minor (as in easy to fix) issue with building
SimGear using gcc 2.96 that was
Jon S Berndt wrote:
On Thu, 29 Jul 2004 10:34:16 -0500
Curtis L. Olson [EMAIL PROTECTED] wrote:
Ok, then how do you explain a frisbee that can curve either way, even
though it's always thrown with the same direction of spin. And please
include the coriolis effect in your explanation (now that
Curtis L. Olson wrote:
Erik Hofman wrote:
Jon S Berndt wrote:
On Thu, 29 Jul 2004 10:34:16 -0500
Curtis L. Olson [EMAIL PROTECTED] wrote:
Ok, then how do you explain a frisbee that can curve either way,
even though it's always thrown with the same direction of spin. And
please include
Durk Talsma wrote:
Hmm, I hate to spoil the party, but I did get a segmentation fault in
FlightGear today (running 0.9.5-pre3). I'm not sure when it happened, since I
started FlightGear this morning and letting it fly between KSFO and EHAM
(which appears to become my favorite test route :-)),
David Megginson wrote:
I've been frustrated with the tendency of the DC-3 (--aircraft=dc3) to
noseover during the takeoff and landing rolls, and of the J3 Cub
(--aircraft=j3cub) to nose over during wheel landings. I've fiddled
with the YASim files a lot in the past but have never found a good
Jon S Berndt wrote:
On Wed, 28 Jul 2004 14:15:04 -0400
Norman Vine [EMAIL PROTECTED] wrote:
This is a 100 year old argument :-)
http://hyperphysics.phy-astr.gsu.edu/hbase/fluids/airfoil.html
If you really want to know read everything you can wriiten by
Koukowskii and Prandtl
Is light a wave or a
David Megginson wrote:
The important thing to note is that the airflow *above* the wing also
curves down, not just the airflow below it. That is why, even with the
same incidence angle, the hstab sees a different angle of attack in the
wings' downwash even if it is level with or slightly above
Jon S Berndt wrote:
On Wed, 28 Jul 2004 22:56:59 +0200
Erik Hofman [EMAIL PROTECTED] wrote:
This is exactly the reason why pressure is build up underneath the
wing (pushing the airfoil up on air molecules == force).
No, not really. See:
http://www.av8n.com/how/htm/airfoils.html#sec-consistent
Erik Hofman wrote:
Try this for a start:
An airflow over the wing is causing the downwash at the end of the
airfoil. The airflow below the wing is now kind of captured between the
airfoil and the layer(s) of air underneath itself.
In this situation it can go in just two directions, up or down
Jon S Berndt wrote:
Which is why he never flew. See the argument about bullets in the link
provided, above.
http://dsc.discovery.com/news/briefs/20031201/leonardo.html
In the case of the airflow below the wing, it's not really trapped. It
gets out of the way, below.
But it will encounter a force
Innis Cunningham wrote:
Hi All
As far as I can tell there is no property to simulate
a stabilizer trim system in flightgear.If this is not the
case then maybe some kind soul could point me to
the said property.
If there is infact no such property currently, is there
some kind soul who could
Vivian Meazza wrote:
Pitot head icing
It might be a bit early, but I seriously read pilot head icing at first ...
Erik
(Is that already implemented?)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Tiago Gusmão wrote:
meanwhile while using tcp.xml, i noticed that using a line separator of
newline actually printed the word newline (this doesn't happen in var
separator), it doesn't bother me much, just reporting
Odd, both cases are handled the same. Maybe your utility to check for
the
Vivian Meazza wrote:
Mastered the Spitfire yet?
Yes. It's a marvelous aircraft to fly!
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Tiago Gusmão wrote:
There are missing elses (generic.cxx), meaning code could run
line_separator= line_sep_string;
even after one of the ifs was true.
You are completely correct on this. Thanks for the catch.
A fix is in CVS.
Erik
___
Flightgear-devel
David Megginson wrote:
Matthew Law wrote:
I agree totally. Does FG define humidity at all?
Yes -- we report it, and I'm pretty sure that we use it in density
altitude calculations (so that it affects both true airspeed and engine
performance).
METAR reported humidity is also used.
Erik
Tiago Gusmão wrote:
meanwhile while using tcp.xml, i noticed that using a line separator of
newline actually printed the word newline (this doesn't happen in var
separator), it doesn't bother me much, just reporting
Good yo know. I'll investigate this.
Is there any generic input support planned
Ampere K. Hardraade wrote:
No. What I want to do is tell each of these animation file where the livery
resides. I want to be able to tell all of them with in one single file,
instead of having to create a new xml file for every animation file.
Ah, That's what you meant. I don't think that
Dave Perry wrote:
Help!
Since my CH Yoke and Pedals don't work with the new joydev driver in
Suse 9.1, I need to use my Saitek Cyborg Evo joystick. Both js_demo and
jstest show all it's axes and buttons working but ony the non DEFANGED
functions work in FlightGear (that is aileron, elevator
Tiago Gusmão wrote:
Hi
I'm having trouble using it on tcp/ip, altough over serial it works as
expected.
i'm using other machine (192.168.0.2) with netcat (nc -l -p 5500)
and firing FG on this pc(192.168.0.1) like this:
$ fgfs --generic=socket,out,5,192.168.0.2,5500,tcp,osc
Failed to find runway
Tiago Gusmão wrote:
$ fgfs --generic=socket,out,5,192.168.0.2,5500,tcp,osc
Failed to find runway 28R at airport LPMA
Initializing OpenAL sound manager
Unable to load the protocol configuration file
This is fixed in CVS and will be included in the next release of
FlightGear (0.9.5).
Erik
Ampere K. Hardraade wrote:
Dialog scenery_loading not defined
The message only appears when one is in KSFO. As for other airports, the
message doesn't appear; neither does the scenery. All there is is an ocean.
Is you base package in sync with FlightGear?
Both FlightGear and the base package
Ampere K. Hardraade wrote:
I'm sorry, but I still don't get it.
Take a look at FlightGear/data/Aircraft/f16/Models/f16.xml:
?xml version=1.0?
PropertyList
pathf16.ac/path
offsets
z-m0.15/z-m
pitch-deg0.3/pitch-deg
/offsets
!-- Submodels --
model
nameRudderPedals/name
Jim Wilson wrote:
This is a workaround for an issue where the xml dialogs were shrinking on
subsequent pops.
Committed. Thanks.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon S Berndt wrote:
\
Is the MD-11 a JSBSim aircraft? I thought it was, but I don't recall it
being in our CVS ... is the AI aircraft its own FDM?
It is and it's in JSBSim CVS (since about two weeks).
AIModels are driver by a very (very) simple FDM that basically makes
sure the aircraft goes in
Ampere K. Hardraade wrote:
I think someone should implement the followings:
1. Treat each taxi way as a line.
2. Joint the end of two taxi ways together.
http://www.student.yorku.ca/~ampere/STEP1.jpg
3. Apply fillet.
http://www.student.yorku.ca/~ampere/STEP2.jpg
4. Apply loth.
Jonathan Polley wrote:
I just updated tonight and FlightGear no longer runs on the Mac. As of
last night, everything ran just file, but after updating everything
(SimGear, FlightGear, and base packages) I get an abort.
Oops, sorry all. This is caused by me not including a bunch of
Jim Wilson wrote:
For now anyway can we reduce this a level? This makes the airport not found
message (in ATC code only) warning level. I'm amazed at how often this gets
called.
Good idea, it's committed.
Erik
___
Flightgear-devel mailing list
[EMAIL
Ampere K. Hardraade wrote:
Thank you.
So, is there anyway to include more than one XML file? The reason I ask is
because I have multiple mesh files, and each of them has its own XML
animation file. I would like to tell all of them where the livery resides in
in one single XML file.
In most
Jim Wilson wrote:
Correct a typo that produces segfault during cleanup on some systems.
Committed. Thanks.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jim Wilson wrote:
Cool. Also, I posted a second patch for the scenery startup issue. I ended
up using an xml dialog instead of nasal for the Scenery Loading message so
it could also pop-up when teleporting to different airports. Probably I could
have used nasal, but I'm just not up to speed on
Durk Talsma wrote:
Also, note that including the MD-11 at this stage is not my first preference:
that would be including the new traffic manager and AIFlightplan code, and
use *only* the 737 traffic.
Done.
Erik
___
Flightgear-devel mailing list
[EMAIL
Ampere K. Hardraade wrote:
Is it possible to have something like this:
light-mappath/mon-scheme-texture.RGB/light-map
Using XML to define fading in places such as the landing light and taxi light
is fine, but doing so in places such as the cockpit is too much I would
think.
It depends a bit on
Jim Wilson wrote:
There is a modified sound config in cvs that at least partially addresses the
problems. I hope Erik doesn't mind.
Neh, it really needed an update anyway. If I find some time I will try
to improve the sound quality also (probably getting to back to 16-bit
audio), but if any one
Ampere K. Hardraade wrote:
...code last weekend, and did this:
http://www.cs.yorku.ca/~cs233144/PROTOTYPE.jpg
this:
http://www.cs.yorku.ca/~cs233144/FINNAIR.jpg
and this:
http://www.cs.yorku.ca/~cs233144/KLM.jpg
Very well done Ampere!
I've put them in CVS.
Erik
Jim Wilson wrote:
I've got the FDMs waiting while the scenery loads on startup. Mid air starts
are smooth again and even ground starts are a little nicer, especially if
you've left the throttle on the joystick open full. The screen shows the
scene as it always does, the aircraft just isn't
Jim Wilson wrote:
Erik Hofman said:
It's easy to do with a tiny Nasal script, which remains visible when a
property (/sim/initialized ?) is false.
Wouldn't that end up getting invoked every frame for the life of the program?
This is just a one shot thing.
No, a Nasal program is in essence a one
Jim Wilson wrote:
Erik Hofman said:
Jim Wilson wrote:
Erik Hofman said:
It's easy to do with a tiny Nasal script, which remains visible when a
property (/sim/initialized ?) is false.
Wouldn't that end up getting invoked every frame for the life of the program?
This is just a one shot thing
Swail, Carl wrote:
I am trying to use the OpenGC interface to Flightgear to communicate
with my own custom symbology display software via a network connection.
The standard documentation that comes with Flightgear does not explain
how to set up a connection, at least I don't understand. Any
Jon Berndt wrote:
Note you will need a recent Cygwin DLL to use these
this is untested
http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz
Norman:
Is this file still online? Cape.com seems to think the site is offline or the file
doesn't
exist. Transient ISP problems?
Maybe this is am
Ampere K. Hardraade wrote:
Please tell me that you don't play FlightGear in wireframe mode. =P
Neh, my O2 does support filled triangles.
Just kidding.
Oh. ;-)
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Alex Perry wrote:
I'd observe that it would be nice to turn _off_ texturing of the models,
both the aircraft I'm sitting in and the AI aircraft around the airport,
and turn _on_ texturing for the head up display (needed for PLIB fonts).
That would make it much easier to fly with unaccelerated 3D
Innis Cunningham wrote:
It is quite possible that the new graphics card/system is not set up for
FG.I will have a play with it and see if I can improve the situation.I
think
anisotropic filtering is on.
The point I was trying to make is people trying FG for the first time will
be dissuaded from
Boris Koenig wrote:
Erik Hofman wrote:
Well, if we turn all that off, people start to complain that
FlightGear looks like crap and will search for something else. At
least now they start asking questions ...
Then how about optionally offering to disable such things in the
(advanced) rendering
Frederic Bouvier wrote:
What about calling SDL_Quit in a function installed by 'atexit', remove
fgOSExit and only rely on exit in all the program ?
The problem is that plib has taken the liberty to call exit() whenever
they feel like it
Erik
___
Remy Villeneuve wrote:
Hi,
Just discovered Flight Gear last night, and it installed relatively well,
apart from the missing fs_os.cxx problem which I finally tackled by using
the file from CVS (before I had the chance of reading Erik's comment on
the tarball hickup)... Anyway, great work you guys
Durk Talsma wrote:
I do remember seeing something similar happening, on a long haul test flight
between Tokyo and Sydney, which judging from the timestamp on the scenery
directory, I did around the 22nd of June. Same problem: Huge memory leak, up
to the point where the aircraft became
Curtis L. Olson wrote:
Yes, in my most recent reply to this company, I asked specifically about
FG support (and support for operating systems not owned and operated by
MS.) It's not necessarily clear from their web page exactly how their
products interface with the computer and how they work
Boris Koenig wrote:
Getting even more extreme, one might ponder about offering that said
company to integrate their webpage address or even company logo directly
into some of the future official FlightGear releases.
No, No No. Never.
This is not going to happen.
Erik
Ampere K. Hardraade wrote:
make[2]: *** No rule to make target `fg_os.cxx', needed by `fg_os.o'.
Good catch. There was a mistake in the build system. This should be
solved in the FlightGear-0.9.5-pre2. (In the mean time you could just
copy the fg_os* files from CVS)
Erik
Frederic Bouvier wrote:
Indeed, the package only contains fg_os_sdl.cxx. I think it reflects
the packager's ( Curt ) own build option. And the package doesn't include
Network/jpg-httpd.* .
May I suggest to include all the files that are in conditional statement in
Makefile.am to be include
Vivian Meazza wrote:
SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in
[openal-test1.exe]: cannot find -lalut.
This is using Norman's prebuild libraries, isn't it?
Norman has integrated the alut library and the openal library so the
reference should then be removed in the
Frederic Bouvier wrote:
Erik Hofman wrote:
Vivian Meazza wrote:
SimGear-0.3.6-pre1 will not compile under Cygwin. It fails in
[openal-test1.exe]: cannot find -lalut.
This is using Norman's prebuild libraries, isn't it?
Norman has integrated the alut library and the openal library so
Boris Koenig wrote:
SO, instead of taking my mail apart and telling me what's NOT going
to happen it might be more helpful for the final outcome to make
new suggestions
Not really. If you have spent the amount of money on FlightGear as I
have done then you may make any suggestion you like. Until
Frederic Bouvier wrote:
Would these messages be removed before the release ?
WARNING: ssgLoad3ds: Texture coords missing.
WARNING: ssgLoad3ds: Texture coords missing.
WARNING: ssgLoad3ds: Texture coords missing.
WARNING: ssgSGIHeader::: Failed to open
Vivian Meazza wrote:
Once the offending entries are removed from simgear/sound, simgear compiles
correctly, but Norman's pre-built libraries were still present. I'll remove
those and try again.
Nono, that's not what I meant.
Norman once build a separate library for alut and openal, but in the end
Boris Koenig wrote:
Erik Hofman wrote:
instead of some bozo who just noticed the existence of our
project
This is really getting funny - I didn't expect to have that much
fun here...
(No I'm not referring to you in this case).
Thanks, that's really nice :-)
In case you didn't notice it, I
Vivian Meazza wrote:
I'm a bit confused now!
There is really no need to be confused.
Norman's last version put all the stuff into openal
Good. That part is fixed in CVS no.w
Unless test1 and test2 do something useful they can be easily removed from
simgear/sound/makefile.am
We sometimes include
Ampere K. Hardraade wrote:
The MD-11 has 4 different level of details for parts that have a high
concentration of polygons (engines). I plan to expand it to the entire
aircraft in the future. I am confident that the amount of triangles is small
enough for the traffic manager.
In the end, or
Norman Vine wrote:
Frederic Bouvier writes:
fgrun is installed by fgsetup. It is launched when you double-click on
the FG icon.
Cool,
Perhaps merntion of this should be made as a 'dependenciy'
then on http://www.flightgear.org/Downloads/source.html
IRIX and Solaris binaries also include it
Ampere K. Hardraade wrote:
Scrubbing FlightGear because of framerates was excatly what a friend of mine
did. I agree with Innis that someone should fix this problem.
The following tests were done using windows 98SE
The old box was a 850meg duron with 256 meg ram and
a GF4-MX-440 64meg graphics
Vivian Meazza wrote:
Back up with an upgraded machine - 2.8 Mhz P4, 512 Ram, Gforce 5200. I've
rebuilt Cywin, and FGFS-CVS. I've just copied the latest version of the
Spitfire from FGFS-0.9.4, where it was working, after a fashion, to
FGFS-CVS. All the files. Now it won't fly, as David pointed
Ampere K. Hardraade wrote:
Bump.
So, is my idea a good one or a bad one? There doesn't seem to be much
response...
There has been some discussion related to this off-line. No conclusions
where drawn yet. Part of the problem is that we need some one to do the
coding, and then we need to
It is a bit of a shameless plug, but it's for my own interest :-D
Found at http://www.luchtzak.be/article4876.html
It is the intention that this trimester the production of Fokker 70 planes is resumed. This
is anounced by the commercial director Ruud Kleinendorst from Rekkof today (8 April) in
Boris Koenig wrote:
Hi again !
I am just about trying to add some test-hooks to FlightGear, but
wouldn't like to have to rebuild the whole FlightGear build tree each
time (~ 350 MB ), just for 2-3 added small test-functions, hence I
came up with the following idea:
How about adding a sub-directory
Innis Cunningham wrote:
The size of the model does not seem to effect frame rates in FG.I get
nearly
the same rate if I use the cessna or the an225.I have tried with the
fuselage
double sided and single sided the frame rates seem to be the same.
There are others though for which this is becoming
Innis Cunningham wrote:
The thing is is it the total number of vertices/surfaces in the model
that determines the frame rate or is it also dependant on if the model
is double sided or single sided.
Both. Double sided objects count for the fillrate. Using singe sided
polygons can speed up
Boris Koenig wrote:
By the way, the addition of a plugin architecture has pushed all major
flight simulators tremendously forward, I don't even mention stuff like
Microsoft's FS, but I suggest to have a look at X-Plane: Since the
author added support for basic plugins, there are numerous projects
Boris Koenig wrote:
Besides there occured some OpenGL problems (weird graphics) which
I could only solve by disabling some rendering options such
as --disable-specular-highlight
That must be a driver bug. The only thing --enable-specular-highlight
does is enabling a hardware option (if available)
Boris Koenig wrote:
Frederic is right that a plugin system is actually in contrast with
the GPL (FlightGear's license), that requires everything to be opened
when using some piece of GPL software within your project.
I don't think that would be a major problem, there's other opensource
(GPL'ed)
Boris Koenig wrote:
I wouldn't have a problem, creating the authoring part of the
application as an external application - but THEN I would need
to be able to load FlightGear resources (aircraft/images/panels).
Ok. Lets start a *minimal* list of items that really are needed for this
and skip the
Boris Koenig wrote:
Erik Hofman wrote:
Boris Koenig wrote:
Frederic is right that a plugin system is actually in contrast with
the GPL (FlightGear's license), that requires everything to be
opened when using some piece of GPL software within your project.
I don't think that would be a major
Andy Ross wrote:
Erik Hofman wrote:
* The ability to load a set of sheets, one after each other.
* Be able to add the following to these sheets:
- Dynamic text at a static location (*)
- Static images (*)
- Animated instruments that react to actions of the user(*)
Most of this sounds like
Boris Koenig wrote:
Maybe it is now easier for you to tell me, IF the desired functionality
could be (easily) achieved using primarily nasal scripting and some
smaller FlightGear source code modifications or whether it would
be more feasible for me to really start writing directly into the
Ampere K. Hardraade wrote:
Would you mind posting the link to your site and forum again?
http://flitetutor.sourceforge.net
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Boris Koenig wrote:
So I hope to know now for example that nasal's lack of threadsafety
is unlikely to become an issue, as not nasal itself would handle things
like animations but rather a specific subsystem - that nasal would only
access to provide the necessary parameters - correct ?
Hmm, well
Boris Koenig wrote:
If anybody of you doesn't yet know what this is all about, please check:
http://flitetutor.sourceforge.net (please leave feedback using the poll)
Boris,
First of all, the documentation for Nasal can be found here:
http://www.plausible.org/nasal/flightgear.html
Secondly, I
Boris Koenig wrote:
I am currently mainly looking for answers to some of the following
questions:
- is there demand for an application like this ?
I think there is. This could particularly be useful for the first couple
of lessons for a PC-ATD. It also reminds people that flying isn't easy
Ampere K. Hardraade wrote:
New animation type as in specifying the effects in the XML file? If so, that
is what I was thinking as well.
Yep. That's what I meant.
Erik
On July 9, 2004 03:57 pm, Erik Hofman wrote:
Ampere K. Hardraade wrote:
I know. It is like the way things are done in 3D Studio
Ampere K. Hardraade wrote:
I know. It is like the way things are done in 3D Studio. Unfortunately, most
of these features aren't working with 3ds format in FlightGear. I even had a
specular level problem at the very beginning.
As for illumination, it is better done by a mask rather than
Tiago Gusmão wrote:
Michael Stilmant wrote:
please update the clock of your computer
you send old Email
It's probably just my ISP lagging ;) thanks for pointing that out
Ampere K. Hardraade wrote:
I was using multiple textures on the MD11's fuselage at first but then
switch to a single gigantic
Ampere K. Hardraade wrote:
Couple of questions:
- Is this ATC Simulator that you speak of similar to us (being an open source
project, etc.)?
- How did they get your attention at first? May be we can use their methods
to help FlightGear gain some publicity.
- Where do their money come from? If
Roberto Manca wrote:
Hi all,
This is just to thank you all for helping me. I've modified the netfdm
client Erik told me (the client works perfectly but does exactly the
opposite job I needed) to act as a server and receive the current flight
model status through a FGNetFDM 'variable'. If you
[EMAIL PROTECTED] wrote:
I have a few Qs...
1. As i said i've got FGFS going on cygwin. Its great apart from it runs half
the speed. I'm thinkin this is cygwin's doing. I have heard of compiling FG on
MSVC. I hit a wall when i couldnt get SimGear going as there wasnt a project
file. Everything
Mathias Fröhlich wrote:
On Sonntag, 4. Juli 2004 13:20, Erik Hofman wrote:
It looks like this makes it easy to support different liveries with just
a minimal set of changes (actually only the exterior textures should be
different) without any changes to plib.
It does require some (fundamental
David Megginson wrote:
Erik Hofman wrote:
It turned out to be easier than I suspected. I've put a patch in CVS
that allows one to add a texture-path/texture-path tag to the
animation configuration file. The specified path should be defined
relative to the model path. For some unknown reason
David Megginson wrote:
Erik Hofman wrote:
It turned out to be easier than I suspected. I've put a patch in CVS
that allows one to add a texture-path/texture-path tag to the
animation configuration file. The specified path should be defined
relative to the model path. For some unknown reason
Norman Vine wrote:
Lee Elliott writes:
I think we need to push a patch to the plib developers list that
optionally lets one specify the texture directory when loading a
geometry file, but still default to the geometries own directory.
void ssgLoaderOptions::setTextureDir ( const char *s )
{
Hi,
For my own convenience I've created a general developers TODO list:
http://www.seedwiki.com/page.cfm?doc=TODO%20Listwikiid=2418wpid=147807
This is not intended to be a bug reporting facility, just a reminder of
things that need some special attention sooner or later.
Fell free to add and
Chris Metzler wrote:
On Sat, 3 Jul 2004 01:19:27 +0100
Lee Elliott [EMAIL PROTECTED] wrote:
As I understand it, the 3d model and texture handling in FG is done via
plib, which treats the texture map path incorporated in the .ac model
file as a relative path.
Relative to what? To the directory
Jon Berndt wrote:
Can anyone tell me if/where the props.html file is that describes the property system?
I
can't seem to find it in the source tree or on the web sites - but it IS in simgear
CVS.
There doesn't seem to be a file called props.html, and as far as I can
remember there hasn't been
Jon Berndt wrote:
Would you say that the JSBSim property tree is grafted onto the FlightGear tree?
Yes, that sounds like a good description of the situation.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Norman Vine wrote:
Lee Elliott writes:
I think we need to push a patch to the plib developers list that
optionally lets one specify the texture directory when loading a
geometry file, but still default to the geometries own directory.
see ssgLoad.cxx
void ssgLoaderOptions::setModelDir (
801 - 900 of 2467 matches
Mail list logo
