[Lua] Select negative altitude by setting offset 0x07D4 not working

[Matthew Twomey]

I'm trying to set the autopilot altitude selector via lua by using ipc.writeUD(0x07D4, value). I can't seem to set it to a negative value, like I can with the knob in the cockpit. I've tried several approaches, writing to it as a signed number, generating the 2's compliment, ...etc. I must be missing something simple here?

Thanks,

-Matt

[Pete Dowson]

2 hours ago, Matthew Twomey said:

I'm trying to set the autopilot altitude selector via lua by using ipc.writeUD(0x07D4, value). I can't seem to set it to a negative value, like I can with the knob in the cockpit

 The "U" in "writeUD" stands for "Unsigned". For signed values you must use "ipc.writeSD" (guess what the S stands for) 😉

I don't actually know of any real aircraft on which you can instruct the A/P with a negative altitude and it may not be simulated in SimConnect.  I expect I'll be corrected on the former point by someone who knows of such real-world aircraft. What does offset 07D4 read when you manage to set a negative altitude using the mouse? (You can monitor it via FSUIPC's offset monitoring facilities, in Logging).

Of course, it is also possible that the coding in FSUIPC doesn't allow such values.

Pete

 

 

[Matthew Twomey]

So interestingly, 0x07D4 monitors as NAN when I set it to -100 using the aircraft dial:

1843968 Monitor IPC:07D4 (FLT32) = -nan
1843968 SimRead: 07D4="AUTOPILOT ALTITUDE LOCK VAR"
          FLT32: -30.4799995422

The SimRead does seem to reflect the correct value, however. If I try to set 0x07D4 to -30.4799995422 using ipc.writeFLT(0x07D4, -30.4799995422) - that sets the alt to the max value 99500.

[Matthew Twomey]

Something very strange going on with writing to this offset it seems. I can actually read the offset and immediately write it back and things get messed up. I also tried reading all 4 bytes individually, saving them, then turning around and writing them back - that also seems to cause issues.

The only case that seems to act as expected is writing positive values (as either signed or unsigned 32 byte values):

ipc.writeSD(0x07D4, 400 * 0.3048 * 65536);

That does set the altitude to 400. 

[Pete Dowson]

5 hours ago, Matthew Twomey said:

So interestingly, 0x07D4 monitors as NAN when I set it to -100 using the aircraft dial:

That's because it isn't a Float32. Why did you select that? To see the Signed DWORD value you'd use S32 (Signed 32-bit). Or, better, UIF32. Please see the description of the Types in the Advanced User manual (about page 15 or so, depending on edition). Search for the heading "Monitor facilities".

5 hours ago, Matthew Twomey said:

If I try to set 0x07D4 to -30.4799995422 using ipc.writeFLT(0x07D4, -30.4799995422) - that sets the alt to the max value 99500.

Because it isn't a FLT!!!!  I already pointed out to you that it's an SD! Have you forgotten already? Please do read the descriptions of offsets before misusing them!

It's metres*65536, so to write -100 metres you'd write -6553600. For feet write (-100 / 3.28084) * 65536. But as SD.

Pete

 

[Matthew Twomey]

I may have shown you the wrong screenshot, but I've have been debugging this for hours and have tried all manner of monitoring, tracing, and debugging via lua script. It is still probably the case that there is something I am missing - however, I've tried what you've suggested and it appears you can not set a negative value this way.

Monitoring the decrement to -100 shows this:

5239984 14272 Monitor IPC:07D4 (S32) = -1997536
5239984 14272 SimRead: 07D4="AUTOPILOT ALTITUDE LOCK VAR"
FLT32: -30.4799995422

Writing negative values to this address doesn't work.

ipc.writeSD(0x07D4, -6553600); --doesn't work
ipc.writeSD(0x07D4, (-100 / 3.28084) * 65536); --doesn't work

I may be still be missing something - but it doesn't appear to function as writable at least as described in the documentation. Any other ideas on how this can be done?

[Pete Dowson]

11 hours ago, Matthew Twomey said:

I may be still be missing something - but it doesn't appear to function as writable at least as described in the documentation. Any other ideas on how this can be done?

If the SimConnect facility to write a negative value to the Sim Var doesn't allow it then I don't think anything FSUIPC can do will fix it/

If this is something you really believe is needed then you should put the request to MS / Asobo on Zendesk.

BTW could you explain, please, when you'd actually want to use a negative altitude for the autopilot? I know some parts of the world are below sea level, but you wouldn't use the A/P at low altitudes in any case, except maybe in landing (APPR) mode,, in which case the descent is via a glideslope in any case, not a target altitude.

Pete

 

 

[Matthew Twomey]

Yes, I'm connecting a rotary encoder to that autopilot altitude select dial. I have custom acceleration setup for it, which makes it feel much more natural than assigning it directly in FSUIPIC - so I'm driving it via a lua script. It works great, until I spin it down below zero, then I run into this problem.

Can you clarify why FSUIPC log monitoring reports this value the way that it does? Why does it print out a FLT32 value?

5239984 14272 Monitor IPC:07D4 (S32) = -1997536
5239984 14272 SimRead: 07D4="AUTOPILOT ALTITUDE LOCK VAR"
FLT32: -30.4799995422

Quote

If the SimConnect facility to write a negative value to the Sim Var doesn't allow it...

I don't really have much evidence that it doesn't allow it at this point, honestly it seems more likely to be an issue with FSUIPC. Or maybe a case where some other flag is getting set somewhere when it goes negative and FSUIPC isn't aware of it.

[Pete Dowson]

17 minutes ago, Matthew Twomey said:

. It works great, until I spin it down below zero

I think you missed my question, which wasn't about HOW, but WHY?

4 hours ago, Pete Dowson said:

could you explain, please, when you'd actually want to use a negative altitude for the autopilot? I know some parts of the world are below sea level, but you wouldn't use the A/P at low altitudes in any case, except maybe in landing (APPR) mode,, in which case the descent is via a glideslope in any case, not a target altitude.

Anyway. onwards:

18 minutes ago, Matthew Twomey said:

Can you clarify why FSUIPC log monitoring reports this value the way that it does? Why does it print out a FLT32 value?

Because that's what it receives from SimConnect. I think it writes a FLT32 also. BUT the offset is defined as a Signed Dword (SD or S32). Most offsets are designed to match what FSUIPC has always provided, since FS98. In those days the offsets were actual values in an FS module, not mapped after reading them through an interface.

FSUIPC has striven to maintain compatibility across all versions of FS since FS98. New facilities and data are added, but the original ones are continued as far as possible, so applications can continue to work with changing flight simulator versions. That was always its main purpose.

If you want to write an application specifically dedicated on one flight Simulator then you probably should use it's provided interface (SimConnect in MSFS) directly.

Pete

 

 

[Matthew Twomey]

7 minutes ago, Pete Dowson said:

think you missed my question, which wasn't about HOW, but WHY?

Why? Because I want my physical rotary knob to behave like the rotary knob in the simulated cockpit!? I'm trying to simulate that control - and that control in the cockpit spins clockwise and counter-clockwise. When you spin it counter-clockwise past zero, it continues to a negative value. When I spin my physical control, which writes to that offset, it breaks as soon as it would go negative. If I wanted a control that didn't work like the one in the cockpit this wouldn't be a problem - but I'm trying to create a physical control that acts like the control that the simulation is presenting me in the cockpit.

[Pete Dowson]

39 minutes ago, Matthew Twomey said:

Because I want my physical rotary knob to behave like the rotary knob in the simulated cockpit!? I'm trying to simulate that control - and that control in the cockpit spins clockwise and counter-clockwise. When you spin it counter-clockwise past zero, it continues to a negative value. When I spin my physical control, which writes to that offset, it breaks as soon as it would go negative. If I wanted a control that didn't work like the one in the cockpit this wouldn't be a problem - but I'm trying to create a physical control that acts like the control that the simulation is presenting me in the cockpit.

But my point is: when would you ever turn it to a negative value, assuming you could? 

To stop the control "breaking" just program it to stop at zero -- i.e just keep at zero.

Or ask MS/Asobo to change SimConnect to let you set negative values.

It would be good, too to find out if you really can set negative values in the real aircraft. Have you done' any such checking? I'm sure you can't with any Boeing or Airbus airliners, nor in the Cessna I took my flying lessons in.

Pete

 

[Matthew Twomey]

Ok. I'll take a look. I've been flying the c208 with a g1000 and it does it in the sim, but I'll have to defer to other as to if it also does this in real life.

I've found a suitable workaround to this issue for now (posted here in case anyone stumbled across this thread and would like to do something similar):

	currentAlt = ipc.readSD(Offsets.AutoPilotAltitudeValue) / 65536 * 3.28084;
	ipc.control(66124, currentAlt + amount * 100);

Although you can't write negative values, you can send them via the control. So this method will read the value from the offset, modify it, then send a modified value via the control + parameter. (code is inside one of my modules, so ignore the variable references).