Melchior FRANZ wrote:
Unfortunately, so far it only works with solid (unsmoothed) objects.
Looks like a plib bug to me, but I have yet to find the exact reason.
Ahh, that would be a shame. I'm very much looking forward to see this in
action (or better yet, see it in FlightGear).
Erik
Melchior FRANZ wrote:
At least that's how it currently (sort-of :-) works. In theory,
aileron/flap/... movements should still work. But I haven't tested
that yet.
Good point, I'm afraid they don't work properly anymore since the center
point and the normal axis' probably have changed after
Vassilii Khachaturov wrote:
Attached are 2 patches for cleaning up some build warnings,
in both simgear and flightgear. Caught with gcc-4.0.
Thanks Vassilli, it's been committed.
Erik
___
Flightgear-devel mailing list
Stefan Seifert wrote:
Also nice would be any review of the code :) and of course some info
about how the chances are for inclusion.
I must say I like the idea, but given it's current state (no windows
support) I would like to postpone it until after FlightGear 1.0 is released.
There are a
Frederic Bouvier wrote:
What is missing for windows ?
Stefan Seifert wrote:
Missing is support for Windows, where the directory should be like %PROFILE%/Application Data/FlightGear (or such). Also I don't know if Windows supports the mkdir function. Would be nice if someone could port.
Erik
Hi,
I was thinking, FlightGear is already able to handle way more options
than advertised when running fgfs -h -v
How would we all fell about minimizing the number of command line
options in favor of the --prop:prop=value method and make sure all
of them are explained in a document rather
Melchior FRANZ wrote:
Sorry to be annoying yet again, but that's what I'm best at:
* Erik Hofman -- Saturday 17 December 2005 10:48:
I must say I like the idea, but given it's current state (no windows
support) I would like to postpone it until after FlightGear 1.0 is released.
And I would
Frederic Bouvier wrote:
I don't see the real benefit of this naming change. I rather see the
burden of changing fgrun. And there are options that are not reduced to
a property assignment.
True, those should be kept. But the main reason I started this was because:
1. We have at least two
Stefan Seifert wrote:
Erik Hofman wrote:
Lighten up, I just started looking at this patch since Fred promised
to fill in the missing gaps.
I just noticed, that this patch could break compilation, since in
sg_patch.cxx the new method is called makeDir and in the header it's
still makedir. I
AJ MacLeod wrote:
I really hope this is made to work at least as well as the earlier patches
because I think it's a _great_ feature and one that makes life with FG that
little bit more pleasant...
Yeah well, I was trying to outsmarten myself, and got hit in the back.
It took me way longer
Dai Qiang wrote:
Hello,
Is FGFS is able to output the flight envelope chart,
according to the specific information defined in FDM
files, by traversing the property tree?
I think you would be better of with scripted runs of the standalone
version of the FDM.
Erik
Dai Qiang wrote:
Hi Erik,
Thanks for the reply.
Would you please explain your point more detailedly?
Well, if the only thing you want is to plot the flight envelope then it
would be overkill to use a full featured flightsimulator. So it might be
better to only run the FDM and feed it with
Vivian Meazza wrote:
Oliver Schroeder, Mathias, and I have all been discussing merging the MP and
AI code, so that we could sort out the animations and the jerky movements of
MP models, and give us the capability of passing AI models over the net.
Ah, I didn't know that, good to hear!
Erik
Ampere K. Hardraade wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=5142
So, the problem seems to be that pbuffer is not supported?
Yes, and it also looks like the detection code is missing in
RenderTexture.cpp ??!
Erik
___
Flightgear-devel
Jim Alberico wrote:
I'm interested in starting from ASCII time-histories of position,
orientation, and possibly surface positions.
I'm not sure whether 0.9.8 had the capability to read back ASCII file
using the generic protocol but 0.9.9 has a playback protocol defined
which could be used
Jim Wilson wrote:
If this is just flipping the sign why not just grep and fix all the aircraft in
CVS that specify incidence? I guess I don't understand the ritual. Maybe
there was more to this change that I'm just not aware of?
Most modelers (if not all) were unaware of this problem. Some
Carsten Hoefer wrote:
BTW: How do I play sounds by Nasal scripts?
The same way one would do animations using Nasal;
Adjust properties in Nasal (they may be private properties in your own
subtree of the property list, say /tmp/aircraft) and let the sound
configuration file act on those
Joacim Persson wrote:
On Thu, 1 Dec 2005, David Luff wrote:
I have no experience of plugin architectures, and don't feel competent to
attempt it at the moment.
First of all: there's obviously no panic. (If there were fifty-seven
hard-linked GPS models, AP's etc it would be a problem, ;)
David Luff wrote:
Hi folks,
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Well, I object. How could I tell others to postpone their contribution
until after the release of FlightGear 1.0 if you are allowed to add this
rather comprehensive peace of code?
Erik
Melchior FRANZ wrote:
Good question, indeed! How could you? There was no discussion about
this topic on flightgear-devel before this order was announced, and
every discussion after that was passively suppressed by ignoring valid
arguments. How was this decision made and by whom? Is FlightGear
Melchior FRANZ wrote:
As demonstrated before [1], this is quite easy to do even
with Nasal[2]. The only thing that needs to be implemented in fgfs
is a way to tell it where to store the files. Something like
FG_HOME/--fg-home. Paul was already working on that for exactly
this purpose[3], but
Josh Babcock wrote:
Good point. I also do this, but because this model has knees (not sure
what to call them) instead of oleos, I skipped it. Still, it should be
Hinges I believe.
Erik
___
Flightgear-devel mailing list
Arthur Wiebe wrote:
But as it seems to be a bad idea, I guess we can forget this thread.
Why do you think that? I've not seen any negative responses.
It's like everything else, a good idea is always welcome but like you,
others might not have time to develop it (right away).
Erik
Ampere K. Hardraade wrote:
I was referring to the ambient light that is casted on every object in the
scene.
Before dawn and after dust, everything is casted in a shade of blue. Even
when the sun is up, there is a slight shade of blue on objects that are
hidden behind a shadow.
In
Ampere K. Hardraade wrote:
First of all, thanks for looking into this. I have just tried your patch (I
assume it was commited to the CVS). Unfortunately, it didn't work. I am
still getting the GLXUnsupportPrivateRequest error at exactly the same spot.
I'm afraid I can't help any further.
Georg Vollnhals wrote:
Hi,
with the newest SimGear CVS I get this compiling error (Cygwin, gcc 3.4.4):
RenderTexture.cpp:1595:44: macro SG_LOG passed 4 arguments, but takes
Bah, conditional compiles don't make life easier.
This should be fixed now.
Erik
Josh Babcock wrote:
No, I was responding based entirely on the e-mails. I did just take a
peek, and it seems like a neat way of making the touchdown squeal if I
am reading it right. What is the dt_stop section about though?
dt_stop is the time in seconds after the sound has stopped, this is
Ampere K. Hardraade wrote:
Speaking of sky and color, I think FlightGear could use more blue in its
ambient light source.
Are you sure this isn't because of the humidity level which colors the
sky more pale.
Erik
___
Flightgear-devel mailing list
Josh Babcock wrote:
Won't the FDM have to tell the sound system when the wheels are
skidding? You can figure out touchdown pretty easily, but not say,
skidding from braking.
The FDM already reveals when the brakes are applied in the property
tree. One thing that still is missing (and I have
Josh Babcock wrote:
Erik Hofman wrote:
The FDM already reveals when the brakes are applied in the property
tree. One thing that still is missing (and I have a solution for the
next JSBSim release) is a ground-speed property.
Yeah, but just putting them on doesn't make them skid (I hope
Dimitris Papavasiliou wrote:
Anyway I'm working on a sort of free flightsim myself (nothing like
flightgear though, more like what you would call a game) and have
recently completed the implementation of the skycolor part of Preetham's
paper A Practical Analytic Model for Daylight. It only
Hi,
I might have solved the nasty RenderTexture bug for ATI cards in CVS.
Anyone cares to test it?
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Frederic Bouvier wrote:
search the string '_vsnSG_LOG' in rendertexture.cpp
In case you missed the CVS log message; this is fixed now.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Dimitris Papavasiliou wrote:
Hmmm, on closer inspection it doesn't seem to be a simple gradient
indeed. Does the color depend on the weather (that is turbidity) as
well?
Yes.
Also bear in mind that the paper also describes a way to calculate
sunlight color based on sun position and other
Hi,
I've put the IRIX binaries of FlightGear 0.9.9 at the usual place:
http://www.a1.nl/~ehofman/fgfs
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Bohnert Paul wrote:
A file for the c172-le is missing.
localhost$ fgfs --aircraft=c172-le
Error reading panel:
Failed to open file
at
/usr/local/share/FlightGear/data/Aircraft/c172/Panels/c172-trans-panel.xml
(reported by SimGear XML Parser)
The problem with that one is that it's not in
Melchior FRANZ wrote:
And finally, this is my TODO list:
* try to get rid of a few more hardcoded dialogs, or at least
make them accept gui colors
Not that I explicitly stated no major updates to the *source* *code*.
Removing code would be no problem (and neither would be putting an
Stefan Seifert wrote:
Another thing that's really missing (and was mentioned in the
linux-user.de review) is handling of any cases other than normal flight.
Redout and Blackout are a good start, but everything from structural
failures to things like skid sounds if you turn too quick on ground
Adam Dershowitz wrote:
I just downloaded from CVS and built 0.9.9 and have found a bug.
When it comes up the sound is muted. If I click file-sound
configuration it brings up the sound dialog box with Mute Sound
checked. If I uncheck it I get sound. But then I can't seem to get it
to again
Hi,
In the OpenAL mailinglist someone mentioned an ALSA optimized version of
OpenAL that supports multiple streams. It might be worth to check out:
http://dino.e4a.it/openal-alsa/
Erik
___
Flightgear-devel mailing list
Melchior FRANZ wrote:
http://members.aon.at/mfranz/concorde-gui.jpg [130 kB]
http://members.aon.at/mfranz/seafire-nimitz.jpg [70 kB]
http://members.aon.at/mfranz/clouds-winter-bo105.jpg [182 kB]
http://members.aon.at/mfranz/lightning-rain-b1900d.jpg [83 kB]
Mathias Fröhlich wrote:
Well, that will in effect turn off everything using the rendertexture code.
I would vote against that ...
This is only a temporary work around for r200 owners.
Would it be possible not to initialize the rendetexture code if we don't need
it, e.g. we have not 3d
Melchior FRANZ wrote:
Error fetching live weather data: More than 10 stale METAR messages in a row.
Stop fetching data permanently.
fgfs: /usr/local/include/simgear/threads/SGThread.hxx:150: void \
SGThread::join(): Assertion `status == 0' failed.
/home/m/bin/fgfs: line 239:
Erik Hofman wrote:
Next stop: IRIX.
Same problem.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Curtis L. Olson wrote:
Argh! Can we pick a different more intuitive name for this directory.
It got created because the old 3d clouds demo needed it's stuff there,
but we really need a more intuitive name beyond data/Data ... !
Yes, but not before 0.9.9 has been released.
Erik
Curtis L. Olson wrote:
Hi all,
I would really like to get v0.9.9 out the door this week ... maybe
committing to the final source code version on thursday or friday.
I agree, it really is time to get it out.
Erik
___
Flightgear-devel mailing
Kevin Jones wrote:
Regarding the file /data/Sounds/intro.mp3:
FlightGear doesn't use OpenAL for MP3 playback. In fact, it isn't even
supported.
Does that mean that the command line options --disable-intro-music and
--enable-intro-music have no effect on any platform or should there be
a
Melchior FRANZ wrote:
* Harald JOHNSEN -- Saturday 12 November 2005 17:09:
Melchior FRANZ wrote:
I've just implemented the check for stale METAR reports (to stop
fetching after 10 stale reports). This triggers an assert in
SGThread:
It's perhaps because of the PTHREAD_CREATE_DETACHED
Dave Culp wrote:
The message:
WARNING: ssgLoadAC: Failed to open
'/home/dave/FlightGear-0.9.9-pre2/data/Aircraft/c172r/Models/c172-dpm.ac' for
reading
I've already fixed this by referencing the default c172p instead.
Erik
___
Flightgear-devel
Jeff McBride wrote:
Hello All,
I am considering using a property tree similar to that in Flightgear
for a UAV ground control application, and I have a question for the
developers on the list. Has anyone ever looked into creating a system
to share a common property tree between two computers
Pigeon wrote:
Figured out the problem with ATIS voice. It's in SimGear with the
code for OpenAL/Alut 1.1, whereby with in sample_openal.cxx,
alutCreateBufferFromFile() does not give us the raw sound data, and
ATCVoice depends on it, which leaves the data and the data size
uninitialized.
Arthur Wiebe wrote:
I think this report basically pins down two of my problems.
First, where spash screens on startup showed up as strange color stipes.
And second, where certain aircraft which define their own spash screen
crash fgfs.
I got this report when trying to load the c310 (pre3).
Curtis L. Olson wrote:
Just a quick announcement that I rolled up v0.9.9-pre3 tonight. I had
screwed up and missed a file in the base package, and then some other
changes got snuck into simgear/flightgear so I figured I might as well
roll out another try.
There's one thing I really like to
Steve Hosgood wrote:
That's certainly not getting in before 0.9.9!
Turns out to be wy more tricky than it looked. It would seem that
the entire handling of sun/moon azimuth/altitude as it's done now in
flightgear needs replacing, with the alt/az calculations themselves done
in Simgear.
Ladislav Michnovic( wrote:
2005/11/11, Erik Hofman [EMAIL PROTECTED]:
There's one thing I really like to see solved preferably before 0.9.9
(but it is a must for 1.0) and that's the sun/moon azimuth calculation
code to be replaced.
If you are talking about code from xglobe ( src/Time
Melchior FRANZ wrote:
I'm strongly in favor of 0.9.9. If it takes us as long to get 1.0.0
out as it took us for 0.9.9, then there will be several releases of
Linux distributions during its lifetime. Risking that fgfs won't be
included in any of these releases is not a good idea. (Similar
Steve Hosgood wrote:
I shall go hang my head in shame somewhere quiet
There's no reason for that, I didn't manage to get around it at first
either. I think I have a lucky day today to discover how simple it could
be done.
Let me emphasize that I really appreciate it that you took the
Steve Hosgood wrote:
And the following file probably should (considering that otherwise you
get a complaint message on the screen when using the default aircraft):
data/Aircraft/c172r/Models/c172-dpm.ac
I've fixed this in the code to use the default included c172p instead.
Erik
Curtis L. Olson wrote:
If you could run the clock forward a year or two or five or 10 and
verify that the new code matches the results of the existing code within
acceptable tolerences, then I think I'd be ok with sneaking it into v0.9.9
Both 1970 and 2025 seem to work properly.
Erik
Ladislav Michnovič wrote:
2005/11/11, Erik Hofman [EMAIL PROTECTED]:
This is the reason why I proposed to release a patch:
http://www.a1.nl/~ehofman/fgfs/download/sunpos.diff
Great work. Thanks, but there is still moonpos.cxx which needs to be replaced.
I've removed moonpos.[ch]xx
Arthur Wiebe wrote:
Now when it comes to debugging stuff like this I'm a newbie.
When I select the default c172p aircraft everything works fine. But if I
select say the f16 or A-10 then fgfs crashes.
Here's the output from gdb.
http://www.codecomments.com/archive242-2004-4-170396.html
The
Kevin Jones wrote:
Hi,
There's a file in the base package /data/Sounds/intro.mp3 The
filename suggests this is introduction music presumably played during
the FG boot. I have CVS FG compiled with Cygwin for Win32 (using
Norman Vine's pre-compiled OpenAL libraries in case OpenAL is
suspicious
Arthur Wiebe wrote:
OK,
But then why when I select the A-10 or f16 fgfs crashes? But when
selecting the c172p and j3cub there is no problem?
The only commonality between the A-10 and f-16 is the turbine sound file??
Erik
___
Flightgear-devel
Martin Spott wrote:
RANTWe know exactly this phenomenon for several years now and to my
observation very little changed in the meantime. The biggest success
was to install a consensus that the pre-release phase should last at
least two weeks. To my opinon two _months_ would be appropriate for
Stefan Seifert wrote:
Hi,
attached are two small patches for giving the 737 nosewheel some
animations. Namely it rotates when steering and compresses on breaking.
For the latter I attached a one line patch that let's JSBsim expose
compression-norm to the property tree just like YaSim.
I
Buchanan, Stuart wrote:
Hi All,
I've updated the Cessna 182 as follows.
Great, we have a new c182 maintainer.
- New Skylane textures to replace the old ones (which said Skyhawk on the
side!)
- Re-upholstered interior :)
- Improved 3D cockpit with new
- yokes
- engine controls -
Andy Ross wrote:
Erik Hofman wrote:
Ok, I've test compiled the simgear/nasal library using gcc on IRIX
and linked it with the MIPSpro build version of FlightGear and it's
working like a charm. Now remains the question, is it an exploited
gcc bug/feature or is it really a MIPSpro bug?
I've
Arthur Wiebe wrote:
Here's the output when I try to run fgfs 0.9.9-pre2 with SimGear
0.3.9-pre2 and 0.9.9-pre2 base package.
Using Mac OS X hack for initializing C++ stdio...
Error reading properties:
Failed to open file
at .//data/cloudlayers.xml
(reported by SimGear XML Parser)
Bus error
Buchanan, Stuart wrote:
Have you synced Instruments-3d ?
The new C182 model requires the new yoke, flaps and trimwheel that I
submitted at the same time. I assume they were all checked in at the same
time.
Oops, they hadn't.
Erik
___
Andy Ross wrote:
Again: I've run fairly rigorous tests on both Sparc and PPC at this
point with no failures, so I think we've pretty much ruled out
endianness.
Ok, I've test compiled the simgear/nasal library using gcc on IRIX and
linked it with the MIPSpro build version of FlightGear and
Curtis L. Olson wrote:
I reserve the right to make the final determination (and all
non-included aircraft will still always be available for separate
download from the web site ...)
Given that new aircraft have arrived on the scene since the last
release, do we want to make any changes to
Josh Babcock wrote:
possibly the Colditz glider to follow it. BTW, how come the Colditz
never made it into CVS, IIRC it's GPL, and I personally thought it was a
pretty neat little project. Anyway...
The last message I saw about this subject indicated it wasn't ready for
inclusion. After that
Josh Babcock wrote:
Dave Culp wrote:
All you experienced modelers, please tell me, is this possible? Can you set a
piece of a model to flash somewhat randomly using only XML animation code?
I'm pretty sure you would need to have each t-storm running its own
instance of a simple Nasal
Dave Culp wrote:
I don't understand. Are you saying there is no need for the AIStorm because
the 3D clouds and METAR will handle this? I am not familiar with either of
these, so I'll have to experiment with them.
Yes, the 3d clouds can draw good thunderstorm clouds and lightning and
rain,
Hi Andy,
Since you've not yet responded to my questions I assume you've been busy
lately?
So far I've tracked down the problem to the getMember() function
simgear/nasal/code.c. The problem starts to appear when ctx-opTop
increments from 2 to 3 in which case obj.ref.reftag isn't valid
Andy Ross wrote:
If it's not happening across a garbage collection, then I strongly
suspect a compiler bug. Note that opTop is only modified when a new
reference (with valid reftag) has been pushed on the stack.
This section does look fushy to me (code.c setupFuncall()):
naRef result
Steve Hosgood wrote:
I'll be quite happy for the Colditz Glider to be part of 0.9.9
Ok it's committed to CVS. It won't be part of 0.9.9 directly but it will
be downloadable from the aircraft page after that.
Erik
___
Flightgear-devel mailing
Vivian Meazza wrote:
You might consider adding the following:
* Carrier - added working arrester wires and catapults. The carrier is
selectable as a starting position. AI has been added to the
carrier in the form of an operating box and an automated turn
into/outof wind. TACAN
Georg Vollnhals wrote:
Hi Erik,
you have a nice pic on your webside with all your aircraft placed on two
medium sized ships and there is also one sailboot and a firetruck:
http://www.a1.nl/~ehofman/3dmodels/3dmodels.png
If these are models *you* have created I would ask you whether you
Paul Surgeon wrote:
Since it's in the default San Francisco area you can submit it to Erik or Curt
or you could sumbit it to the FlightGear scenery database.
http://fgfsdb.stockill.org/
I'm just not sure if Curt will include objects from the FG scenery db into the
default scenery area. Curt
Melchior FRANZ wrote:
FYI: a few days ago I committed an extension to the GUI system that
allows to select buttons via keyboard.
Nice! It would be great to see the ESC key default to dialog exit at
some point in time. It's too often I expect the dialog to close but
instead get a new (exit)
Melchior FRANZ wrote:
Yes. But I was concerned about the double function: cancel dialog
(harmless) or exit fgfs (theoretically harmless, too, but I'm quick
with pressing RETURN, so it isn't).
Ah, the average MS Windows users mentality.
A former colleague of mine once put a common windows
Sam Ingarfield - VK6HSI wrote:
...both openal and alut are installed
But there's no '-lalut' reference the linker line:
../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath
Ima Sudonim wrote:
I have co'ed all plib/simgear/flightgear files from CVS a few minutes
ago. I am running autogen.sh and configure before flightgear. However
I am still getting a build break on the renamed files
make[3]: *** No rule to make target `multiplaymgr.cpp', needed by
Pigeon wrote:
Hi all,
Running fgfs cvs, starting up normally at KSFO. Bringing up the radio
dialog and switching COM1 to the ATIS frequency. Sometimes I get:
ERROR - mismatch between ATC .wav and .vce file in ATCVoice.cxx
Are you using the separate alut package from OpenAL CVS?
Ampere K. Hardraade wrote:
A texcopy function that allows one to copy one part of the texture to another
would be useful.
Although it would be doable, one problem with this is that the textures
themselves are stored in video memory so updating them isn't as easy as
it sounds.
Erik
In the process of changing, adding and removing files the last few years
there was the situation where four directories contained just two files,
of which three directories were aircraft related, and one directory
contained test code from Curt that might be better of in SimGear anyhow.
This
Sam Ingarfield - VK6HSI wrote:
Evening -
I am currently trying to compile FlightGear - SimGear, openl, plib etc
have compiled without any errors whatsoever, but for some strange and
obscure reason that i can't figure, the FG compile spits this out -
Dave Culp wrote:
2) Texture cropping for 2D panels so that Attitude Indicator ladders stay in
bounds.
This can be done now by using the texture animations;
texrotate and textranslate
See FlightGear/data/Docs/model-howto.html for more information.
Erik
Dave Culp wrote:
On Sunday 30 October 2005 03:23 am, Erik Hofman wrote:
This can be done now by using the texture animations;
texrotate and textranslate
This works for 2D panels? The document only mentions animations for 3D
models.
Ow, that I'm not sure of.
I guess it would be better
Vassilii Khachaturov wrote:
Since this got no bad comments, and since it fixes the bug, I suggest
applying the patch. The tread starter, with the patch in there:
http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039770.html
It's still in my TODO list, hut I wanted to think a
Josh Babcock wrote:
/usr/local/include/AL/alut.h:17:21: error: altypes.h: No such file or
directory
Huh, is there any chance you have two versions of the header files
installed?
Do I just need to get the CVS version and compile it?
It should not be needed, but it does work.
Erik
Jim Wilson wrote:
Adjusting the near clip plane to 0.10 units (approx 3 inches) is less
ambitious, a bit more forgiving for the 3D modelers, and perfectly adequate.
This sounds perfectly fine to me. It's committed.
Erik
___
Flightgear-devel
Vassilii Khachaturov wrote:
Why are the bells commented out in raindeer-sound.xml?
They do sound cute.
I think it's a leftover from a previous test.
It's corrected now.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Alex Romosan wrote:
i tried to make sure accessor functions which return by reference act
on const objects. also replaced some iterators with const_iterator
and a few return/pass by reference that were missed the first time
around:
Thanks Alex, it's committed.
Erik
Vivian Meazza wrote:
It is entirely possible that the fault lies in the cvs version that I have
here, but I think I have the correct HEAD version.
It looks like your src/AIModels/AIFlightPlanCreate.cxx isn't up to date.
You might want to run cvs up -PdAC AIFlightPlanCreate.cxx
Erik
Josh Babcock wrote:
/usr/local/include/AL/altypes.h:22: error: conflicting declaration
'typedef signed char ALbyte'
/usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous
declaration as 'typedef char ALbyte'
visual_enviro.hxx: In constructor 'SGEnviro::SGEnviro()':
Remove altypes.h,
Vassilii Khachaturov wrote:
http://caliban.lbl.gov/fgfs_patches/flightgear.diff
Great work. I wonder if there is a way to profile fg/sg for this kind
of inefficiencies somewhere in a tight loop.
Ok, these changes have been committed. It's quite extensive but I'm
rather pleased with them.
Jim Wilson wrote:
2) Raindeer in the santa model should be spelled reindeer. It might be a
common misspelling but it is still a misspelling ;-)
Ehr Alright, but only because it's you who mentioned it.
I could have called it rendier instead as it's called in Dutch, but I
chose to call it
Buchanan, Stuart wrote:
How are you driving the panel? From the same box as
the cockpit view (multiple FG instances?)or by using
multiple machines?
I'm quite interested in the possibilities of
multi-display setups, but it feels a bit excessive to
have a box just dedicated to displaying a
1 - 100 of 2467 matches
Mail list logo
