Re: [Flightgear-devel] Problem with ballistic sub-model
On Monday 20 September 2004 08:39, Vivian Meazza wrote:
{snip...]
Lee,
Here's some pics off the effects I obtained:
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_drag-full_g
ravity.jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-acc
elerating.jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bom
bs_overtaking. jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bra
king.jpg
I hope that you can achieve the same.
Regards
Vivian
Sadly, no. Those pics are pretty much what I was hoping to see
here but it's just not happening. This is very odd.
I could post a pic showing the a/c after braking, with the string
of bombs behind and the cluster around the nose (which would
show that it had moved, while releasing bombs and was now
stationary) but is there any point?
I'm a bit reluctant to do a full fresh cvs checkout because I'd
have to also get a new base package too, wouldn't I? Still on
dial-up here so I'd like to avoid having to do that if possible.
If I delete the source code directories from my local cvs and
then did an update, would it replace anything that was missing?
I guess I could try getting FG installed on one of my other
workstations and see if I get the same results.
I did try setting a more verbose log-level but didn't see
anything there either.
This is such a strange problem. Because there are no apparent
run-time errors it's difficult not to conclude that there's a
logic error in the code but the fact it works elsewhere rules
that out.
Feeling pretty stumped here:-/
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Sunday, September 19, 2004 12:48 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Sunday 19 September 2004 10:42, Vivian Meazza wrote: Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model ...snip .. Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE PLIB is not involved. I've just rechecked the cvs version - works here. The tracer is visible in the upper sector of the gun sight, but you might have to zoom into the gunfight a little to see it. If your eyes are very good, it is also visible from behind the aircraft, but you have to know where to look. The tracer is only visible from behind. You could also try at night, the tracer are more visible. That's at 800 x 600; if you have a 21 screen, its no problem at all. Do you have the tracer files in ..data/models/geometry? Any luck with the other tests? V. Not had a chance today to try them yet - hopefully later this P.M. I'm using a 19 screen at 1600x1200 and run FG in a maximised window i.e. with title bar and edges. Lee, Here's some pics off the effects I obtained: http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_drag-full_gravity.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-accelerating.jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bombs_overtaking. jpg http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-braking.jpg I hope that you can achieve the same. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: ---snip If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE Just a thought - can anyone else confirm either behaviour? Well, I upgraded to cvs (simgear/flightgear about 23:00 UTC 2004-09-18). I'm not exactly sure what behaviour is expected, but when I trigger via property browser - I can hear the cannon firing - I can see (very)little red dots from within the cockpit seeming to leave the cannon - I can see (very)little red dots from outside seeming to leave the cannon - I stops after - hmm... 20-30secs? - maybe out-of-submodels :-))) (using plib-1.8.3) Horst ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? Do you tried with --enable-ai-models ? I was caught by this recently. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model ...snip .. Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE PLIB is not involved. I've just rechecked the cvs version - works here. The tracer is visible in the upper sector of the gun sight, but you might have to zoom into the gunfight a little to see it. If your eyes are very good, it is also visible from behind the aircraft, but you have to know where to look. The tracer is only visible from behind. You could also try at night, the tracer are more visible. That's at 800 x 600; if you have a 21 screen, its no problem at all. Do you have the tracer files in ..data/models/geometry? Any luck with the other tests? V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Arnt Karlsen Sent: Saturday, September 18, 2004 11:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Sat, 18 Sep 2004 13:21:13 +0100, Vivian wrote in message [EMAIL PROTECTED]: ... snip ... I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..eh, accellerations, no, forces, yes. Same thing: a body changes velocity (i.e. accelerates) as the result of an applied force. Newton's 2nd Law. Both bomber and bomb sees the same wind etc until release of child. In a bomb bay or in a gun, the wind exposure happens as these objects emerge outta these shielded hideouts. Not quite true. The parent is experiencing wind, so it is a good enough approximation to apply wind to the child from instantiation. Turbulent airflow around the bomb-bay doors etc. is quite another thing. Although I suspect that the tumbling that you see on films is more or less rotation of the bomb about its CofG. Any that is not can be modelled by applying a bit of randomness to the trajectory. ..If either (plane or bomb etc) object passes thru say wind shear, wing tip vortices, then the wind forces are _different_, even if they can be approximated as the same as the bomb drops thru that vortice in a millisecond. ..and don't forget gun recoil forces. Yes, and charge temperature, barrel temperature and wear, Coriolis effect, parturition effect ... . Don't think I'll bother for guns fired from an aircraft with an effective range of 400 yds. Gun childs also experience wind drift. ;-) We already apply wind drift, but the wind is that experienced by the parent, not the child. This approximation is OK for guns, but makes no allowance for the various winds experienced by bombs during their descent. ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..true, but see below. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? ..this is a design philosophy decision; how close to reality _do_ we wanna go? My point is do as you like, but don't cut off future development by hardcoding stuff, leave open hooks as bait for future developers to go berserk on. ;-) I'm afraid that it's all pretty hard stuff in C++, but if anyone wants to have a go at some of the math or coding, I'd welcome any help. As realistic as the input data will allow. I'm sure Lee wont let up on me 'till his BB bomb is right. Regards V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Sunday 19 September 2004 10:42, Vivian Meazza wrote: Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:28 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model ...snip .. Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE PLIB is not involved. I've just rechecked the cvs version - works here. The tracer is visible in the upper sector of the gun sight, but you might have to zoom into the gunfight a little to see it. If your eyes are very good, it is also visible from behind the aircraft, but you have to know where to look. The tracer is only visible from behind. You could also try at night, the tracer are more visible. That's at 800 x 600; if you have a 21 screen, its no problem at all. Do you have the tracer files in ..data/models/geometry? Any luck with the other tests? V. Not had a chance today to try them yet - hopefully later this P.M. I'm using a 19 screen at 1600x1200 and run FG in a maximised window i.e. with title bar and edges. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Sun, 19 Sep 2004 11:23:35 +0200, Horst wrote in message [EMAIL PROTECTED]: I can hear the cannon firing I can see (very)little red dots from within the cockpit seeming to leave the cannon I can see (very)little red dots from outside seeming to leave the cannon I stops after - hmm... 20-30secs? - maybe out-of-submodels:-))) ..1/3 to 1/2 a minute sounds about right to be out of ammo. -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Sun, 19 Sep 2004 11:17:22 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen Sent: Saturday, September 18, 2004 11:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Sat, 18 Sep 2004 13:21:13 +0100, Vivian wrote in message [EMAIL PROTECTED]: ... snip ... I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..eh, accellerations, no, forces, yes. Same thing: a body changes velocity (i.e. accelerates) as the result of an applied force. Newton's 2nd Law. ..ah, precisely what I meant. ;-) Both bomber and bomb sees the same wind etc until release of child. In a bomb bay or in a gun, the wind exposure happens as these objects emerge outta these shielded hideouts. Not quite true. The parent is experiencing wind, so it is a good enough approximation to apply wind to the child from instantiation. ..I guess we'll leave that as bait for the berserk coders for now. ,-) Turbulent airflow around the bomb-bay doors etc. is quite another thing. Although I suspect that the tumbling that you see on films is more or less rotation of the bomb about its CofG. Any that is not can be modelled by applying a bit of randomness to the trajectory. ..quite right, some of this is caused by the turbulence, some of it by the bomb release mechanism letting go of the bomb. Also, there are those refreshingly wild stories of guys having to enter the bomb bay to kick out bombs riding that turbulent airflow. ;-) ..If either (plane or bomb etc) object passes thru say wind shear, wing tip vortices, then the wind forces are _different_, even if they can be approximated as the same as the bomb drops thru that vortice in a millisecond. ..and don't forget gun recoil forces. Yes, and charge temperature, barrel temperature and wear, Coriolis effect, parturition effect ... . Don't think I'll bother for guns fired from an aircraft with an effective range of 400 yds. Gun childs also experience wind drift. ;-) We already apply wind drift, but the wind is that experienced by the parent, not the child. This approximation is OK for guns, but makes no allowance for the various winds experienced by bombs during their descent. ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..true, but see below. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? ..this is a design philosophy decision; how close to reality _do_ we wanna go? My point is do as you like, but don't cut off future development by hardcoding stuff, leave open hooks as bait for future developers to go berserk on. ;-) I'm afraid that it's all pretty hard stuff in C++, but if anyone wants to have a go at some of the math or coding, I'd welcome any help. As realistic as the input data will allow. I'm sure Lee wont let up on me'till his BB bomb is right. .. ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:59, Vivian Meazza wrote: Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE The Spitfire uses a trigger on your joystick - something like: button n=1 descTrigger/desc binding commandproperty-assign/command property/systems/submodels/trigger/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command property/systems/submodels/trigger/property value type=boolfalse/value /binding /mod-up /button I would suggest that you use the property browser to test the Spitfire m/gs. If the cvs download was OK it is unlikely that there is something wrong with your system. Similarly, if the submodel aligns with the parent when taxi-ing at a reasonable speed, then, basically, it's working since it calculates the angles from speed N/E/D. Try these submodel settings: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda1.2/eda windfalse/wind buoyancy0/buoyancy /submodel And these: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda0/eda windfalse/wind buoyancy32/buoyancy /submodel And let me know what you see so that I can compare. Regards V. Hello Vivian, I tried the two settings above for the Canberra and tried the Spitfire again at dusk but I'm still getting the same results:( I get identical behaviour with the Canberra: I'm accelerating to about 10kt, cutting the throttle so I'm rolling down the runway, and then hitting the release. In both cases I leave a trail of stationary bombs floating behind me and when I hit the brakes I get a cluster of bombs at different pitches oriented around the origin (still the nose of the a/c atm) In the Spitfire I can still hear the guns firing until the ammo is out but I can't see any tracer at all, in either cockpit or external views. Once the ammo's all out I can re-set the count and the guns start firing again but still no visible tracer. This is really odd:-/ LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
..quite right, some of this is caused by the turbulence, some of it by the bomb release mechanism letting go of the bomb. Also, there are those refreshingly wild stories of guys having to enter the bomb bay to kick out bombs riding that turbulent airflow. ;-) Can we model the Dr. Strangelove effect? Giles ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Giles Robertson Sent: Sunday, September 19, 2004 6:02 PM To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ..quite right, some of this is caused by the turbulence, some of it by the bomb release mechanism letting go of the bomb. Also, there are those refreshingly wild stories of guys having to enter the bomb bay to kick out bombs riding that turbulent airflow. ;-) Can we model the Dr. Strangelove effect? Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. I love it. You can have a special parameter for it: slim_pickens=1. :) G -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
The Stetson is being spun, so there's actually a twisting effect there as well. Giles Robertson -Original Message- From: Gene Buckle [mailto:[EMAIL PROTECTED] Sent: 19 September 2004 22:42 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Now let's see. What's the Cd of a human - 1.0 - 1.3? Area seated astride a booomb - 4 sq ft? Make allowance for silly hat - 2 sq ft? Yup, we can do that. I love it. You can have a special parameter for it: slim_pickens=1. :) G -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Friday, September 17, 2004 9:57 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. Like the model: up to your usual standard. (Well, all except the pilot's bone dome - wrong pattern :-)) It works. The operative word is 'accelerate'. As you accelerate you leave bombs behind: they are instantiated with the velocity at the time of release, but since the aircraft is accelerating it will be left behind. Try the following using your original values in submodel: Release a bomb while stationary: it turns and aligns with the velocity - note although the aircraft is stationary, there are still some small N/E/D velocities. I'm not sure why. Accelerate down the runway: the bombs gradually align with the aircraft as forward motion is added, but they are left behind. Brake: the bombs shoot ahead of the aircraft, with their proper velocity. All those left behind now go past. Great fun - like big fish swimming by. I've convinced myself, anyway - Newton's Laws of Motion at work (see Arnt's comments). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Fri, 17 Sep 2004 16:09:12 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse .. ;-) I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. ..precisely, we will need roll rate, yaw, yaw rate, pitch rate etc, but no accellerations except gravity, to get it right. ..also, when we get that far in the modelling; some divebombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymetric or whatever. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Arnt Karlsen wrote: Sent: Friday, September 17, 2004 9:47 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 16:09:12 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse .. ;-) I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. ..precisely, we will need roll rate, yaw, yaw rate, pitch rate etc, I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 10:14, Vivian Meazza wrote: Lee Elliott wrote: Sent: Friday, September 17, 2004 9:57 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. Like the model: up to your usual standard. (Well, all except the pilot's bone dome - wrong pattern :-)) It works. The operative word is 'accelerate'. As you accelerate you leave bombs behind: they are instantiated with the velocity at the time of release, but since the aircraft is accelerating it will be left behind. Try the following using your original values in submodel: Release a bomb while stationary: it turns and aligns with the velocity - note although the aircraft is stationary, there are still some small N/E/D velocities. I'm not sure why. Accelerate down the runway: the bombs gradually align with the aircraft as forward motion is added, but they are left behind. Brake: the bombs shoot ahead of the aircraft, with their proper velocity. All those left behind now go past. Great fun - like big fish swimming by. I've convinced myself, anyway - Newton's Laws of Motion at work (see Arnt's comments). Regards Vivian Hello Vivian, I guess I'd better try to find some helmet 3-views;) I tried your suggestion of accelerating a little before releasing and then braking but the bombs are definitely staying in the same place after release. The buoyancy setting doesn't seem to be working either. I was originally using a buoyancy setting of 31 so that the bombs would fall slowly, allowing me to judge the eda value I needed but even when I set buoyancy to 34, so that they should rise, they still stayed in the same place, neither moving backwards or forwards, or up or down. When I set the speed to 100 I noticed that the bombs were all aligned correctly but when I tried re-setting it back to 0 I could see the alignment changing
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott Sent: Saturday, September 18, 2004 3:03 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Saturday 18 September 2004 10:14, Vivian Meazza wrote: Lee Elliott wrote: Sent: Friday, September 17, 2004 9:57 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. Like the model: up to your usual standard. (Well, all except the pilot's bone dome - wrong pattern :-)) It works. The operative word is 'accelerate'. As you accelerate you leave bombs behind: they are instantiated with the velocity at the time of release, but since the aircraft is accelerating it will be left behind. Try the following using your original values in submodel: Release a bomb while stationary: it turns and aligns with the velocity - note although the aircraft is stationary, there are still some small N/E/D velocities. I'm not sure why. Accelerate down the runway: the bombs gradually align with the aircraft as forward motion is added, but they are left behind. Brake: the bombs shoot ahead of the aircraft, with their proper velocity. All those left behind now go past. Great fun - like big fish swimming by. I've convinced myself, anyway - Newton's Laws of Motion at work (see Arnt's comments). Regards Vivian Hello Vivian, I guess I'd better try to find some helmet 3-views;) I tried your suggestion of accelerating a little before releasing and then braking but the bombs are definitely staying in the same place after release. The buoyancy setting doesn't seem to be working either. I was originally using a buoyancy setting of 31 so that the bombs
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 15:44, Vivian Meazza wrote: [snip...] It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my todo list. You'll need the visor as well. Regards Vivian Thanks for looking into this - strange one though. Good to hear that it works properly on your system but that now means I have to find what's wrong with mine:) I'll take up your offer of a more accurate Bone dome too and use the one from the Hunter - Ta. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. You could try this: cd FlightGear/src cvs login cvs -z3 up -Pd cvs diff -puRN /tmp/diff cvs logout cat /tmp/diff Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... I'll look further into this... update cvs etc. Thanks for checking. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:06, Lee Elliott wrote: On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:28, Lee Elliott wrote: On Saturday 18 September 2004 23:06, Lee Elliott wrote: On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... It's just occurred to me that although my cvs is up to date, I haven't copied over the base package data for a couple of days - is there anything in there that could be causing this problem? I've got to go out now but I'll try copying over the latest data too, when I get back. LeeE It's just occurred to me that I'm using my local version, so it's possible that I haven't asked Erik to upload one of the multitude of files it requires to alter one parameter, or there's something wrong with the files I sent in. It's definitely OK here with your model. I'll check. There's nothing in the base package. BTW negative velocities don't work, otherwise drag would cause things to run backwards. If you want submodels to move to the rear apply a +ve speed with 180 yaw offset. Bone dome is easy - there's a Mk1A in the Hunter models. Feel free to use it. There's no under-helmet right now - on my to-do list. You'll need the visor as well. Lee Blown that theory. I've just downloaded and recompiled. The Red Beard does what it should. I've made it go up, down, forward, back Buoyancy (sp ?) etc. all work. Try Buoyancy = 32 and eda = 0 (eda = 1 is the non-op), and you'll see that the parent velocities are transferred to the submodel. I can't think of anything else to suggest. Regards Vivian Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE Hmm... (part 2) Just tried firing the Spitfire cannon via the property browser and while I could hear the cannon firing I couldn't see anything leaving the a/c. Could a library version mismatch cause this? There must be a problem at this end because it works for you on your system but I'm at a bit of a loss to explain it - the compilations of SimGear FlightGear seem to go fine. I haven't updated plib for a while - could the problem lie there? LeeE Just a thought - can anyone else confirm either behaviour? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Saturday 18 September 2004 23:40, Arnt Karlsen wrote: On Sat, 18 Sep 2004 13:21:13 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 9:47 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 16:09:12 +0100, Vivian wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequences like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse.. ;-) I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. ..precisely, we will need roll rate, yaw, yaw rate, pitch rate etc, I can do all of that, providing I can get at the location of the CofG to relate the offsets. but no accelerations except gravity, to get it right. Not strictly true. We also need to apply aerodynamic forces. Drag is already applied, and wind can be applied, but no other. Wind is that experienced by the parent, not the submodel. This approximation is OK for tracer, less so for bombs. ..eh, accellerations, no, forces, yes. Both bomber and bomb sees the same wind etc until release of child. In a bomb bay or in a gun, the wind exposure happens as these objects emerge outta these shielded hideouts. ..If either (plane or bomb etc) object passes thru say wind shear, wing tip vortices, then the wind forces are _different_, even if they can be approximated as the same as the bomb drops thru that vortice in a millisecond. ..and don't forget gun recoil forces. Gun childs also experience wind drift. ;-) ..also, when we get that far in the modelling; some dive bombers had release rigging that threw some, say centerline bombs, clear of the propeller, adding to the fun we dream up here. We can already do that - just apply an appropriate initial velocity, and instantiate at the right offsets. ..also keep in mind most bombs are hung by more than one points, so the hardpoint mechanism and the flight conditions, attitude, rates etc, act together deciding which points release first, second etc on each bomb. We can probably ignore that. ..true, but see below. ..this too, has a major impact on the initial ballistics, think bobbing bombs dropping from B-52's or B-17's, on dropping out of the bomb bay, some of this is sudden exposure to the airstream, some is un-even release, asymmetric or whatever. We could probably add some randomness to account for this, if you think it's a significant factor, given all the other approximations, chief amongst which could be that the submodel has no inertia, and so aligns instantly with its trajectory. Again, OK for tracer, but for bombs? ..this is a design philosophy decision; how close to reality _do_ we wanna go? My point is do as you like, but don't cut off future development by hardcoding stuff, leave open hooks as bait for future developers to go berserk on. ;-) The development philosophy behind FG seems, to me, to be: get something working, then refine it:) I'm still at the get-it-working stage:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Saturday, September 18, 2004 11:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Saturday 18 September 2004 19:05, Vivian Meazza wrote: I wrote Sent: Saturday, September 18, 2004 3:44 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model ... Snip ... Hmm... Just re-updated from cvs - no significant changes. Copied over all the latest data, did a make clean in both SimGear and FlightGear before re-compiling but still get no change. This is odd. If it wasn't for the fact that the same model works for you I'd suspect I'd got something wrong in the set-up. How do I fire the cannon in the Spitfire? I can't see a key-mapping anywhere. I suppose I could fire it via the property browser but that just makes me feel even more strongly that there's something wrong my end. LeeE The Spitfire uses a trigger on your joystick - something like: button n=1 descTrigger/desc binding commandproperty-assign/command property/systems/submodels/trigger/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command property/systems/submodels/trigger/property value type=boolfalse/value /binding /mod-up /button I would suggest that you use the property browser to test the Spitfire m/gs. If the cvs download was OK it is unlikely that there is something wrong with your system. Similarly, if the submodel aligns with the parent when taxi-ing at a reasonable speed, then, basically, it's working since it calculates the angles from speed N/E/D. Try these submodel settings: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda1.2/eda windfalse/wind buoyancy0/buoyancy /submodel And these: submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0/yaw-offset pitch-offset0.0/pitch-offset eda0/eda windfalse/wind buoyancy32/buoyancy /submodel And let me know what you see so that I can compare. Regards V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of course, they shouldn't inherit the plane's velocity exactly either unless they are at the cg of the plane or the plane isn't rotating. Theoretically, if you released a wing tip tank just at you gave a sharp roll input, you could toss it over the fuselage. You'd probably also tear your wings off and break your neck too, but you get the point. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Josh Babcock wrote: Sent: Friday, September 17, 2004 5:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model Vivian Meazza wrote: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Of course, they shouldn't inherit the plane's velocity exactly either unless they are at the cg of the plane or the plane isn't rotating. Theoretically, if you released a wing tip tank just at you gave a sharp roll input, you could toss it over the fuselage. You'd probably also tear your wings off and break your neck too, but you get the point. I would like to add the parent rotational velocities to the submodel for completeness. The math is a bit complex, but the main problem is that I can't find where the CofG is. I need to relate the offsets to the CofG, rather than the model origin. However, as a compromise, I might add roll velocity assuming it to be around the x axis, and ignore the other 2 axes ... I'm not sure if that is better than ignoring the problem altogether. Perhaps someone could tell me how to get at the CofG? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Friday 17 September 2004 16:09, Vivian Meazza wrote: Arnt Karlsen wrote: Sent: Friday, September 17, 2004 10:03 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On Fri, 17 Sep 2004 07:56:42 +0100, Vivian wrote in message [EMAIL PROTECTED]: Ampere K. Hardraade wrote Sent: Thursday, September 16, 2004 7:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Problem with ballistic sub-model On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level ..uh, in the real world, this is possible if not permissible, with fun consequenses like one or more hard points releases jammed for at least a while etc. They shouldn't inherit accelerations. Quite right - they shouldn't. I was getting over enthusiastic there, and forgetting my Newtonian physics. ..don't worry, there is also Murphy law physics. ;-) Right, back to Newton :-). I think I've solved the problem. Mixing elevation up = positive with speed down = positive nearly made my brain blow a fuse I had to reverse a number of signs to get it right. I took the opportunity to add roll to the submodel so that droptanks will come off with the right orientation. I not yet added either the parent rotational speed to the submodel, or yaw, so if you release droptanks with significant roll rate or yaw angle on the aircraft the submodel will not be quite right. Straight and level, or nearly so, is fine. I've asked Erik to upload the modified files to CVS. It looks OK on the Hunter, but perhaps Lee could give the revised submodel a good test. Regards Vivian Hello Vivian, I just updated from cvs, including updates to the sub-model stuff and while the pitch of the sub-model seems fixed ok, I'm still not able to get the speed right. I tried reducing the eda setting to a very low value (0.001) and then 0 but the velocity of the sub-model always seems to be zero. As an experiment I tried setting some +ve speed values i.e. 10 1000 but still got a zero sub-model speed - I tested this by 'releasing' the bomb (bearing in mind I have repeat and unlimited models set for de-bugging purposes) while sitting on the runway. Instead of a stream of sub-models moving forward away from the stationary a/c they remain at the origin. If I then accelerate the a/c I leave a trail of sub-models behind me. There's an archive of the a/c at http://www.overthetop.freeserve.co.uk/EE-Canberra-20040916.tar.gz ...if you want to have a look. The release keyboard mapping has been commented out in the ~set.xml file. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problem with ballistic sub-model
Vivian Meazza wrote: Sent: Thursday, September 16, 2004 8:33 AM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. I've checked and tested the submodel code. The submodel definitely inherits the parent velocities. Unfortunately, there's a basic snag: in order to get tracer to go in the right direction, I inserted a -ve rotation in pitch, but while making tracer correct, it applies an inverted pitch sense to droptanks/bombs. I don't understand why at this stage. Back to the drawing board! There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Thursday 16 September 2004 18:08, Vivian Meazza wrote: Vivian Meazza wrote: Sent: Thursday, September 16, 2004 8:33 AM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Problem with ballistic sub-model Lee Elliott wrote: Sent: Wednesday, September 15, 2004 10:16 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Problem with ballistic sub-model Hello all, I'm trying to use a ballistic sub-model to simulate a bomb but the parent a/c's speed and pitch etc. doesn't seem to be inherited i.e. the bomb appears to have no initial velocity and the pitch doesn't match that of the a/c. The sub-model.xml I'm using is below. Some of the settings are for de-bugging i.e. repeat, delay, count and buoyancy but I figure the important ones for a bomb would be speed and eda ?xml version=1.0? PropertyList submodel nameredbeard/name modelAircraft/EE-Canberra/Models/RedBeard.xml/model trigger/controls/armament/red-beard-released/trigger speed0.0/speed repeattrue/repeat delay1.0/delay count-1/count x-offset0.0/x-offset y-offset-0.0/y-offset z-offset0.0/z-offset yaw-offset0.0/yaw-offset pitch-offset0.0/pitch-offset eda0.0001/eda buoyancy30/buoyancy windfalse/wind /submodel /PropertyList LeeE I've been doing the same work for droptanks for the Hunter, with the same results. The ballistic submodel should inherit the parent velocities, and unless I've got a sign wrong somewhere (very possible), it does. On the other hand, the initial alignment of the submodel seems wrong. At the moment it aligns to the initial vector. This is a feature not a bug :-). The current module was designed for tracer and then extended to smoke, where it doesn't matter so much. I'll continue to investigate both issues today, but I can't promise instant results, as I think we may be hitting some fundamental design concepts rather than software bugs. I've checked and tested the submodel code. The submodel definitely inherits the parent velocities. Unfortunately, there's a basic snag: in order to get tracer to go in the right direction, I inserted a -ve rotation in pitch, but while making tracer correct, it applies an inverted pitch sense to droptanks/bombs. I don't understand why at this stage. Back to the drawing board! There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian Thanks for the updates Vivian. I have complete confidence that you'll get it working;) I'll comment out the bomb release key-mapping for now, do some documentation and get an archive-package sorted out. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
They shouldn't inherit accelerations. Ampere On September 16, 2004 01:08 pm, Vivian Meazza wrote: There are some other basic shortcomings as well: the submodel doesn't inherit the parent accelerations, or the velocities and accelerations due to roll, pitch and yaw. Only release droptanks when flying straight and level :-). Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
