Csaba Halász > > > On 4/12/07, Vivian Meazza wrote: > > > > > > > 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? > > Umm, actually that is what I have done. Just in a more > generic way, such as possibly accounting for lateral > displacement and non-level orientation of the carrier. > Admittedly does not amount to much in case of the tacan, but > seems to be more logical this way. Looks like just for me. > > > > > 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. > > Right. Next step would be to send tacan channel over MP as > well and then this temporary workaround would vanish. In the > meantime I thought it wouldn't matter as I assumed pretty > much everybody uses the default config anyway. But changing > my version to support this is easy as all the pieces are in > place. Carriers come from scenarios now - no need for their > tacan to be in the carrier-nav.dat, might as well add them to > the scenario (which essentially models the headquarters) If > in the future they come from MP, the carrier-nav.dat is again > not needed. Also note that "runtime" includes whenever a new > pilot joins, similar to passing the call sign. Everybody else > should see the tacan of *my* aircraft as *my* ground crew > (the command line) set it - not as it is mapped in *their* > carrier-nav.dat. > > > > > 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. > > Umm, I think you missed something here. I did not move those > offsets anywhere. I just added a generic convenience function > that reads a generic offset value. I have only moved the > parsing code, the value is still stored wherever it was up to now.
Exactly my point: AIBase only reads generic values. Offsets are not generic values, and their reading should remain where they are at present. If another AI Object comes up with a requirement, then that is a different matter. > Your point would be valid about the whole tacan equipment not > belonging in AIBase, but I allowed for that in my original > mail by saying maybe there should be a separate FGAIBaseWithTacan. Ugh - the whole point of AIBase is that it supplies generics for the rest of AI Objects - FGAIBaseWithTacan!!! > > 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. > > That's why I asked for it *not* to be committed, and that's > why it says RFC in the subject. If nobody helps or nobody > likes it then that's that. > > > Well, you haven't convinced me that this is a valid change, > in fact I > > think it flawed in several important respects. > > Maybe I don't understand your points, so let me summarize > what I gathered: You don't like: > > 1) hardcoded tacan channel for MOBILx -- this is I think an > acceptable temporary solution. But it can be changed to read > the mapping from a file. Just not the global carrier-nav.dat > because this information should be local. You completely miss the point - there is no way that MOBIL* TACAN channel needs to be, or should be, hardcoded. MOBIL* is NOT involved in TACAN. carrier_nav.dat provides an easy-to-change way of assigning TACAN channels to any mobile unit, and is consistent with the way fixed TACAN frequencies/channels are assigned. Is_Tanker should be passed over MP: that would circumvent the tie-up between the callsign and tanker capabilities. Although I have a sneaking desire to leave it as is - that way everyone on MP knows that MOBIL* is a tanker, and that has its advantages. It is right that TACAN assignments should be global - that's the way it is in RL - they are not made up locally. Of course it's not really hard to change the settings if you get the urge. > 2) that I added tacan position -- I say this is modelling > reality. Why is this bad? It isn't bad, just not needed right now. > 3) the implementation of 2) -- I agree with you here, but > wouldn't call it an "important respect". Good > 4) the FLOLS/ParkPos issue -- that is just a code cleanup > without any change in functionality whatsoever. Maybe I > should have split that into a separate patch. Yes - this is Mathias' business, I really can't comment, except to say that I would be surprised if there were anything much wrong with his code, and certainly not his mathematics. > > Have I missed anything? > Yup - if it ain't broke don't fix it. Now back to something which is totally broken - AIBallistic and Submodels. That is a complete mess here with _apparently_ hundreds of ballistic objects not being removed when their life expires which causes FG to slow to a crawl. I just love fixing things which used to work. And it looks as if I won't get around to it until next week at the earliest, and it might not be until the week after. Vivian 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
