On 4/13/07, Vivian Meazza <[EMAIL PROTECTED]> wrote: > Csaba Halász > > > > > On 4/12/07, Vivian Meazza <[EMAIL PROTECTED]> 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. 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. > 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. 2) that I added tacan position -- I say this is modeling reality. Why is this bad? 3) the implementation of 2) -- I agree with you here, but wouldn't call it an "important respect". 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. Have I missed anything? Thanks for your time. Greets, Csaba ------------------------------------------------------------------------- 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
