Re: [Flightgear-devel] [RFC] tacan rewrite

[Vivian M. <viv...@li...>]

Csaba Hal=E1sz

> > > 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=20
> > > feet. And that *is* fixed, no matter where the carrier happens to=20
> > > be. It should be fixed relative to the carrier. So as to=20
> hide this=20
> > > detail I have introduced the TACAN position which gets calculated=20
> > > from the model position and an offset vector.
> >
> > Well - if a carrier ever moves from sea level we can take the=20
> > elevation add the carrier altitude. Is anything more needed?
>=20
> Umm, actually that is what I have done. Just in a more=20
> generic way, such as possibly accounting for lateral=20
> displacement and non-level orientation of the carrier.=20
> Admittedly does not amount to much in case of the tacan, but=20
> seems to be more logical this way. Looks like just for me.
>=20
> > > > 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=20
> is just a=20
> > > temporary solution - I expect tacan information to come=20
> through MP=20
> > > protocol. Then this code will just disappear without affecting=20
> > > anything else. And please note that the isTanker flag=20
> *is* set from=20
> > > this hardcoded "MOBIL" callsign as well. I don't think my=20
> solution=20
> > > is that much worse. At least it is well localized.
> >
> > Yes - I know - wrote it. And I think that you might have=20
> > misinterpreted the code here. The flag isTanker is set if any MP=20
> > object has a callsign starting with MOBIL - it can be followed by=20
> > anything. But just because it has the callsign MOBIL* doesn't imply=20
> > that it fitted with TACAN - that is determined by the=20
> callsign/TACAN=20
> > ID assignment in carrier_nav.dat. Any callsign can be=20
> associated with=20
> > any TACAN ID - MOBIL is just a bit of a pun. Not all tankers have=20
> > TACAN transmitters - the Sea Vixen in the Buddy-Buddy role=20
> is one such=20
> > example. The inverse is, I think, true: I know of no airborne TACAN=20
> > transmitter which isn't a tanker, but I'm a bit out of date=20
> here, and=20
> > this might have changed. Of course, the association of the callsign=20
> > MOBIL* with a tanker is a hack - the property isTanker ought to be=20
> > passed over MP. But when this was written no properties=20
> were passed,=20
> > and adding them to the MP servers is not trivial.
> >
> > > And these changes make it possible to provide tacan=20
> parameters from=20
> > > MP. Like changing channels, disabling transmitter and=20
> such. All at=20
> > > runtime. That is a desirable goal is it not? My solution=20
> might not=20
> > > be the best way to do it, though.
> >
> > Switching on/off is indeed desirable, but not changing channels at=20
> > runtime. Channels are assigned by headquarters for a=20
> mission and not=20
> > changed in flight. In my day, this was only done by the=20
> ground crew,=20
> > but it might well be possible in flight nowadays. Passing the=20
> > appropriate property value over MP should suffice, if we had a=20
> > controllable TACAN transmitter in the aircraft, which right now we=20
> > don't.
>=20
> Right. Next step would be to send tacan channel over MP as=20
> well and then this temporary workaround would vanish. In the=20
> meantime I thought it wouldn't matter as I assumed pretty=20
> much everybody uses the default config anyway. But changing=20
> my version to support this is easy as all the pieces are in=20
> place. Carriers come from scenarios now - no need for their=20
> tacan to be in the carrier-nav.dat, might as well add them to=20
> the scenario (which essentially models the headquarters) If=20
> in the future they come from MP, the carrier-nav.dat is again=20
> not needed. Also note that "runtime" includes whenever a new=20
> pilot joins, similar to passing the call sign. Everybody else=20
> should see the tacan of *my* aircraft as *my* ground crew=20
> (the command line) set it - not as it is mapped in *their*=20
> carrier-nav.dat.
>=20
> > > > What is wrong with the existing FLOLS and Parking Position Code?
> > >
> > > Nothing, that was just a code cleanup. Refactored duplicated code=20
> > > that reads a x-offset-m, y-offset-m and z-offset-m triplet into a=20
> > > corrected SGVec3d. It now lives in
> > > FGAIBase::readOffsetFromScenario() because I happened to=20
> need that=20
> > > too. Surely that is not a bad thing?
> >
> > It is indeed a bad thing - only properties that are common to more=20
> > than one AI Object live in AIBase. The FLOLS and ParkPos=20
> offsets are=20
> > peculiar to AICarriers, and so it is right that they should live=20
> > there.
>=20
> Umm, I think you missed something here. I did not move those=20
> offsets anywhere. I just added a generic convenience function=20
> that reads a generic offset value. I have only moved the=20
> 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=20
> belonging in AIBase, but I allowed for that in my original=20
> 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!!!
=20
> > Well, I think it's better if patches don't have built in problems -=20
> > the trouble is no one is likely to pick up on little=20
> details for you.
>=20
> That's why I asked for it *not* to be committed, and that's=20
> why it says RFC in the subject. If nobody helps or nobody=20
> likes it then that's that.
>=20
> > Well, you haven't convinced me that this is a valid change,=20
> in fact I=20
> > think it flawed in several important respects.
>=20
> Maybe I don't understand your points, so let me summarize=20
> what I gathered: You don't like:
>=20
> 1) hardcoded tacan channel for MOBILx -- this is I think an=20
> acceptable temporary solution. But it can be changed to read=20
> the mapping from a file. Just not the global carrier-nav.dat=20
> 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.=20

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=20
> 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=20
> wouldn't call it an "important respect".

Good
=20
> 4) the FLOLS/ParkPos issue -- that is just a code cleanup=20
> without any change in functionality whatsoever. Maybe I=20
> 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.
=20
>=20
> Have I missed anything?
>=20

Yup - if it ain't broke don't fix it.=20

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=20