Norman Vine wrote:
> since we are now agnostic as pertains to the lowlevel OpenGL
> initialization routines I don't see why the choice of OpenGL toolkit
> used couldn't just be an option
Uh, that's the whole point. What would you prefer, if not SDL? If
you want to write a windows-only implementa
Erik Hofman wrote:
> JSBSim does basically the same (although there is a name allocated
> for it), but the real question is: Is left most defined 0, or is
> right mos define d0, or is it something completely different
> (numbered in order of appearance)?
Maybe I'm confused: why do we care? The "0
Erik Hofman wrote:
> This way it is easy to change the YASim or the JSBSim or the
> animation configuration file to match each other. Fixed (non
> compatible numbers) don't allow for that.
I'm not arguing against having names for the gear, which actually
sounds kind of elegant. But it should be p
Norman wrote:
> Out of curiosity what can't you do today that would make FlightGear
> better because we are using GLUT that you would do differently today
> if we were using SDL and what exactly is it that would make FGFS
> better.
Off the top of my head:
+ Build out of the box on Fedora, which n
Curtis L. Olson wrote:
> I understand that there are (or at least were) issues between SDL
> and cygwin, but perhaps it would be more productive to address that
> problem directly ...
Ah. I honestly didn't know this. I just assumed that cygwin was one
of their native platforms. I just checked,
Curtis L. Olson wrote:
> Probably the best short term solution is to make sure we can build
> with both SDL and glut and let the builder decide?
Sure. This should work right now. The only bits missing are the
autotools magic to do the detection and set up the makefiles
appropriately. I fear aut
Norman Vine wrote:
> FWIW I would be much more excited about this if we were switching to
> a library designed for highend simulations such as OpenProducer
> which by the way also has a portable threading library OpenThreads
The argument is still open. Sell us on OpenProducer. I've never
heard o
Curtis L. Olson wrote:
Today (I *think*) [...]
Yeah. Daylight savings time always confuses me too. :)
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Melchior FRANZ wrote:
> Isn't. Key combinations with Alt and Meta are neither
> processed (Alt-Tab) nor forwarded to the DE (Meta-F1). They are
> simply dismissed, which is bad, because they are used for
> interaction with the the desktop (Meta-F1 is supposed to switch
> to Desktop 1 here).
To my
Melchior FRANZ wrote:
> Oh, and the geometry isn't restored after exit. fgfs/SDL switches to
> 800x600 when called without --geometry, and leaves it at that. One
> has to call it again with the geometry that one wants to have
> afterwards.
Known issue. Lots of places in our source tree like to ca
I wrote:
> Melchior FRANZ wrote:
> > Isn't. Key combinations with Alt and Meta are neither
> > processed (Alt-Tab) nor forwarded to the DE (Meta-F1). They are
> > simply dismissed, which is bad, because they are used for
> > interaction with the the desktop (Meta-F1 is supposed to switch
> > to Des
Melchior FRANZ wrote:
> What I really, really want is: switch to another desktop and write two
> lines in "konversation", or look at Atlas, or check for mail,
> etc. Without the possibility to switch desktops (despite running fgfs
> in fullscreen mode) SDL is completely out of question for me. I'll
Curtis L. Olson wrote:
> If SDL can't switch to other virtual desktops when running
> fullscreen/no-window decorations, then perhaps would there be a way
> to toggle between fullscreen/window mode so that once you are
> running in a standard window again, then you can hotkey between
> virtual deskt
Melchior FRANZ wrote:
> There's a workaround under KDE that makes SDL as usable as glut:
> $ kstart --fullscreen fgfs
What does that do?
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-d
I wrote:
> Melchior FRANZ wrote:
> > There's a workaround under KDE that makes SDL as usable as glut:
> > $ kstart --fullscreen fgfs
>
> What does that do?
Never mind. We can't use that: it's a brutal window management hack
that grabs the window at creation and diddles its properties before
the
Jon S. Berndt wrote:
> I'm trying to build an application in gnu fortran (g77) but I end up
> with these link errors:
>
> undefined reference to `__umoddi3'
> undefined reference to `__udivdi3'
Those look like the software math emulation stuff implemented in
libgcc. You could try adding -lgcc to
Curtis L. Olson wrote:
> Ok, since you have your head into this at the moment: With X11, is it
> possible to run an SDL app in window (so it behaves well with the
> window manger) but in a window that fills the entire screen and is
> undecorated (so it looks "full screen")?
Sadly, no. Even if it
> How can this be a "wrong way" to run an app?
It's a fine way, just not the only one. Most people run their
desktops at high resolutions that may not be good choices for a 3D
buffer. Older cards (like the Radeon 7500 in my laptop) can handle
FlightGear just fine, but not at 1280x1024.
And some
Curtis L. Olson wrote:
> So I still don't understand, is SDL unable to open a window covering
> the entire desktop but with no window decorations? Or can this be
> done?
No. Well, yes. It's complicated. :)
SDL *is* opening a window covering the entire desktop but with no
window decorations. Bu
Jorge Van Hemelryck wrote:
> This is a patch (plus examples of use) I've created to solve the
> problem we had at work. Short explanation - the aim was to have a
> separate HUD code (as opposed to included in the FlightGear code).
>
> Long explanation - the easiest solution I saw was to develop a p
Jorge Van Hemelryck wrote:
> We already have an external HUD code. Actually, it is quite large,
> [...] and more importantly it can't be distributed. At all.
That was my fear. Opinions differ (widely!) on this point. But in
general, adding a dynamic loading API to a free software project for
the
Jorge Van Hemelryck wrote:
> Is it not possible to just include my work (with some improvements
> such as conditional compilation of the functionality) with the
> distribution of FlightGear ? It would make my task of making people
> accept FlightGear here easier...
But you seem to miss the point.
Erik Hofman wrote:
> I'm not sure what to think about this, but ... We already allow for
> things like this and I can see the need to drive external HUD code
> from within FlightGear (if nothing else for FlightGear's own HUD code
> on a separate display).
My understanding was that this was a patc
Jorge Van Hemelryck wrote:
> The GPL requirements are in no way removed, of course.
OK, excellent. My fear was that your management/team was afraid the
GPL, and you were trying to sell them on this patch as a way to "get
around" it.
But do be aware that this stuff is complicated. An FSF interpr
Jon Stockill wrote:
> That's because Linus made the exception - not because it's allowed by
> the GPL - in effect he extended the rights granted by the GPL (this is
> allowed - it's restricting rights that's forbidden).
You're thinking about the exception for running programs, which
appears at the
Durk Talsma wrote:
> It looks like the crash is somewhere inside the AIMgr (judging from stackdump
> item #15), but since I'm still incredably unfamiliar with this part of the
> code, this might just be a wild guess.
>
> Anyways, I hope that this is useful debug information. Can others
> confirm th
Lee Elliott wrote:
> I first reported this on 02-April and had updated from cvs two
> days prior to mentioning the problem. I think the last update
> I'd done before that was about two weeks earlier.
Can anyone confirm the same behavior from the 0.9.4 binaries? (I
think it branched sometime righ
Jon S. Berndt wrote:
> Where in the FlightGear code are command line options parsed?
They're XML-controlled and map to properties at runtime. You can add
new ones in options.xml in the base package. The actual C++ code is,
I think, in Main/fg_options.cxx
Andy
__
Erik Hofman wrote:
> Andy Ross wrote:
> > Can anyone confirm the same behavior from the 0.9.4 binaries? (I
> > think it branched sometime right around there.) Is there any
> > platform dependence to this? I have to admit it's been a long time
> > since I'v
I found something that might be a candidate for the overflow. Around
this timeframe, some sprintf("%f") code got added to the atis handler.
The problem is, printf() can generate almost unbounded output for very
large values* and the buffer is only 10 bytes long.
* Try this: int main() { prin
Ilja Moderau wrote:
> - engine sound in cockpit does not differ from outside engine sound
> - no cockpit light at night visible
These two are relatively easy. The "outside" sound handling will
probably require some code, but nothing difficult.
> - no jetstream visible
I assume this means contra
Gene Buckle wrote:
> Andy Ross wrote:
> > [...] otherwise forgettable "Strike Fighters" game [...]
>
> I don't know why you'd call it forgettable. There's a huge
> following that's been making new aircraft and other things for
> it.
It&#
Durk Talsma wrote:
> I assumed that your latest yasim fuel code had a lot to do with
> this, which would explain why the cvs 747 is performing so much
> better (i.e. longer)
Heh, that's because I cleverly introduced a units bug (kgs/lbs) in the
process. :)
It's fixed now, so the 747 should be a s
Durk Talsma wrote:
> I experienced (some of) these pauses as well when I built FlightGear
> without threading support (See my bug reports on fgfs-devel last week,
> the "smoother performance" refers to the absence of the pauses
> :-)). After enabling threading again, the pauses went away. So my
> g
Roy Vegard Ovesen wrote:
> Is there any way to play sounds from a Nasal script?
Sort of. The current sound model is property-driven. You can create
a new sound event (see the *-sound.xml files under Aircraft for
examples) and drive it from a given set of properties. You can then
set those prope
Curtis L. Olson wrote:
> Andy, one thing that would be useful would be a
> globals->get_commands()->addCommand() type function that would load
> and play an arbitrary sound file. I don't know if there is a nasal
> interface to these commands but if not, that would be a useful thing.
> These comman
Roy Vegard Ovesen wrote:
> Very simple. I just want to make a beeping sound or a number of
> beeps to use when the autopilot is disengaged (or any other audible
> annunciators).
If it is aircraft-specific, then the mechanism of putting it into the
-sound.xml file is probably exactly what you want.
Roy Vegard Ovesen wrote:
> I don't think it's possible to put sound configurations into the
> instrument configuration XML files, or is it?
No, it has to live under /sim/sound/fx in the global property tree.
We can make a set of "global" sounds in preferences.xml (or something
included from there)
Vivian Meazza wrote:
> wastegate-mp="18.32"
> [...]
> mp-osi = 26.050 - does the "wastegate" work? - is this psi?
The units are absolute pressure in inches of mercury (I honestly don't
know what the "-osi" suffix means). The wastegate should indeed work.
However, it is an overpressure release val
Vivian Meazza wrote:
> YASim crashes, or perhaps, fails to converge, just by
> attempting to run with takeoff-rpm="1360">
Crashing and solution failure ought to be easily
distinguished. :) Maybe the recent logging changes have hidden
the failure message, I'll take a look.
Try running the command
Vivian Meazza wrote:
> With these values
>
> eng-power="1140" eng-rpm="2850"
> cruise-power="2850" cruise-rpm="1359"
> takeoff-power="1100" takeoff-rpm="1359"
>
> YASim appears go into a loop and provides no output.
These settings don't make much sense in combination.
The "eng" setting
Vivian Meazza wrote:
> The "takeoff" values. Are these the power absorbed by the propeller
> at propeller rpm, or the engine output at engine rpm, super- or
> un-supercharged?
Un-supercharged. And the equations are solved such that both power
values are the same. Basically, don't sweat this one;
Jon S. Berndt wrote:
> undefined reference to `___gxx_personality_v0'
> undefined reference to `__Unwind_Resume'
> ...
Those are internal g++ things. It looks like you upgraded your
compiler without doing a full rebuild? Versions of g++ are not
binary-compatible between versions*.
Andy
* Well,
I wrote (incorrectly):
> The "eng" setting is a maximum power (at standard sea level) for the
> engine without supercharging.
Never mind the last part. The code *does* correctly handle the boost
setting, and assumes that it is at maximum (in most cases, the
wastegate setting) at the specified pow
Giles Robertson wrote:
> Not that I've noticed. It would be useful for mingw32. I've tried
> building on that, and it compiles fine, but the linker fails because
> the input is too long ;).
The linker fails with long file lists? That sounds odd -- this is the
same linker used in Linux, and it's a
Vivian Meazza wrote:
> However, eng-power should be the un-supercharged max power, so I reduced
> eng-power value,
No no, I was wrong. Use the superchared value, the eng-power gets
corrected before solving to assume "max" sea level manifold density
(i.e. with boost and wastegate applied).
> Is i
Lee Elliott wrote:
> While I remember, if a YASim a/c only has one tank, the second tank -
> tank[1] - seems to be set with a 'nan' level. Doesn't stop the a/c
> engine from starting or running but it screws up the tot fuel figure.
> Setting the level for tank[1] to zero via the property browser s
Vivia Meazza wrote:
> As does this (2):
> cruise-speed="308" cruise-rpm="2850"
>
> This does not (3):
> cruise-speed="308" cruise-rpm="1360"
Again, these are *wildly* different propoellers you are
specifying. The second one is going to end up with four (!)
times the fo
[Starting a new thread. The reply nesting level in my mozilla window
was getting freaky.]
Vivian Meazza wrote:
> The engine I'm trying to specify developed 1140 HP at engine
> revolutions of 2850 rpm at a boost pressure of 9 psi. It was fitted
> with 1:0.477 reduction gearing, which I think mean
Vivian Meazza wrote:
> Here are some calculations on propeller rpm.
> [...]
> We can see that 2850 is unlikely to be the rpm of a 10.75 diameter
> propeller
Yeah, you're right. This is a real bug. I was playing with it this
morning, and we're hitting an edge case in the propeller solver.
The pr
Luca Masera wrote:
> about YASim: in which units is measured the oil pressure?
> In JSBSim the value is holded by "oil-pressure-psi" and it's
> measured in psi; in YASim is holded by "epr" but the units
> are missing.
Er, that's an Engine Pressure Ratio , which is a thrust metric used in
early jet
David Megginson wrote:
> How about allowing the config to contain a couple of sample values
> and then interpolating (taking into account outside temperature,
> engine temperature, and power setting)?
Sure. That was the idea with the Nasal script, actually. Set it to
poll every second or so and
Curtis L. Olson wrote:
> 3. The maximum pitch factor that OpenAL allows is 2.0 ... we blow
>by that with some of our sound configs ... that's another
>thing that will need to be tweaked and looked at.
We can do the down-sampling manually and choose the right one at
runtime; basically mipma
Hermann Schiffer wrote:
> > The Merlin is a rotary engine, isn't it?
>
> A rotary engine ? As in http://travel.howstuffworks.com/rotary-engine.htm ?
He meant "radial", of course, which was true of most WWII era aircraft
engines other than the Merlin.
And if you really want to nit, what you descri
Durk Talsma wrote:
> I've seen this as well, but as far as I can tell, this is due to the
> wind blowing against the tail. I've seen this more stronger with heavy
> winds, and the yawing of the aircraft in heavy winds appears to change
> with changing rudder position, as I expected.
It's a misfeat
Lee Elliott wrote:
> will this require an OpenAL (dev) package to be installed, or will
> everything needed be included in the FG source?
It will require OpenAL to be installed separately. I just did it
under linux, and it's a relatively benign "./autogen.sh && ./configure
&& make && make install
Ampere K. Hardraade wrote:
> Weird how the X-axis runs lengthwise in FlightGear, while the Y-axis
> runs sideway.
What convention would you have chosen? :)
Coordinate systems are like cuisines. There's no accounting for
taste, and you can't fix things by mixing them together.
Andy
Innis Cunningham wrote:
> I am just wondering is there a very good reason that we use zero to
> number things in FG. Engines tanks and the like. Because in the real
> world of aviation nothing is numbered zero as far as I know.
>
> Why does it matter you may ask. Well it seems a bit strange that
Mathias Fröhlich wrote:
> May be this 'do not use a leading slach' should also show up in that
> model animation HOWTO?
Or even generate a runtime warning during parsing. This is a really
easy typo to make.
Andy
___
Flightgear-devel mailing list
[EMA
I just commited an implementation of GUI layout management, ported
over from my game project last year*. What this means is that you no
longer need to position your widgets manually in dialogs, and can
instead lay them out in tables and boxes like the pros do. :) I've
redone a few of the dialogs u
Curtis L. Olson wrote:
> I can't seem to set autothrottle speed with the new autopilot
> dialog. It keeps reverting 1.0 (might there be anyway to
> trim the trailing zeros?)
Oh, whoops. Sorry, I meant to fix this before I checked it in but
forgot. Both the pitch and speed input fields a
I wrote:
> Curtis L. Olson wrote:
> > I can't seem to set autothrottle speed with the new autopilot
> > dialog. It keeps reverting 1.0 (might there be anyway to
> > trim the trailing zeros?)
>
> A better solution would be to either write some Nasal to keep the
> values synchronized or else
Lee Elliott wrote:
> Was the stencil shadow stuff for generating object shadows? How far
> off usable was it, and did it only work with your terrain engine?
It was decidedly "demo" quality. But it was part of the model code,
not the terrain engine. Doing shadows on terrain is sort of a 2D
probl
Giles Robertson wrote:
> Just got an error on the following compile:
>
> In file included from C:/msys/1.0/fg/include/plib/pu.h:2140,
> from layout-props.cxx:1:
> C:/msys/1.0/fg/include/plib/puGLUT.h:36:22: GL/glut.h: No such file or
> directory
My fault; I Forgot to test the build
Ampere K. Hardraade wrote:
> hmm... if FlightGear is to be as realistic as possible, it will be a
> good idea to simulate everything down to the very last detail.
>
> Perhaps a translator of some sort can be written?
I can't quite tell if this is a joke or not. If it is, then accept my
apologies.
Bruce Finney wrote:
> Andy Ross wrote:
> > Real Programmers count from zero. Always have, always will.
>
> NOTE: FORTRAN programmers count from 1, always have, always will!!!
So we agree. :)
Andy
___
Flightgear-devel mailing list
[
Vivian Meazza wrote:
> As you can see, it "flies". The engine/propeller combination is
> a horrid bodge in YASim. Very unrealistic performance. Looking
> forward to resolving that issue.
I actually thought it was resolved. Did the recent changes not
work for you? I can only fix bugs that are rep
Jim Wilson wrote:
> Erik Hofman checked in:
> > Make it possible to define a tag in the joystick
> > configuration file. This would make it possible to have different
> > configuration files for Windows. Possible values are: Windows, UNIX
> > or All. Not specifying the tag equals to 'All'.
>
> Ju
Roy Vegard Ovesen wrote:
> I get this error when compiling ATCVoice.cxx
It looks like you did a CVS update in FlightGear without grabbing
the required changes from SimGear. Curt changed the API
yesterday.
Andy
___
Flightgear-devel mailing list
[EMAIL
David Luff wrote:
> I also got that output from autogen.sh, also on Linux - it appears
> to be harmless. Make went fine on Cygwin. No audio output from the
> test programs on Cygwin though :-(
It's important to point out that the "linux/src/arch/windows"
directory in the OpenAL source distributi
Erik Hofman wrote:
> After endless times of no discussion and no solutions I hacked
> something together that works for every situation. Not acceptable
> won't do in this case unless I see something show up that is elegant
> and that works in every situation.
Agreed. We need to get something actu
Here is a page where someone claims to have windows OpenAL building
under MinGW (strictly under a linux cross compiler, which is basically
the same thing). This will/should produce a GNU .a file which you can
use with cygwin.
http://omapi.sourceforge.net/extra/
I'll boot to windows and see if
Melchior FRANZ wrote:
> Whereby "unix" would be an alias for "n" and the line could also be
> written as
>
>
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available i
Jim Wilson wrote:
> Not knowing any better, that would be my guess. Is there a bit being
> toggled by the _nix drivers? Or is this a completely unpredicatable
> effect of the way windows drivers work? If not it seems like this
> would be a multiplatform bug in plib.
I think both platforms are p
Marco Gugel wrote:
> I would like to have an explanation regarding the yasim xml config file.
> In particular I want to know more about the coordinate system used on this
> file.
There is a README.yasim in the base package, in the Aircraft-yasim
directory.
The YASim coordinate system is "X forwar
Frederic Bouvier wrote:
> axis 2 and 3 need to be exchanged
> Linux 2 == Windows 3 == rudder
> Linux 3 == Windows 2 == throttle
> axis 4 and 5 are hat on Linux and becomes 6 and 7 on Windows.
>Linux 4 == Windows 6 == left/right
>Linux 5 == Windows 7 == up/down
This isn't universall
Melchior FRANZ wrote:
> Here's my take on the discussed problem: Add an alternative
> attribute "n_win" to all "axis" definitions that should be different
> in Unix and Windows.
Well, once you overcome the initial revulsion to the fact that the
core, low level property array indexing API is being
Frederic Bouvier wrote:
> No, we want to define a key differently according to the language,
> but it is another problem. Do you want to add n_french, n_spanish
> also ?
You don't map keys according to language. The '$' key ("keysym", in
X11 lingo) should always create a dollar sign. Non-US keyb
Jim Wilson wrote:
> Is this still true? I'm running KDE and can't remember the last
> time artsd got in the way. To be honest though, I don't recall what
> changed. Maybe I just turned off most of the stupid sounds in the
> kde apps.
My impression was that recent versions of arts and esd releas
Norman Vine wrote:
> Unfortunately I do not have the time to support the libraries I port
> so I do not submit them for inclusion with Cygwin but the official
> method of doing this is here http://cygwin.com/setup.html
I suspect the OpenAL people should be the first ones to contact. I
doubt the C
I actually got interested in all this windows stuff yesterday (no, I
can't explain why), and played around with getting it built. Here's
the proof:
http://plausible.org/andy/fgfs-mingw.zip [2.3 MB]
It's a MinGW* build, using SDL and OpenAL. It works, with sound and
video mode switching. The
Marco Gugel wrote:
> My idea is to develop a truck simulation inside FlightGear and I
> have thought to start from Yasim because it uses the rigidbody
> dynamics;
Right. That's the RigidBody/Integrator/BodyEnvironment
implementation. You set masses on the body, calculate forces inside
the enviro
Curtis L. Olson wrote:
> Anyone want to take a crack at a new FDM model for the Beech 99
> as well? You could probably start with the data for the UIUC
> model and go from there.
The Beech 99 is a turboprop, which means that YASim is going to
need new code to support it. I'd be happy to write it
Lee Elliott wrote:
> It looks like the fuel was being taken from each tank at the same rate
> instead of proportionally, depending upon their capacity, with the
> result that the external wing tanks were emptied while the other tanks
> still held plenty of fuel, and this caused the engine shutdown.
Lee Elliott wrote:
> Is there a way of starting a Nasal script automatically at start-up?
> (this would help with zeroing the A-10 external tanks for the clean
> configuration)
Sure, you can put a block at the top of a -set.xml file (next
to, not inside, the block). Something like this:
Lee Elliott wrote:
> and the scripts then need to be explicitly invoked.
>
> Presumably, omitting the '' bits will then result in the
> scripts being executed at start-up.
No, the CDATA stuff is just escaping to prevent the XML parser from
being confused by literal "<", ">" or "&" characters insid
OK, I think I've got the kinks worked out of the MinGW work, and
have written up a little README (attached) describing how the
process works. Thanks to Norman and Frederic for the pointer to
the pthread library.
The required changes are in CVS now, and the process has been
tested at least on my F
Roy Vegard Ovesen wrote:
> I tried this inside an instrument config file, but it didn't work.
It doesn't. The nasal code is read only from under the /nasal/*
subtree of the global properties. Instruments live farther down.
> Would it be possible to implement the ability to include nasal
> code
David Megginson wrote:
> Lots of GA planes have an option turbocharged (or turbonormalized --
> I'm not technie enough to remember the distinction)
I think it's certification. A turbonormalized engine has a wastegate
setting of normal atmospheric pressure. It never develops more power
than the n
I wrote:
> Lee Elliott wrote:
> > I could do a script that monitors the tank levels and de-selects
> > them when they're empty but I don't know how to best invoke it.
>
> Actually, it wouldn't be hard to make this the default. We could set
> a "kill engines if empty" flag on the tank for aircraft
Gunnstein Lye wrote:
> Thanks for the info. Do you really have to build separate binaries
> of gcc for each target? I thought I could use the same binary for
> linux (native) and windows (crosscompiling).
Not to my knowledge. The code generation is more or less identical,
but some of the symbol n
Norman Vine wrote:
> Andy Ross wrote:
> > You *can* do this with cygwin [...] The compiler supports a
> > -mno-cygwin flag
> >
> > Unfortunately it turns out that cygwin doesn't install these tools
> > under the conventional "platform-program" name
Marco Gugel wrote:
> as I told to Andy Ross I would like to implement a truck driving
> simulation in FlightGear but my doubt regards the collision detection,
> which is not implemented! It's only a week that I study FlightGear
> code and I have now no idea if the collision detect
Erik Hofman wrote:
> Why do you think that collision detection is not implemented? You
> can crash to the ground and to the buildings (maybe even other
> aircraft?), so there must be some logic behind this.
Ground handling right now only uses a flat, horizontal ground plane at
the MSL altitude of
Melchior FRANZ wrote:
> Contact points are per model, but the behavior is AFAIK the same for
> all models: you can fly through walls, but not through roofs
> (neither up nor down). I've no idea if this was intended.
It was. This is the same rule that allows you to fly under bridges;
before that c
Jim Wilson wrote:
> Maybe I'm misunderstanding why you are doing this. Lower pitch
> angle, fast spinning prop. That doesn't makes sense?
Not pitch angle: A lower value of "_j0" indicates a low advance ratio,
which increases windmilling speed. This was just a sign bug to the
previous checkin, b
Jim Wilson wrote:
> Is any of this addressing the low rpm propeller issue discussed last
> week? (In other words, should I bother trying to correctly adjust
> the p51d prop config yet?)
In theory, yes. I haven't had a whole lot of time to test it yet, but
the slow/windmilling propeller regime sh
Martin Spott wrote:
> "Giles Robertson" wrote:
> > This is a multi-part message in MIME format.
> >
> > --_=_NextPart_001_01C42FC5.F549B62D
> > Content-Type: text/plain;
> > charset="utf-8"
> > Content-Transfer-Encoding: base64
>
>
> Do you have a readable translation available ?
Your mail
Erik Hofman wrote:
> There might be one step in between here, which I have been thinking of
> a bit. It would be easy to implement a bounding cylinder (2d collision
> detection) and only if there is a hit go to the bounding sphere. For
> me it looks like that approach would be much less costly as
Martin Spott wrote:
> mail2news, inn, tin ;-))
> Aside from that, I find it very unfamiliar to post _any_ sort of
> human-_un_readable messages to a mailing list. Isn't it ?
It was a perfectly readable text document, it was just flagged with an
encoding of UTF-8, which while more general than nec
701 - 800 of 1471 matches
Mail list logo
