On Friday, November 23, 2012 15:56:01 James Turner wrote:
Hi James,
> Suggestion: make a runtime switch, to build the 'new' nav-radio when the
> old one is asked for - this can be done via some logic in the instrument
> manager. This of course assumes the visible interface, i.e read / written
> properties, for the new code matches the old, possibly by adding some
> backwards compatibility properties.
>
> (Switch would be a bool prop like /sim/radios/use-new-radios)
Obviously, I should have explained myself this issue: actually the change to
the navradio.cxx and newnavradio.cxx codebase is very small, only adding a
function to set some properties which are then dealt with by the radio
subsystem. I looks somewhat like this:
if( fgGetBool( "/sim/radio/use-radio", false ) ) {
signal_quality_norm = computeSignalQuality(is_loc);
}
where I'm just using a new and rather simple function to get the signal
quality. The rest of the complicated stuff is happening inside the radio
subsystem. This can be enabled at start with --prop:/sim/radio/use-radio
as long with a set of other properties which are all explained detailed in
README.radio inside the minidocs.
>
> If there's a problem making the new code fit the old property API, then you
> have a bigger issue, but updating all the aircraft XML seems ridiculous -
> the current code exposes some slightly strange properties, but emulating
> them in the new code should not be a problem. So, make it a drop-in
> replacement, and make the drop-in automatic via an option. For the current
> release, we'll leave the default as the old code, and after the release is
> out, flip the default to be the new code, for testing by Git users.
>
> Comments?
Of course, no change whatsoever is needed. The classic navradio code as well
as newnavradio already determine the signal strength by some other means, I'm
just using more realistic calculations, that's all. No aircraft XML or
anything else to be updated, just a start-up switch and some other switches
which turn on detailed simulation of antennas, ground clutter attenuation and
other stuff. I took care to write a small guide for the minidocs.
The strange properties you noticed are just internals from the radio
subsystem, and can be used by someone who wants to do radio specific analysis.
If you want to take a look at the code, I'll upload a new branch to my
gitorious clone tonight.
Cheers,
Adrian
>
> James
>
> ---------------------------------------------------------------------------
> --- Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
