On 09/10/09 14:11, willie wrote:
>> I think the pairing of a DME with a VOR is unchallenged. People
>> (including me) are doubtful about the pairing of a DME with an NDB,
> Here's a real-world discussion showing that they really do exist.
> http://www.pprune.org/archive/index.php/t-77933.html
It
On 09/09/09 14:31, James Turner wrote:
> In practice, all the instruments I've seen so far handle 'parking' the
> GS needle in two ways: either masking layer above the needle, at the
> extremities of the range, or an interpolation table where the extreme
> values map to a particular hidden p
On 09/09/09 06:16, Tim Moore wrote:
>>> Yes, the 2009 code is different from the 2007 code.
>>> The 2009 features and bugfixes are a superset of the
>>> 2007 features and bugfixes. Also the 2009 commits
>>> were rebased so that they applied cleanly to the FGFS
>>> release that was current at the
On 09/08/09 23:10, Tim Moore wrote:
> Is this different from this commit in sportmodel?:
> commit 77a6f88082a74e3187268c9fde4cee49539cae43
> Author: John Denker
> Date: Sun Jun 24 19:11:34 2007 -0400
>
> Fix the azimuthal dependence of localizer service volume ...
>
On 09/08/09 15:18, dave perry wrote:
> [The] note below caused me to ask if the LOC needle deflection is scaled
> differently than the VOR needle deflection in navradio.cxx. It is and
> the comment that it is 4x more sensitive is correct according to notes
> from Instrument Ground School.
1
On 09/05/09 13:22, Torsten Dreyer wrote:
> Looks like this is a chicken-egg problem:
>
> The chicken:
> The model class in multiplayer.nas listens on the
> property /ai/models/model-added and checks for all models the
> property "valid" to be true.
>
> The egg:
> When AIManager attaches a mode
On 08/03/2009 09:04 AM, Curtis Olson wrote:
> I want to know the
> heading and pitch offsets (pan & tilt angles) that will point the camera at
> the target ... while the aircraft flies through any arbitrary position and
> orientation.
>
> I know the target lon/lat/elevation.
> I know the vie
On 03/19/2009 04:43 PM, Lauri Peltonen wrote:
> First of all I'd like to say hi to all as this is my first message to
> this list! Hi :)
Hi. I hope your contributions meet a better fate than mine have.
> Then, when messing around with fg, I noticed that the current atmosphere
> model is somewh
On 01/30/2009 03:44 AM, Tim Moore wrote:
> Give the new version a try please.
All better now. Thanks.
VIRT = 460 peak, 440 steady state.
Readers who aren't closely following the context should note
that we are referring to the "next" branch of _simgear_.
> Point of information: there are 2.6
On 01/28/2009 10:20 AM, Tim Moore wrote:
> Alternatively, try
> starting with /sim/rendering/random-vegetation set to false.
Bingo.
That makes a huge difference. VIRT = 371 instead of 888.
> I imagine there are a lot of trees around KASE...
Yes.
--
On 01/28/2009 09:55 AM, Stefan Seifert wrote:
> "bloat" is a hard word for something, which you did not even measure yet. The
> VIRT column of top is basically useless for getting the memory usage. It's
> just the virtual address space allocated to that process. That includes:
> * memory allocat
On 01/28/2009 02:25 AM, Erik Hofman wrote:
> I didn't check it myself yet, but every once in a while I have to do a
> 'make clean' before 'make install' for this sort of things (both for
> Simgear and FlightGear)
Good advice; thanks.
Alas after doing that, the memory bloat remains, as bad as
This morning I did a git-pull and make.
I observe that the new version executes in 855 megabytes under
conditions where the previous version from a week or two ago
executed in only 450 megabytes.
That seems kinda extravagant.
Is everybody else seeing the same thing?
Specifically I'm talking a
On 01/27/2009 12:15 AM, Martin Spott wrote:
>> Alright, I've updated JSBSim now, including a number of engine files.
>> The following files might need some attention though, since they are not
>> in JSBSim CVS:
>
> Mmmmh, did you make a plan to take care for those models whose authors
> don't r
On Sat, Jan 3, 2009 at 7:49 AM, Torsten Dreyer wrote:
>> The CDI needle can move a little further out, than the outermost dot on the
>> scale. Here, also the receiver detects offsets of more than 10deg, just the
>> display is limited to full deflection.
That is the sensible approach.
On 01/03/2
On 01/23/2009 11:03 PM, Durk Talsma wrote:
> Date: Wed Jan 14 22:13:12 2009 +0100
>
> as the latest commit for simgear.
In which branch? I see that as the latest commit on the "master" branch,
but there is newer stuff on the "maint" branch.
> Also, to test whether this was just me, I did a n
One guy says not to report bugs in the "old" FGPiston,
because it has been "fixed upstream".
Another guy say snot to report bugs in the "new" FGPiston,
because it is not "committed code".
I guess that's one way to make sure there are no reported
bugs.
=
If anybody is interested in
I quote from
http://www.av8n.com/fly/fgfs/htm/bug-list.htm
80::As of mid-January 2008, there is a “new” version of
FGPiston.cpp floating around. It has not yet been committed to
FlightGear CVS. It gets rid of the specific problems mentioned in bug
79, replacing them with new and different
On 01/23/2009 01:40 AM, Erik Hofman wrote:
>> Don't believe everything you read in the docs.
>
> You'd better do, this is the specification of OpenAL.
I was talking about what happens in the Real World.
The "specification of OpenAL" does not supersede the laws
of physics.
There are lots of pla
Two pieces of physics that haven't heretofore been mentioned:
1) Propeller noise is fairly directional. For more on this, see
http://www.google.com/search?q=propeller+noise+directivity
This means that when a Real World aircraft flies past, you will
hear a more rapid build-up and more rapid fal
On 01/22/2009 04:20 PM, James Sleeman wrote:
> Hi John, great answer, thanks..
:-)
>> We see that at the reference distance (r0), the signal is not
>> attenuated at all. That's the defining property of the reference
>>
> So the reference distance is actually the distance from the microphone
On 01/22/2009 02:20 PM, Vivian Meazza wrote:
> Looks good to me. Thanks for the explanation.
:-)
> I suppose we don't allow for
> humidity and pressure?
In the 1/r^2 attenuation regime, none of that matters.
Again, the exponential dissipation regime would be another
story.
> I get the imp
On 01/22/2009 05:47 AM, Maik Justus wrote:
>>> Just to clarify on the reference-dist, is it that this value is a
>>> diminishing effect, that is for reference-dist of 1 after distance 1
>>> the volume is half original, after distance 2 the volume is 1/4
>>> original (half of a half), distance 3
On 01/13/2009 12:43 PM, Torsten Dreyer quoted flying.toaster as follows:
>> The issue is that JSBSIM gets the external atmospheric model
>> (/environment/params/control-fdm-atmosphere set to true in flightgear). I
>> assume that imposes flight gear own atmosphere model to the FDM and THIS
>> mode
Here's a simple patch to give a slightly delayed start to the _repeat_
function for mouse events in the new "3D" pick animation. This gives
the conventional behavior, expected of all user interfaces ... and
not coincidentally, this how the good old "2D" panel does it.
To say the same thing the
On 01/18/2009 12:53 PM, Jon S. Berndt wrote:
>> Newer aircraft are better at it than older aircraft. And that's
>> not a fluke or any kind of "miracle". It's something they design
>> for.
>
> You are simply asserting what aircraft manufacturers are *supposed*
> to do.
You think I am just ma
On 01/18/2009 08:28 AM, Jon S. Berndt wrote:
> With that said, I'd be careful about claiming "ditchworthiness".
It *is* something they design for. It's required by the FARs.
Newer aircraft are better at it than older aircraft. And that's
not a fluke or any kind of "miracle". It's something t
On 01/18/2009 02:22 AM, Erik Hofman wrote:
> I still think the passengers where lucky to have such a skilled pilot at
> the controls...
Not too long ago one of my relatives came up to me and said:
Him: I've always thought you were incredibly lucky, and I
wondered why. Now I begin to underst
On 01/17/2009 10:11 PM, Alex Perry wrote:
> Procedural trainers are useful and the FAA has a minimum specification
> (PCATD) which determines how much fidelity is needed to ensure a net
> positive training value for the student. FlightGear does not
> currently meet that standard.
Agreed. But is
On 01/17/2009 05:47 PM, Curtis Olson wrote:
> You are expecting a complete cockpit enclosure, instruments, radio hardware,
> instructor station software, plush seat, and FAA certification for free?
> The FAA doesn't certify a software application (well unless you are looking
> at a PCATD and even
On 01/17/2009 05:16 PM, Curtis Olson wrote:
> http://www.atcflightsim.com/index.html
If I may be permitted to answer in kind:
http://www.atcflightsim.com/pricing.html
--
This SF.net email is sponsored by:
SourcForge Co
Hi Folks --
I suppose you've heard about the Airbus A320 that ditched
in the Hudson river, in the shadow of downtown Manhattan, on
Thursday. As crashes go, it must be considered a success,
since there were no fatalities and almost no serious
injuries.
Around here it has received around-the-clo
On 01/14/2009 09:49 PM, Alex Perry wrote:
> Laser gyros do indeed behave the way that the wiki page describes.
> Mechanical gyros, such as you find in light aircraft, have other drift
> sources that are considerably larger than the diurnal one. And, since
> the aircraft tend not to move far from t
On 01/14/2009 12:43 PM, Csaba Halász wrote:
> If anybody knows a better value than 0, speak up. It will be slowly
> pulled to the proper value by the low-pass filter anyway.
Initializing it to zero is 100% fine. At this point in
the initialization process, no better value is available.
Actually
On 01/13/2009 12:25 PM, flying.toaster wrote:
> flightgear I assume that imposes flight gear own atmosphere model
> to the FDM and THIS model is stuck after 10 ft
I can easily generate ISA atmosphere data to 71,000 m (232940 ft)
... and beyond that if you wish (to the limited extent tha
On 01/10/2009 11:10 AM, Csaba Halász wrote:
> That approach could also work.
Of course the real problem is that this code should never
have been performing an asin() in the first place. It's
been that way for many years, and it works OK in typical
cases, but it is unphysical and (as we have seen
On 01/10/2009 10:22 AM, Csaba Halász wrote:
>> Clamping it is guaranteed 100% safe and effective.
>
> Something like the attached patch? Not sure what to do about the x == 0 case.
How about this version? It assumes dist is not less than zero,
but is otherwise pretty defensive.
diff --git a/s
On 01/10/2009 09:13 AM, Csaba Halász wrote:
> #2 0x0080188d in FGNavRadio::update (this=0x98df490,
> dt=0.058334) at src/Instrumentation/navradio.cxx:613
> 613 double angle = asin( y / x ) * SGD_RADIANS_TO_DEGREES;
> (gdb) p x
> $1 = 3.2580450943147174
> (gd
On 01/09/2009 02:53 PM, Csaba Halász wrote:
> This usually means that port 5500 is already in use.
Is there any reason why simgear/io/sg_socket.cxx could not return
a more informative error message, one that included sys_errlist[errno]?
That would be better for users. They wouldn't have to gues
On 01/08/2009 04:59 PM, Ron Jensen wrote:
> this has been
> fixed up stream,
Wow. That's great. Perhaps I overlooked the announcement.
Will the fix be coming downstream anytime soon?
Is there any other news we should know about.
---
79::Let’s do an ordinary preflight runup in the c182rg. With the
prop control full forward, advance the throttle to 1700 rpm in
accordance with the POH checklist. Now pull the prop control full
back. In the Sim World as of 1.9.0, I observe the RPM drops from 1700
to 1400. This is highly unreal
79::As of 1.9.0, changing "helvetica-bold" to "helvetica" in e.g.
Instruments/altimeter.xml causes the cockpit/panel loader to
segfault.
a) It would be nice if helvetica were supported.
b) Failing that, if helvetica is called for it would be nice to print
a warning and substitute some s
75:: As of 1.9.0, in the c182, the altimeter is not self-consistent.
There is an analog scale and a digital readout. It takes 10 clicks of
the Kollsman setting knob to move the digital readout ten hundredths
of an inch. It takes 14 or 15 clicks to rotate the analog scale the
corresponding amount.
On 01/07/2009 01:19 PM, James Turner wrote:
> On 7 Jan 2009, at 19:05, Tim Moore wrote:
>
>> I like to fetch and then rebase my local work without merging; it
>> makes
>> it much easier to get the commits into CVS via git-cvsexportcommit.
>> When we move
>> to git and publish (sometimes) perso
74:: As of 1.9.0, the cockpit/panel system will segfault if the
switch statement is omitted from a layer that has
nothing but sublayers. Actually you don’t even need any sublayers; an
empty layer also segfaults:
SIGSEGV
The same of course applies to layers of the undocume
On 01/03/2009 10:04 AM, James Turner wrote:
> I.e, let's just normalise to [-1.0 .. 1.0] and be done with it.
> (Except, as Torsten just noted, the values can probably go slightly
> beyond that, since any clamping should be done at the panel-instrument
> level, not the receiver level).
OK..
On 01/03/2009 08:49 AM, Torsten Dreyer wrote:
> So my question is: why clamp the xxx-deviation-deg properties at all?
> Shouldn't it be a duty of the instrument to define where it hits the border?
I completely agree with TD.
Currently there is no clamp on the GS deflection in
navradio.cxx. Th
On 01/03/2009 08:34 AM, James Turner wrote:
Lots of stuff we agree on
> No, the *deflection* properties really are broken, because they're in
> ambiguous units, I think (especially the magic factor-of-5 multiple
> that started this thread).
As always, I look at things primarily from th
e
> 0.7 degree limit.
Sorry, no. Here's a counterexample:
http://www.aircraftspruce.com/catalog/graphics/11-05106.gif
> Referring back to the ICAO docs that John Denker
> posted, and the Mk-VIII manual, which says 0.0875 DDM per dot on the
> GS, and the ICAO docs say
On 01/02/2009 05:33 PM, Bohnert Paul wrote:
> http://scenemodels.flightgear.org/modeledit.php?id=39 vordme_1
> http://scenemodels.flightgear.org/modeledit.php?id=615 vordme_2
1) Thanks for the points.
2) For folks without "edit" passwords, the following is more
useful:
http://scenemodels.fl
On 01/02/2009 06:26 AM, Anders Gidenstam wrote:
> Just a minor side-note:
>
> Could we find more descriptive property names for these voltage/potential
> difference properties? Just to make it clear what they are (and avoid
> confusion with potential future properties, e.g. for current, charge
On 01/02/2009 03:28 PM, Alex Perry wrote:
>From the point of view of implementation in a simulator, just take the
> actual slope number for a specific runway and combine that with the
> aircraft's position to generate a ratio. Repair the ratio to allow
> for the side lobes (which as I recall are
On 01/02/2009 02:25 PM, Alex Perry wrote:
> Here is a derivative idea. There are several classes of VOR
> (irrespective of the other radio services that might be colocated)
> which determine what the receivable range is ... and whether they're
> usable for jet routes. That change in transmitter
On 01/02/2009 01:37 PM, Curtis Olson wrote:
> I can say from personal experience that Gopher (GEP, 117.30) is really tough
> to spot from the air.
Here's the picture:
http://www.google.com/maps?ll=45.145694,-93.373194&spn=0.012077,0.018539&t=h&z=16
If I'm measuring it properly, it's even big
On 01/02/2009 01:01 PM, Erik Hofman wrote:
> I've modeled them after these images in the past:
> http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg
> http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg
> http://members.chello.nl/vdleije/pics/ssj_vor.jpg
Wow, tho
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small. I've seen them sometimes w
On 01/02/2009 11:37 AM, syd adams wrote:
> Going through the Primus manaul again , and one section states that capture
> occurs at +- 0.5 degrees , and an approach illustration states typical
> capture point at 1/3 dot ... so for the Primus it looks like each dot is 1.5
> degrees deviation...
Whic
On 01/02/2009 05:42 AM, Torsten Dreyer wrote:
>> For designers who prefer real volts:
>>/systems/electrical/nominal = 12
>>/systems/electrical/subnominal = 7
> Doing it that way requires a definition of absolute values in each system and
> for every possible operating voltage.
No, i
On 01/02/2009 02:05 AM, Torsten Dreyer wrote:
>> I don't think a normalized voltage makes any sense. It should be real
>> voltage in volts. Then the particular instruments should check for
>> acceptable input voltage. I must be missing some point, what's wrong
>> with this approach?
That proposal
On 01/01/2009 10:05 PM, syd adams wrote:
> I think i assumed long ago that the GS deflection had a limit of -10 to 10
> like the heading-needle-deflection , and so scaled the needle to the
> outermost dot accordingly.
That is not consistent with what is implemented in navradio.cxx
That instrumen
On 01/01/2009 06:14 PM, dave perry wrote:
> John, I agree completely with pursuing such a standard. Having a
> documented standard would make both AC and instrument modeling easier.
:-)
> Either approach could work and I could live with either. With the
> "jumper" approach, we should also
On 01/01/2009 05:05 PM, Martin Spott wrote:
> Different aircraft are equippped with electrical systems of different
> nominal voltage. You can buy most of the common instruments for at
> least two different voltages,
I have no objection to standardizing on "real volts" so long
as we standardize o
Hi --
On 01/01/2009 01:17 PM, Torsten Dreyer wrote:
> Please find attached a patch as a proof of concept that has been in my head
> for a while now. Here is a short description of what it does:
>
> Check if /systems/electrical/outputs/dme exists (but don't create)
> If yes: use this node's valu
On 12/31/2008 11:46 PM, Alex Perry wrote:
>> If you want more
>> detail than the handwave that the AIM contains, go read the FAA
>> technical manual on how to design and deploy LOC antenna arrays ..
Found it.
In such matters, the FAA defers to the ICAO.
http://dcaa.slv.dk:8000/icaodocs/Annex
On 12/31/2008 11:46 PM, Alex Perry wrote:
> I've observed this variation in sensitivity in practical operations. We
> can get away with using the 0.5 degree rule, but I'd prefer us to
> perform the divide-and-constrain that John describes.
I've got most of the code to do this.
In the absence
On 12/31/2008 06:22 PM, Ron Jensen wrote:
> for what its worth, the in-air dialog could
> set /fdm/jsbsim/gear/unit[*]/WOW to false.
I thought of that.
It doesn't work.
The FDM rewrites the "wow" property at frame rate,
forcing it to 1.
Why it is so insistent on writing a value to the
pr
On 12/31/2008 10:29 AM, I wrote:
> Standard dogma in IFR training is that the VOR CDI indicates
> two degrees per dot, while the LOC CDI indicates half a degree
> per dot. These numbers are quite believable. Good practice
> is to check them as part of the 30-day IFR receiver check.
Important
On 12/31/2008 11:20 AM, Curtis Olson wrote:
> The way this was explained to me is that JSBSim only performs the wow test
> when it is within 200' of the ground. Unfortunately, this means that if you
> start in the air higher than that, the gear variables can be left in an
> unsettled state because
I have a pretty-much workable workaround for the worst
of these bugs.
The big clue is that "presets-commit" apparently just
deletes the old FDM instance and creates another.
To make the new FDM happy, I had to delete a bunch
of nodes from the property tree. Some other nodes
needed to be set to -
On 12/31/2008 06:23 AM, James Turner wrote:
> Reckons 5 degrees per-dot for a VOR, 1.25 for a LOC (yay, the 4x
> factor is sane) and 'about a quarter of a degree per dot' for a GS
> indicator, so the 0.32 term is plausible.
Standard dogma in IFR training is that the VOR CDI indicates
two deg
On 12/30/2008 02:51 AM, Alasdair Campbell wrote:
> I wonder if there is a case for introducing a -v
> (--verbose) option for turning all occurences these statements ON via an
> IFDEF condition.
That's a reasonable question. As previously mentioned, the answer
is SG_LOG. However, AFAICT SG_LOG i
Additional JSBsim FDM initialization-related bugs:
62:: I observe that in a JSBsim aircraft e.g. c182rg, after departing
the runway via the location-in-air menu item, there remains "weight
on wheels". That is, the gear/wow property remains true. It appears
to remain true forever, long after t
On 12/30/2008 02:51 AM, Alasdair Campbell wrote:
> I am currently engaged in trying to solve an annoying problem (bug) with
> the ATIS/real-weather-fetch code.
>
> I find that if I have a comm radio tuned to an ATIS frequency
> in .fgfsrc, fgfs will start up with a default (erroneous) weather
> re
I've been trying to use the
presets-commit
feature ... with less-than-satisfactory results.
All I wanted to do is pop the aircraft into the air, with a
reasonable airspeed, attitude, et cetera.
Note that I set presets/trim {BOOL} = 0 since the trim was
known to be already OK, and be
On 12/29/2008 05:28 AM, James Turner wrote:
> Possibly I'm being a little slow, but what does 'bobble' mean in this
> context? The last time I heard that word, it was referring to a round,
> fluffy ball that might be attached to the top of a child's hat.
According to http://www.yourdictionary
57:: Core feature: As of CVS 26 Dec 2008 I observe that at (say) KJFK
the "Tower" view and the "Tower Look From" view are conspicuously
broken. Other airports are broken, just less conspicuously so. This
appears to be the same problem previously discussed on the devel list
under the heading "
On 12/28/2008 02:19 PM, LeeE wrote:
>> What finally broke this camel's back was the thread about release
>> schedules, but it goes further than that.
On 12/28/2008 03:45 PM, Jon S. Berndt wrote:
> The idea of release schedules for an open source project struck me as odd,
> as well.
Me, too.
>> G
On 12/28/2008 01:31 PM, sydad...@telus.net wrote:
> The "repeat" function is a rather important user-interface feature.
>
>
>
> the pick repeat rate is set with a 0.2
Roger, thanks, that helps.
Here's the patch to make the "new" pick animation behave more
like the good old "2D" panel. This
On 28 Dec 2008, at 15:54, Heiko Schulz wrote:
>> Currently there are two approaches:
>> -making it all 3d. Means that signs, symbols lines are mostly done
>> with 3d-objects. Good example the 787-display
>>
>> -using 2d-layers. Syd is using this approach on his 777 but it does
>> have problems
On 12/26/2008 08:24 PM, Ron Jensen wrote:
>> IMHO we would be way ahead of the game if DP's upgrades
>> had been incorporated in the "library" copy in
>> Aircraft/Instruments-3d/, rather than being confined to
>> a private pa24-only copy.
>>
>> Sometimes it pays to put all your eggs in one basket,
On 12/26/2008 06:26 PM, dave perry wrote:
> John Denker wrote:
>> Question: In the current CVS, why are there five inequivalent copies
>> (six copies total) of kr87.xml?
>>
>> Similarly, why are there four inequivalent copies of kx165*1.xml?
>>
>> And other
Question: In the current CVS, why are there five inequivalent copies
(six copies total) of kr87.xml?
Similarly, why are there four inequivalent copies of kx165*1.xml?
And other examples
Other things being equal, such lack of modularity might be
somewhat suboptimal from the point o
On 12/25/2008 05:07 PM, James Turner wrote:
> What I mean is, for example, EGPH has two
> ILS-equipped runways - 06 and 24, but no marker beacons defined at
> all. KSFO has some, but for example, 28L has an OM, while 2R has MM
> and IM, but no outer. (in nav.dat)
>
> I've just checked my Si
On 12/25/2008 04:21 PM, James Turner asked:
> I was under the
> impression that *every* ILS/LOC approach defined all three beacons - I
> couldn't have been more wrong! What's the real-world situation here?
Please ask a more specific question.
Do you need to know something that's not in apt.da
Remark: Not all of these bug reports are orignal with me. Some
were pointed out to me off-list.
47:: c172p, dhc2, and a tiny bit of SenecaII: As of 1.9.0, apparently
neither the c172p nor the dhc2 have have an outside air temperature
gauge. An OAT gauge is factory-standard equipment for these
On 12/21/2008 09:59 AM, Ron Jensen wrote:
> Given the data available in the configuration
> file, how do we create values for K and a for all engines from the
> smallest engines, like the Rotax582 in the Dragonfly to the Wasp R-5800s
> in the DC6?
This is newly discussed at
http://www.a
On 12/20/2008 10:39 PM, Ron Jensen wrote:
> Here is a dynamometer test report of an engine intended for use in an
> aircraft:
> http://members.cox.net/alg3/Dynamometer%20test%20report.htm
Ah, good, that's useful data.
> Please note especially the RPM v. Manifold Pressure chart at the end:
> http
On 12/20/2008 08:52 PM, Ron Jensen wrote:
> Yes, 2400 is full fine. I asked about full coarse. I was under the
> impression, perhaps mistaken, that you expected the engine to turn
> faster than 1750 rpm with the lever back (coarse):
OK, sorry, most recently I misread course/fine. My bad.
Howe
On 12/20/2008 04:37 PM, Ron Jensen wrote:
>> You don't need to tell me the propeller and engine interact.
>> I'm pretty sure I knew that already. That's exactly why
>> they should be tested separately.
>
> And yet, you are testing them together and posting your results.
I report my results in
I was reminded [off list] that as of 2008, you can get by
without ADF in the US but not necessarily elsewhere.
Therefore I retract my half-suggestion that the ADF could
be removed entirely. Item 22 now reads:
22:: c172p: No GPS? Is it realistic to fly without a GPS these days?
Suggestion: Re
On 12/20/2008 10:24 AM, Ron Jensen wrote:
> Lets look instead at finding out the real reasons why the output
> behavior is not as it should be.
>
> First question, prop_81in2v.xml gives a minimum and maximum propeller
> pitch of 12.0 and 31.8. Any idea if these numbers are right or are they
> ju
On 12/20/2008 02:44 AM, Ron Jensen wrote:
> John,
>
> You've just convinced me you don't have a clue what is happening inside
> this code.
You keep saying that. Even if it were true (which I
doubt), it wouldn't be important.
I call attention again to the scenario I posted:
>> The Sim World c1
On 12/20/2008 01:59 AM, Erik Hofman wrote:
>
> Syd wrote:
>> John Denker wrote:
>>> 46:: Capitalization: Example: As of rc2, on the command line, when
>>> specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
>>> the "W&q
46:: Capitalization: Example: As of rc2, on the command line, when
specifying --aircraft=dhc2W, the "dhc" must not be capitalized, while
the "W" must be capitalized. This does not seem user-friendly. From
the user's point of view, this does not make any sense.
--
Consider the following scenario: The Sim World c182rg is sitting on
the runway at KSFO. The propeller control is pulled back, so that the
engine is operating at relatively low revs, about 1750 RPM in
contrast to redline which is 2400 RPM. The pilot can observe that if
the throttle is open anywhere
45:: Mr. Freeze: Early in the flight, the first time the "v" key is
used to switch to a new view, the display freezes for several
seconds. The machine appears to be CPU-bound during this time;
usually no disk access is observed.
The controls are frozen also, but sim-time appears to pass afte
On 12/17/2008 12:18 AM, Ron Jensen wrote:
> I've made the constant "C" a configurable item, but I don't have a good
> name for it. The patch calls it but there must be a better
> name... I just can't think of one.
Physically, this C represents internal friction. So, maybe
"gagg_friction" or
On 12/17/2008 08:04 PM, Csaba Halász wrote:
> I assume you are not using sync-to-vblank or fps throttle.
That's a correct assumption. Forsooth, I've never heard of
sync-to-vblank or fps throttle in this context. The names
sound nice, but
-- They are not mentioned in --help --verbose
-- They
43:: CPU hog: When the sim is paused, it eats CPU cycles. It will
happily use 99+% of the CPU if there is no competition. I don't
understand why any appreciable CPU cycles are needed during pause.
44:: Memory hog: When the sim is paused, if you leave it alone for 15
minutes or so, it starts
A couple more six-legged crawly things:
41:: c172p: As of rc2, if the pilot is tall or if the pilot's seat is
cranked up high, a weird artifact appears in the field of view. To
demonstrate this, use the property viewer to set
/sim/current-view/y-offset-m to 0.4 (instead of the default value of
201 - 300 of 576 matches
Mail list logo
