I was having a fiddle with keyboard.xml to support a UK keyboard, and
discovered that the characters £ and ¬ (which are shift-3 and shift-key
to left of 1) break the XML parser. Is this intentional?
Also, in the grand re-organisation of the XML files that appears to be
planned, do we need to
Wolfram Kuss writes:
The XML files get IMVHO more and more confusing.
I think that it would be more accurate to say that FlightGear is
getting more sophisticated -- there's more to learn if you want to
customize things, but that's only because there's so much more that
you can customize.
The
Richard Bytheway writes:
I was having a fiddle with keyboard.xml to support a UK keyboard, and
discovered that the characters £ and ¬ (which are shift-3 and shift-key
to left of 1) break the XML parser. Is this intentional?
By default 8-bit XML files use Unicode UTF-8 encoding. That's
David Megginson [EMAIL PROTECTED] said:
David Megginson writes:
3. The orientation is incorrect when the view is not straight forward
and the plane is not flying level (waiting for a fix from me, but I
don't understand matrix math well enough) -- that means that when you
look out
* [EMAIL PROTECTED] (David Megginson) [2002.03.10 10:47]:
Jim Wilson writes:
Hehe. Yep. Didn't notice that one. Actually I don't know why
that would be in the preferences.xml. Anyone know why that isn't
in the panel or at least aircraft-set xmls?
A cleanup and reorg is long
Cameron Moore writes:
[ Why doesn't Tarzan have a beard? ]
Jane, n'est-ce pas?
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
On Sat 9. March 2002 20:36, you wrote:
As far as I can figure out, there are only three situations we need to
deal with in the viewer code:
1. Looking away from a known position.
2. Looking towards a known position from a known distance and
angle(s).
3. Looking from one known position
I find that we call fgReshape function in each RenderFrame, and it is
IMHO needless. When you remove fgReshape from fgRenderFrame all
resizing works, you only can't change resolution via property manager.
But do we need it?
Do you have some objection, before I send a patch.
Regards,
Madr
--
Richard Bytheway wrote:
I was having a fiddle with keyboard.xml to support a UK keyboard,
and discovered that the characters £ and ¬ (which are shift-3 and
shift-key to left of 1) break the XML parser. Is this intentional?
Also, in the grand re-organisation of the XML files that appears
Martin Dressler writes:
There are some diferents how the viewer is initialized and from
where it take new position. Your viewpoint could be static or
change position or (and) up vector in some dependency on FDM or
maybe time.
Right, but none of that's the viewer's concern. As long as
I was once on check ride (in a DC-6 simulator) where the person flying
the sim (not me!) ran teh fire proceedure as follows:
Throttle close, closed the number one throttle
Feather the engine, feathered the number two engine
Mixture control idle-cut off, placed the number three mixture to cut
David Megginson wrote:
I disagree -- the view code gets *very* hard to understand very
easily. If that information is tracked, it should be tracked
externally (the view manager, again?) and not in the viewer code
itself.
Amen. I spent many hours over the weekend trying to make the view
David wrote:
Wolfram Kuss writes:
The XML files get IMVHO more and more confusing.
I think that it would be more accurate to say that FlightGear is
getting more sophisticated -- there's more to learn if you want to
customize things, but that's only because there's so much more that
you can
Wolfram Kuss writes:
BTW, in your list you forgot the *-dpm.xml files, which are of most
interest to me and which are currently the only ones that I really use
:-). With the little time I currently have, I am glad if I manage to
have a nice 3D model at the correct place in fgfs.
Ah, yes
decloaking
Hopefully the list administrators will allow this post from
a non-subscriber thru to the list :-)
Here are some of my thoughts on how the 'View'
please change this to 'Camera' should work.
2. The instruments rotate with the 3D cockpit but they don't tilt with
it (also
[A bunch of notes on Norm's notes. Basically, everything he wrote
(even the editorializing) makes sense to me, with a few exceptions as
detailed below]
Norman Vine wrote:
Easy beans - no gimble lock - infinitely stackable orientations -
everything has it's own logical spot - quick -
Normally the FlightGear project isn't affected by or concerned with
various platform security problems or viruses, and because FlightGear
shouldn't need to be run suid root, typical security issues shouldn't
affect us.
However, a bug has been found in zlib-1.1.3 (which is distributed as a
[A bunch of notes on Norm's notes. Basically, everything he wrote
(even the editorializing) makes sense to me, with a few exceptions as
detailed below]
Norman Vine wrote:
Easy beans - no gimble lock - infinitely stackable orientations -
everything has it's own logical spot - quick -
I just updated my Windows machine with the latest source and did a build.
Under MSVC, it does not like:
static const struct {
string name;
double (*fn)(double);
} __fg_snd_fn[] = {
// {lin, _fg_lin},
{inv, _fg_inv},
{abs, _fg_abs},
{sqrt, _fg_sqrt},
Changing the data structure to read:
static const struct {
char * name;
double (*fn)(double);
} __fg_snd_fn[] = {
caused everything to work properly. I know that this is not the proper C+
+ solution, but it worked for me.
Jonathan Polley
On Monday, March 11, 2002, at 08:21
20 matches
Mail list logo
