Csaba Halász > > On 4/12/07, Vivian Meazza <[EMAIL PROTECTED]> wrote: > > > > Doesn't make any sense to me - what bug are you trying to fix? > > None, it is already fixed. This is just a follow-up. > > > Why do you want to offset a TACAN position? > > You know why: because on the carriers the tacan altitude is > 100 feet. And that *is* fixed, no matter where the carrier > happens to be. It should be fixed relative to the carrier. So > as to hide this detail I have introduced the TACAN position > which gets calculated from the model position and an offset vector.
Well - if a carrier ever moves from sea level we can take the elevation add the carrier altitude. Is anything more needed? > > Why on earth are you hard coding TACAN idents? > > Why limit the MP to only one tanker ident? > > It is actually a limit of 9, MOBIL1-9. I could have used a > *local* configuration file (or property) there, but this is > just a temporary solution - I expect tacan information to > come through MP protocol. Then this code will just disappear > without affecting anything else. And please note that the > isTanker flag *is* set from this hardcoded "MOBIL" callsign > as well. I don't think my solution is that much worse. At > least it is well localized. Yes - I know - wrote it. And I think that you might have misinterpreted the code here. The flag isTanker is set if any MP object has a callsign starting with MOBIL - it can be followed by anything. But just because it has the callsign MOBIL* doesn't imply that it fitted with TACAN - that is determined by the callsign/TACAN ID assignment in carrier_nav.dat. Any callsign can be associated with any TACAN ID - MOBIL is just a bit of a pun. Not all tankers have TACAN transmitters - the Sea Vixen in the Buddy-Buddy role is one such example. The inverse is, I think, true: I know of no airborne TACAN transmitter which isn't a tanker, but I'm a bit out of date here, and this might have changed. Of course, the association of the callsign MOBIL* with a tanker is a hack - the property isTanker ought to be passed over MP. But when this was written no properties were passed, and adding them to the MP servers is not trivial. > And these changes make it possible to provide tacan > parameters from MP. Like changing channels, disabling > transmitter and such. All at runtime. That is a desirable > goal is it not? My solution might not be the best way to do > it, though. Switching on/off is indeed desirable, but not changing channels at runtime. Channels are assigned by headquarters for a mission and not changed in flight. In my day, this was only done by the ground crew, but it might well be possible in flight nowadays. Passing the appropriate property value over MP should suffice, if we had a controllable TACAN transmitter in the aircraft, which right now we don't. > > What is wrong with the existing FLOLS and Parking Position Code? > > Nothing, that was just a code cleanup. Refactored duplicated > code that reads a x-offset-m, y-offset-m and z-offset-m > triplet into a corrected SGVec3d. It now lives in > FGAIBase::readOffsetFromScenario() because I happened to need > that too. Surely that is not a bad thing? It is indeed a bad thing - only properties that are common to more than one AI Object live in AIBase. The FLOLS and ParkPos offsets are peculiar to AICarriers, and so it is right that they should live there. > > If you "don't know how to properly add a body-relative > vector to the > > lat,lon,alt coordinates" don't muck with Mathias' code - he > does know. > > I pointed out what I don't know so that somebody who does can > help me out (and it does not slip in unnoticed). In the > meantime that code works for the 2 cases currently in use. > (My guess is that I would need to convert to cartesian, > rotate by the yaw,pitch,roll add the offset and convert > back.) Do you think I should have done nothing because I am > not sure about that little detail? Well, I think it's better if patches don't have built in problems - the trouble is no one is likely to pick up on little details for you. > Personally I also disliked the old TACAN::search from a > coding point of view. Lots of code duplication, variable > names like str1,str2, ... str6 etc. Fair comment. It grew out of the old dme code, and I would have probably done it differently with a clean sheet of paper approach > I won't mind if this does not get into cvs. I am having much > fun with FG - both flying and coding. So I thought why not > try something other than bug fixes (even though this started > out as that as well). Well, you haven't convinced me that this is a valid change, in fact I think it flawed in several important respects. Sorry, especially if you have spent any great time on this. But thank you very much indeed for finding and correcting the original bug. Hmm - no one noticed for 6 months! Oh well ... particularly as it had been fixed once. > Hope Mathias doesn't mind that I "mucked with his code". > Looks like JSB is next :) I sure he will note any possible improvements to the code and incorporate them if he thinks that appropriate. Vivian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
