Possibility for a new offset?

[spokes2112]

Hi Pete,
 
Hope all is well with you.
 
Just updated to 4.949p from "c" to get the latest docs to search but not found. What i'm looking for & hoping you can provide is a read offset to show the state (on / off) of control C66724 - "Toggle Airport Names". This is for a flight validation program.

According to the SDK this command is shared cockpit available so hopefully a variable is floating around? Just did a quick test while writing this and confirmed FSX starts up with names defaulted off so maybe a "flip/flop" can be had by monitoring the control?

 

If names = on then

C66724

end

 

Thanks in advanced,

Roman

[Pete Dowson]

Just updated to 4.949p from "c" to get the latest docs to search but not found. What i'm looking for & hoping you can provide is a read offset to show the state (on / off) of control C66724 - "Toggle Airport Names". This is for a flight validation program.

According to the SDK this command is shared cockpit available so hopefully a variable is floating around? Just did a quick test while writing this and confirmed FSX starts up with names defaulted off so maybe a "flip/flop" can be had by monitoring the control?

 

I can't see anything even vaguely related to such a setting exposed by SimConnect, so I wouldn't know how to find it. I'm well past my hacking days I'm afraid, the techniques I used for FSX and before, and now I have to relay on what SimConnect provides.

 

Let me know if you can find any way to detect it, and I'll implement it.

 

Pete

[spokes2112]

Hi Pete,

 

 Instead of using the "state" would a control "listener", similar to lua's event.control, work in your .dll? We need the returns at an offset since the programmer is using C# w/ Paul Henty's client .dll and using lua on the end-users machine is not feasible.

 

Something like, using lua as an example (added 1 more needed control) -

function TogBit(controlnum, param)
   if controlnum == 0x104A4 then
      ipc.togglebitsUB("assigned byte", 0x1)		
   elseif controlnum == 0x103D0 then
      ipc.togglebitsUB("assigned byte", 0x2) 		
   end	
end

event.control(0x104A4, "TogBit")
event.control(0x103D0, "TogBit") 

If this will work and you are willing, there will be no huge hurry in implementing into your next release. If done, could you provide the assigned offset via PM? (Secretive)

 

P.S. It looks like you and Ray had an excellent time at Brooklands Museum!  :mrgreen: with envy..  lol !

 

Thanks in advanced,

Roman 

[Pete Dowson]

 Instead of using the "state" would a control "listener"

 

But what would the flag in an offset actually mean?  You won't know if it was on or off to start with, and loading flights and so on, or using the menus, could change it without any control being detected.

 

Sorry, but I really don't see the point at the moment.

 

Pete

[spokes2112]

With airport names it is defaulted off when FS starts, it's state does not get saved in a flight file or the sim config.

 

For both, when the program starts logging a flight we would get the state of the bits/byte in FSUIPC, then store them for a comparison. As the flight goes on, continue to query the FSUIPC offset bits/byte to see if they changed compared to our saved bits/byte. If changed, a warning will be logged. Our saved bits/byte would then be updated to the new state providing additional comparison queries throughout the logged flight. 

 

The program is a validation / cheat logger, an output example is here - http://fs-duenna.com/flights/logs/VGLnbVak2KrmIBdnIPHC4KLS9M.txt

 

Thanks,

 

Roman    

[Pete Dowson]

With airport names it is defaulted off when FS starts, it's state does not get saved in a flight file or the sim config.

 

For both, when the program starts logging a flight we would get the state of the bits/byte in FSUIPC, then store them for a comparison. As the flight goes on, continue to query the FSUIPC offset bits/byte to see if they changed compared to our saved bits/byte. If changed, a warning will be logged. Our saved bits/byte would then be updated to the new state providing additional comparison queries throughout the logged flight. 

 

The program is a validation / cheat logger, an output example is here - http://fs-duenna.com/flights/logs/VGLnbVak2KrmIBdnIPHC4KLS9M.txt

 

I see. And this is just for Reload user aircraft and Toggle airport name display? For the former isn't the counter changing at offset 32FC sufficient? That changes when that control is used as well as when a different AIR file is loaded. (There's also a count at 3F02 for flight loading).

 

Pete

[spokes2112]

Pete,

 

 

 

 And this is just for Reload user aircraft and Toggle airport name display?

 

Yes. Nothing else really jumps out as being needed. (  a waste of 6 bits :-(  )

 

 Just checked (FSUIPC Logging) & the 32FC increment doesn't work on my side (4.949p) when using the reload user aircraft control (C66512) with the same .air file & aircraft name. We are checking for aircraft.cfg changes while in flight and being logged which need an aircraft reload to take effect.

 

No need for flight loading (3F02) as our logging cannot start until ready for flight, if the flight fails for any reason it must be restarted and re-logged. 

 

Roman 

[Pete Dowson]

 Just checked (FSUIPC Logging) & the 32FC increment doesn't work on my side (4.949p) when using the reload user aircraft control (C66512) 

 

Aha! It's a little bug. Fixed now. Sorry. That must be a VERY long-standing one. Evidently no one has tried to use it for that in the past, or has but failed to report it.

 

For "Toggle airport name display" I'd rather have a count as well. It'll be the one byte at 305D, incrementing 0-255 and back. If you only want to test one bit use the 2^0 bit, but I think you are safer checking a change in the value -- otherwise with bit toggling you can miss two successive uses of the control made quicker than your monitoring (I can double tap a button or key pretty fast for those two controls -- a way of cheating with single bit detection?)...

 

That, and the fix to 32FA for Reload user aircraft will be in the ext released version, hopefully by the end of this week.

 

Pete

[spokes2112]

Pete, 

 

Sounds great! Will keep an eye out for the next release.

Thank You Very Much!

 

Roman

[spokes2112]

Hi Pete,

 

4.945 tested out just fine... Thank You!

 

Roman

[Pete Dowson]

4.945 tested out just fine... Thank You!

 

Typo? The current release is 4.95.

 

Pete

[spokes2112]

Yes a typo.

OOOPS! Not enough coffee yet. UTC-5  :oops:

 

Roman