Re: [Flightgear-devel] UIUC compile problem
Jonathan Polley wrote: I just updated to the newest uiuc_menu.cpp and am still getting the compile problem, but far fewer instances. MSVC error is: c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' : left operand must be l-value on the following lines: 1454, 1506, 1558, 1927, 1979, 2031, 2300, 2352, 2404, 2614, 2666, 2718, 2770, 2822, 3020, 3072, 3124, 3176, 3228, 3438, 3490, 3542, 3594, 3646 You could try this one: http://www.a1.nl/~ehofman/fgfs/download/uiuc_menu.cpp Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Jonathan Polley wrote:
I just updated to the newest uiuc_menu.cpp and am still getting the
compile problem, but far fewer instances. MSVC error is:
c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' :
left operand must be l-value
on the following lines:
1454, 1506, 1558, 1927, 1979, 2031, 2300, 2352, 2404, 2614, 2666, 2718,
2770, 2822, 3020, 3072, 3124, 3176, 3228, 3438, 3490, 3542, 3594, 3646
It would be nice to see if the attached test program produces the
following output on all supported platforms(This would allow us to
improve the speed of the code dramattically by using memcpy instead of
for-loops):
0 1 2 3 4 5 6 7 8 9
Erik
#include stdio.h
#include string.h
int main () {
int a[2][2][5];
int b[2][5];
int q;
for (q=0; q 10; q++) {
a[0][q/5][q%5] = q;
a[1][q/5][q%5] = q+100;
}
memcpy(b, a[0], sizeof(b));
for (q=0; q 10; q++)
printf(%i\t, b[q/5][q%5]);
return 0;
}
[Flightgear-devel] Re: Base package access via rsync?
Ok, people, please have a look at rsync scenery.flightgear.org::Base and tell me what you think. Very nice, indeed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASIM/Viewer mismatch
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. Things got even more interesting when I started playing with the view position offsets, because everything was wrong: the x offset moved the viewpoint sideways (y-axis), the y offset moved the viewpoint up and down (z-axis), and the z offset moved the viewpoint backwards and forwards (x-axis). I cannot figure out why this is happening. YASIM uses a different coordinate system internally, but there should be no direct dependency between the view offsets and the FDM -- YASIM simply reports the geodetic position (lon/lat/alt) and orientation (roll/pitch/heading) for the model itself, and the viewer positions the model appropriately. Any ideas? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Michael, What you are observing isn't exactly how you describe, although it appears that way. I was trying to simplify things by just pointing out that the aircraft stays horizontal (appears to not roll) in the chase view, but that isn't exactly how it works. The difference is that the xyz offsets to the eye position are applied in relation to a vector that is perpendicular to the aircraft in the cockpit view and perpendicular to the ground, that is in relation to the earth (radial from center of earth or world up) in the chase view. Since in both cases the same rotations are applied to the model, then you are seeing the effect of the difference in how the eye is positioned. The axis going to the right, is always in relation to the model (the aircraft orientation). The effect of this is as follows: In the case where the camera is offset in relation to world up (as in chase view) then the horizon doesn't move to pitch looking forward and doesn't move to roll looking sideways. Draw a picture for yourself and you can see what I'm talking about. In the case of chase view make the up axis that the eye is on parallel to a line that goes through the aircraft and is always perpendicular to the ground. However, let the eye rotate right and left with the model. This is not roll I'm talking about only rotation of the axis that the eye is on (can be due to pitch or roll or both). Anyway, this is why I suggested that you set the offset way back in the 3d cockpit view so that you were following the aircraft in cockpit view. When I get done with the first pass on the configurable viewer, experiment with that as well. Then we can go from there. Best, Jim That's why I suggested setting your z-offset way back behind the aircraft. Best, Jim Michael Selig [EMAIL PROTECTED] said: At 4/2/02, you wrote: 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 aircraft.) Actually only the pitch is applied to the model. The roll is not. From the side it does look a little funky. In relation to the horizon, the pitch angle gets doubled. Maybe I should wait until you have it done, but I'd like to comment on my observations which you are surely aware of. As things are now, one gets this when the model is viewed from behind: - pitch is applied to the model (model pitches up-down / horizon is level on screen) - roll is applied to the view (horizon rolls / wings are level on screen) - yaw is applied to the view (horizon swings side-to-side / model is straight nose-to-tail on screen) Then when the model is viewed from the side: - pitch is applied to the view (horizon rolls / aircraft is level --- opposite above) - roll is applied to the model (opposite above) - yaw is applied to the view (horizon swings side-to-side --- same as above) Things are halfway between these two with the quartering views. For me, speaking from experience, this is a recipe for vertigo. But I guess it is also a cure for my addiction to flying the sim! Because I am not ready to be cured, I'd like to propose in these terms above one basic view mode, which is somewhat similar to the way things were. It goes like this: In rearview: - pitch is applied to the model - roll is applied to the model - yaw is applied to the model In sideview, etc: - same as above I think this would be a very intuitive view. In this case, the horizon is always level on the screen and only the model rolls, pitches and yaws. The viewer is always looking at the airplane from a point on a circular perimeter that surrounds the airplane and this disk is always parallel to flat ground. Regards, Michael [2] What would be seen from a following aircraft. In this case, the horizon will move like it does on the HSI. The final view will look very much like the current cockpit view minus the instruments but w/ the 3D model of the aircraft shown. Hmmm...try setting the z-offset to -25.0 in the pilot view. [3] A lagged version of [2]. Not as important, but neat. It would effectively show what one would record from a video camera in the chase plane. The 3D model of the aircraft will not always be centered on the screen. In extremely rapid maneuvers, the 3D model might even move off of the screen (out of the camera field of view). It seems that to do 2 and 3, the aircraft trajectory history (so many feet of flight path trajectory) needs to be saved and used by the viewer code. Yes, some sort of fifo buffer would work. Tower view: [1] One version w/ the view positioned at the end of the runway and slightly behind and above the aircraft, looking down on the aircraft. This view is
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 c172-3d-set.xml or maybe it isn't reading that file? Those are defaults from somewhere...probably from c172-set.xml. Things got even more interesting when I started playing with the view position offsets, because everything was wrong: the x offset moved the viewpoint sideways (y-axis), the y offset moved the viewpoint up and down (z-axis), and the z offset moved the viewpoint backwards and forwards (x-axis). That is intentional. Before the pilot and chase were different than each other (or seemed that way). Prior to knowing anything about using plib or Opengl, I always assumed as a user that x was across the screen, y was up and down and z was depth. That is I think most intuitive to the xml user, and the fact that it doesn't coincide what's going on in the viewer black box is not important. Anyway, it is in my change log entry, documented in the source, and all my proposal stuff ;-) I cannot figure out why this is happening. YASIM uses a different coordinate system internally, but there should be no direct dependency between the view offsets and the FDM -- YASIM simply reports the geodetic position (lon/lat/alt) and orientation (roll/pitch/heading) for the model itself, and the viewer positions the model appropriately. There's no interface problem, only a settings file issue. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
On Wed, Apr 03, 2002 at 11:15:55AM +0200, Erik Hofman wrote:
It would be nice to see if the attached test program produces the
following output on all supported platforms(This would allow us to
improve the speed of the code dramattically by using memcpy instead of
for-loops):
0 1 2 3 4 5 6 7 8 9
Erik
#include stdio.h
#include string.h
int main () {
int a[2][2][5];
int b[2][5];
int q;
for (q=0; q 10; q++) {
a[0][q/5][q%5] = q;
a[1][q/5][q%5] = q+100;
}
memcpy(b, a[0], sizeof(b));
for (q=0; q 10; q++)
printf(%i\t, b[q/5][q%5]);
return 0;
}
8---
#include stdio.h
#include stdlib.h
int main(void)
{
char a[2][2][5];
char b[2][5];
char *p;
int index, i, j, k;
index = 0;
for(i = 0; i 2; i++) {
for(j = 0; j 2; j++) {
for(k = 0; k 5; k++) {
a[i][j][k] = k+j;
}
}
}
for(i = 0; i 2; i++) {
for(j = 0; j 5; j++) {
b[i][j] = i+j;
}
}
p = a[0][0][0];
for(index = 0; index sizeof(a); index++) {
printf(index a: %2d; element: %2d\n, index, *(p + index));
}
p = b[0][0];
for(index = 0; index sizeof(b); index++) {
printf(index b: %2d; element: %2d\n, index, *(p + index));
}
return 0;
}
8---
Compiled with both gcc and g++, this shows a to be two copies of b
arranged contiguously in memory, which would suggest that you can
indeed use memcpy the way you outlined . . .
Looking at my copy of KR I think that's funamentally how C handles
multidimensional arrays: from the right, each successive subscript
declares an array of n times the size of the array declared so far,
and when accessing an element, each subscript is multiplied by the
size of the array to the right of it and then added to the index
into the area of memory . . . Which isn't very coherent. The perils
of posting well past one's bedtime ;-) Still, I think it's
definitely safe to use memcpy this way . . .
So, memcpy away ;-)
Simon
--
PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc
(crappy) Homepage: http://bg77.anu.edu.au
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/
msg04826/pgp0.pgp
Description: PGP signature
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jim Wilson writes: That is intentional. Before the pilot and chase were different than each other (or seemed that way). Prior to knowing anything about using plib or Opengl, I always assumed as a user that x was across the screen, y was up and down and z was depth. That is I think most intuitive to the xml user, and the fact that it doesn't coincide what's going on in the viewer black box is not important. Anyway, it is in my change log entry, documented in the source, and all my proposal stuff ;-) 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 differently, of course). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Plotting tool
Hi there, my name is Quint Mouthaan and I'm a student at the Technical University Delft in the Netherlands. I'm working a project in which we want to use FlightGear. The first thing we want to do is analyze some flight data. I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? Thanks, Quint. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 differently, of course). It's already inconsistent. The model is one way (as you expected) and the panel xml is x across and y up/down. 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 3d programming or modeling. The FDM and other stuff I'd leave alone, but the panel, model, and viewer that end users are most likely to mess around with, I'd make consistent. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jim Wilson writes: It's already inconsistent. The model is one way (as you expected) and the panel xml is x across and y up/down. Yes, I know. One consideration, though, is that each panel is (soon) going to be projected to any arbirtary location and orientation in the aircraft, so you can think of it as being drawn from overhead and then rotated around. 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 3d programming or modeling. The FDM and other stuff I'd leave alone, but the panel, model, and viewer that end users are most likely to mess around with, I'd make consistent. Fair enough, but it would drive the aero people crazy. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
On Wed, 03 Apr 2002 14:57:01 +0200 Quint Mouthaan [EMAIL PROTECTED] wrote: Delft in the Netherlands. I'm working a project in which we want to use Can you tell us about your project? We always like to hear about how FlightGear is being used. :-) FlightGear. The first thing we want to do is analyze some flight data. I assume you mean flight dynamics data? Roll, pitch, control surface deflections, etc.? I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? David already answered this to some extent, but let me add something. JSBSim has pretty good data logging capabilities on its own if you are interested in only flight dynamics data. See the OUTPUT section (at bottom) of any JSBSim aircraft model for more information, e.g. X15.xml. JSBSim can output data to the console or to a file in .csv format (comma separated values). JSBSim can also write the data out to a socket. See FGOutput.cpp and FGfdmSocket.cpp for more information. The socket approach is nice for real time stuff. Flightgear may have some or all (and more) capabilities than this for logging, but perhaps not all of the desired flight dynamics data is available that way. Let us know if you need more information. Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 it. 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. YASim _sets_ those offsets based on its own configuration. I think this is a problem of data ownership -- who owns the location of the cockpit? I argue that it's the FDM, since it's the code responsible for other issues of aircraft geometry. But then the model wants it too. I dunno. Maybe the sane thing to do would be to put the cockpit location into the model file, and work really hard to insure that the coordinate origin is identical between the representations? Yanking this out of YASim is easy. Beyond that, there appears to be an axis mismatch somewhere. I verified that the code worked with the old viewer (the 747 cockpit was high, the 172 slightly to the left, etc...), but things might have changed since. We really need to write up a coordinates bible that defines, once and for all, the conventions we're using. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jim Wilson wrote: It's already inconsistent. The model is one way (as you expected) and the panel xml is x across and y up/down. But this is OK -- these are different coordinate systems with different usages. You'll never put airframe coordinates into the panel XML, nor use panel coordinates in a model file. The problem with inconsistencies is when multiple conventions get used for the *same* coordinates. To take airframe coordinates as an example (I'm not 100% certain on some of these): JSBSim uses X-forward, Y-right, Z-down YASim uses X-forward, Y-left, Z-up The model ac3d file appears to use X-right, Y-forward, Z-up All of these are right handed coordinates, and any of them could work. Internally, it really doesn't matter what convention the subsystem uses (YASim converts its coordinates to JSBSim conventions before exporting them, for example). But externally (on the bus, as it were), we really need to pick one and only one canonical way to represent a unique point on the airframe. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 it. 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. YASim _sets_ those offsets based on its own configuration. I think this is a problem of data ownership -- who owns the location of the cockpit? I argue that it's the FDM, since it's the code responsible That isn't the issue here though. Those are just the offsets from the lon+lat+alt to the eyepoint and it was those that were off. Where that origin is FDMwise is another issue and not related to what David was observing. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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: YASim _sets_ those offsets based on its own configuration. I think this is a problem of data ownership -- who owns the location of the cockpit? I argue that it's the FDM, since it's the code responsible for other issues of aircraft geometry. But then the model wants it too. I agree. The published geometric and physical properties of the aircraft - necessary for the creation of an aircraft flight model - often includes if not the exact eyepoint of the pilot at least a diagram that allows the flight modeler to deduce it. The flight modeler may also want to place a point mass weight where the pilot sits, too, so the information is very much critical to the aircraft flight modeler. JSBSim will include the eyepoint of the pilot - as well as ballast to represent the pilot - regardless of whether or not the modeler uses it. I suggest that the FDM be looked to for supplying such a value - at least as a recommendation. Also, be it known that the day is coming when a standard method of describing aircraft via some form of XML specification file is present. It is likely that the coordinate system used for such a standard specification will be one that is already a standard. That is, the aircraft structural frame: X axis increasing out the tail, Y axis increasing out the right side of the aircraft (when looking forward), and the Z axis of course positive upwards to complete the right-handed coordinate frame. The origin would typically be somewhere at the nose or just ahead of the nose of the aircraft, with the X axis either coincident with the centerline or parallel to it but below it (in order that all the Z coordinates would be positive numbers). It would be nice if there was some coherent and stable method of describing aircraft models and how they relate to the aircraft structural frame, if not coincident. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 3d programming or modeling. The FDM and other stuff I'd leave alone, but the panel, model, and viewer that end users are most likely to mess around with, I'd make consistent. Fair enough, but it would drive the aero people crazy. Should I just sit on this until we hear from some model people? Or should I change something? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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: YASim _sets_ those offsets based on its own configuration. I think this is a problem of data ownership -- who owns the location of the cockpit? I argue that it's the FDM, since it's the code responsible for other issues of aircraft geometry. But then the model wants it too. I agree. The published geometric and physical properties of the aircraft - necessary for the creation of an aircraft flight model - often includes if not the exact eyepoint of the pilot at least a diagram that allows the flight modeler to deduce it. That's fine, but this is really anybody's eye (as far as the viewer is concerned). It could for example be a passenger in 5A on a dc3. It doesn't need to be tied to the FDM. Now the origin location for the 3d model itself is a different story and that probably should be addressed. Right now it is set to whatever the fdm is reporting for lon/lat/alt (plus model offsets that I think aren't being used any more?). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jim Wilson wrote: Andy Ross wrote: David Megginson wrote: 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. YASim _sets_ those offsets based on its own configuration. I think this is a problem of data ownership -- who owns the location of the cockpit? I argue that it's the FDM, since it's the code responsible That isn't the issue here though. Those are just the offsets from the lon+lat+alt to the eyepoint and it was those that were off. Where that origin is FDMwise is another issue and not related to what David was observing. No, I meant the airframe offsets, not the global ones. The following code appears in YASim.cxx (the negations are due to the difference in coordinate sense): // The pilot's eyepoint float pilot[3]; a-getPilotPos(pilot); fgSetFloat(/sim/view/pilot/x-offset-m, -pilot[0]); fgSetFloat(/sim/view/pilot/y-offset-m, -pilot[1]); fgSetFloat(/sim/view/pilot/z-offset-m, pilot[2]); 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 the 3D model work got done. Now, there are *two* aircraft definitions: one to decide on physical performance and one to control visual display. Basically, we need to pick one mechanism. I think the simplest thing to do would be to yank the YASim cockpit mechanism (and whatever JSB and UIUC do) and use the model stuff only. Then, at least, we're guaranteed to be consistent across FDMs so long as we get the origin correct. The axis mixup, though, still requires a solution. My guess is that the new viewer draws the new models correctly in their (new) coordinate system, but misinterprets the offset information generated by the FDMs. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 the 3D model work got done. Now, there are *two* aircraft definitions: one to decide on physical performance and one to control visual display. Basically, we need to pick one mechanism. I think the simplest thing to do would be to yank the YASim cockpit mechanism (and whatever JSB and UIUC do) and use the model stuff only. Then, at least, we're guaranteed to be consistent across FDMs so long as we get the origin correct. 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. The only thing I can think of that the FDM should be concerned about reporting (for viewer/model use) other than orientation is the aircraft model position...ie where the origin should be. Right now I believe the model's origin is being placed at the lon/lat/alt that is set by the FDM, converted to fg coordinates. Note that this isn't taking center of gravity into consideration, so at some point we should be adding in an offset to cg too (or is lon/lat/alt at cg)? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Hallo and questions
Hi all, I'm a physicist from Bonn/Germany and though I haven't written to the developer list yet I'm scanning it now for some months. I'm really impressed by the progress that has been achieved in this short time and FlighGear has come a long way since I first had a look at it some years back. I've been interested in flight simulators since long and the possibility to participate in the developement of one sounds very exciting to me. This together with my desire to start learning C++ lead me to the decision to engage myself in FlightGear. I already contacted David Luff who works on the ATC system and we agreed that I start thinking about and writing code for the approach control. In the meantime there exist already some basic functionalities which will hopefully show up in the CVS code later. But as I'm new to FlightGear I need now some information how to get certain parameters from the program in order to extend the Approach capabilities. 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? I would prefer not to use the real time as that can be changed by the player while the program is running. Do we have something like the time the program is already running? Then a real-world aviation question. Is it correct that all heading instructions from a control station are given in magnetic heading? This is the first bunch of questions but I'm sure there will be much more in the future. Cheers Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Coolie hat on FlighSimYoke USB
Hi again, a question I forgot in my last mail. Does anybody of you know how to control the view direction (in the 3D cockpit) with the coolie hat on a FlighSimYoke? First, I have the problem that the hat direction is coded with two digital axis and they are not uncorrelated. What I have achieved so far is to control the horizontal movement but for the vertical one I even don't find the correct property name. Is there somewhere a complete list of the properties that can be controled in the joystick.xml? Best regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
- Original Message - From: Julian Foad [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 03, 2002 1:16 PM Subject: Re: [Flightgear-devel] UIUC compile problem Robert, maybe I'm missing something but it looks to me like you don't need to do all this copying; you just need to tell the file reader function where you want it to put the data. Like this, for example: uiuc_2DdataFileReader(Clfarf_file, Clfarf_aArray[Clfarf_index], Clfarf_rArray[Clfarf_index], Clfarf_ClArray[Clfarf_index], Clfarf_nAlphaArray[Clfarf_index], Clfarf_nr[Clfarf_index]); instead of uiuc_2DdataFileReader(Clfarf_file, datafile_xArray, datafile_yArray, datafile_zArray, datafile_nxArray, datafile_ny); d_2_to_3(datafile_xArray, Clfarf_aArray, Clfarf_index); d_1_to_2(datafile_yArray, Clfarf_rArray, Clfarf_index); d_2_to_3(datafile_zArray, Clfarf_ClArray, Clfarf_index); i_1_to_2(datafile_nxArray, Clfarf_nAlphaArray, Clfarf_index); Clfarf_nr[Clfarf_index] = datafile_ny; Can some one with MSVC or SGI please try the above? If it works, I'll change it. Rob ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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. It is *also* true that, under YASim, you have non-zero pilot offset numbers. These are (1) defined by the FDM, in conflict with similar definitions in the model, and (2) in an apparently different coordinate space from the one the viewer is expecting. The viewer must be using those properties (/sim/view/pilot/x-offset-m), no? How else would the settings by YASim be affecting the view location? Ah ok. After I get done with the configurable viewer, those values won't be used by the viewer. You are correct we have been using them if they are set by Yasim. Under other flight models (eg JSBsim) the values defined in the xml are being used. When I get done those offsets will be in each view with xml and not in that path. If there is something that I need to use that comes from the FDM let me know what it is and how to use it. But I'm not going to be setting the eyepoint with FDM data (other than offseting it from the available origin value). Because, as I said before, the eyepoint is not necessarily the pilot's eye. Right now I believe the model's origin is being placed at the lon/lat/alt that is set by the FDM, converted to fg coordinates. This is correct, and exactly as it should be (so long as the FDM and model agree on where the origin is, at the nose, for example). It looks like most of the 3D models have the origin on the firewall. I think that is what JSBsim is using too. Note that this isn't taking center of gravity into consideration, so at some point we should be adding in an offset to cg too (or is lon/lat/alt at cg)? Eep, no. 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. We certainly don't want code outside the FDMs to have to worry about this. The c.g. is an internal parameter of the FDM. Other code might want to inspect it out of curiosity, but we *certainly* don't want the view code worrying about rigid body dynamics. :) Well this might be useful to the 3D model. The effect probably isn't all that noticable compared to what we have now, but a real plane would pitch and roll about it's cg rather than the fixed origin as defined in a 3D model, wouldn't it? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
On Wed, 3 Apr 2002 20:47:57 - Jim Wilson [EMAIL PROTECTED] wrote: If there is something that I need to use that comes from the FDM let me know what it is and how to use it. But I'm not going to be setting the eyepoint with FDM data (other than offseting it from the available origin value). Because, as I said before, the eyepoint is not necessarily the pilot's eye. I'm not sure I understand what you are saying, here. I will say, however, that if there is a viewpoint given for pilot eyepoint in a JSBSim config file it would be good to reference it somehow (even if you copy it into an aircraft 3d model file) because it will be accurate information for the *pilot* eyepoint, if nothing else. It looks like most of the 3D models have the origin on the firewall. I think that is what JSBsim is using too. Actually, that is not necessarily the case. Tony created the coordinate frame there and its just as good as anything else. For us FDM guys, for the most part, it is the relative locations of various items that is most important. However, the X-15 and Space Shuttle, etc. models use various other conventions for structural frame origin. Well this might be useful to the 3D model. The effect probably isn't all that noticable compared to what we have now, but a real plane would pitch and roll about it's cg rather than the fixed origin as defined in a 3D model, wouldn't it? FWIW, the CG location can/will change as fuel is burned off and external stores (if present) are dropped. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Heads up: Boost - http://www.boost.org/
Bernie Bright has submitted a simplified boost distribution for SimGear and I have committed it to CVS. The boost web page is here: http://www.boost.org/ We will begin depending on this package soon. We are treating it in the same way we treat the zlib and metakit libraries. It is another package that we depend on, but many people may already have these installed on their systems. Thus, we don't build and install it automatically as part of SimGear to avoid poluting their system with multiple copies of the same thing. Instead we include the source tar ball with SimGear in $(top_srcdir)/src-libs/ so that those users that don't have it already installed can build and install it themselves without having to hunt around the net for the source code. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] View hat on FlighSimYoke USB
Alexander Kappes writes: a question I forgot in my last mail. Does anybody of you know how to control the view direction (in the 3D cockpit) with the coolie hat on a FlighSimYoke? First, I have the problem that the hat direction is coded with two digital axis and they are not uncorrelated. What I have achieved so far is to control the horizontal movement but for the vertical one I even don't find the correct property name. Is there somewhere a complete list of the properties that can be controled in the joystick.xml? You can control any property with the joystick, but to control the view direction, use something like this: axis n=4 binding commandproperty-scale/command property/sim/view/axes/lat/property /binding /axis axis n=5 binding commandproperty-scale/command property/sim/view/axes/long/property /binding /axis All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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. The effect probably isn't all that noticable compared to what we have now, but a real plane would pitch and roll about it's cg rather than the fixed origin as defined in a 3D model, wouldn't it? It would indeed. And it already does. Again, the rigid body magic required to move the coordinate origin appropriately for a given rotation about the center of gravity is the FDM's job. They already do this; all the rest of the system has to do is draw the origin at the right place. Once more: there's no error. Things are taken care of for you by the physics code in the FDMs. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Custom terrain
Hello, What's the best way to go about adding custom terrain to FlightGear? We're developing a soaring model and would like to be able to add in hills and slopes of any shape. Also, what about static ground objects? For example, (is there) || (will there be) a way to add trees and buildings based on 3D model files? Thanks, Glen
re: [Flightgear-devel] Hallo and questions
Alexander Kappes writes: 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? I would prefer not to use the real time as that can be changed by the player while the program is running. Do we have something like the time the program is already running? Just about any information you want is available in the property tree. There's an interactive GUI browser built into FlightGear -- choose Properties from the View drop-down menu. Then a real-world aviation question. Is it correct that all heading instructions from a control station are given in magnetic heading? No. In the Canadian far north, headings (runway numbers, approaches, etc.) are often true rather than magentic, and the same may apply to northern Alaska and Greenland. In southern Canada, where I live, we use magnetic headings. You can probably fake this by looking at the magnetic deviation -- if it's more than (say) +-30 degrees, use true headings. That won't be right all the time (and you might have to pick a different number), but it will probably be right often enough. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hallo and questions
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 look at src/Autopilot/newauto.cxx starting around line 210 for examples. These are similar to what you'll be needing. I would prefer not to use the real time as that can be changed by the player while the program is running. Do we have something like the time the program is already running? Do you mean time elapsed? Try the property picker on the menu for any other values you need. Keep in mind that you may need to find out where the value is generated before using it, but many are self explanatory. Time related values are found in the tree /sim/time. If you click on the . in the proppicker list it will refresh the values to what they are currently. Then a real-world aviation question. Is it correct that all heading instructions from a control station are given in magnetic heading? Think so, but I don't really know. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jon S Berndt writes: I'm not sure I understand what you are saying, here. I will say, however, that if there is a viewpoint given for pilot eyepoint in a JSBSim config file it would be good to reference it somehow (even if you copy it into an aircraft 3d model file) because it will be accurate information for the *pilot* eyepoint, if nothing else. At least it would be close. I'm sure that the eyepoints are different for a 5'2 pilot and a 6'4 pilot, and we also want to be able to model leaning forward, etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
I mildly disagree. I think the FGFS should require that the FDMs _and_ the aircraft models all have the reference point at the original manufacturer's defined reference point (so they all match nicely) even if this is done by a parametric offset that the FDM's configuration file has somewhere. The Aircraft's model file should contain an empty piece of movable airframe that is named PILOT and has the origin at the location of the obvious point of symmetry underneath a sitting person (grin) and has the up vector aligned with the slope of the seat back. This would allow the viewpoint stuff to specify pilot-centric viewpoints in terms of the PILOT location plus a specified distance that corresponds to the notional torso height of the simulated pilot to get the matrix. Here's what make sense to me. The FDM defines some aribitrary reference point (i.e. on the firewall) and provides the lon/lat/elev of that point. The FDM really doesn't care about the actual FlightGear view point. It won't know if the user is flying from the left seat, the right seat, or seat 5A in the DC-3. It seems like it would make much more sense for the flightgear side (maybe the aircraft-set.xml file?) to provide the actual view offset point relative to the FDM reference point. Curt. David Megginson writes: Andy Ross writes: We're evidently talking past each other. What you say is true. It is *also* true that, under YASim, you have non-zero pilot offset numbers. These are (1) defined by the FDM, in conflict with similar definitions in the model, and (2) in an apparently different coordinate space from the one the viewer is expecting. The viewer must be using those properties (/sim/view/pilot/x-offset-m), no? How else would the settings by YASim be affecting the view location? OK, here's how I had understood things: 1. The FDM sets the plane's lat/lon/alt to the ideal pilot viewpoint. 2. /sim/view/pilot/*-offset-m are properties controlled by the user and/or the view manager, and are added to the lat/lon/alt supplied by the FDM. Here's how Andy understands things: 1. The FDM sets the plane's lat/lon/alt to the origin, which is any arbitrary point on the plane's body. 2. /sim/view/pilot/*-offset-m are properties controlled by the FDM to give the offsets from the origin to the ideal pilot viewpoint. I'd like to reserve the /sim/view properties literally for allowing the user to move around inside (or outside) the plane. If my #1 is not correct, perhaps we should all the FDMs to put offsets somewhere under the FDM hierarchy. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
On Wed, 3 Apr 2002 16:26:57 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: The FDM defines some aribitrary reference point (i.e. on the firewall) and provides the lon/lat/elev of that point. We provide the lat/lon/elev of the current _CG_. The FDM really doesn't care about the actual FlightGear view point. True. It won't know if the user is flying from the left seat, the right seat, or seat 5A in the DC-3. True. It seems like it would make much more sense for the flightgear side (maybe the aircraft-set.xml file?) to provide the actual view offset point relative to the FDM reference point. All true. I just want to make these points: 1) In JSBSim (and I am assuming in YASim, too) one can add a weight to where the pilot sits - or anybody for that matter, including someone seated in 5A or a piece of luggage, etc. This will typically be where the pilot sits. If you change the viewpoint you won't be changing where the pilot ballast is. You'll merely be changing the viewpoint. You won't be virtually walking around the aircraft. 2) The flight modeler will usually have an intimate knowledge of where the *pilot* sits from aircraft manufacturer 3-views or other means. In some cases this data is given directly as X, Y, Z coords in the structural frame. An aircraft 3D modeler might have this information, too, if working from the same diagrams, or [s]he can probably guess fairly well. 3) The turn coordinator instrument (to my knowledge) works in consideration of where it is located, typically right in front of the pilot. The accels sensed by this instrument include rotational effects at the pilots moment arm from the CG. 4) If FlightGear was ever to be hooked up to a motion base, the motion of the base might be linked to the second derivative of the body velocities _at_the_pilot_location_. Thus, again in this case and with point #3, above, the flight model still needs to know where the pilot is. I still recommend that the FDM be allowed to at least _recommend_ a pilot eyepoint, as some calculations inside the FDMs will use this value. It would be nice if this value could be useful to FlightGear. FlightGear could still be allowed to shift the viewpoint as it wished, but withe understanding of points 1 - 4, above. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Memory problems with props getStringValue and getter fonctions returning const char *
Hello,
I didn't express myself when changes were made to the interface of property
classes,
resulting in the change of string to const char * but now, I experiment many
segfault
that are a direct result of these changes.
While I totally agree with the fact that input parameters should be const
char * to
avoid unnecessary memory allocations, I thing that making the same changes
to return
values such as in getStringValue is a big mistake. Here is why :
First, I am trying to build latest CVS flightgear with MSVC6 on Win2k. I am
surprised
that these problems do not show up with gcc (linux or Win2k)
First example :
/sim/logging/classes is tied and its getter function is :
/**
* Get the logging classes.
*/
static const char *
getLoggingClasses ()
{
sgDebugClass classes = logbuf::get_log_classes();
string result = ;
for (int i = 0; log_class_mappings[i].c != SG_UNDEFD; i++) {
if ((classeslog_class_mappings[i].c) 0) {
if (!result.empty())
result += '|';
result += log_class_mappings[i].name;
}
}
return result.c_str();
}
the string result is a local variable and is not valid when getStringValue
returns.
Same problem with /sim/time/gmt-string and its getter function (from
fg_props.cxx) :
/**
* Return the GMT as a string.
*/
static const char *
getGMTString ()
{
string out;
char buf[16];
struct tm *t = globals-get_time_params()-getGmt();
sprintf(buf, %.2d:%.2d:%.2d,
t-tm_hour, t-tm_min, t-tm_sec);
// cout t buf endl;
out = buf;
return out.c_str();
}
Here again the string out is destroyed before the return value has a chance
to be copied !
There are tons of similar examples. A quick and dirty fix would be to
transform those
locals static but with the loss of reentrancy (bye-bye threaded flightgear
!)
The changes also introduced the need for the caller to allocate a string or
to call strcmp
that I consider ugly (it's a matter of taste) in C++ programs and that obfus
cate the code.
The only way to avoid these memory management problems is to return a class
that can hold
and free its memory. The standard string class can do that, or we can create
a new string
class that do copy on write with reference counters.
I don't want to advocate for a compiler or an other but I am still perplex
about the fact
that no one noticed these problems with gcc !
Cheers,
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: ..yawed OpenGL on 8 MB ATI mach64, was: [Flightgear-devel] Re: framerate
On Wed, 3 Apr 2002 00:41:26 +0200 (CEST), Martin Spott [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: From: Alex Perry [EMAIL PROTECTED] I don't know whether the IIC has the Pro feature set (suspect not). If it does, the Mach64 driver of Utah-GLX works fine for me. You might want to have a look at recent DRI development. I'm following this already for a while and it appears to me that the guys got quite far with implementing DRI for Mach64, ..thanks. Any chance it is available as a rpm, or a tarball that will come out as an ok rpm, out of a 'rpm -ta '? (Up to my ears in work.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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. The effect probably isn't all that noticable compared to what we have now, but a real plane would pitch and roll about it's cg rather than the fixed origin as defined in a 3D model, wouldn't it? It would indeed. And it already does. Again, the rigid body magic required to move the coordinate origin appropriately for a given rotation about the center of gravity is the FDM's job. They already do this; all the rest of the system has to do is draw the origin at the right place. Once more: there's no error. Things are taken care of for you by the physics code in the FDMs. 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 and the pitch rotation is always on the access that intersects there. Should we be doing something different? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
Quint, There is Atlas (atlas.sourceforge.net), which connects to Glight Gear and plots the aircraft's track on a nice moving map display. It doesn't record any other data, but the source code will show you one way of getting data out of FlightGear. - Julian Quint Mouthaan wrote: FlightGear. The first thing we want to do is analyze some flight data. I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Adding an Airport
After digging through several README's, FAQ's and Robin's manual I decided to have a rough try with my so much desired airport. I did some calculation and then I added two lines to the default.apt(.gz) file for a minimal airport definition - to have a 'proof of concept' before I start working on the details. You can find it here: ftp://ftp.uni-duisburg.de/FlightGear/Devel/FX01.apt There will be _lots_ of details to follow once I have a start. This picture might tell you (I know the Airfiled from wandering around, so I know what's valid on this picture ): http://www.xs4all.nl/~nvav/afb/rsa-kaartje-1.gif I know that I will not see the runway as long as I don't rebuild the scenery but I understood that I should at least have the ability to sit on the grass at the desired place. Unfortunately this is not the case: sirius: 0:55:17 ~ fgfs [...] Attempting to set starting position from runway code FX01 heading 270 Failed to find FX01 in database. [...] It appears I still don't have read enough manuals because I need help to understand what's missing, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] YASIM/Viewer mismatch
Curtis L. Olson writes: Jon S Berndt writes: On Wed, 3 Apr 2002 22:54:01 - Jim Wilson [EMAIL PROTECTED] wrote: Ok, so are you saying that the lon/lat/alt values that the fdm outputs are at the origin already adjusted for cg? JSBSim gives the lat/lon/alt of the CURRENT CG - NOT the origin of the structural frame. This means that currently as the CG moves (i.e. loading baggage, fuel, people, etc.) the aircraft and the view point will move as well. This is probably too small to normally notice and we typically aren't changing the CG over time, but this does seem like something that needs to be straightened out. Whatever the FDM's are returning for position, it does need to be a fixed point relative to the airframe. FWIW I think the whole problem here stems from an old misunderstanding that although is a quite reasonable one is unfortunately mistaken ie CG has been considerd by some to be Center of Gravity and by others as Center of Geometry and its usage has gotten mixed up When we weren't changing the mass of the plane this made no difference but now that we are this needs to be cleared up I should have pointed this out at the time we started 'burning fuel' but I was well just 'burning' at the assumption that default behaviour could be changed ar will with out 'group' discussion. which BTW would have led very quickly to exposing this CG confusion FWIW 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 described more exactly in the individual model's configuration file so as the Viewer part of the program can do it's thing Ciao Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
On Wed, 3 Apr 2002 17:29:42 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: Jon S Berndt writes: I think this boils down to let's have the FDM worry about where the plane is, and let's have FlightGear worry about where the current view point is. I agree. We don't care about where the view is. Just remember the four points I made in the earlier email (particularly #3 and #4). We will be supplying a pilot position in the aircraft config file for weight and balance and sensed accelerations purposes. I'll be happy that the view is not merely at the CG like it was with the LaRCSim Navion. At landing the proper pilot placement prevents poor position perception. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 described more exactly in the individual model's configuration file so as the Viewer part of the program can do it's thing Yeah, I think that's where we're headed. It might work that we could keep doing things as we (JSBSim) are doing, with an added step. The initial CG of the aircraft could be defined to be the refernce point that we both understand. We would continue to burn fuel and drop stores and launch carried vehicles, etc. and change the CG. However, when reporting location (lat/lon/alt) we'd need to report NOT merely the location of the current aircraft CG, but the location of the current aircraft CG minus the delta from the original - i.e. the location of the original CG. (?) Is that right? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 described more exactly in the individual model's configuration file so as the Viewer part of the program can do it's thing Yeah, I think that's where we're headed. It might work that we could keep doing things as we (JSBSim) are doing, with an added step. The initial CG of the aircraft could be defined to be the refernce point that we both understand. We would continue to burn fuel and drop stores and launch carried vehicles, etc. and change the CG. However, when reporting location (lat/lon/alt) we'd need to report NOT merely the location of the current aircraft CG, but the location of the current aircraft CG minus the delta from the original - i.e. the location of the original CG. (?) Ok, I think this means I can continue in the same direction with the viewer code. It would be just a matter of editing xml to switch from using /position/lat||lon||alt to somewhere else in the property tree, so if folks want to experiment they can. As for the xyz viewer eyepoint offsets, those will be in the /sim/view[x] tree(s) and can be set with aircraft-set.xml or whatever else. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Latest Build Problems
I just updated to the latest CVS and tried to build. ATCmgr.cxx c:\flightgear\src\atc\atcmgr.cxx(201) : warning C4715: 'FGATCMgr::GetATCPointer' : not all control paths return a value JSBSim.cxx c:\flightgear\src\atc\atc.cxx(34) : error C4716: 'FGATC::RemovePlane' : must return a value Linux complains as well, but generates a WARNING for the second problem instead of an error. I then fix the error, updated to Erik's version of uiuc_menu.cpp, rebuild, and I then get: approach.cxx c:\flightgear\src\atc\approach.cxx(360) : error C2374: 'i' : redefinition; multiple initialization c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i' c:\flightgear\src\atc\approach.cxx(366) : error C2374: 'i' : redefinition; multiple initialization c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i' ground.cxx c:\flightgear\src\atc\ground.hxx(28) : error C2065: 'vector' : undeclared identifier c:\flightgear\src\atc\ground.hxx(28) : error C2501: 'SG_USING_STD' : missing storage-class or type specifiers c:\flightgear\src\atc\ground.hxx(29) : error C2065: 'list' : undeclared identifier c:\flightgear\src\atc\ground.hxx(29) : error C2501: 'SG_USING_STD' : missing storage-class or type specifiers c:\flightgear\src\atc\ground.hxx(29) : error C2086: 'SG_USING_STD' : redefinition c:\flightgear\src\atc\ground.hxx(49) : warning C4091: 'typedef ' : ignored on left of 'struct arc' when no variable is declared c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error : missing ';' before '' c:\flightgear\src\atc\ground.hxx(51) : error C2378: 'list' : redefinition; symbol cannot be overloaded with a typedef c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error : missing ';' before '' c:\flightgear\src\atc\ground.hxx(52) : error C2653: 'arc_list_type' : is not a class or namespace name c:\flightgear\src\atc\ground.hxx(52) : error C2146: syntax error : missing ';' before identifier 'arc_list_itr' c:\flightgear\src\atc\ground.hxx(52) : fatal error C1004: unexpected end of file found runways.cxx c:\flightgear\src\atc\runways.cxx(40) : fatal error C1083: Cannot open include file: 'runways.hxx': No such file or directory I can fix the problem in approach.cxx, but the ones in ground.cxx I cannot (I love the STL problems). Also, I have no idea where runways.hxx went. Thanks, Jonathan Polley
RE: [Flightgear-devel] YASIM/Viewer mismatch
Jim Wilson writes: 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 described more exactly in the individual model's configuration file so as the Viewer part of the program can do it's thing Yeah, I think that's where we're headed. However, when reporting location (lat/lon/alt) we'd need to report NOT merely the location of the current aircraft CG, but the location of the current aircraft CG minus the delta from the original - i.e. the location of the original CG. (?) Ok, I think this means I can continue in the same direction with the viewer code. It would be just a matter of editing xml to switch from using /position/lat||lon||alt to somewhere else in the property tree, so if folks want to experiment they can. As for the xyz viewer eyepoint offsets, those will be in the /sim/view[x] tree(s) and can be set with aircraft-set.xml or whatever else. Right The Viewer Code HAS to assume that the position reported by the FDM is invariant with respect to the airframe or else the Viewer really is 'lost' So I would just carry on assuming this to be the case and hopefully the rest will get sorted out shortly. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CTRL+U and JSBsim
At 2/13/02, you wrote: BERNDT, JON S. (JON) (JSC-EX) (LM) writes: OK. What does Ctrl-U do?? This was a *hack* that incremented altitude by 1000'. It was easy to do in LaRCsim. However, it's ugly, not realistic, and I'd rather have a more sensible and complete set of repositioning options instead. I'd be happy to see us jettison ^U ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org I have found the Ctrl-U very useful to jumping up in altitude. Beginners like this feature too. The current deal where the aircraft freezes on crashes is not so handy to me. Why not have some sort of realism feature that at one extreme does not freeze on crashes and allows for some sort of slew to altitude feature and then on the other extreme you've got to claw your way up and when you crash your done. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Car Model
At 4/2/02, you wrote: On 02 Apr 2002 15:45:18 -0500 Sam Varner [EMAIL PROTECTED] wrote: I'm working on an automotive simulator, http://vamos.sourceforge.net A while ago, Curt suggested that I try to make my car model work with FlightGear. !! I'd like to start working on that now, but I don't know where to begin. Could somebody give me some tips on adding a vehicle model to FlightGear? Thanks. You might start by looking at the ground dynamics / landing gear modeling code in the various FDMs (flight dynamics model). In JSBSim this would be FGGroundReactions.[cpp|h] and FGLGear.[cpp|h]. You should look at YASim and LaRCSim code, as well, to get the widest exposure to how ground reactions are modeled. Off the top of my head, after first being a bit clueless on where to start, I'd suggest that you ought to be able to get pretty far pretty fast in JSBSim by merely specifying in a config file an aircraft that had very poor aerodynamics ;-) Theoretically, this shouldn't be too hard to get a start with. The same is probably true with YASim, I'm sure Andy will direct you how to do this with YASim. I tried this as well. I ended up w/ something that simulated driving on a frozen lake bed --- a skating rink. But without too much more trouble, it could work. I think the challenging part is going to be modeling the suspension system. FWIW: I know that in motorsports people are using ADAMS to model the system dynamics. This is a commercial product. One of the problems we face with JSBSim (and which I haven't had time to deal with, yet) is that ground reactions can be a little tricky. Maybe a driving sim will pay enough special attention to that aspect of modeling that you can help us out with your time. Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Re: [Flightgear-devel] Plotting tool
JSBSim can output data to the console or to a file in .csv format (comma separated values). JSBSim can also write the data out to a socket. See FGOutput.cpp and FGfdmSocket.cpp for more information. The socket approach is nice for real time stuff. Flightgear may have some or all (and more) capabilities than this for logging, but perhaps not all of the desired flight dynamics data is available that way. Yes, It is. I would better if the socket approach use UDP broadcast socket to output data. UDP Broadcast socket would be faster than stream socket(TCP), and so we can add more than one other modules which want JSBSim data in real time. I am now using a module to receive JSBSim's output from socket and relay to other modules. and I am going to modify FGOutput/FGFDMSocket for UDP broadcast socket. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CTRL+U and JSBsim
like this feature too. The current deal where the aircraft freezes on crashes is not so handy to me. Why not have some sort of realism feature that at one extreme does not freeze on crashes and allows for some sort of slew to altitude feature and then on the other extreme you've got to claw your way up and when you crash your done. The freeze feature is typical of the big-boy sims with the object being you don't want negative training by modeling something you can't really model accurately, and also because you are really DEAD. We did not always freeze on crash, but some time ago we were asked to do so because we'd go out of bounds otherwise and segfault - effectively a crash, too, but unrecoverable. I think the best current path is to freeze. In the future, various other ways to handle this could be done, but we don't have time presently. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: ..yawed OpenGL on 8 MB ATI mach64, was: [Flightgear-devel] Re: framerate
On Wed, 3 Apr 2002 15:03:17 -0800 (PST),
Alex Perry [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
On Wed, 3 Apr 2002 00:41:26 +0200 (CEST),
Martin Spott [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
From: Alex Perry [EMAIL PROTECTED]
I don't know whether the IIC has the Pro feature set (suspect
not). If it does, the Mach64 driver of Utah-GLX works fine for
me.
You might want to have a look at recent DRI development. I'm
following this already for a while and it appears to me that the
guys got quite far with implementing DRI for Mach64,
..thanks. Any chance it is available as a rpm, or a tarball
that will come out as an ok rpm, out of a 'rpm -ta '?
I have no idea. Last time I touched an rpm was about a year ago.
As I remember, I carefully used a long pole that had an alien
on the end ... what do those command line switches mean ?
..build rpm from this tarball. If it barfs, or a cvs commit warrants,
'rpm -e' it, and try another, say 'rpm -ba ', as in build that darn rpm
from the tarball using the '.spec'-file I fixed. Length of pole is
discretionary. ;-)
..snippets of 'man 8 rpm':
BUILDING PACKAGES:
rpm {-ba|-bb|-bp|-bc|-bi|-bl|-bs} [build-options] SPECFILE ...
rpm {-ta|-tb|-tp|-tc|-ti|-tl|-ts} [build-options] TARBALL ...
rpm {--rebuild|--recompile} SOURCEPKG ...
...
BUILD OPTIONS
The general form of an rpm build command is
rpm {-bSTAGE|-tSTAGE} [build-options] FILE ...
The argument used is -b if a spec file is being used to build the
package and -t if rpm should look inside of a (possibly compressed) tar
file for the spec file to use. After the first argument, the next
character (STAGE) specifies the stages of building and packaging to be
done and is one of:
-baBuild binary and source packages (after doing the %prep, %build,
and %install stages).
...etc. Enables use of /usr if /usr/local chokes like: ;-)
[arnt@lana http-install]$ df -h
FilesystemSize Used Avail Use% Mounted on
/dev/hda9 251M 97M 141M 41% /
/dev/hda5 23M 4.6M 16M 22% /boot
/dev/hdb7 4.8G 4.1G 544M 89% /home
/dev/hdb5 2.8G 2.3G 455M 84% /home/arnt/DL
none 62M 0 61M 0% /dev/shm
/dev/hda71011M 82M 878M 9% /tmp
/dev/hda6 4.9G 4.2G 580M 88% /usr
/dev/hda113.6G 2.9G 524M 85% /usr/local
/dev/hda81011M 275M 685M 29% /var
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
On Wed, 3 Apr 2002 17:16:31 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Jon S Berndt writes: I'm not sure I understand what you are saying, here. I will say, however, that if there is a viewpoint given for pilot eyepoint in a JSBSim config file it would be good to reference it somehow (even if you copy it into an aircraft 3d model file) because it will be accurate information for the *pilot* eyepoint, if nothing else. At least it would be close. I'm sure that the eyepoints are different for a 5'2 pilot and a 6'4 pilot, and we also want to be able to model leaning forward, etc. ..a wee point: in sideslipping, will the responsible pilot stare, towards the infinte end of the longitudal axis, or will he watch/look out to where he is going? My .02, only. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CTRL+U and JSBsim
At 4/3/02, you wrote: Michael Selig writes: I have found the Ctrl-U very useful to jumping up in altitude. Beginners like this feature too. The current deal where the aircraft freezes on crashes is not so handy to me. Why not have some sort of realism feature that at one extreme does not freeze on crashes and allows for some sort of slew to altitude feature and then on the other extreme you've got to claw your way up and when you crash your done. LaRCsim was good at 'bouncing' on impact, but at least two other FDM's I'm dealing with are more likely to have their math blow up when faced with the excessively weird stuff that happens on impact. This depending on the situation can lead to the entire sim crashing if the positions returned by the FDM are entirely bogus. It's not unreasonable to make crash behavior configurable if someone out there is willing to do the work. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org I definitely understand the arguments for freezing on crash. I'm just saying I liked it the other way (and I believe that on the LaRCsim/UIUC side things still work this way ... we've not changed it). With the new UIUC models that have more reasonable gear parameters, the fgfs *very rarely* crashes like it used to do. I realize that trying to model wild ground handling is not high priority right now. It's also a perspective thing ... big aircraft vs small aircraft. RC models can take a lot of abuse and the funky cart wheeling is nice to have. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CTRL+U and JSBsim
Andy Ross writes: freezing on crashses isn't so handy. What *is* a handy thing to do in a crash? I mean, I can't make the plane *not* crash; it already did! :) There's really nothing realistic that can be done in this situation. I suppose I could just invert the vertical component of velocity -- that would be a nice bounce. In all seriousness, though, what would you like? All the consumer simulators I'm aware of do something equivalent to freezing on crashes. Some of them play nice animations of the airplane disintigrating, which is basically the same thing as far as the FDM is concerned. 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? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 and the pitch rotation is always on the access that intersects there. Should we be doing something different? OK, now I'm confused. :) To the first part: yes. If you take an aircraft with zero velocity and spin it, the output lat/lon/alt values from the FDM will be moving in a circle around the center of gravity, even though the c.g. is stationary. All of this math is done for you by the FDM. The second answer, if I understand the question, is it doesn't matter. Orientations and positions have nothing to do with each other. The lat/lon/alt values tell you where the firewall point of the aircraft is, but they don't say anything about where the aircraft is pointing. The hdg/pitch/roll numbers tell you how the aircraft is oriented, but not where the firewall is. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
Jon S. Berndt wrote: 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? JSBSim gives the lat/lon/alt of the CURRENT CG - NOT the origin of the structural frame. Ack, really? I was honestly under the impression that you were handing out the coordinate frame too; I thought I had checked this in code when writing YASim. Why c.g.? Since it moves, it forces the model renderer to track the current value and do an extra translation. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM/Viewer mismatch
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 and the pitch rotation is always on the access that intersects there. Should we be doing something different? The second answer, if I understand the question, is it doesn't matter. Orientations and positions have nothing to do with each other. The lat/lon/alt values tell you where the firewall point of the aircraft is, but they don't say anything about where the aircraft is pointing. The hdg/pitch/roll numbers tell you how the aircraft is oriented, but not where the firewall is. Sorry, I mistyped that message. What I was concerned about was the axis of rotation. Where the aircraft pivots when the pitch angle changes similar to where the fulcrum would be if the aircraft was a seesaw. It probably doesn't change all that much (for visualization) and I'm not going to worry about it right now. As far as the viewer.cxx and model.cxx code are concerned the axes for orientation rotations will continue to be at the model origin (which is set at the lon/lat/alt reported by FDMs) until further notice :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CTRL+U and JSBsim
At 4/3/02, you wrote: Andy Ross writes: freezing on crashses isn't so handy. What *is* a handy thing to do in a crash? I mean, I can't make the plane *not* crash; it already did! :) There's really nothing realistic that can be done in this situation. I suppose I could just invert the vertical component of velocity -- that would be a nice bounce. In all seriousness, though, what would you like? All the consumer simulators I'm aware of do something equivalent to freezing on crashes. Some of them play nice animations of the airplane disintigrating, which is basically the same thing as far as the FDM is concerned. 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? Curt hits the nail on the head --- I'd just like to continue on, and I think a lot of users would like to do the same. One of my motives: In my workshop right now I am building models for a range of aircraft: RC models --- hang gliders --- sailplanes --- vintage aircraft --- and others. I try to get all the aero right from the start (before I start the sim), but invariably I need to tweak and along the way there are a lot of crashes. Yes, I could restart, but it would be easier to plow along with all that nice airspeed and get back up quick rather than take off from scratch again. Maybe the current freeze on crash logic in the gear code could be set true/false in an xml file? What Curt mentions above, could also work. That's my two cents. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] YASIM/Viewer mismatch
Ack, really? I was honestly under the impression that you were handing out the coordinate frame too; I thought I had checked this in code when writing YASim. Perhaps this is related to the misunderstanding of our gear model and how we determined where we were? Why c.g.? Since it moves, it forces the model renderer to track the current value and do an extra translation. When we wrote the code for this initially, and for years afterwards, there *was* no model renderer. :-) In hindsight, I realize we may have erred in this. I'll add that initially we didn't model moving the CG around either, so it wasn't a big deal. I'll repeat points 3 and 4 I made earlier: 3) The turn coordinator instrument (to my knowledge) works in consideration of where it is located, typically right in front of the pilot. The accels sensed by this instrument include rotational effects at the pilots moment arm _from_the_current_CG_. 4) If FlightGear was ever to be hooked up to a motion base, the motion of the base might be linked to the second derivative of the body velocities _at_the_pilot_location_ relative to _the _current_CG_. Thus, again in this case and with point #3, above, the flight model still needs to know where the pilot is. I still recommend that the FDM be allowed to at least _recommend_ a pilot eyepoint, as some calculations inside the FDMs will use this value. It would be nice if this value could be useful to FlightGear. FlightGear could still be allowed to shift the viewpoint as it wished, but with the understanding of points 1 - 4, above. In any case, to the best of my recollection, this is how LaRCSim does it, how McFarland's paper describes it, etc. This is how to do it naturally. It may be that we should take it a step further and extrapolate the reference point from that, whatever that should be, and report the lat/lon/alt (henceforth known as LLA). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CTRL+U and JSBsim
Curt hits the nail on the head --- I'd just like to continue on, and I ... crashes. Yes, I could restart, but it would be easier to plow along with We'll be glad to honor any sane request ... Recommendations? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Plotting tool
Regarding the thread you are referring to - The code is presently with Alex Perry and he is in the process of integrating it into SimGear (?) and should be available soon. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Quint Mouthaan Sent: Wednesday, April 03, 2002 6:27 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Plotting tool Hi there, my name is Quint Mouthaan and I'm a student at the Technical University Delft in the Netherlands. I'm working a project in which we want to use FlightGear. The first thing we want to do is analyze some flight data. I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? Thanks, Quint. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Tower View preview
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 PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower View preview
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 - Original Message - From: Jim Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 03, 2002 9:43 PM Subject: [Flightgear-devel] Tower View preview 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 PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower View preview
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 the archives (within the last couple months). For now the HUD works fine for judging altitude. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CTRL+U and JSBsim
On Wed, 3 Apr 2002 21:31:43 -0600, Jon Berndt [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Curt hits the nail on the head --- I'd just like to continue on, and I... crashes. Yes, I could restart, but it would be easier to plow along with We'll be glad to honor any sane request ... Recommendations? ..ignore planet Earth? Spool the movie back? Autofire big recoilless tunnel-maker gun? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CTRL+U and JSBsim
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! has this cool feature where you can rewind like a tape player (up to a minute or so) and then fix what you did wrong just before the crash. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CTRL+U and JSBsim
We'll be glad to honor any sane request ... Recommendations? ..ignore planet Earth? Spool the movie back? Autofire big recoilless tunnel-maker gun? Someone's been in the cold too long. ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
Regarding the thread you are referring to - The code is presently with Alex Perry and he is in the process of integrating it into SimGear (?) and should be available soon. On a side note ... Curt, did you decide whether you want to have it in the CVS tree for SimGear ? If you did and you still don't, let me know and I'll stick it into the CVS tree for FGATD on the SF account. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
Alex Perry writes: Regarding the thread you are referring to - The code is presently with Alex Perry and he is in the process of integrating it into SimGear (?) and should be available soon. On a side note ... Curt, did you decide whether you want to have it in the CVS tree for SimGear ? If you did and you still don't, let me know and I'll stick it into the CVS tree for FGATD on the SF account. My apologies, this is among the things that are currently buried in my inbox. I haven't had a chance to take a look at it yet. :-( Too many, too much, too fast ... I need to pick a less popular project to be involved in ... maybe a python to cobol translator written in prolog. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plotting tool
I need to pick a less popular project to be involved in ... maybe a python to cobol translator written in prolog. Which reminds me ... does Mesa have support for AALIB yet ? Several people have been complaining about having to run FGFS under X and/or Windows. I know that AALIB supports both DOS and Linux consoles. 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Erik, Worked like a champ. Jonathan Polley On Wednesday, April 3, 2002, at 03:05 AM, Erik Hofman wrote: Jonathan Polley wrote: I just updated to the newest uiuc_menu.cpp and am still getting the compile problem, but far fewer instances. MSVC error is: c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' : left operand must be l-value on the following lines: 1454, 1506, 1558, 1927, 1979, 2031, 2300, 2352, 2404, 2614, 2666, 2718, 2770, 2822, 3020, 3072, 3124, 3176, 3228, 3438, 3490, 3542, 3594, 3646 You could try this one: http://www.a1.nl/~ehofman/fgfs/download/uiuc_menu.cpp Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CTRL+U and JSBsim
At 4/3/02, you wrote: Curt hits the nail on the head --- I'd just like to continue on, and I ... crashes. Yes, I could restart, but it would be easier to plow along with We'll be glad to honor any sane request ... Recommendations? Jon Asking me? plowtrue or false/plow Seriously, crashDetection/crashDetection ;) Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
Doing some more investigation, I found that there is a runways.cxx in both FlightGear/src/ATC and FlightGear/src/Airports. Are they the same? Thanks, Jonathan Polley On Wednesday, April 3, 2002, at 07:30 PM, Jonathan Polley wrote: I just updated to the latest CVS and tried to build. ATCmgr.cxx c:\flightgear\src\atc\atcmgr.cxx(201) : warning C4715: 'FGATCMgr::GetATCPointer' : not all control paths return a value JSBSim.cxx c:\flightgear\src\atc\atc.cxx(34) : error C4716: 'FGATC::RemovePlane' : must return a value Linux complains as well, but generates a WARNING for the second problem instead of an error. I then fix the error, updated to Erik's version of uiuc_menu.cpp, rebuild, and I then get: approach.cxx c:\flightgear\src\atc\approach.cxx(360) : error C2374: 'i' : redefinition; multiple initialization c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i' c:\flightgear\src\atc\approach.cxx(366) : error C2374: 'i' : redefinition; multiple initialization c:\flightgear\src\atc\approach.cxx(350) : see declaration of 'i' ground.cxx c:\flightgear\src\atc\ground.hxx(28) : error C2065: 'vector' : undeclared identifier c:\flightgear\src\atc\ground.hxx(28) : error C2501: 'SG_USING_STD' : missing storage-class or type specifiers c:\flightgear\src\atc\ground.hxx(29) : error C2065: 'list' : undeclared identifier c:\flightgear\src\atc\ground.hxx(29) : error C2501: 'SG_USING_STD' : missing storage-class or type specifiers c:\flightgear\src\atc\ground.hxx(29) : error C2086: 'SG_USING_STD' : redefinition c:\flightgear\src\atc\ground.hxx(49) : warning C4091: 'typedef ' : ignored on left of 'struct arc' when no variable is declared c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error : missing ';' before '' c:\flightgear\src\atc\ground.hxx(51) : error C2378: 'list' : redefinition; symbol cannot be overloaded with a typedef c:\flightgear\src\atc\ground.hxx(51) : error C2143: syntax error : missing ';' before '' c:\flightgear\src\atc\ground.hxx(52) : error C2653: 'arc_list_type' : is not a class or namespace name c:\flightgear\src\atc\ground.hxx(52) : error C2146: syntax error : missing ';' before identifier 'arc_list_itr' c:\flightgear\src\atc\ground.hxx(52) : fatal error C1004: unexpected end of file found runways.cxx c:\flightgear\src\atc\runways.cxx(40) : fatal error C1083: Cannot open include file: 'runways.hxx': No such file or directory I can fix the problem in approach.cxx, but the ones in ground.cxx I cannot (I love the STL problems). Also, I have no idea where runways.hxx went. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory problems with props getStringValue and getter fonctions returning const char *
David Megginson wrote: The changes also introduced the need for the caller to allocate a string or to call strcmp that I consider ugly (it's a matter of taste) in C++ programs and that obfus cate the code. That's why I originally used std::string, but then I found the string constructor near the top of the profiling reports. When the caller wants a string, it's easy enough to do string myval = fgGetString(/foo/bar); In fact, it looks exactly the same as it would if fgGetString still returned string. You made two changes at a time, so we can't say if the profiling problem is caused by input parameters or by return values ! By the way, tell me how you plan to correct that and I will submit patches with the same spirit. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Hi Andy, The bindings support a high and low pseudo-property for this. There's a FAQ somewhere on the website about it, but the basic idea is that you do: axis n=... low repeatabletrue/repeatable binding commandproperty-adjust/command propertyWHATEVER/property step type=double1.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command propertyWHATEVER/property step type=double-1.0/step /binding /high /axis The high and low bindings are invoked as keystrokes when the joystick enters the top 10% of travel in either direction. Yes, I looked at the page and that's how I actually do it at the moment. The problem was they didn't know what properties to use. So /sim/view/axes/lat and /sim/view/axes/long are the right properties for this. Best regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hallo and questions
Hi David, Just about any information you want is available in the property tree. There's an interactive GUI browser built into FlightGear -- choose Properties from the View drop-down menu. How do I have to imagine this property tree, I mean how is it realized in memory (C++) and what kind of things are stored in it? Is it something like an interface between different parts of FGFS? Best regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
