I have Arne Bartels wonderfull TCAS gauge installed in the OpenSkyOS772V2KLM in a FS9 environment.It works fine but at irregular intervals the gauge "freezes" .I can't find what causes the freezing, neither the amount of traffic nor the number of polled aircrafts nor the range makes any difference.When the flight is saved after the freezing and reloaded afterward the gauge starts with a new AI environment and works fine for sometimes more than an hour.Has anybody expirienced the same and some clues to a solution.It happened also with the Trafficradar.Please helpSimon

You should use Eric Marciano's radar instead, it never freezes in any way and works for hours.

I have had exactly the same problemTas

To Moneymaker,The advance of the TAS600MHD is that it is easily adaptable to your own panel, other gauges are less or not at all programmable. If Arnes gauge does not freeze it is my preferred TCAS gauge.To Tas:What have you done about it? Taken an other gauge?greeting Simon

The same as you didI still use it as it is part of my freeware scenery packageReally annoying as it is quite easy to modifySteve

In observations that i did about Arne Bartels' XML TCAS gauge, it had never work without a freeze more than 60 + a half minutes(1hrs 30 sec) So, i thought it might be UINT16 overflowing somewhere? (60*60*18hz) but 1 time it stuck only after 52 minutes of flight:Thinking: what do FS code masters can spell about this trouble? can anyone confirm that he saw this gause running flawlessly (>>1 hr)?

Up with a fresh news 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.cppIf you look presizely 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.n<m_tick18.var_old.n)    	m_tick18.var_old	=	m_tick18.var_value;	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;}

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 :(

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

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. Thanks for the "update" despite the dusty thread. :Party:RegardsEtienne

Hi guysIs the only fix for this problem the re-write of the source code then? I was really exited when i downloaded this and saw it in action. I spent a full week adapting it into the Boeing 747 panel (and making it perfect)...It was only on my maiden voyage that i found this anoying problem.It's a brill gauge this and i wish it was a full worker. I mean fair enough, save the game, reload and it's fine, but it would be better if there was a (simple enough) fix for it...It's obviously gotta be the DLL because all other gauges that use it freeze aswell (the enhanced GPS and other radars).I does surprise me that no one threw an updated DLL on avsim...Something else must be going on i assume?