Andy Ross [EMAIL PROTECTED] said:
David Megginson wrote:
Wolfram Kuss writes:
Are r,p,h relative to the plane or the current view?
I imagine two RPH vectors: the main vector (which would in some cases
be the orientation of the plane) and the offset vector, which are
David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
- we have a pilot view point offset from the CG. Right now this is
handled in the view code, but perhaps this would make more sense to
move to some code specific to the instance of the current
aircraft.
Perhaps,
David Megginson [EMAIL PROTECTED] said:
I figured out how to tweak the view position in the (very rough) 3D
cockpit, so that the runway is now visible during taxiing and
takeoff. As before, use
fgfs --aircraft=c172-3d
to try it out.
Nice seats too :-)
David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
I'm just about to commit a massive series of changes that converts all
the .xml files to more standard .ini files. Oh, shoot, I meant to
save that announcement for 4/1/2002. :-)
We have to coordinate better -- I'm
Jon S Berndt [EMAIL PROTECTED] said:
Don't laugh, yourself! ;-) I've used C++Builder since
v1.0 and it's an awesome tool. It is waaay RAD. I'm
excited that they ported Delphi to Linux, and the C++
version is due soon. In a former job we used it for
developing a *major* gas measurement
Marcio Shimoda writes:
Does anybody have a tutorial describing how to create the ac
models?
Yes, here is one.
http://www22.brinkster.com/wtailgunner/tut/.%5Csample.html
I've got Blender too but haven't tried using it yet for anything real yet.
It is possible to convert work back and
If I was going to add blinking lights to the model animation code, how would I
do the timing?
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Michael Selig [EMAIL PROTECTED] said:
That would be nice, but even something simple that puts the viewpoint 200
ft above the runway behind the aircraft would be great to start with. That
view is a help when building and testing the new aircraft models. It also
makes the sim well-primed
Erik Hofman [EMAIL PROTECTED] said:
Talking about views.
Currently when looking around in the cockpit you turn around a single
point (if I recall it correctly). Wouldn't it be nessercary to actually
incoorporate the eye distance from the middle of the head into that
action (and limit
Curtis L. Olson [EMAIL PROTECTED] said:
If something doesn't make sense, or seems out of place, there's no
harm in asking ... perhaps the author will look at the 'cruft' and say
oh yea, nothing valuable there, we can axe it. But perhaps the code
is there is for valid reasons and it's worth
Norman Vine [EMAIL PROTECTED] said:
I realize that this is a 'religous' issue and a 'tough' problem but IMHO
it is a major obstacle to FGFS code evolution
It is a tough problem to solve, but I haven't found it to be much of a problem
reading fgfs code (have seen much worse). Maybe I'm not
Melchior FRANZ [EMAIL PROTECTED] said:
* Jim Wilson -- Sunday 17 March 2002 19:09:
Interesting note, the top item on the list, Racer is not GPL or
anything
close to opensource ( see http://www.racer.nl/legal.htm ). It also
uses the
fmod lib for sound...which is imho overkill for a race
Curtis L. Olson [EMAIL PROTECTED] said:
positive... we really go no where when we are busy flaming each other
and there has been really too much of that going on lately.
On that note I propose we dump this thread (known as: ARGG!) now and
continue the discussion under different heading
David Megginson [EMAIL PROTECTED] said:
Here are some tests I just ran, for 100,000,000 accesses of a double
property (I ran each on a few times then picked the most typical user
time; there was little variation anyway):
Tied to object methods: 5.880 sec
Internal (access only): 2.870
Andy Ross [EMAIL PROTECTED] said:
David Megginson wrote:
Tony reported back to the list on a more organic test -- he un-inlined
the most common inline methods in JSBSim, and discovered a slight (but
not exciting) speed *increase*.
Actually, my interest would be in a different
Norman Vine [EMAIL PROTECTED] said:
FWIW for vertical virtual panel
added 3 lines to Panel.cxx to get and multiply panel matrix by
gui_quat_ matrix
added 5 lines to viewer.cxx add gui_quat_matrix and a get function
removed line from viewer_rph.cxx and viewer_lookat.cxx that
Andy Ross [EMAIL PROTECTED] said:
Erik Hofman wrote:
While I don't see a direct improvement in framerate I notice a real
effect on the screen update. The old behaviour had a small bump in the
update every second or so, while the new code elliminates that.
This doesn't make much
Here's a backtrace on this.
Best,
Jim
#0 0x82ddfba in SGPropertyNode::clear_value (this=0x9747f90) at props.cxx:464
464 delete _value.string_val;
#1 0x82de8e0 in SGPropertyNode::~SGPropertyNode (this=0x9747f90, __in_chrg=3)
at props.cxx:672
#2 0x806c0e0 in
Jon Berndt [EMAIL PROTECTED] said:
engines/engine[0]/rpm = 2700
engines/engine[1]/rpm = 2700
What was the RPM reading?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jim Wilson
Sent: Wednesday, March 20, 2002 10:44 PM
To: [EMAIL PROTECTED
David Megginson [EMAIL PROTECTED] said:
I'm suggesting that we start with
nothing (or almost nothing) inlined, then inline only what can be
proven to help through profiling and timing tests -- uninlined until
proven necessary, rather than inlined until proven unnecessary. This
Sounds like
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Here's a backtrace on this.
I've just checked in some minor fixes to props.cxx in SimGear, and
swapping panels (with 's') in FlightGear is working again. Thanks.
By the way, we need to get rid of the panel_2 property
Here it is John.
Description:
Wilson's new u3a panel. It's not very accurate. Haven't found a picture yet.
The shape and layout is fairly close and looks ok. Also linked to c310
default sound.xml and changed model so the props aren't so syncrhonous to look
weird.
File:
Melchior FRANZ [EMAIL PROTECTED] said:
The changes from yesterday turned my framerate at KSFO from about
10 to 1 per second. Ten is already painful enough, and that with
clouds and panel turned off. But one is a bit weak and makes fgfs
virtually unflyable. (I've only got a 266MHz processor
Melchior FRANZ [EMAIL PROTECTED] said:
* Jim Wilson -- Friday 22 March 2002 13:23:
Are you using Linux? I'm using a V3 but its on a 100mhz motherboard (750 mhz
processor) and I'm seeing an increase at KSFO. It slowed down to 10 to 15 fps
a little while back and is now over 30. Other
Alex Perry [EMAIL PROTECTED] said:
It's working fine for me, in terms of framerate. Still getting a bunch
of segfaults with teleport and attempts to change the loaded panel.
Update SimGear rebuild/install it. Then do a complete rebuild of flightgear.
This will fix it. I tried to shortcut
David Megginson [EMAIL PROTECTED] said:
Alex Perry writes:
It's working fine for me, in terms of framerate. Still getting a bunch
of segfaults with teleport and attempts to change the loaded panel.
When did you last update? I check in a fix for changing the panel
yesterday, and if
David Megginson [EMAIL PROTECTED] said:
I've put together a quick scenery overlay for the entire w130n30 chunk
around the Bay area, with runway lighting for all the airports. You
can download it here (temporarily):
Just did a quick test, I can see Hayward but Oakland is very dark. Made
There should be backup files in each folder (prefixed with .#).
Best,
Jim
Keith Wiley [EMAIL PROTECTED] said:
I want to keep my flightgear project up to date, but I also want to be
able to undo a cvs update if I decide I don't want to be using the version
I end up with after a cvs update.
Norm,
Your viewer/model work looks great. I've been doing some major work in there
myself the last few days and what you've done will fit in well. If it's ok
with you, I'd like to merge them in with what I've got over the next couple
days. Currently where I am at is I've removed a ton of junk
Norman Vine [EMAIL PROTECTED] said:
Since these routines only run once or twice per iteration of the loop
They really don't have to be 'super optimized' and I think my method
of handling them as 3x3 and just filling in the 4th row and column
by 'inspection' is probably good enough.
Yes
Curtis L. Olson [EMAIL PROTECTED] said:
One problem I saw is that if you pitch up/down the view from the
'inside the cockpit' view and then switch to an external view, the
aircraft model itself is left at the 'view' pitch offset which is
incorrect.
Strange, I didn't notice that one.
Hi David,
Tonight I'll be looking adding in Norman's new patches and working on a
couple minor glitches in the viewer.
I'd also like to make the change I mentioned earlier of getting the reference
position data (from a property path) that is set in viewmanager.
For example:
Now it does this:
Let me clarify what I just said. The bug is still there, but the program
otherwise builds and works :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Curtis L. Olson [EMAIL PROTECTED] said:
Geoff McLane writes:
Also have noted a few changes of, like -
318 ! if ( fgGetString(/sim/startup/units) == meters) {
to
318 ! if ( !strcmp(/sim/startup/units, meters)) {
but am i missing something here? To compare 2
different
Alex Perry [EMAIL PROTECTED] said:
PS.
5. On the non-3D panel, the transparent instrument panel is still doing
the viewport incorrectly. Oddly, the non-instrument panel viewport is fine.
A few mini-panels were screwed up after a bug fix a couple weeks ago. The
default transparent mini
Wolfram Kuss [EMAIL PROTECTED] said:
I indeed think it is very important while landing to be able to look
ahead or look at the landing spot with the press of a key. In RL, my
head swivels between those two views, especially while in base. Don't
know whether some AI or much user defined stuff
Erik Hofman [EMAIL PROTECTED] said:
Hi,
Do Normans changes get applied automatically, or do I have to do it
myself? There seem to be some nice features and it would be a pitty to
have them left out.
Erik
Which ones? I did a lot of work on the viewer around the time he sent in
Erik Hofman [EMAIL PROTECTED] said:
I think I just got the conformation from both you and David.
It's a bit hard to tell if they get applied, when the patches are sent
to the list and nobody responds.
Erik
cvs logs?
Best,
Jim
___
Erik Hofman [EMAIL PROTECTED] said:
Yeah, but they don't move ...
coughcough
Sounds like an easy animation. :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
This patch creates a seperate scene graph for the cockpit. The near plane is
only moved up when in the interior (pilot) view. This is because with
rounding (I presume) it the visible ground is a bit up higher than it is with
the older nearplane setting. Not much, but it is enough to bury the
It looks like somehow the panel is locking the the offset adjustments. So
that if you move into the back seat the panel comes with you.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
Jim Wilson [EMAIL PROTECTED] said:
This patch creates a seperate scene graph for the cockpit. The near plane is
only moved up when in the interior (pilot) view. This is because with
rounding (I presume) it the visible ground is a bit up higher than it is with
the older nearplane setting
Norman Vine [EMAIL PROTECTED] said:
This patch creates a seperate scene graph for the cockpit. The near plane
is
only moved up when in the interior (pilot) view. This is because with
rounding (I presume) it the visible ground is a bit up higher than it is
with
the older nearplane
Andy Ross [EMAIL PROTECTED] said:
Your changes to put the panel in a scene graph are the big part of the
solution. Really, the panel should be drawn immediately after the
aircraft model, with the same matrix environment. If you can get this
put together (forgive me if you already have -- I
Would it be ok with everyone to add the values for the two near and far plane
settings to preferences.xml? I'd like to be able to use them in makeing
eyepoint and model origin translation adjustments.
Norm, where did you get that magic number? I know its got something to do
with the near
Jim Wilson [EMAIL PROTECTED] said:
Andy Ross [EMAIL PROTECTED] said:
Your changes to put the panel in a scene graph are the big part of the
solution. Really, the panel should be drawn immediately after the
aircraft model, with the same matrix environment. If you can get this
put
Norman Vine [EMAIL PROTECTED] said:
I could care less about those folks running FGFS in a window
this is a FlightSIM and the operative word is FRAMERATE
which any windowing system KILLS.
If you got a real operating system ;-) that runs X you'll find there's a very
small difference in
David Megginson [EMAIL PROTECTED] said:
I have no problem with adding them to the property tree, but I suspect
that they will be both model- and view-specific,
Well I hope not. I've got an idea, hang on a bit.
Best,
Jim
___
Flightgear-devel
Ok this did the trick. Thanks Andy for setting me straight :-)
Description:
Clear frame buffer and render model after rest of 3D scene. This has a
small frame rate cost (YMV). But who thought 3D cockpit would be cheap?
If anyone has a better idea, have at it!
Files:
David,
Just did some more careful testing and I see little or no frame rate loss
with the depth buffer clear. Also you can change the near plane to 0.1
and get rid of the sunroof (so I don't have to make up another set of
patches.
Thanks,
Jim
Melchior FRANZ [EMAIL PROTECTED] said:
c310-vfr-panel.xml says:
...
multibackgroundAircraft/c310/c310-panel-11.rgb/multibackground
multibackgroundAircraft/c310/c310-panel-12.rgb/multibackground
...
but there are no such textures. Have they been forgotten to upload,
or are they
David Megginson [EMAIL PROTECTED] said:
I have come up with a kludge (not a proper fix) for the lack of
smoothing in AC3D models in PLIB. The AC3D loader is the only one
Very nice! Just patched it to plib-1.4.1 here and it worked great.
Best,
Jim
David Megginson [EMAIL PROTECTED] said:
The thing is that the default bindings have to be for something. If
you're rebinding anyway, then changing the 'squared' feature isn't a
lot of extra work. I find that the squared feature makes an enormous
difference in usability for regular
Jim Wilson [EMAIL PROTECTED] said:
David Megginson [EMAIL PROTECTED] said:
The thing is that the default bindings have to be for something. If
you're rebinding anyway, then changing the 'squared' feature isn't a
lot of extra work. I find that the squared feature makes an enormous
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Sure we do (but implicitly; see below). That's the whole point of a
scene graph -- objects draw themselves into their own coordinate
system, and their containers, being higher up in the scene graph,
set up
Andy Ross [EMAIL PROTECTED] said:
Nope; just the matrices. The panel knows that if it runs an airframe
coordinate through teh modelview and projection matrices, it'll get
screen coordinates in the range [-1:1]. Just invert that matrix and
we can go from screen coordinates to airframe,
Michael Selig [EMAIL PROTECTED] said:
Chase views:
[1] One view like the old one, but minus the sway that was due to
sideslip. In this case the horizon on the screen is always level. (I
don't think the new chase view behaves like this. The horizon is not
level, it rolls w/ the
David Megginson [EMAIL PROTECTED] said:
For those who didn't read my long post about PLIB problems, there is
now a new C172 3D model in the base-package CVS, including the
much-requested translucent propeller disk for high RPM.
Unfortunately, to see the model correctly, you will have to
Is there a simgear or plib function that I can use to get the angle between
two locations? Namely the angle of direction from eye (lon, lat, alt) to
aircraft (target_lon, target_lat, target_alt). For example in our current
chase view the angle would be the heading since we are always following
://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Jim Wilson - IT Manager
Kelco Industries
PO Box 160
58 Main Street
Milbridge, ME 04658
207-546-7989 - FAX 207-546-2791
http://www.kelcomaine.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http
David Megginson [EMAIL PROTECTED] said:
I tried this
fgfs --aircraft=c172-3d --fdm=yasim
and had an interesting experience -- I ended up sitting on the runway
a meter or two to the right of the plane, rather than inside it.
Something is overwriting the xyz offsets in the
David Megginson [EMAIL PROTECTED] said:
Sorry for the confusion there. I think that it's probably not a good
idea to do things that way -- we should stick with normal aircraft
axes for consistency with the rest of FlightGear, at least at the
property level (a GUI can present things
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
David Megginson wrote:
I tried this
fgfs --aircraft=c172-3d --fdm=yasim
and had an interesting experience -- I ended up sitting on the runway
a meter or two to the right of the plane, rather than inside
David Megginson [EMAIL PROTECTED] said:
If I was the only one to have say in this I'd make the xyz in the
model files conform to the expected by the user axes (x across, y
up/down, z depth). It is also what would be expected by anyone who
is unfamiliar with plib but has done other
Jon S Berndt [EMAIL PROTECTED] said:
On Wed, 03 Apr 2002 09:32:12 -0800
Something is overwriting the xyz offsets in the c172-3d-set.xml or
maybe it isn't reading that file? Those are defaults from
somewhere...probably from c172-set.xml.
Andy Ross [EMAIL PROTECTED] replied:
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
Ultimate, the pilot position comes from the cockpit tag in the YASim
.xml file. The rationale here was that this was the best place to put
the information about the cockpit position was in the aircraft
definition. But that was before
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
That's ok, but as I said earlier, the offsets that the viewer will
use will be defined elsewhere because they are not necessarily the
true actual pilot's eye point.
We're evidently talking past each other. What you say is true
Hi Alexander,
See the inline comments for your answers. Good luck!
Alexander Kappes [EMAIL PROTECTED] said:
First, how do I get information like actual heading of the plane, its
vertical speed etc? How is this fgGetNode stuff working and do we have
something like an internal time?
Take a
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
Andy Ross wrote:
The FDMs already take the c.g. into consideration. If a stopped
aircraft rotates (about the c.g, of couse), you will see the
coordinate origin moving.
Well this might be useful to the 3D model
Jon S Berndt [EMAIL PROTECTED] said:
On Wed, 3 Apr 2002 18:44:23 -0500
Norman Vine [EMAIL PROTECTED] wrote:
My take on this is that all we need is a 'fixed' position ie 'Center of
Geometry' returned by the FDM. This fixed position can be anywhere
on the AirFrame and it needs to be
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
Ok, so are you saying that the lon/lat/alt values that the fdm outputs
are at the origin already adjusted for cg? If so then how would that
affect the axis of say pitch rotation on the c172 model? It's origin
is at the firewall
Here's a series from the tower (aka RC pilot) view. Note that I really have
trouble flying this way. The last seen is 2.3 seconds before impact :-)
http://www.spiderbark.com/fgfs/towerpreview.png
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL
Glen Dimock [EMAIL PROTECTED] said:
Looking good. From an R/C perspective, it would be great to have an
aircraft shadow for judging altitude. Having worked mainly on the UIUC/FDM
side of things, I'm not sure how difficult it would be to add this...
Glen
This has been discussed...check
Curtis L. Olson [EMAIL PROTECTED] said:
Perhaps Michael likes the ability to 'continue on' after a crash
without having to start over? Would reseting and ground trimming at
the crash site be enough? Air start at XXX' AGL @ YYY kts at the
last good heading at the time of the crash?
Fly!
Marcio Shimoda [EMAIL PROTECTED] said:
How do I see the 3D cockpit?
Run with --aircraft=c172-3d
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Curtis L. Olson [EMAIL PROTECTED] said:
I need to pick a less popular project to be involved in ... maybe a
python to cobol translator written in prolog.
Ooo ooo yeah. I've been looking for one of those :-)
___
Flightgear-devel mailing list
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Err umm...what is it that won't be necessary?
Using properties other than the /position ones.
Right from the start I've been planning to support that anyway.
Two reasons:
1) Probably soon to be realized multiple instances
As far as I know that file should still be in there (nothing to replace it
yet). Why was it removed?
Best,
Jim
Curtis L. Olson [EMAIL PROTECTED] said:
Yes, it appears that this file was removed from CVS. What is the
recommended way to fly the 3d cessna?
Curt.
Curtis L. Olson [EMAIL PROTECTED] said:
The DCS system would take care of loading and attaching the 3d models
to the correct place in the scene graph and removing them. It would
call the update() routine for each of their engines. And it would
probably provide some sort of property
David Megginson [EMAIL PROTECTED] said:
While we're talking about refactoring, I think that it might be time
to consider creating something like an FGLocus class, to keep track of
a single location. Its interface would look a lot like the viewer's:
Yes I was thinking the same thing. If
David Megginson [EMAIL PROTECTED] said:
Norman Vine writes:
But we really need another name and I realize that you are trained
in 'English' and will argue for (1) below however I believe (3)
below is paramount in this case as this class refers to a 'single
point' not a 'set of
Now that the viewer is somewhat free of the model code, there are some
other problems that need to be dealt with. Apparently it is still the
authority for where the airplane is (even though the FDMs know perfectly well).
My guess is the problems are in the Scenery directory. I'd like to stop
Norman Vine [EMAIL PROTECTED] said:
It seems as if we are losing FrameRate rather quickly
all figures are for at rest no HUD or Panel Default location
at Noon Brakes on MingW32 compiled on Win2k
Geforce2 GTS No model shown ie. View[0]
March 16 ~78 fps
last week ~71 fps
Jonathan Polley writes:
make: Making all in src-libs
make[1]: Entering directory `/home/jwpolley/SimGear/src-libs'
make[1]: *** No rule to make target `all'. Stop.
make[1]: Leaving directory `/home/jwpolley/SimGear/src-libs'
make: *** [all-recursive] Error 1***
Oops, I think I clicked the wrong button and sent a blank one.
David Megginson [EMAIL PROTECTED] said:
Left and right brakes are also bound to ',' and '.' on the keyboard,
and you can bind them to joystick buttons if you want, but then you're
stuck with a choice between no brakes and full
Paul Deppe [EMAIL PROTECTED] said:
However, I am seeing a strange clipping problem in the tower view mode with
the C172 and C310 models when I use the 'x' key to zoom in (Cygwin/Win2k).
Here's how to duplicate it:
Oh yes, I'm seeing it on my voodoo. What kind of card are you using? I
David Megginson [EMAIL PROTECTED] said:
It's a bad one for inlining, actually, because that forces globals.hxx
to have a dependency on viewmgr.hxx, so all of FlightGear has to
rebuild whenever Jim touches the viewer code.
What we should do is find out why get_current_view is called so much
David Megginson [EMAIL PROTECTED] said:
Norman Vine writes:
So ???
So it hurts development a lot. Developers have limited time to
contribute to FlightGear, and if the program takes always takes 5 or
10 minutes to rebuild (and has to be rebuilt, say, 10 times to test
and debug each
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Haven't had a chance to look through the changes, but umm...I'm seeing a
25% decrease in framerate after this mornings patches. Sorry.
(Voodoo3/P3-750mhz/100mhz MB/384mb Ram)
Ouch! Have you upgraded SimGear as well
Alex Perry [EMAIL PROTECTED] said:
Gadds. I don't know...even with an almost completely idle cpu occaisonally I
seem to have these weird performance discrepencies. It isn't heat, so who
knows. Maybe its something weird about the kernel. Later without changing
anything it looked much
David Megginson [EMAIL PROTECTED] said:
Alex Perry writes:
Do we care about this error ?
/usr/bin/ld: Warning: size of symbol `current_model' changed from 4 to 8
in ../../src/Model/libModel.a(acmodel.o)
Yes, I'm getting this as well and I don't understand it.
It's probably the
Sorry I mistyped thatit should have been extern not export :-/
Andy Ross [EMAIL PROTECTED] said:
David Megginson wrote:
Alex Perry writes:
Do we care about this error ?
/usr/bin/ld: Warning: size of symbol `current_model' changed from
4 to 8 in
[EMAIL PROTECTED] said:
In an ideal world I'd like to make one model that would , with a minimum of
kludging, work in FGFS and FS2002 since I regularly use both. I appreciate
that this might upset the purists!
To the contrary, it's kind of iteresting having a fgfs model converted for use
in
Andy Ross [EMAIL PROTECTED] said:
David Megginson wrote:
Alex Perry writes:
Do we care about this error ?
/usr/bin/ld: Warning: size of symbol `current_model' changed from
4 to 8 in ../../src/Model/libModel.a(acmodel.o)
Yes, I'm getting this as well and I don't understand it.
Curtis L. Olson [EMAIL PROTECTED] said:
Frederic Bouvier writes:
I don't know how a scene is drawn now but by drawing :
1. the scenery,
2. the lights,
3. the cockpit,
4. the panel.
in that order, we should avoid this kind of anomaly.
Am I missing something ?
If we draw
Curt,
The new default properties set up the various views. So the problem is if
running the new code, and none is defined there would be no view to access.
I'm going to submit some patches that consolidate some of the matrix math for
models and views, which included some patches to the view
David Megginson [EMAIL PROTECTED] said:
I've signed up for ground school and for more lessons and
have joined the Ottawa Flying Club as a student member (about US
$60/year) -- I'll introduce them to FlightGear when I'm better
established.
Yep, your in it now. Congratulations!
Best,
Jim
constants
defined as a part of their classes. MSVC does not want them to be used to
define structures, but will take the enumeration equivalent.
As always, I have no problems with Linux.
Thanks,
Jonathan Polley
--
Jim Wilson - IT Manager
Kelco Industries
PO Box 160
58 Main
David Megginson [EMAIL PROTECTED] said:
I've added a new property, /controls/parking-brake (also available
through FGControls). For both JSBSim and the YASim C172, this
property overrides the toe brakes for the main gear (actually, for
YASim, it is just added then clamped).
The 'B' key
Jonathan Polley [EMAIL PROTECTED] said:
Changing the '' to a '*' did not solve the problem. When I made Fred's
change (removing 'const' but leaving the '') I was able to get it to
build.
Ummm...did you change those to a pointer to an array of arrays? It wasn't
just a matter of changing
101 - 200 of 1695 matches
Mail list logo
