On Monday 19 December 2005 21:26, Alex Romosan wrote:
The Interface is deleted and a new one is created.
That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223874848 (LWP 22155)]
This next world scenery build will include SRTM2 data. In the USA I
[snip]
My goal is to have everything done (for this round) by Jan 1 of the new
year. But I reserve the right to push that date back in case I run into
any new glitches.
Thanks! Don't forget to take the rest on the seventh
From your description, it looks like the --enable-game-mode works with the
debian freeglut3 package due to a debian specific patch. Just verified
with freeglut3 and freeglut3-dev/2.2.0-8, it still works as expected here
on a Debian system with the CVS flightgear, i.e., this is not some
breakage
I've tried today the c172r from today's CVS, and had this effect -
the magnetos/electrical switches panel seems rendered OVER the yoke,
no matter how the latter is rotated/pushed, the panel still gets drawn
over it.
http://www.tarunz.org/~vassilii/fg/Images/c172r-switches-over-yoke.jpg
for a
And now comes the attachment... Sorry.
Vassilii
Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v
retrieving revision 1.19
diff -u -p -r1.19
Following Melchior's suggestions of not disabling the axis0/1
as somebody might want to fly a rotorcraft with the yoke nevertheless,
I have modified the patch. Here's what it does now:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the
1) You didn't even try the patch. I didn't either, but I see that
it can't work. Hint: xmllint :-}
I don't know how you see that, because I picked it off working tree.
I tested after that with the new property set to false, true, and
absent.
If you mean the markup in the print statement,
oh, I see what you mean -- the closing tag in the joystick.xml file.
Strange thing I didn't caught it while testing...
Vassilii
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
oh, I see what you mean -- the closing tag in the joystick.xml file.
Strange thing I didn't caught it while testing...
I know what happened. First, I tested it without the joystick.xml change
and it worked (yoke controls the cyclic). Then I put the true in, and it
worked (yoke control of cyclic
Attached are 2 patches for cleaning up some build warnings,
in both simgear and flightgear. Caught with gcc-4.0.
Please apply...
Vassilii
Index: src/FDM/LaRCsim/ls_model.c
===
RCS file:
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
get the menu disabled. Working on that. Comments still welcomed, though.
Great idea. Do that, and I'll rework the CH Products Yoke cyclic hack to
add a
The patch below enables the SimGear doxygen-produced docs
to relate to the sources that were added since last time
the sources list was updated.
Please apply, it's harmless for stability and helps those
using the Doxygen docs.
Vassilii
Index: Doxyfile
I've just tried out the c310 @KSFO, current metar conditions.
The Yasim one develops 38PSI of manifold pressure, ~2700RPM
at props and throttle full forward on the ground, brakes applied.
The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground
roll at the Yasim one's is much shorter.
2) when I hit the F3 to generate the above snapshot, I got an unusual
attitude, from which it was very difficult to recover
Are you flying using the mouse?
Affirmative.
When you hit F3 the cursor is slewed to the bottom left corner of the
screen. If you are using the mouse
Having seen the recent request to try out a list of yasim-based aircraft
from the current CVS, I've tried out the TU154. Here are 3 things I've
noticed:
1) by hand-flying, I was able to get supersonic, pretty low and the
aircraft flew all right, with no fluttering or reaching limits of some
The attached patch does the following things:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the collective.
If one wants to fly and use the mouse as the cyclic control,
it's impossible unless the yoke doesn't send the axis0/1 position
as
2) when I hit the F3 to generate the above snapshot, I got an unusual
attitude, from which it was very difficult to recover
Are you flying using the mouse?
Affirmative.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Last night I noticed that a couple of the yasim-related updates happened
later after my prev. pull. This time tu154 doesn't want to load up at all
(btw this time I am not flying using the mouse, having the CH Products
USB yoke+pedals connected):
YASim SOLUTION FAILURE:
Insufficient elevator to
Flightgear (and any other flight sim) is trying to reproduce the
experience of flying, both in terms of the flight dynamics and (to a
limited extent) the whole experience.
As such, many of the instruments in the virtual cockpit can be
configured with mouse-clicks on the instruments
windowmanagers have a magnifier tool. It can't magnify beyond the screen
resolution of course (640x480 would still be 640x480), but it solves the
problem with blurred tiny characters on small weathered monitors, like
is it not the same effect as if the characters are rendered w/o
antialiasing?
So I'm unsure if it is a good idea to include those patches.
They are harmless, but according to what Melchior has pointed out, some of
the code (what I added to the exceptions classes) is redundant (basically,
what is written there is auto-generated by the compiler unless it has
problems).
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?
What about labelling the fg tree with your own 1.0 pre-release label?
And branching off it, only merging in the
For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG. Others may think, that we lived without
this
Right now I suspect that most users of FG are either developers or
bleeding edge people. But the idea is that that should start changing as
of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely?
FYI: I had been on and off subscribing the fg lists and basically just
the Debian stable package
Could be added to the list of admitted features for 1.0, next
to landing lights ... :-)
Agreed. Esp. because this is mostly a gui XML / trivial NASAL thing.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross schrieb:
Dai Qiang wrote:
I'm wondering, if it's possible to calculate and record the pressure
distribution on all parts of a plane, e.g. gears, wings etc, when
it's landing?
[snip]
Dai Qiang, for what do you need that data?
I can only think of animating the model. This
On Samstag 26 November 2005 19:47, Joacim Persson wrote:
fgfs --airport=EGLL --aircraft=ufo
...puts you in a mysterious place with thick fog, where ground level is
about 6 million m below sea level. This must be the airport of Hell.
While trying to investigate this, I found the
Of course, any changes to the Getting Started Guide will only be present
in the next release for most users, so we'll have a fair few questions
until then...
It's safe to assume that if users are smart enough to RTFM and see the
local docs folder, then most of them will also check the
So I'm unsure if it is a good idea to include those patches.
They are harmless, but according to what Melchior has pointed out, some of
the code (what I added to the exceptions classes) is redundant (basically,
what is written there is auto-generated by the compiler unless it has
problems). For
But ... classes without copy/assignment operator aren't copied
byte-by-byte, but member-by-member[1]. So, for string members the
string copy constructor is used. Again, the code looks right to me
as it is.
m.
[0] Bjarne Stroustrup, The C++ Programming Language, 2nd edition,
p. 582,
Hi Melchior,
thanks for the help.
* Vassilii Khachaturov -- Saturday 26 November 2005 11:02:
But ... classes without copy/assignment operator aren't copied
byte-by-byte, but member-by-member[1].
It's a pity I am at home sick, and without the book. I don't know
what is written
Index: ../../SimGear/source/simgear/environment/metar.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/environment/metar.cxx,v
retrieving revision 1.7
diff -b -u -p -r1.7 metar.cxx
---
Index: ../../FlightGear/source/src/ATC/AIMgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/ATC/AIMgr.cxx,v
retrieving revision 1.29
diff -b -u -p -r1.29 AIMgr.cxx
--- ../../FlightGear/source/src/ATC/AIMgr.cxx 11 Nov 2005
This is just a pinpointing portion of the patch, as it doesn't fix
anything -- since it's all in the JSBsim, and that one is about
to be overridden with another upstream version. Please apply nevertheless
so that we have it in the fgfs code, until that happens --- it's just
comments change.
This is to announce the 3-part patch I have just submitted to the list.
It has been split as follows:
1.
http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040968.html
SimGear-level changes
2.
http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040969.html
I wonder: what does actually happen when you create a static object in
the middle of a method?
Same as if you create it in the beginning of the method :-) it gets
initialized before it's first used, that's guaranteed; whether
it's actually done before the function first runs or before the
block
* Vassilii Khachaturov -- Friday 25 November 2005 15:11:
* whenever an exception object was created on a stack and then thrown
(thus causing the dtor for that object to fire!), it was replaced
with a STATIC exception
The whole thing looks like a solution desperately searching
* whenever an exception object was created on a stack and then thrown
(thus causing the dtor for that object to fire!), it was replaced
with a STATIC exception
The whole thing looks like a solution desperately searching for a
problem. The reasoning for this patch contradicts
I use Borland C++, and the g++ compiler in the cygwin distribution. I
also compile under a flavor of Linux, just to see what happens. I've
been worried that try/catch/throw is something that is not supported
similarly on different compilers.
I've got other priorities right now, but please
I've tried to compile FG with this patches. But there is a problem
Dear Ladislaw,
thank you very much for your help in testing this.
to compile it because
no errno is declared in those files.
I don't know, how it is mentioned, I'm not up to the code. I don't
know how to fix it cleanly. So
I have re-worked the patch into a shorter one.
It has been split as follows:
1.
http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040968.html
SimGear-level changes
Please see the attached simgear-except.diff for the new version of
these, or
Hrm... Why is debian shipping shared libraries for SimGear? As
discussed, that is not the intended deployment mode for the upstream
package (us!), so it seems awfully strange for debian (or Linspire?)
to be making its own decisions there. Does it do the same for plib?
FYI: we do have the
I suppose I could complain that maybe the reliance on an environment
variable to point to the scenery may be great for scenery developers,
but isn't so great for package maintainers who might like to try and
make (say) FlightGear-LakeConstance-Scenery-0.9.9-0.rpm
Rather difficult for the
but you should note that there is no way to feed this terrain back
into the 'official' FlightGear Scenery,
[snip]
I'm pretty sure we will have tools in the near future to merge certain
landcover enhancements into the main scenery. We may have tools to
merge elevation data into the
Like in the dawn screenshot where I tried to show that off;
http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg
[snip]
I don't know anything about the theory of it all, but I do know that the sky
in FG looks truly amazing at dawn and dusk in particular (colours, moon
Yeah, a while back I stopped posting me email address on usenet news.
It gets into the web archives, goes all over the internet and the world,
and pretty soon you are back to measure your spam in messages per second
... :-(
I'm proudly posting my email address on the webpages and never
1) If I fly out of an airport that is located out of the included
sample scenery, then at the command line I get: Failed to open
file repeated twice. I am using 0.9.8 scenery in that case, because
that is all that is available. But there is no indication of what
files are not opening, or
Dear Curt,
please update the links to the getting started and the short reference
guides to point to the newer docs which are now in the CVS. (Or maybe
just copy the docs into the same place).
Currently,
http://www.flightgear.org/docs.html and
http://www.flightgear.org/Downloads/source.shtml
I noticed that on one of your FG pages you mentioned that OpenGL can have
a maximum of 8 light sources. Presumably this is going to cause some dull
rendering issue if we ever had landing lights enabled in a mult-plane
environment?
Good point. Perhaps the non-local models should have a
May be. But once you have landed you are stuck on the runway without taxi
lights. There's no way to leave the runway without bumping into parked
aircraft, towers, windsocks. Releasing a version 1.0.0 in such a state
is a bad idea.
Absolutely. When taxiing, a landing light or taxi light is
Where are they located on the C-172, C-182, C-310 - on the wing or on the
nose like I've seen in pictures of a C-210?
I own the pilot info manuals for various model C-172 planes, so I can look
it up and even scan for you the relevant drawings. Will do in the evening.
V.
I'm thinking, if it's a good idea to add a new
rendering option into FGFS: water shader, which will
make the sea and the experience of carrier taking off
and landing more realistic.
It's certainly a good idea! go ahead.
Here's a screenshot of a game using OpenSceneGraph,
and the technique
Well, there's this:
Format: SNINCR [i/g]
i - Increase in snow level in inches per hour.
g - Snow level on the ground in inches.
I googled for metar snow level :-)
OTOH, various stations have various capabilities, which is (in the US at
least) differentiated by the METAR
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.
The earliest time slot I might possibly have at serious hacking of fgfs is
this Friday night.
However, I would like to give everyone the opportunity to mention
On Mon, 14 Nov 2005, Stefan Seifert wrote:
Buchanan, Stuart wrote:
OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for
*nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows.
I'm sure you meant /usr/share/FlightGear/... and not /var.
I thought /var because of the
I've seen a couple of Failed to open file messages w/o a file,
and decided to hunt for that one. It looks like this is only
thrown from within simgear, but always with a path.
Closer examination reveals that easyxml.cxx throws it, and uses the same
pattern as JSB and I had recently agreed to
Hi All,
As with 0.9.9 we'll be using the FG scenery DB objects, will the default
scenery directory topology be something this
Scenery/Terrain/w010n50
Scenery/Objects/w010n50 ?
I suggest encouraging 2 directories --- 1 for the static scenery
coming with FG, and the other one for the
Additionally no one should run terrasync as root anyway, so it can't
write to /var/share/FlightGear. terrasync users should have their own
scenery directory in their homes or anywhere their user is able to write.
Nine
I agree.
User data (like from terrasync) belong to
Terragear is sufficiently crude and unrefined and user unfriendly that I
think we should leave it out of the getting started guide. We are going
to send unsuspecting users down a wild goose chase and they'll be
disappointed. We can mention it and forward them to more information,
but I
Help Help from the gui on mac os x is still broken.
The help application is STILL set to netscape even after the
options.cxx change
Doesn't it mean that something resets it between the options parsing and
the GUI help stuff processing? I'd rather see a patch that finds
the offending code
Forwarding a notice about fgrun over to flightgear-devel,
as per Bernie Bright's suggestion. Please see below,
if you feel like patching fgrun.
-- Forwarded message --
Date: Mon, 14 Nov 2005 09:28:39 +1100
From: Bernie Bright [EMAIL PROTECTED]
To: Vassilii Khachaturov [EMAIL
$ fgfs
opening file: /usr/local/share/FlightGear/Navaids/carrier_nav.dat
/usr/local/share/FlightGear/Navaids/TACAN_freq.dat
RenderTexture Error: glXCreateGLXPbufferPtr() failed.
Initialising callsign using 'Aircraft/c172p/Models/c172p.xml'
freeglut (fgfs): Failed to create cursor
freeglut
On things like Debian, this is also wrong because sensible-browser
should be used instead. Is there some autoconf library function to
discover the most likely browser on a system?
Also the WIN32 section in src/GUI/gui_funcs.cxx with the 1024-long
hardcoded buffers can be a crash trigger when the
Maybe some German-speaking user could point the reporters to Atlas
for the moving map solution they describe as absent (and to the new
Pigeon's map!)
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Here's what I'm doing:
In the Table class:
In FGTable constructor:
if (operation_types.find(parent_type) == string::npos) {
internal = true;
} else {
throw(string(An internal table cannot be ...));
}
Now, this seems to work OK - I throw an exception if a situation
occurs that is
OK, is there a way to get sensible-browser at compile time? Is this a
link know to the OS or something? is it callable or does it need to be
read on Debian somewhere?
It's a callable standard script on debian.
It tries various intelligent decisions to guess what browser to run.
It is pretty
I probably would do, but I don't have any experience with Atlas at all,
so I'm unable to give appropriate response to the questions that I
suppose will follow
It's pretty straightforward, just give it a try following the WWW
instructions. Be sure to use the CVS version and not the last
I am unable to get 3d clouds with todays CVS for FlightGear and data and
SimGear. I am running via fgrun and 3D clouds is checked and
--enable-clouds3d is in the list under the show command line window.
I also ran fgfs from the command line with --enable-clouds3d and still
no 3D clouds. In
Unknown exception in the main loop. Aborting...
Possible Cause: No error
This makes me report the following seemingly related sighting
that I had today in the middle of something else, w/o exploring it until
the end (I did mention it on the IRC earlier today).
I've seen a couple of Failed to
Yep, but sipmly _delaying_ the next release doesn't cure anything.
This only makes sense if the developers agree on a feature freeze and
announce a bugfix-only phase.
..or if it can be enforced somehow. ;o)
or that a separate branch is created for the feature freeze while the
development
Just a suggestion:
Maybe it is a good idea to put some of the important rules on the
http://www.flightgear.org/mail.html webpage so people can read them, before
they subscribe to the mailinglists.
Good idea, in case someone really is annoyed with top-posts/encodes etc.
Such folks are welcome
3). J3 - The J3-Cub is complete (not much to cubs anyway) and easy to
fly for someone just starting out.
A real life Cub has a ball slip/skid indicator (just like in a turn
coordinator), and a wire sticking out of the fuel cap in front,
showing the fuel level. Other than that, it's pretty
Thanks for applying the patch to the current code.
I wonder what the jamming logic should be instead. Maybe check
whether the angle between the cockpit Y axis and the resultant force
presently acting on the plane is within some limit?
I have no problem checking the angle above (based on the
3
Next on the list are
the Nat. Cathedral, Basilica of the Immaculate Conception, Mormon
Temple, Pentagon and then the Mall. Not sure what timetable I'm
looking
at though. If you can think of any other big visible structures
that you
would like to see (sorry, I'm not tackling the
Did you upgrade your data from the cvs?
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
I would like to see all new scenery object contributions to end up in
the scenery database. However, the last time I wanted to sync the base
package and the DB there were more than one objects in the same space
because of automatic object generation.
btw it looks pretty cute sometimes ---
Since when the search via the input is used, the dialog is closed, I suggest
to auto-close it when a nearby-ATC button is hit as well, as per the patch
below.
Alternatively, we can rename the OK button to Search and DON'T have it
auto-close the dialog. The question is whether mostly you use
In the light of the recent multiple 0.9.9-pre1 commits I've been going through
the list of open issues that worry me and this one
When I start the CVS version at the UG25 airport with bo105 (yesterday's
CVS data, the day before CVS sources), it core dumps on startup as
follows:
[snip]
The
This is to say a huge thanks for the keyboard accelerators.
All the times I had hit ESC to close a dialog during
low-level maneuvering (and then cursing because of an extra
dialog I had to close or tolerate on my windshield) are now
history! The ATC xmission menu change is also very handy
for
A very cool user-felt feature is Vivian's redout/blackout, currently
implemented in the hunter. Please add it to the list.
I couldn't resist from taking the following picture that shows the redout
sphere from the side:
http://www.tarunz.org/~vassilii/fg/Images/hunter-redout.jpg
Hey, someone noticed :-) It was fixed in cvs Thursday last though.
:) Of course, I keep looking at the CVS commits since I am learning FG.
Actually I kept thinking of doing this one myself, since nobody answered
my challenge yet to tell me about smth interesting to do for FG while
learning GL.
With either jsbsim or yasim aircraft, when is in the vicinity of the
(North) pole, the AGL (as seen in the HUD) goes into 2*10^7 ranges. You
can either start up with --lat=90 (and any longtitude you please), or, if
you dislike the singularity of --lat=90 at the startup, use --lat=88 and
head
Mathias Fröhlich:
I have now fixed the problem that flying below bridges was broken by some
groundcache work.
Thanks a lot!! this is a very important eye-candy feature --- one of the
bigger ones to draw folks to fgfs tryouts over here :-)
___
Index: ../data/Aircraft/Hunter/hunter-set.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Hunter/hunter-set.xml,v
retrieving revision 1.13
diff -u -r1.13 hunter-set.xml
--- ../data/Aircraft/Hunter/hunter-set.xml 1 Nov
while waiting for your advice on the subj matter, I have found
the CVS source for the flightgear site ---
(BTW, is the site material in the CVS somewhere, so as to make it
easier to send the patches against?)
it's in the www module of the same CVS repository --- and had
sent a couple of minor
I have just recently got FG working and it has turned out to be a pleasant
suprise - anyway just wondering what the status on Multiplayer is.
Please have a look at the README.[Mm]ultiplayer in the CVS.
___
Flightgear-devel mailing list
Dear fellow developers,
I've decided to upgrade my fgfs addiction from just submitting
janitorial/small nagging feature patches to a next level --- specifically,
I've begun to study the GL APIs and would like to help the project with doing
some graphics-related programming.
While I used to do
Dear Melchior,
thanks a lot for the descpeckler script. I actually lifted it off your
page yesterday and came on to the irc to say that it rocks, but you were
not there. I used it on c150 which was the most irritating speckle-wise.
I suggest you commit it to the utility scripts section of the
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
V.
___
Flightgear-devel mailing list
On Thu, 27 Oct 2005, Harald JOHNSEN wrote:
Bohnert Paul wrote:
All,
When the 150 was statred it was postioned with it's
wheels below the runway surface. Adding z-m offset and
[snip]
You should try the lastest cvs version, commited a few days ago. The
plane should be
above the ground
In the recent 737 autopilot change,
we see that the only improvement is the change of the target speet.
diff -u -2 -r1.15 -r1.16
--- 737-set.xml 18 Oct 2005 16:32:23 - 1.15
+++ 737-set.xml 27 Oct 2005 08:34:40 - 1.16
@@ -110,5 +110,5 @@
target-altitude-ft
On Thursday 27 Oct 2005 20:20, Vassilii Khachaturov wrote:
In the recent 737 autopilot change,
we see that the only improvement is the change of the target
speet.
[snip]
Hello Vassilii,
these aren't 'hardwired' values but defaults. The values
declared here, in the aircraft 'set
When this is done on the FG c150, the engine stutters (FDM program fuel
starvation on neg-G?)
According to the HUD, it stutters at about +0.30G.
In the real aircraft, we could make 0G manouevers that could last for a
couple of seconds without the engine missing.
In a real gravity-fed
reply from David
-- Forwarded message --
Date: Mon, 24 Oct 2005 17:55:31 -0400
From: David Megginson
To: Vassilii Khachaturov
Subject: Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code
(fwd)
On 23/10/05, Vassilii Khachaturov [EMAIL PROTECTED] wrote:
i've sent
On Mon, 24 Oct 2005, Robin Peel wrote:
Paul:
In general, X-Plane only supports water runways at designated seaplane
bases, not as additions to terrestrial airports (I forget the reason, I am
afraid). I will look into whether they can be added back.
I do recall that PHNL has this
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.
A couple of comments:
diff -u -r1.43 AIBase.hxx
--- src/AIModel/AIBase.hxx 15 Oct 2005 14:55:51 - 1.43
+++
Why are the bells commented out in raindeer-sound.xml?
They do sound cute.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
On Mon, 24 Oct 2005, Martin Spott wrote:
Vassilii Khachaturov wrote:
H even an empty aircraft doesn't get blown away that easy.
I can't believe it will be blown away by anything under 15 knots,
especially with the brakes engaged.
This is correct. At least you can land and taxi
-string ConvertRwyNumToSpokenString(string s) {
+string ConvertRwyNumToSpokenString(const string s) {
this should be string ConvertRwyNumToSpokenString(const string s)
so we don't make unnecessary copies.
-double dclGetHorizontalSeparation(Point3D pos1, Point3D pos2) {
+double
Another problem I forgot to mention:
before the update, I had the aircraft painted with a white-beige
scheme outside (albeit one of the 2 sides was a mirror inverse
of the other, including the tail number written in a mirrored font).
After the update, it looks dull grayish on the outside, as if
1 - 100 of 160 matches
Mail list logo
