AXIS PAN HEADING control in LUA script

[aua668]

Pete,

 

In my multi-monitor setup I use three seperate camera windows for the outside views (left, fwd, right; 45 degrees FOV each). In a LUA script I am able to set the heading of each view with the AXIS PAN HEADING control.

 

For looking 45 degrees to the right I use ipc.control(66504,-4096) etc.

 

I have a switch triggering a LUA script, which is shifting the view angle in all three outside views by 45 degrees to the left or right. By that I could look out for landing traffic for example as I am limited to the 135 degrees with my three monitors.

 

But If I want to switch back to the forward position (angle=0 degrees) this doesn't switch the view back. I have to use ipc.control(66504,1) instead.

 

But 0 as the parameter doesn't seem to change the axis value. Would it be possible, that you check this in your code ?

 

I use FSX+Accelleration under Windows 7 and use FSUIPC 4.911

 

Best regards

Reinhard

 

 

[Pete Dowson]

But If I want to switch back to the forward position (angle=0 degrees) this doesn't switch the view back. I have to use ipc.control(66504,1) instead.

But 0 as the parameter doesn't seem to change the axis value. Would it be possible, that you check this in your code ?

 

There's realy no code to check. It doesn't touch the control number or the parameter, it just sends them on to FS.

 

Not sure why you need a Lua script for this. I've just tested it using direct assignment in FSUIPC's "Keys" tab (would be the same in the Buttons tab). I assigned V to "Axis Pan Heading" with parameter 4096, and Shift+V to the same with Parameter 0. Testing it, V changed the view to 45 degrees left and Shift+V returned it to directly forward.

 

If you log Axis controls (see logging tab) you can check what is actually being sent. Here's a section of my log doing the above (I'm also logging buttons and keys here):

 

   170306 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=0

   170306 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= 4096 (0x00001000) AXIS_PAN_HEADING

   170322 FS Control Sent: Ctrl=66504, Param=4096

   170322 .. This key is programmed in FSUIPC4 'Keys' options

   170509 KEYUP: VK=86, Waiting=0   176671 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1

   176671 .. Key not programmed -- passed on to FS

...

   177576 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1

   177576 .. Key not programmed -- passed on to FS

   177592 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=1

   177592 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING

   177592 FS Control Sent: Ctrl=66504, Param=0

   177592 .. This key is programmed in FSUIPC4 'Keys' options

   177685 KEYUP: VK=86, Waiting=0

   178044 KEYUP: VK=16, Waiting=0

That worked fine. If the control with parameter 0 is being sent and your aircraft isn't responding then I can only think it's an add-on which for some odd reason is trappping and preventing a Pan of 0.

 

Pete

[aua668]

Pete,

 

I will test with the direct assignment via a key tro check, if this works on my system too. Thanks for investigating in this topic. I need this out of a LUA script, as this is part of my cockpit setup procedure. I run a multi-monitor setup (3 screens for the outside view and 2 touch screens for the panel). With this setup I have implemented several aircraft types (F100, A32x, C172, ...). With the LUA scripts I arrange depending on the aircraft type all the panels and I initialize the outside views accordingly.

 

I tested this (as always) with the default FSX C172 to avoid influences from third-party aircrafts. So this is not the reason here. I did the same what you did with the keys in my LUA script. I changed the axis value to 4096 and tried to change it back to 0. But with 0 I had no success in my setup. So maybe passing the parameter 0 via the LUA ipc.control call is different to non-zero values.

 

I can live with 1 too, as this 0.01 degress, which makes no difference in the outside view. I will try the logging for my LUA as you did it for the keys. Thanks for pointing me in this direction.

 

Best regards

Reinhard

[Pete Dowson]

I will test with the direct assignment via a key tro check, if this works on my system too. Thanks for investigating in this topic. I need this out of a LUA script

I tested this (as always) with the default FSX C172 to avoid influences from third-party aircrafts. So this is not the reason here. I did the same what you did with the keys in my LUA script. I changed the axis value to 4096 and tried to change it back to 0. But with 0 I had no success in my setup. So maybe passing the parameter 0 via the LUA ipc.control call is different to non-zero values.

 

Well the Lua function calls exactly the same routine in FSUIPC so it s guaranteed to do the same thing. Here is a log using two Lua plug-ins, one only containing:

 

ipc.control(66504,-4096)

 

and assigned to keypress 'V', and the other only containing

 

ipc.control(66504,0)

 

and assigned to Shift+V. Here is the log of them being used:

 

   846087 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=0

   846087 .. This key is programmed in FSUIPC4 'Keys' options

   846087 LUA.0: beginning "E:\FSX\Modules\atest.lua"

   846149 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= -4096 (0xfffff000) AXIS_PAN_HEADING

   846149 FS Control Sent: Ctrl=66504, Param=-4096

   846149 LUA.0: ended "E:\FSX\Modules\atest.lua"

   846259 KEYUP: VK=86, Waiting=0

   848318 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1

   848318 .. Key not programmed -- passed on to FS

   848505 KEYDOWN: VK=86, Waiting=0, Repeat=N, Shifts=1

   848505 .. This key is programmed in FSUIPC4 'Keys' options

   848505 LUA.0: beginning "E:\FSX\Modules\atest0.lua"

   848536 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING

   848536 FS Control Sent: Ctrl=66504, Param=0

   848536 LUA.0: ended "E:\FSX\Modules\atest0.lua"

 

As you can see, it is sent to FS exactly the same. There can't in fact be any difference!

 

How are you measuring this value '1' in any case if you aren't logging?

 

Pete

[aua668]

Hi,

 

I did the test with the following script:

ipc.control(66504,4096)
ipc.sleep(2000)
ipc.control(66504,0)
ipc.sleep(2000)
ipc.control(66504,-4096)
ipc.sleep(2000)
ipc.control(66504,0)

It produced the correct logging:

  1035924 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= 4096 (0x00001000) AXIS_PAN_HEADING
  1037937 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING
  1039949 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= -4096 (0xfffff000) AXIS_PAN_HEADING
  1041961 ***  AXIS: Cntrl= 66504 (0x000103c8), Param= 0 (0x00000000) AXIS_PAN_HEADING

And it produced the correct result on the screen. In my code I change the camera too before setting the view angle by using ipc.control(66851) as I also switch between outside view and cockpit view. And if the camera has to be changed, then the view is not always changing although it's logged correctly. 

 

So the conclusion: It's obviously a timing problem. The changing of the camera takes longer and therefore the setting of the view angle comes too early before the view is ready.

 

Thanks for helping to analyze this strange behaviour.

Reinhard

 

[Pete Dowson]

So the conclusion: It's obviously a timing problem. The changing of the camera takes longer and therefore the setting of the view angle comes too early before the view is ready.

 

But surely you didn't want the view 45 degrees either side to be instantaneously cancelled to a view forward in any case? Why would you have two different view settings close together on one Lua plug-in in any case? I thought you'd be selecting a view and holding it whilst actually using your eyes on it. Else what's the point?

 

I certainly don't understand "the setting of the view angle comes too early before the view is ready". that makes no sense to me. Sorry.

 

You still haven't explained how you measured the originally reported 1/360th discrepancy in the view. Did you have some sort of massive micrometer scale in the scenery ahead of you?

 

Regards

Pete

[aua668]

Pete,
 
To answer your question about "measurement": That was pure calculation: 1 = 1*180/16384 degrees = 0.01 degrees. No measurement.

 
To explain my script more in detail (not the test script above but the one I use for setup of my views). I have three screens for the outside views. By default I set the left screen to 47 degrees left (47 is for bezel correction). Middle screen to 0 and right screen to 47 degrees to the right.

With the mode selector switch on my Saitek yoke I can shift all three camera views by 45 degress to the left or the right. And with another switch I can set left screen to Tower view, middle screen to outside plane view and right screen to map view. By that I can orient if I got lost during taxi.

So for switching between these view modes I have to set the camera and the view angle for each screen.

But in the meanwhile I did more testing with logging and I found the real reason:

The ipc.control for an AXIS doesn't produce an additional event in the logging, if you call it with the same parameter you used at the last call. So calling:

ipc.control(66504,-4096)
ipc.control(66504,-4096)
ipc.control(66504,-4096)

produces only one AXIS event in the log. And that was my problem, if I switched to the left forward view and then back to forward view again. Why? It's simple. For  left Forward I called the control with the following parameters:

Screen 1:  ipc.control(66504,8556)
Screen 3:  ipc.control(66504,0)
Screen 2:  ipc.control(66504,4278)

I call screen 3 as the last screen, so that the forward screen has the focus at the end of my setting. Just for optical reasons because of the white pixel border of the active view.

But when I switch back to forward view again, I have the following values:

Screen 1:  ipc.control(66504,4278)
Screen 3:  ipc.control(66504,-4278)
Screen 2:  ipc.control(66504,0)

And as the first call of the control in this second sequence is the same as the last call in the first sequence (4278), this contol produces NO event - although it is directed to a different view.

 

So the lesson learned: If you send AXIS commands to different views/cameras and you have the same parameter, then the control fires no event. By using a parameter 1 before setting it to the desired value, I had success, as then the AXIS event was triggered.

 

Thanks again for pointing me to logging. Didn't think on it. I just had added some ipc.log calls in my scripts to check, if I call the right functions, before posting here. But as the called sequence was correct, I went the wrong direction during my analysis. But by logging the events the root cause is now found.

 

Rgds

Reinhard

 

[Pete Dowson]

To answer your question about "measurement": That was pure calculation: 1 = 1*180/16384 degrees = 0.01 degrees. No measurement.

 

No, you missed the question yet again! How did you measure the 1 in the first place, when the logging clearly shows 0 being sent? What told you the actual view was 1?

 

...

So for switching between these view modes I have to set the camera and the view angle for each screen.

 

 

Yes, but that also answers no questions. Why would you want to switch to a view and back again so fast, afraction of a second, that the timing, as you called it, would come into it?

 

The ipc.control for an AXIS doesn't produce an additional event in the logging

 

Yes, of course. FS only reacts to changes in an axis value. Else it would spend most of its time sending itself controls for every connect axis for no reason at all! But that doesn't matter, because you don't care about an axis not changing. It only means anything when it changes.

 

And as the first call of the control in this second sequence is the same as the last call in the first sequence (4278), this contol produces NO event - although it is directed to a different view.

 

Aha, finally the last section of your explanation does clarify some things. But still not the forward view of 1. Where does that come into any of this and, again, how did you measure it?

 

Regards

Pete

[aua668]

Hi,

 

I think, you didn't understand correctly, what I did and I didn't completely understand, what was ongoing. And obviously I also didn't describe it good enough  :???:

 

There was no "measurement of 1". First the screen not responding was showhing a 45 degrees view. When I want to set it back to 0 it didn't work, because the last control sent (to a different view) was also 0. By that the event in this view didn't fire. With 1 it switched back to forward view. So a pure "optical measurement". No logging at tht time. And the only thing I wanted to express is, that 0 or 1 makes no visual difference looking forward.

 

Where I went wrong was, that I didn't realize, that calling this control in other views before with the same parameter 0 inhibts the event in the actual window. So the non-working zero was just a result of the sequence by which I set the views. It could have been with any other number too.

 

So if you have to set the same view angles in seperate views by that contrrol (or even more realistic: if you want to set pitch and tilt by the respective controls), then this won't work, if you don't do a little trick. You have to set the parameter first to a different value and then to the final value to be sure, that the axis in that view is set correctly. This only applies, if you use multiple views. In a single view environment this makes no sense.

ipc.control(66504,pAngle+1)  -- dummy call to be sure, that the next value is set
ipc.control(66504,pAngle)    -- this sets the angle to the actual value

Another misunderstanding: I don't switch to a view and back again fast. I switch to look 45 degrees to the left and later I switch back to normal view. That's all. Don't know, how you got the impression, that I am doing this so fast. It was only the sequence of the control calls, which produced the strange results. And as I then manually sent first a 0 (with no reaction) and then a 1 setting the view to forward again I thought in the wrong direction. And the timing problem was another wrong direction ... my fault. Trial and error. That's how mankind evolved :???:

 

And the main reason for all these problems: I didn't know, that sending a control doesn't always produce an event. I expected, that every single call of the ipc.control really triggers that event. In the case of the AXIS control this obviously isn't the case for the reasons you mentioned. I have not been aware of this.

 

Hope this explains all ...

I have a stable and working solution now.

 

Reinhard

[Pete Dowson]

There was no "measurement of 1". First the screen not responding was showhing a 45 degrees view. When I want to set it back to 0 it didn't work, because the last control sent (to a different view) was also 0. By that the event in this view didn't fire. With 1 it switched back to forward view. So a pure "optical measurement". No logging at tht time. And the only thing I wanted to express is, that 0 or 1 makes no visual difference looking forward.

 

Ah, sorry. Yes, after going back to the very first message in the thread I see I got confused on the way!

 

You have to set the parameter first to a different value and then to the final value to be sure, that the axis in that view is set correctly.

 

Yes. I would probably have suggested this early on had I not confused myself!

 

Anyway, as long as all is well now ...

 

Regards

Pete