RE: [Flightgear-devel] Portable unlink() / rmdir()
Norman Vine wrote: Curtis L. Olson writes: I forgot to point out the necessay nonstandard Windows headers though #include io.h _unlink( const char * ) #include direct.h _rmdir( const char * ) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Portable unlink() / rmdir()
Norman Vine wrote: Norman Vine wrote: Curtis L. Olson writes: I forgot to point out the necessay nonstandard Windows headers though #include io.h _unlink( const char * ) #include direct.h _rmdir( const char * ) I have no problem using unlink and rmdir with MSVC ( without leading _ ). They are also defined in io.h and direct.h for compatibility ( if __STDC__ is not defined which is the case for C++ ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
Andy Ross wrote: Lee Elliott wrote: I think drop tanks would be feasible but it would need some thinking about:) The fun bit will be counteracting the a/c manuevours after the tank has dropped so it falls straight even though the a/c may be climbing and banking. This is more of a code architecture issue. Once something has left the aircraft, it ought be be handed to a simple "ballistics FDM" or somesuch. Making it "disappear" from the aircraft model is as simple as adding a select animation and can be done right now. And you can set the weight tag to zero to get the FDM behavior correct. Running it under a separate "FDM" handler is something that the C++ code just doesn't support yet, though. It's probably not hugely difficult to make work, though. Andy The same option should then be used for all the weapons as well; let it be dumb bombs, rockets or missles. They will all start with certain vector of speed and some point in space and will then change it through time (effect of force of gravity and weapon's propulsion). The tankers should be treated like normal dumb bombs. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Jon Berndt wrote: I give up. Sort of. No need to IMHO. I think we now have an excellent solution. Could someone file a patent request for this? There are some gotcha's involved which could mean some other points/locations should be exposed also in the future, but that's about it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Russell Suter wrote: Of course someone must know this relationship. That doesn't mean they must be the same point. Someone must not only know the relationship but also be able to calculate, measure, or WAG a delta x,y,z between these two frames of reference and put them in the XML wrapper file. But the understanding need not be a prior agreement!!! So the answer is still NO! I think we should all live with what we have now. I am going to ignore any of your posts on this subject (congratulations, you're the first ever!). Now we go on doing some useful stuff. Thank you very much. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy - Wing Bending
kreuzritter wrote: Upgrade: And how to simplify it and integrate it nicly into flightgear so that it is still fast enough. I also gave up the idea of limiting the number of wing sections to only 4, imho this should depend on the type of airplane, so i thought about a dynamic range of wing sections that can be adjusted to the type of airplane. I think the tweening support should be added for this. Then you would have as many wing sections as you define in the 3d model. You would basically have two different version of the same object bot defined at their maximum and the tweening code will take care of the rest. I think the tweening code will be fast enough. To be prepared for the future you could already add three versions of the wing: a max positive and max negative bend version which should be turned off in the animations file for now, and a normal version which should be turned off when tweening is implemented. I haven't looked at tweening yet, but since plib already supports it, implementing it into the SimGear animation code would probably be not much of a problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jim Wilson Sent: 13 February 2004 15:31 David Megginson [EMAIL PROTECTED] said: Jim Wilson wrote: Yes it is. I'm probably being really dense, but I can't think of a reason why it would be important to know what the origin is in fdm coordinates. So long as position is reported to fgfs at the nose, we should be fine. Assuming that the model also has its origin at the nose. If we can tell the FDM to report a different point, then the model can have its origin anywhere. The *.ac file doesn't actually need to be changed in any case. You can always use the offsets to move the 3D model origin to the nose. IIRC these are the offset properties that were originally used to place MSFS models that we couldn't edit. That dimmension would be easy to figure out because it would be the distance from the 3D model's origin to the location of the nose. For those who don't know what I'm refering to see: http://www.flightgear.org/Docs/fgfs-model-howto.html#repositioning In a sense what I've described here is analogous what you suggest, it's just the FDM doesn't actually need to know it (besides what ever you report would have to refer to some sort of static location). If we stick to having the only thing connecting the 3D to the FDM those /orientation and /position properties, then we'll be in better shape for multi-instance FDMs. That makes sense. So, I apply an offset to the 3d model, then an appropriate one to the views to bring those to the CofG (dry, I suppose). Then we can dynamically adjust the view offset to account for variations in the CofG with time so that the 3d model appears to rotate around the correct point at all times. Or will the views be offset some other way? Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC voice howto
Jonathan Richards wrote: On Thursday 12 Feb 2004 5:31 pm, David Luff wrote: OK, here's some instructions on how to generate new ATC voices for FlightGear. Hopefully this will make some sense to somebody, ask if it's unclear. snip Two files are required for each voice - a wave file containing the actual sounds, and an index file that basically describes where in the wave file buffer to find each word or phrase. The current voices for the ATIS can be found in $FG_ROOT/data/ATC and are called default.wav and default.vce for the wave and index file respectively. Note that one important change will be made in default.vce - currently it is indexed by byte position into the sound buffer, but I've decided it would be better to index by time into the buffer, since that is more robust to changing the recording quality, and in the future possiby using encoding such as Ogg Vorbis. Also, the first line currently contains the number of subsequent lines, but I think that can be ditched! massive snip David In what units shall the time index be specified? The sampling rate sets a resolution limit on the timing, so for 8kHz we only need 1/8000 sec = 125 microseconds precision, but if we have an ambition for higher rates, we need more. [1] In reality, radio comms are not HiFi standard. Does anyone know what the typical bandwidth is? Or should we simulate by taking a beautiful 22kHz recording and filtering it to sound like the real thing? Perhaps as an option, so one can do radio practice with bell-like clarity at first, and graduate to crackly reception of foreign languages and accents later! Regards Jonathan [1] It occurs to me that for chunked formats like WAV, there is a mathematical relationship between the byte position and the time offset which could be used for conversion, no? Does anyone know, does Plib include realtime sound mixing, downsampling and volume control (the sound should be downsampled to match the real aircraft comms, it should be more soft when you're further away from the transmitter and we should mix some noise sounds with a speech to sound everything more like in real life). - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Eye candy
On Samstag, 14. Februar 2004 22:33, Jon Berndt wrote: One feature in JSBSim that I began and have not yet finished (pending other things) is a parent/child capability. You can (for instance) load a Mk82 on an F-16 and the physical effects of the Mk82 will affect the F-16. The position is based on the position of the parent, and so is the orientation. However, the Mk82 position is not integrated, it always has a position based on the parent, UNTIL it is released. Then, the EOM begins integrating and the flyout is physics based. The child objects are each their own individual JSBSim objects in their own right, and each could be loaded and flown by itself. The JSBSim executive is sort of recursive in this way. Each would be addressable in a way that I think Tony set up with Properties, but I can't recall what it is. Technically, it is also possible for each droppable piece to have its own propulsion and flight control system, too. The possiblities there are quite broad. Sounds interresting. I have this in mind now for my timestepping changes. As I told you before in a private mail, many ideas for something like that in my head ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Sunday 15 February 2004 01:08, Jon Berndt wrote: [snip...] I am trying to preclude confusion amongst the audience of 3D modelers and flight model creators. Jon I'm not confused - am I doing something wrong? ;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
Jon S Berndt [EMAIL PROTECTED] wrote: On Fri, 13 Feb 2004 10:23:56 -0700 Russell Suter [EMAIL PROTECTED] wrote: Jon S Berndt wrote: But then, the FDM still has to report where the FDM is in a common reference frame. Exactly! At my company, we call this the control point and we have standardized on the Empty Weight CG. The 3D model designer will likely have no idea where the empty weight CG is, nor will they often care. They do know where physical points on the aircraft are, however. Additionally, the empty weight CG will be a slippery item to standardize on. Does that mean no fuel? No cargo? nothing? no stores? the C/D model or the A/B model? etc. The VRP is a **solid** point of reference. I realize that it is useful to agree to the nose as VRP in purpose to take the load off the 3D model designer to determine the empty weight CG. This is a valid argument. Albeit I don't want to hide an argument that speaks for the empty weight as a VRP which stems from practical experience as an engineer in say a production environment, where reality 'sometimes' differs from how things _should_ be in theory. You could call the rule: Reduce possbile errors already in early stages of design. Adopted to the current case this means: The longest distance from whichever CG you take to the edges of the aircraft is _always_ smaller than the longest distance from the nose to arbitrary edges. This results in smaller relative 'errors' in case some details don't get modelled as exact as it probably could be. Consinder the case as an example that the flight model (not the FDM) is built upon data from an early design of some aircraft - because access to this data is easier. On the other hand, the 3D designer takes recent pictures as a basis for his model, because old picures from the early design are hard to find. If you take the empty weight as VRP then chances are that the 3D model fits to the flight model with a smaller error because probably during development the shape of the nose has changed, a different radar was chosen (military aircraft), later production models got a different propeller with a different spinner (light aircraft) or whatever reason it might have had. Cheers, 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] waves white flag
Mathias Fröhlich wwrites: On Sonntag, 15. Februar 2004 10:49, Erik Hofman wrote: Jon Berndt wrote: I give up. Sort of. I hope you don't! No need to IMHO. I think we now have an excellent solution. Could someone file a patent request for this? There are some gotcha's involved which could mean some other points/locations should be exposed also in the future, but that's about it. And even then, JSBSim is now able to satisfy *every* request in that direction. I also did not understand why this simple feature is such a big question! The main remaining problem is that the rest of the subsystems have yet to take this adjustment into account also. Also from my reading of the current Model code it appears as if the absolute positioning of an aircraft with the world will be *very* dependent on the designer's choice of the VRP and I am also not sure if just with this addition the current code will fix the 'issue' that prompted the incarnation of this thread again. i.e. the aircraft appears to be rotating about the nose But since this is an abstract thing it is good to have a 'public' thrashing so all can gain an understanding of the issues involved please note this is non-trivial to most and not just a simple feature request which has far reaching consequences on the very 'core' of most everything within the SIM so to outline what I have gleaned so far 1) the 'modellers' coordinate frame will be [ X ] longitudinal increasing aft i.e. smallest at the nose [ Y ] latitudinal increasing righti.e. smallest at the left wing tip [ Z ] verticalincreasing up i.e. smallest at the ground 2) within this frame a VRP virtual refrence point will be designated to represent the origin of the coordinate frame with respect to the 'tip' of the nose of the aircraft. 3) The SSG will assume a 'similar frame' but keep in mind that the Object.getBSphere()-getCenter() will return the point that is 'magically' computed to be at the center of the 'Geomettry' when passed to SSG at Object creation time. Most likely this will not be the VRP and in any case can *not* be assumed to be, and is . IMPORTANT: This *is* the point ultimately used by the Rendering Engine from which any rotation and / or translation is derived. 4) The FDM will compute the center of 'Gravity' WRT to the frame and pass it's offset WRT to the VRP back to FGFS. note this is not and thus can *not* be assumed to be the same as the center of 'Geometry' that will be used by the Rendering Engine. 5) AFAICT FGFS will then reposition the AirCraft using the offset provided by the FDM and rotate the AirCraft to align itself with the orientation. Here is where I get confused and ... I am probably missing the obvious but nowhere in the above is the offset from the possibly corrected VRP WRT the Object.getBSphere()-getCenter() accounted for ?? Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. Also there is this issue about where exactly the [ lat, lon. alt ] reported back from the FDM each cycle refers to that is yet to be decided Again I am probably missing the obvious here and should just go back to lurking so Erik doesn't start ignoring my posts too :-) HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt said: The _only_ difference between now and what we had before is now the position may be reported at a fixed location on the aircraft by JSBsim. Before it was reported at the _current_ center of gravity which varies according to load, fuel consumption, etc. I'm sorry to be so dense, but could some explain what this is going to mess up? Say that initially JSBSim and the 3D model both agreed on where the center was - for JSBSim we simply report the CG location. OK, so the 3D model is flying along nicely - even took off nicely (since the CG matches where the 3D model rotates about in this example). Now, let's say we have fuel burnoff on one wing tank but not the other, so we end up with a CG that is two feet to the left of the fuselage at around the quarter chord (if you could even fly that, but humour me). The 3D model stil thinks the center of rotation is at the initially specified CG point, right? Now, when the aircraft lands, the FDM knows about all the contact points and where the CG is currently, and say one main gear (right) touches down well before the other. When the aircraft touches down the right gear, visually the right gear would hover above the runway some distance, because it is rotating about the initial CG, yet the FDM is rotating about the left-displaced CG, which has also a different altitude than is visually being shown That's not really true because you are providing us with a translated VRP position (which while arbitrary will always have the correct altitude). That visual wheel should hit the ground exactly on time. You wrote the code didn't you? ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 16:08, Norman Vine wrote: i.e. the aircraft appears to be rotating about the nose No, it does not rotate around the nose since the reported position is corrected by just that amount that is required to rotate around the correct axis. This is just a thing of proper coordinate system transforms at the right place. But since this is an abstract thing it is good to have a 'public' thrashing so all can gain an understanding of the issues involved please note this is non-trivial to most and not just a simple feature request which has far reaching consequences on the very 'core' of most everything within the SIM Ok, sorry! so to outline what I have gleaned so far 1) the 'modellers' coordinate frame will be [ X ] longitudinal increasing aft i.e. smallest at the nose [ Y ] latitudinal increasing righti.e. smallest at the left wing tip [ Z ] verticalincreasing up i.e. smallest at the ground JSBSim calls that the 'reference frame' since this seems to be the most often used representation in aircraft industry for construction drawings. I am at the moment not shure if a visual model (in ac3d for example) uses also this conventions. 2) within this frame a VRP virtual refrence point will be designated to represent the origin of the coordinate frame with respect to the 'tip' of the nose of the aircraft. No need for a nose tip of an aircraft at this time of an explanation. This visual reference point is just an arbitrary fixed location in this reference frame. In a JSBSim configuration file this one is also stored as a cordinate value inside this reference frame. And yes, if somone likes to have this visual reference point at the nosetip he can put it there. But you can equally well place it at any other fixed (fixed with respect to the reference frame) point in or outside the aircraft as long as you either place the origin of your visual model (ac3d/mdl/whatever file) at this fixed point. Alternativly you can correct this origin later by these offset values in the visual models xml file. 3) The SSG will assume a 'similar frame' but keep in mind that the Object.getBSphere()-getCenter() will return the point that is 'magically' computed to be at the center of the 'Geomettry' when passed to SSG at Object creation time. Most likely this will not be the VRP and in any case can *not* be assumed to be, and is . IMPORTANT: This *is* the point ultimately used by the Rendering Engine from which any rotation and / or translation is derived. I assume SSG is simple scene graph. Right? I am not really familiar with the code inside flightgear/plib here. So I may omit some things here. It is a requirement for the modeller to match the VRP configured in JSBSim with the origin of the ac3d file after applying the offsets from the xml file used to load/animate this ac3d file. When this matches the reported position/orientation is exactly that required for the getCenter() value of the aircraft model. 4) The FDM will compute the center of 'Gravity' WRT to the frame and pass it's offset WRT to the VRP back to FGFS. note this is not and thus can *not* be assumed to be the same as the center of 'Geometry' that will be used by the Rendering Engine. Hmm, no. Simply no. The FDM traces the center of gravity in the earth frame. I call this the dynamic center of gravity, because this one is not fixed in the reference frame due to fuel loss and such. JSBSim also traces the location of the dynamic center of gravity inside the reference frame. Now, when you know where the dynamic center of gravity is located in the earth frame (lat/lon/h) and you know where the dynamic center of gravity is in the reference frame, you can compute the location of the visual reference point in the earth frame. Of course you will also need the aircraft orientation for this computation. Then this visual reference point is reported to flightgear and plib uses this to draw the aircraft model on your screen. 5) AFAICT FGFS will then reposition the AirCraft using the offset provided by the FDM and rotate the AirCraft to align itself with the orientation. Yes. Here is where I get confused and ... I am probably missing the obvious but nowhere in the above is the offset from the possibly corrected VRP WRT the Object.getBSphere()-getCenter() accounted for ?? I don't completly understand what you mean here. If your configured JSBSim VRP matches the origin of the ac3d file everything fits. Does this help? Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary
RE: [Flightgear-devel] waves white flag
JSBSim calls that the 'reference frame' since this seems to be structural frame, actually. This stuff needs to be compiled into a comprehensible FAQ or document on Coordinate Systems Used, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 17:47, Jon Berndt wrote: JSBSim calls that the 'reference frame' since this seems to be structural frame, actually. Sorry, not the first time I called it reference frame. It seems to be burned in my head with the wrong name... Sure, it is called structural frame! This stuff needs to be compiled into a comprehensible FAQ or document on Coordinate Systems Used, etc. You have already a document about these frames. Can you incorporate? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
You have already a document about these frames. Can you incorporate? That's right. I forgot. I should. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Mathias Fröhlich writes: Norman Vine wrote: Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. You don't need to rotate around an other axis. I will make an example. Assume you will have an aircraft ac3d file whos origin is at tho nose tip. (REALLY JUST FOR EXAMPLE) Assume you have also configured the visual reference point equal to the nose tip. Assume the dynamic center of gravity does not move relative to the earth. Then, when the aircraft pitches the nose downwards around this dynamic center of gravity this pitching angle is reported to flightgear _and_ the reported location of the visual reference point (the nose tip in this case) moves downward. In effect the model rotates around the dynamic center of gravity. Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Jon Berndt writes:
Could this be solved if the camera viewpoint looked at the CG instead of
the VRP? What is being done, now?
The camera viewpoint need not necessarily be either or any fixed point
i.e. the camera should be free to look around :-)
What is required is that the 'center of rotation' of the aircraft is
about the proper point.
But since this is an abstract thing it is good to have a 'public'
thrashing so all can gain an understanding of the issues involved
please note this is non-trivial to most and not just a simple
feature request which has far reaching consequences on the very
'core' of most everything within the SIM
Definitely.
so to outline what I have gleaned so far
1) the 'modellers' coordinate frame will be
[ X ] longitudinal increasing aft i.e. smallest at the nose
[ Y ] latitudinal increasing righti.e. smallest
at the left wing tip
[ Z ] verticalincreasing up i.e. smallest
at the ground
This is definitely my strong preference, but can even this be adusted with
the offsets?
Yes this could be adjusted, probably easiest todo with a single matrix,
as is done with the conversion between SSG space and OpenGL space
ie in SSG space X is to the right, Y is away from the viewer, Z is up
and in OpenGL X is to right, Y is up, and Z is into the screen
and is conversion is accomplished by inserting the
sgMat4 _ssgOpenGLAxisSwapMatrix =
{
{ 1.0f, 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, -1.0f, 0.0f },
{ 0.0f, 1.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 0.0f, 1.0f }
} ;
into the viewer pipeline, but do we want or need this extra flexibility
I think it best if we all just agree that this is the coordinate system
that will be used :-)
2) within this frame a VRP virtual refrence point will be designated
to represent the origin of the coordinate frame with respect to the
'tip' of the nose of the aircraft.
The VRP represents the location that the FDM reports the lat/lon/alt of,
since it is a comprehensible (by all parties) fixed point.
It was my understanding that the VRP was decided by the modeller,
most often for ease of 'modelling' and not for any 'physically based'
reasons. IMO we want a 'consistant' position on the frame to be the
reported [ lat, lon, alt ] location. I would argue that the position returned
by Object.getBsphere-getCenter() is the 'logical' choice for this as
it will make other parts of the SIM easier read more direct to keep in
sync, of course any location shift can be compensated for.
The rendering code is beyond me ...
The rendering code is no different WRT to the 'meaning' of the
various 'reference' points then the code the FDM needs to use
to place the objects appropriately into the 'world' with the added
complexity of merging the coordinate frames.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
Jon Berndt said: That's not really true because you are providing us with a translated VRP position (which while arbitrary will always have the correct altitude). That visual wheel should hit the ground exactly on time. You wrote the code didn't you? ;-) Best, Jim Sorry - I meant the above would happen if the change was not incorporated - that it would be fixed with the VRP. Phew! You had me worried. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 18:39, Norman Vine wrote: Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM I don't see a problem. You can view at this in an other way. The visual reference point introduces an additional frame to the FDM. This addinitonal frame has axis looking into the direction of the structural frames axis and has its origin in the visual reference point relative to the structural frame. I will call it now visual reference frame. I hope that you agree that a FDM must be able to trace - the orientation the structural frame relative to the earth - the position of arbitrary points inside the structural frame Also a FDM must be able to translate the coordinate values in one frame to the coordinate values of an other frame. Then you are done. What you need to report to flightgear is the orientation and position of the visual reference frame relative to the earth fixed frame (lat/lon/h + angles). And all required 'corrections' that the model does not rotate around the nose but around the dynamic center of gravity are automatically included. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Jon Berndt writes: Could this be solved if the camera viewpoint looked at the CG instead of the VRP? What is being done, now? The camera viewpoint need not necessarily be either or any fixed point i.e. the camera should be free to look around :-) What is required is that the 'center of rotation' of the aircraft is about the proper point. I used to think this way, but now I am very suspicious. EVEN IF the aircraft is properly rotating about its CG in world space (like it really would, physically) -- regardless of the method we use to implement that rotation (i.e. using the VRP achieves the same end result: rotation about the CG) ... EVEN IF the aircraft is correctly rotating about its CG, what does it LOOK LIKE it is doing if the camera is pointing AT the aircraft VRP (nose) AND if that look at point is kept centered in the view? I suspect that in this case, it will LOOK LIKE the aircraft is rotating about its nose. Its the same idea, in reverse, that lead us to create the VRP for actual aircraft rotations. What if the view instead is aimed so the look at point is the aircraft CG? Maybe this is the case now, already, and I am guessing off-target? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] NewGUI::closeActiveDialog ()
Hi,
I'm using MSVC .Net and after some cofee, screaming and kicking I got the
CVS Build (1.19 = latest??) to work, using WinCVS :)
For what's it worth: I had to fix the dialog closing code to make my dialogs
work.
Any special version that I should checkout?
Regards,
Derick
diff -u -w -b -i -r1.19 new_gui.cxx
--- new_gui.cxx 8 Dec 2003 02:05:10 - 1.19
+++ new_gui.cxx 14 Feb 2004 01:23:45 -
@@ -91,16 +91,22 @@
if (_active_dialog == 0)
return false;
-// Kill any entries in _active_dialogs... Is there an STL
-// algorithm to do (delete map entries by value, not key)? I hate
-// the STL :) -Andy
+ //DERICK: replace-start
+ bool bErased = false;
mapstring,FGDialog *::iterator iter = _active_dialogs.begin();
-for(/**/; iter != _active_dialogs.end(); iter++)
+ while( (iter != _active_dialogs.end() ) !bErased)
+ {
if(iter-second == _active_dialog)
-_active_dialogs.erase(iter);
-
-delete _active_dialog;
+ {
+ delete _active_dialog; // POP Dialog
+ _active_dialogs.erase(iter); // Delete from list
_active_dialog = 0;
+ bErased = true;
+ }
+ // Not found so now to the next
+ iter++;
+ }
+ //DERICK: replace-end
return true;
}
_
Keep up with high-tech trends here at Hook'd on Technology.
http://special.msn.com/msnbc/hookedontech.armx
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] NewGUI::closeActiveDialog ()
Oh.. forgot another typo that needed to be fixed:
diff -u -w -b -i -r1.50 fg_commands.cxx
--- Main/fg_commands.cxx31 Jan 2004 19:47:46 - 1.50
+++ Main/fg_commands.cxx15 Feb 2004 10:20:50 -
@@ -35,7 +35,7 @@
#include fg_commands.hxx
#include fg_props.hxx
#include globals.hxx
-#include logger.cxx
+#include logger.hxx
#include util.hxx
#include viewmgr.hxx
From: Derick Schoonbee [EMAIL PROTECTED]
Reply-To: FlightGear developers discussions
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Flightgear-devel] NewGUI::closeActiveDialog ()
Date: Sun, 15 Feb 2004 18:24:50 +
Hi,
I'm using MSVC .Net and after some cofee, screaming and kicking I got the
CVS Build (1.19 = latest??) to work, using WinCVS :)
For what's it worth: I had to fix the dialog closing code to make my dialogs
work.
Any special version that I should checkout?
Regards,
Derick
diff -u -w -b -i -r1.19 new_gui.cxx
--- new_gui.cxx 8 Dec 2003 02:05:10 - 1.19
+++ new_gui.cxx 14 Feb 2004 01:23:45 -
@@ -91,16 +91,22 @@
if (_active_dialog == 0)
return false;
-// Kill any entries in _active_dialogs... Is there an STL
-// algorithm to do (delete map entries by value, not key)? I hate
-// the STL :) -Andy
+ //DERICK: replace-start
+ bool bErased = false;
mapstring,FGDialog *::iterator iter = _active_dialogs.begin();
-for(/**/; iter != _active_dialogs.end(); iter++)
+ while( (iter != _active_dialogs.end() ) !bErased)
+ {
if(iter-second == _active_dialog)
-_active_dialogs.erase(iter);
-
-delete _active_dialog;
+ {
+ delete _active_dialog; // POP Dialog
+ _active_dialogs.erase(iter); // Delete from list
_active_dialog = 0;
+ bErased = true;
+ }
+ // Not found so now to the next
+ iter++;
+ }
+ //DERICK: replace-end
return true;
}
_
Keep up with high-tech trends here at Hook'd on Technology.
http://special.msn.com/msnbc/hookedontech.armx
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Aerodynamic centre and 3D models
It didn't seem so obvious when you said this: If we are providing the position of the nose, and the 3D model has some arbitrary origin (that's *not* the nose) then it's not gonna work. Yes, that probably didn't help matters. In this lengthy and convoluted thread it's probably not the only thing I stated confusingly. My assumption has been all along that the 3D model would use an arbitrary frame and origin and that the scene code would have to translate the frame for the 3D model so that the nose was (_effectively_) at the (0,0,0) point. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Mathias Fröhlich writes: What you need to report to flightgear is the orientation and position of the visual reference frame relative to the earth fixed frame (lat/lon/h + angles). Agreed And all required 'corrections' that the model does not rotate around the nose but around the dynamic center of gravity are automatically included. Please reread my earlier post on necessary steps for rotating an object about an arbritrary point. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Norman Vine wrote: Mathias Fröhlich writes: Norman Vine wrote: Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. You don't need to rotate around an other axis. I will make an example. Assume you will have an aircraft ac3d file whos origin is at tho nose tip. (REALLY JUST FOR EXAMPLE) Assume you have also configured the visual reference point equal to the nose tip. Assume the dynamic center of gravity does not move relative to the earth. Then, when the aircraft pitches the nose downwards around this dynamic center of gravity this pitching angle is reported to flightgear _and_ the reported location of the visual reference point (the nose tip in this case) moves downward. In effect the model rotates around the dynamic center of gravity. Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM The first item doesn't need to be done per-frame. It can be done once and remembered. -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Norman Vine wrote: Mathias Fröhlich wwrites: On Sonntag, 15. Februar 2004 10:49, Erik Hofman wrote: Jon Berndt wrote: I give up. Sort of. I hope you don't! No need to IMHO. I think we now have an excellent solution. Could someone file a patent request for this? There are some gotcha's involved which could mean some other points/locations should be exposed also in the future, but that's about it. And even then, JSBSim is now able to satisfy *every* request in that direction. I also did not understand why this simple feature is such a big question! The main remaining problem is that the rest of the subsystems have yet to take this adjustment into account also. Also from my reading of the current Model code it appears as if the absolute positioning of an aircraft with the world will be *very* dependent on the designer's choice of the VRP and I am also not sure if just with this addition the current code will fix the 'issue' that prompted the incarnation of this thread again. i.e. the aircraft appears to be rotating about the nose But since this is an abstract thing it is good to have a 'public' thrashing so all can gain an understanding of the issues involved please note this is non-trivial to most and not just a simple feature request which has far reaching consequences on the very 'core' of most everything within the SIM so to outline what I have gleaned so far 1) the 'modellers' coordinate frame will be [ X ] longitudinal increasing aft i.e. smallest at the nose [ Y ] latitudinal increasing righti.e. smallest at the left wing tip [ Z ] verticalincreasing up i.e. smallest at the ground This should not necessarily be a requirement for the 3D model. It is, however what the model must be translated to with the /offsets/ property. 2) within this frame a VRP virtual refrence point will be designated to represent the origin of the coordinate frame with respect to the 'tip' of the nose of the aircraft. 3) The SSG will assume a 'similar frame' but keep in mind that the Object.getBSphere()-getCenter() will return the point that is 'magically' computed to be at the center of the 'Geomettry' when passed to SSG at Object creation time. Most likely this will not be the VRP and in any case can *not* be assumed to be, and is . IMPORTANT: This *is* the point ultimately used by the Rendering Engine from which any rotation and / or translation is derived. The center of the bounding sphere shouldn't be relevant in this discussion. 4) The FDM will compute the center of 'Gravity' WRT to the frame and pass it's offset WRT to the VRP back to FGFS. note this is not and thus can *not* be assumed to be the same as the center of 'Geometry' that will be used by the Rendering Engine. 5) AFAICT FGFS will then reposition the AirCraft using the offset provided by the FDM and rotate the AirCraft to align itself with the orientation. Here is where I get confused and ... I am probably missing the obvious but nowhere in the above is the offset from the possibly corrected VRP WRT the Object.getBSphere()-getCenter() accounted for ?? The IG shouldn't be used to position the 3D model. If it being used, that's wrong. Also I can not find in the code the mechanism that will rotate the AirCraft about any point other then the point returned by Object.getBSphere()-getCenter() as adjusted by the translation WRT the VRP which appears to be set at Model load time from the OffSet from the nose and not the Geometrical center about which rotations will occur. In order for this to occur you need two complimentary translations. One before and one after the rotation. Also there is this issue about where exactly the [ lat, lon. alt ] reported back from the FDM each cycle refers to that is yet to be decided Again I am probably missing the obvious here and should just go back to lurking so Erik doesn't start ignoring my posts too :-) HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NewGUI::closeActiveDialog ()
Derick Schoonbee wrote: Hi, I'm using MSVC .Net and after some cofee, screaming and kicking I got the CVS Build (1.19 = latest??) to work, using WinCVS :) For what's it worth: I had to fix the dialog closing code to make my dialogs work. Any special version that I should checkout? Excuse my question, but what is the problem you are wanting to cure ? I am asking this because I am able to compile new_gui.cxx r1.19 with MSVC .Net without any modification. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Russell Suter writes: The IG shouldn't be used to position the 3D model. If it being used, that's wrong. By IG I am assuming you mean Image Generator, and you have to understand how the things are drawn or else you are bound to get surprised at least occassionally :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Jim Wilson writes: Norman Vine said: Here is where I get confused and ... I am probably missing the obvious but See 3. Ummm...think about how rotation in 3D space really works for a minute. Easier to just wait for all this to get coded up and then see it live on the monitor :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
On Sonntag, 15. Februar 2004 19:26, Norman Vine wrote: And all required 'corrections' that the model does not rotate around the nose but around the dynamic center of gravity are automatically included. Please reread my earlier post on necessary steps for rotating an object about an arbritrary point. Yes, I know how this relates, at least I believe. :) I will tell you that looking at the problem the way I described, you will see that you don't need to care for that forward and backward translation and rotation since you can reinterprete this sequence - translations and rotations you have in mind to place the model in the world - translate to the rotation axis - rotate - translate back as a matrix product of model transforms. But the same resulting transform matrix can also result from a completly different sequence. And viewing at the problem the way I suggested in my last mail will show you that you will also gain this resulting transform matrix by - translate to lat/lon/h of the vrp - rotate by the given angles I may have described the transforms in the wrong order, but in principle it sould be ok. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] waves white flag
Norman Vine wrote:
Jon Berndt writes:
Could this be solved if the camera viewpoint looked at the CG instead of
the VRP? What is being done, now?
The camera viewpoint need not necessarily be either or any fixed point
i.e. the camera should be free to look around :-)
What is required is that the 'center of rotation' of the aircraft is
about the proper point.
But since this is an abstract thing it is good to have a 'public'
thrashing so all can gain an understanding of the issues involved
please note this is non-trivial to most and not just a simple
feature request which has far reaching consequences on the very
'core' of most everything within the SIM
Definitely.
so to outline what I have gleaned so far
1) the 'modellers' coordinate frame will be
[ X ] longitudinal increasing aft i.e. smallest at the nose
[ Y ] latitudinal increasing righti.e. smallest
at the left wing tip
[ Z ] verticalincreasing up i.e. smallest
at the ground
This is definitely my strong preference, but can even this be adusted with
the offsets?
Yes this could be adjusted, probably easiest todo with a single matrix,
as is done with the conversion between SSG space and OpenGL space
ie in SSG space X is to the right, Y is away from the viewer, Z is up
and in OpenGL X is to right, Y is up, and Z is into the screen
and is conversion is accomplished by inserting the
sgMat4 _ssgOpenGLAxisSwapMatrix =
{
{ 1.0f, 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, -1.0f, 0.0f },
{ 0.0f, 1.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 0.0f, 1.0f }
} ;
into the viewer pipeline, but do we want or need this extra flexibility
I think it best if we all just agree that this is the coordinate system
that will be used :-)
2) within this frame a VRP virtual refrence point will be designated
to represent the origin of the coordinate frame with respect to the
'tip' of the nose of the aircraft.
The VRP represents the location that the FDM reports the lat/lon/alt of,
since it is a comprehensible (by all parties) fixed point.
It was my understanding that the VRP was decided by the modeller,
most often for ease of 'modelling' and not for any 'physically based'
reasons. IMO we want a 'consistant' position on the frame to be the
reported [ lat, lon, alt ] location. I would argue that the position returned
by Object.getBsphere-getCenter() is the 'logical' choice for this as
it will make other parts of the SIM easier read more direct to keep in
sync, of course any location shift can be compensated for.
No! The Bounding Sphere is used to decide if the 3D model appears in
the viewing
frustum. The characteristics of a Bounding Sphere can change. As an
example, if a
sidewinder missile is launched from the tip of the wing, the verticies
of the missile
will no longer be part of the model and the center of the Bounding
Sphere can shift
relative to the rest of the model. If the Bounding Sphere is being used
to move the
model through the scene, it should be changed to use the product of this:
From sgLoad3DModel (in SimGear/simgear/scene/model.cxx):
ssgTransform * alignmainmodel = new ssgTransform;
alignmainmodel-addKid(model);
sgMat4 res_matrix;
sgMakeOffsetsMatrix(res_matrix,
props.getFloatValue(/offsets/heading-deg, 0.0),
props.getFloatValue(/offsets/roll-deg, 0.0),
props.getFloatValue(/offsets/pitch-deg, 0.0),
props.getFloatValue(/offsets/x-m, 0.0),
props.getFloatValue(/offsets/y-m, 0.0),
props.getFloatValue(/offsets/z-m, 0.0));
alignmainmodel-setTransform(res_matrix);
Thanks to Jim Wilson for posting this snippet.
The rendering code is beyond me ...
The rendering code is no different WRT to the 'meaning' of the
various 'reference' points then the code the FDM needs to use
to place the objects appropriately into the 'world' with the added
complexity of merging the coordinate frames.
--
Russ
Conway's Law: The structure of a system tends to mirror the
structure of the group producing it.
-- Mel Conway Datamation (1968)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] waves white flag
Russell Suter writes: Norman Vine wrote: Simply stated the problem is that inorder to rotate an object about an arbritrary point you *must* do the equivalaent of the following 1) translate object so that it's 'rotation point' is at the 'point of rotation' 2) rotate the object 3) translate the object to it's 'desired' position this may not be it's original position depending on a) the 'coordinate frame' the object is described in which very likely is the case with an arbritrary VRP b) if the coordinate frame is dynamically changing as is the case with aerodynamic forces and gravity determining the 'frame' in a sophisticated FDM The first item doesn't need to be done per-frame. It can be done once and remembered. Agreed, and this is AFAICT what is done know although I don't believe the dynamic adjustment to the CG is accounted for yet FWIW AFAICT what isn't done is (3) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Installing scenery helper app.
Curtis L. Olson wrote: Installing scenery can be a bit of a chore for people who are new to our project and don't know exactly how everything is supposed to be layed out on disk. This weekend I've hacked up a little helper app that is intended to be a sibling to Bernie's fgrun. I've tentatively called it fgadmin and it's written similarly using fltk. Thinking about windows and our fgsetup.exe for a moment. The idea is that this app would get installed along with fgrun and fgfs and the installer would automatically set up the fgadmin preferences to know where FG is installed. This means the first time it is run, it will already now where to put scenery. In addition, it's linked against libtar and libz so it can extract the .tar.gz files without any helper apps. So when the app comes up, it presents a scrolling list of all the .tar.gz files at the source which are available to install. In a parallel window it presents all the scenery chunks that are already installed (which the user might want to uninstall.) The user can select any number of files to install/uninstall and the system will do the work automatically. I've placed my first stab at this here: http://www.flightgear.org/tmp/fgadmin-1.0.0.tar.gz It requires requires fltk, plib, simgear, libz and libtar. In the future I can imagine that something similar might be useful for installing/uninstalling aircraft. There are a number of directions we could take this which would all be interesting and useful. I'm hoping a few people could try this out (especially under windows) and see what they think. What changes are required to build under MSVC for instance? (Hopefully none or very few) Between this and Bernie's latest changes to fgrun, I'm hoping that our next release will be a huge leap forward in terms of providing a easy to run/install system for new users. For the moment, libtar is not compilable with MSVC. There are a lot of unix specific typedef and include files that are not in the compat library. There are patch for win32 but I think they assume CygWin. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RC Heli Sim
Hi, My plan is to do some research for building a RC Heli UAV (Hobby) using fgfs: Thus Kalman filters working on simulated GPS, Gyro and Accelerometers (for INS navigation) including noise with a 'real heli sim' etc.. I.e. such as autopilot.sf.net : http://autopilot.sourceforge.net/ Im contemplating getting Aaron Kahns flighsim into fgfs the same way that the BalloonSim was implemented (encapsulating it in FGBalloonSim) Has anybody walked down this lane before? (RC HeliSim for fgfs) Regards, Derick Schoonbee _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NewGUI::closeActiveDialog ()
Derick Schoonbee wrote: Salut, H.. the prob is not a compile error as it compiles fine. Just a 'strange behavior' the happened to me.. for some reason my dialogs did not want to close, for example after making some adjustments to Autopilot settings... when clicking on the buttons it hangs.. Just want to make sure that 1.19 is ok.. and that the latest cvs is ok? Or actually let me rephrase: Which CVS ver should I checkout.. Merci bien Derick From: Frederic Bouvier Please, do not include raw email and ease spammers' job. Subject: Re: [Flightgear-devel] NewGUI::closeActiveDialog () Date: Sun, 15 Feb 2004 19:39:25 +0100 Derick Schoonbee wrote: Hi, I'm using MSVC .Net and after some cofee, screaming and kicking I got the CVS Build (1.19 = latest??) to work, using WinCVS :) For what's it worth: I had to fix the dialog closing code to make my dialogs work. Any special version that I should checkout? Excuse my question, but what is the problem you are wanting to cure ? I am asking this because I am able to compile new_gui.cxx r1.19 with MSVC .Net without any modification. The last revision is always the one to use or to correct. If we would rely on sticky tags, the project would be a huge mess. Your patch doesn't destroy the _active_dialog if it is not in the _active_dialogs map. But how is it possible ? Correct me if I am wrong but I think the real fix is to avoid this. AFAICS, all new dialogs are added in _active_dialogs at creation time, so if it is not there, it is because it has already been closed ( and deleted ). And if the dialog is already deleted, its pointer is surely deadbeef with MSVC. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Installing scenery helper app.
Curtis L. Olson wrote: Frederic Bouvier wrote: For the moment, libtar is not compilable with MSVC. There are a lot of unix specific typedef and include files that are not in the compat library. There are patch for win32 but I think they assume CygWin. Anyone know of any alternate tar extraction libs? Searching on Freshmeat, I found this : http://freshmeat.net/projects/untarka/ It is a single .c file that compile a executable but without a main function, perhaps it can be of any use. It is GPL'ed so we could include it in the distribution. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NewGUI::closeActiveDialog ()
Please, do not include raw email and ease spammers' job. Don't worry.. as far as I see that mail did not reach the list.. only you.. The last revision is always the one to use or to correct. If we would rely on sticky tags, the project would be a huge mess. Thanks.. just did a sanity check... ;) Your patch doesn't destroy the _active_dialog if it is not in the _active_dialogs map. But how is it possible ? Correct me if I am wrong but I think the real fix is to avoid this. AFAICS, all new dialogs are added in _active_dialogs at creation time, so if it is not there, it is because it has already been closed ( and deleted ). And if the dialog is already deleted, its pointer is surely deadbeef with MSVC. I'm neither a C++ guru.. only started realy programmingwith it about 4mnths ago (got years of other programming languages experience.) but here we go: I must admit that I did not study the whole dialog management process .. I borrowed the concept from NewGUI::closeDialog (const string name) which appears to be the counterpart of closing by Name as apposed to closing the active one. As far as I can figure out: Pointers to FGDialog (via new) gets created in the list (showDialog) and deleted (FDialog ptr) on the close (closeDialog closeActiveDialog). _active_dialog is just a copy of a ptr to FGDialog and thus needs to be zeroed. (Except if this happens by some magic that Im not aware of..) The management of the list in these 3 funcs then seems fine by me. But thats just my interpretation of the code (which worked for me), so take it easy on me.. this is my first venture into Opensource.. ;) Can anybody correct me if Im wrong? I even tested with multiple active dialogs (changing xml properties) and it seems ok.. Does the original flavor work fine here to for you? Regards, Derick PS: Whats AFAICS ?? _ Create your own personal Web page with the info you use most, at My MSN. http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Panel Instruments
Frederic Bouvier wrote: I wrote: could you please add the binary tag to the textures you added in CVS. Thanks from a windows user Could someone with CVS write access add the -kb sticky tag to these files : Thank you very much I get a permission denied. This has to wait until Curtis fixes this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NewGUI::closeActiveDialog ()
Hi,
Why changing it then ?
Does not work... ;)
I just want to challenge you and your patch. You're applying for inclusion
in CVS don't you ;-) If you have a problem with current code, just tell us
how to reproduce it.
I like challenges so how about this:
Reproduction steps (for CVS checkout/build):
- Switch on computer, checkout, compile, drink coffee,
,start fgfs etc.. ;)
- Click on the menu Autopilot Autopilot Settings
- No need to modify, then click OK or Cancel (closing actions)
Expected behavior:
- Dialog closes and live goes on
Observed behavior:
- The world stands still (from FGs perspective)
Reason:
- There is a loop-a-dyloop on in GUI/new_gui.cxx (97-102)
for(/**/; iter != _active_dialogs.end(); iter++)
if(iter-second == _active_dialog)
_active_dialogs.erase(iter);
delete _active_dialog;
Suggested fix:
- Change (98-102) to:
for(/**/; iter != _active_dialogs.end(); iter++)
if(iter-second == _active_dialog) {
_active_dialogs.erase(iter);
delete _active_dialog;
}
- This works now for some bizarre reason .. h
Regards,
Derick Schoonbee
_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NewGUI::closeActiveDialog ()
Slight correction.. should be:
bool bErased = false;
mapstring,FGDialog *::iterator iter = _active_dialogs.begin();
while( (iter != _active_dialogs.end() ) !bErased) {
if(iter-second == getActiveDialog()) {
delete getActiveDialog(); // POP Dialog
_active_dialogs.erase(iter); // Delete from list
setActiveDialog(0); // No more there
bErased = true; // Exit loop
}
// Not found so now to the next
iter++;
}
_
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NewGUI::closeActiveDialog ()
Derick Schoonbee wrote:
Hi,
Why changing it then ?
Does not work... ;)
I just want to challenge you and your patch. You're applying for
inclusion
in CVS don't you ;-) If you have a problem with current code, just tell
us
how to reproduce it.
I like challenges so how about this:
Reproduction steps (for CVS checkout/build):
- Switch on computer, checkout, compile, drink coffee,,start fgfs etc..
;)
- Click on the menu Autopilot Autopilot Settings
- No need to modify, then click OK or Cancel (closing actions)
Expected behavior:
- Dialog closes and live goes on
Observed behavior:
- The world stands still (from FGs perspective)
Reason:
- There is a loop-a-dyloop on in GUI/new_gui.cxx (97-102)
for(/**/; iter != _active_dialogs.end(); iter++)
if(iter-second == _active_dialog)
_active_dialogs.erase(iter);
delete _active_dialog;
Suggested fix:
- Change (98-102) to:
for(/**/; iter != _active_dialogs.end(); iter++)
if(iter-second == _active_dialog) {
_active_dialogs.erase(iter);
delete _active_dialog;
}
- This works now for some bizarre reason .. h
Sorry, but it works for me ( window closes and program runs ).
Anybody else seeing what Derick is describing ?
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: NewGUI::closeActiveDialog ()
* Frederic Bouvier -- Sunday 15 February 2004 23:44: Sorry, but it works for me ( window closes and program runs ). Anybody else seeing what Derick is describing ? Nope. Works perfectly. (Linux, CVS/HEAD). I'll run valgrind over it ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: NewGUI::closeActiveDialog ()
* Frederic Bouvier -- Sunday 15 February 2004 23:44: Sorry, but it works for me ( window closes and program runs ). Anybody else seeing what Derick is describing ? Nope. Works perfectly. (Linux, CVS/HEAD). I'll run valgrind over it ... m. The thing that does not make sense is that the for loop even runs delete _active_dialog; when I step in Debug (MSVC 2003) for(/**/; iter != _active_dialogs.end(); iter++) if(iter-second == _active_dialog) _active_dialogs.erase(iter); delete _active_dialog; -- Thus it evaluates: for(... if(... _active... delete.. for(... if(... _active... delete.. And that scares me ;) Maybe the way MS(VC 2003) handles the STL? or CR/LF ... I'll look into this... _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: NewGUI::closeActiveDialog ()
Derick Schoonbee wrote:
* Frederic Bouvier -- Sunday 15 February 2004 23:44:
Sorry, but it works for me ( window closes and program runs ).
Anybody else seeing what Derick is describing ?
Nope. Works perfectly. (Linux, CVS/HEAD). I'll run valgrind over it ...
m.
The thing that does not make sense is that the for loop even runs delete
_active_dialog; when I step in Debug (MSVC 2003)
for(/**/; iter != _active_dialogs.end(); iter++)
if(iter-second == _active_dialog)
_active_dialogs.erase(iter);
delete _active_dialog;
--
Thus it evaluates:
for(...
if(...
_active...
delete..
for(...
if(...
_active...
delete..
And that scares me ;)
Maybe the way MS(VC 2003) handles the STL? or CR/LF ... I'll look into
this...
Hidden braces ? ;-) I must admit I use .Net 2002 but it is hard to think
MSVC is having problem on it. Currently the code is equivalent to this :
for(/**/; iter != _active_dialogs.end(); iter++) {
if(iter-second == _active_dialog) {
_active_dialogs.erase(iter);
}
}
delete _active_dialog;
Try to put them and see if it makes a difference.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Panel Instruments
Erik Hofman wrote: I get a permission denied. This has to wait until Curtis fixes this. Hi, the directory group ownership should be updated. If you remember which files need their tags changed, you should be able to go ahead and change them now. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab 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] 3D Panel Instruments
Frederic Bouvier said: Could someone with CVS write access add the -kb sticky tag to these files : Done. Let me know if I missed anything. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: NewGUI::closeActiveDialog ()
Bracing the for makes the stepping go ok but... the the for loop loops
forever .. eh eh
If I do not clear _active_dialog the for still loops
If if do not brace all it loops... it even looped on the return.. go
figure...
So finally the only way I could get the orignal code work was to modify the
for statement:
for(/**/; iter != _active_dialogs.end() _active_dialogs.size();
iter++)
if(iter-second == _active_dialog)
_active_dialogs.erase(iter);
.. seems like _active_dialogs.end() == true is never reached...
Isn't there an STL rule/feature about iterator consistancy when modifying
the same container the iterator is constructed from in a loop?
My guess is that once the iterator is constructed in this case it forgets
the state of the map and keeping track... performance reasons??
That's all I could figure out (and to get out of the for)
And oh: Why is this hapenning to me ;)
* Frederic Bouvier -- Sunday 15 February 2004 23:44:
Sorry, but it works for me ( window closes and program runs ).
Anybody else seeing what Derick is describing ?
Nope. Works perfectly. (Linux, CVS/HEAD). I'll run valgrind over it ...
m.
The thing that does not make sense is that the for loop even runs delete
_active_dialog; when I step in Debug (MSVC 2003)
for(/**/; iter != _active_dialogs.end(); iter++)
if(iter-second == _active_dialog)
_active_dialogs.erase(iter);
delete _active_dialog;
--
Thus it evaluates:
for(...
if(...
_active...
delete..
for(...
if(...
_active...
delete..
And that scares me ;)
Maybe the way MS(VC 2003) handles the STL? or CR/LF ... I'll look into
this...
Hidden braces ? ;-) I must admit I use .Net 2002 but it is hard to think
MSVC is having problem on it. Currently the code is equivalent to this :
for(/**/; iter != _active_dialogs.end(); iter++) {
if(iter-second == _active_dialog) {
_active_dialogs.erase(iter);
}
}
delete _active_dialog;
Try to put them and see if it makes a difference.
-Fred
_
Find great local high-speed Internet access value at the MSN High-Speed
Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: NewGUI::closeActiveDialog ()
Derick Schoonbee wrote: Bracing the for makes the stepping go ok but... the the for loop loops forever .. eh eh If I do not clear _active_dialog the for still loops If if do not brace all it loops... it even looped on the return.. go figure... You must have screwed memory and map pointers with your mods. Let's wait Melchior and its Valgrind analysis to see if it's not already a problem in FG. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
