Altering Offset datatype possible?

[PhilippK87]

Greetings, we ended up in a situation where FSUIPC and another program are required to communicate, now our specific issue is that the offset that we're using, namely the Cowlflaps (37F0) need to report back their status to that other program.

I know from your documentation and through FSInterrogate that the very offset I'm dealing with is a double float value jumping betweeen 0.0 and 1.0.

So far so good.

"That other program" however only accepts integers, and I'm stuck there.

Is there some, I dare say, rather easy approach to change the output of FSUIPC so that it provides proper Integers?

Im by no means a programmer , I have a wee bit of technical knowledge, seeing that I prefer Linux at home, but as for programming...I guess I have to confess that I'm just more into "arts" than techsavy work.

If there's more info required on what I am actually trying to do et cetera, let me know, thanks in advance, Phil.

[Pete Dowson]

"That other program" however only accepts integers, and I'm stuck there.

Is there some, I dare say, rather easy approach to change the output of FSUIPC so that it provides proper Integers?

Not anything built in. The only thing I can suggest is you have a little Lua plug-in which reads the offset, converts it into a form you like, and puts it into another offset -- one of the user-free ones from 66C0 to 66FF. Something like this, for example:

local function convertCowl(offset, cowl)
    mycowl = cowl * 16384
    ipc.writeUW(0x66C0, mycowl)
end

event.offset(0x37C0, "DBL", "convertCowl")

or alternatively (I'm not sure which method will turn out to be more efficient):

while true do
    cowl = ipc.readDBL(0x37C0)
    mycowl = cowl * 16384
    ipc.writeUW(0x66C0, mycowl)
    ipc.sleep(100) -- limit to 10 updates per second (change number of millisecs to suit use)
end

The first one is more amenable to further additions, other events, should you need them, but its operation isn't so obvious to non-programmers.

Save one of these as "ipcReady.lua" in the Modules folder and it will load up when FS is ready to fly, and operate from then on. You can read the converted cowl flap value as a 16-bit unsigned value, from 0 to 16384, in offset 0x66C0.

Note that I've not tested them, so please confirm.

Regards

Pete

[PhilippK87]

Hi again, now back from lunchbreak (sorry) and I just tried the first method.

Please note that "tried" means I wanted to read the outcome thru FSInterrogate, if for whatever reason FSI is not able to read that ".lua" output let me know and I'll try and read it through the actual "second" program.

I take it

event.offset (0x37C0, ...

has been a typo and you actually wanted me to use

0x37F0

?

Unfortunately both ways turned out to not show any changes in 66C0 - at least according to FSI.

Will try your second suggestion now and report back.

EDIT:

The latter didn't seem to work either, but then that's just me, fiddling around with no deeper insight on what I may have been missing.

I'd actually go as far as to say "ok, your suggestions probably work JUST FINE", I'd just need an idiot safe hand guiding me.

Maybe there's some additional ...conditions,..something along those lines..that need to be sorted out before trying one of your suggestions and you took them for something that "goes without saying?"

PS: Sry for the grammatical, structural weirdness, ..no native speaker ((

[Pete Dowson]

Please note that "tried" means I wanted to read the outcome thru FSInterrogate, if for whatever reason FSI is not able to read that ".lua" output let me know and I'll try and read it through the actual "second" program.

I tend to use the built-in FSUIPC "monitor" facilities to check these things -- it is so much easier, and it shows optionally in real time on screen and in the log, for proof and proper checking.

has been a typo and you actually wanted me to use 0x37F0

Ah, yes, sorry. i read the message and replied from (bad) memory.

Unfortunately both ways turned out to not show any changes in 66C0 - at least according to FSI.

Well, the first was certainly my error. Sorry. The FSUIPC log would have shown you that the Lua code was wrong:

• 64953 LUA: beginning "D:\FSX\Modules\ipcReady.lua"
  64953 *** LUA Error: D:\FSX\Modules\ipcReady.lua:6: Event proc not found
  64953 LUA: ended "D:\FSX\Modules\ipcReady.lua"
  

The problem is the "local" before "function". Please delete that word -- I typed it semi-automatically because I've been using local functions a lot recently. You need any function called from an Event to be "global", else FSUIPC can't see it. Omit "local" and it becomes global.

I've now tested that one here, with the 37C0 corrected to 37F0, and "local" removed, and it works fine.

The latter didn't seem to work either, but then that's just me

Well, with the 37C0 changed to 37F0 that worked fine, straight-off, here. Here's the FSUIPC4 log file with it running and the Baron left cowl flap being changed, using Monitoring of 37F0 as FLT64 and 66C0 as U16:

   125281 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1"
            FLT64: 0.078
   125344 Monitor IPC:37F0 (FLT64) = 0.07800000
   125391 Monitor IPC:66C0 (U16) = 1278
   127766 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1"
            FLT64: 0.156
   127828 Monitor IPC:37F0 (FLT64) = 0.15600000
   127828 Monitor IPC:66C0 (U16) = 2556
   128234 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1"
            FLT64: 0.468
   128281 Monitor IPC:37F0 (FLT64) = 0.46800000
   128281 Monitor IPC:66C0 (U16) = 7668
   128641 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1"
            FLT64: 0.78
   128687 Monitor IPC:37F0 (FLT64) = 0.78000000
   128750 Monitor IPC:66C0 (U16) = 12780

Maybe you should (a) make sure you are using the latest FSUIPC version (3.90 or 4.50, or 3.906 or 4.506 from the Updates above), and (b) enable the monitoring and check the log.

I haven't checked this in FS9 yet -- you didn't mention which versions you were using -- but the Lua code is the same, so it should be okay. Let me know if you need me to test that too.

Regards

Pete

[PhilippK87]

Thanks for the detailed response, will give it another try tomorrow and report back,

again, thanks for your commitment!!

EDIT:

Everything's perfect with....provided that dumb folks like me use

AN UP-TO-DATE .DLL

:oops:

"solved"

[PhilippK87]

And hi once again,

I take it there's no way of doing this the other way around?

Meaning in my specific case I'd be delighted to be able to controll "37F0 (FLT64)" manually?

[Pete Dowson]

I take it there's no way of doing this the other way around?

Meaning in my specific case I'd be delighted to be able to controll "37F0 (FLT64)" manually?

Manually? What does that mean in this context?

There are FSUIPC Offset controls for Setting or Incrementing both 32- and 64-bit floating point values. Why not use those? They take parameters in 1/1000th's so you can get the fractional parts that many floating point values need -- such as this one, from 0 to 1.

Regards

Pete

[PhilippK87]

Thanks so far, what it seems to do is it DOES write changes to our offset, but seems to disregard our parameter (1638 as in 10% of "Integer"), it does alter it yes, but jumps wildly with no appearent control from our site.

[Pete Dowson]

Thanks so far, what it seems to do is it DOES write changes to our offset, but seems to disregard our parameter (1638 as in 10% of "Integer"), it does alter it yes, but jumps wildly with no appearent control from our site.

You are writing it as a what? 16-bit value? if so all you are doing is writing to the lowest two bytes of the 8-byte double floating point value. I've no idea what that will do, it's a waste of time. If you wanted to do something really approximate you could write to the two 2 bytes, at the offset + 6, but you'd need to work out the correct exponent and mantissa values and put those in the appropriate bit positions.

You could of course use a Lua program again -- to read a 16-bit value from one offset and write it as a double float to another. Haven't you tried that? It wouldn't be that much different from the program i showed you earlier.

while true do
    cowl = ipc.readUW(0x66C0)
    mycowl = cowl / 16384
    ipc.writeDBL(0x37C0, mycowl)
    ipc.sleep(100) -- limit to 10 updates per second (change number of millisecs to suit use)
end

Though really you should only do this when 0x66C0 is changed, so use an event (event.offset) to call a function, instead of having a loop like this.

Regards

Pete

[PhilippK87]

Thanks sir, approved and working.