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.0000001) 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, as you said it would. I expected though, that if I used a +ve <speed> value, the bombs should move forward away from the a/c if they're released while the plane's stationary but they don't. I'm just not seeing what you describe, and what I'd expect (I agree with you on Newton;) re the bombs catching up and overtaking the a/c when the brakes are put on. 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 _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
