Traffic Radar

Does anyone know how to "fix" the TrafficRadarXML.dll module provided by Arne? It's available from Avsim, called 'trafficradarxml201.zip'.

The download also has gauge examples and source code. I'm running Fs9.

I've managed to integrate it into Ken Mitchell's A320 panel MFD and it works and looks great 'til the dreaded "TICK18 time rollover" when it locks up. I've found the following info:

Up with a fresh newsPosted Image there is a small story: recently i was sitting on the apron after another Arne's TCAS gauge test flight. 1 hour "in-flight" has passed long away and suddenly i've decided to resize main panel. and voila! the TCAS gauge was working again!:Hug:So, i became well assured that this is time rollover as i mentioned previously. And where is the problem?ok, look at this part of Arne's code:

void MyGaugeCDrawable::Update(void){ lookup_var(&m_tick18); if(m_radar==NULL) return; if(m_owner==NULL) return; if(m_tick18.var_old.n+TICK_MODULO>m_tick18.var_value.n) return; m_recalced = true; m_radar->QueryAiData((int)m_maxnum_act,m_max_range_nm, m_owner->GetTimeSepTA(),m_owner->GetTimeSepRA(), m_owner->GetDistanceSepTA(),m_owner->GetDistanceSepRA(), m_owner->GetAltitudeSepTA(),m_owner->GetAltitudeSepRA() ); m_tick18.var_old = m_tick18.var_value;}]

=================================================

This is from XMLCCallbacks.cpp If you look precisely you will see (in line 8) that if m_tick18.var_value.n would oddly become zero again, the essential thing of Update call - m_radar->QueryAiData would never happen because m_tick18.var_old.n+TICK_MODULO - (1 time per second updating) would always be greater than that rollovered MS messAnyway, all you need is to add checking for m_tick18.var_value.n and reset the m_tick18.var_old.njust like this...

void MyGaugeCDrawable::Update(void){ lookup_var(&m_tick18); if(m_radar==NULL) return; if(m_owner==NULL) return; //additional checking against rollover :) if (m_tick18.var_value.nm_tick18.var_value.n) return; m_recalced = true; m_radar->QueryAiData((int)m_maxnum_act,m_max_range_nm, m_owner->GetTimeSepTA(),m_owner->GetTimeSepRA(), m_owner->GetDistanceSepTA(),m_owner->GetDistanceSepRA(), m_owner->GetAltitudeSepTA(),m_owner->GetAltitudeSepRA() ); m_tick18.var_old = m_tick18.var_value;}

==========================

But.. there was the other side of the coin . After panel resizing XML variable P:Absolute time rollovers also. Meaning that your favourite clock gauge will show you pretty nice zeros :(

===============================================

'dragonflightdesign', on 25 Sept 2010 - 12:47 PM, said:

You might want to remove the rollover checks completely. There was an undocumented update with FS2K2 when the original UINT16 time limit of 65535 was changed to a 32-bit integer; the rollover period now is in excess of 7.5 years. ACES forgot to update the SDK. ESP also still states 65535, IIRC.-Dai

So this means TICK18 has been an UINT32 since FS2K2? Wow, seems to be new to me. Then again, I don't do gauges more than every once in a while, haha. Posted Image Thanks for the "update" despite the dusty thread. :Party:RegardsEtienne

===============================================

I'm hoping someone can shed some light on this. Working with dll and C programing are way beyond my ken. Thanks.