3110 and FS commands

[Capt_Geoff]

OK, the Luamenu test works as advertised! :D

AFA the restart of FS is concerned - Could it be because I am modifying my gauge and I am doing this:

start FS

check my gauge functionality

load a different aircraft

modify my gauge code/recompile

reload the original aircraft

and during the reloading of the aircraft something gets hosed up in fs? The lua test works fine after reloads, the 3110 code does not and I am executing the code (I've got print statement verifying that I'm actually in the code). Note that I load a different airframe because the compiler complains that it can't write the gauge file as FS9 has it "locked".

[Pete Dowson]

OK, the Luamenu test works as advertised! :D

Good. So that proves the sequence of 1070 controls is working, and so it should certainly also work in your program.

AFA the restart of FS is concerned - Could it be because I am modifying my gauge and I am doing this:

start FS

check my gauge functionality

load a different aircraft

modify my gauge code/recompile

reload the original aircraft

You are connecting to FSUIPC from a Gauge? I thought you were using an external program still!

Are you using the module user library for this, with FSUIPC_Open2(...) instead of FSUIPC_Open(...)? If you are still using the external interface with an internal program, like a Gauge, then, yes, it explains a lot. It is a big no-no. the normal external interface for FSUIPC is based on shared memory for inter-process communication. When you are completely in-process the shared memory is shared by every client, so gets trampled on.

Also, please make sure that you only Open the FSUIPC link once when the gauge is loaded, and is Closed when it is unloaded. Do not keep opening and closing it, and do not forget to close.

Regards

Pete

[Pete Dowson]

162922 FSUIPC Control Action: Ctrl=1070, Param=13

162922 SendKeyToFS(0000000D=[Rtn], KEYDOWN) ctr=0

I hadn't noticed before: you are sending a Return as well as Alt+A, A, P. Try adding a Return code to the Lua program too, i.e. use this:

ipc.writeStruct(0x3110,"2UD", 1070, 0x1041,
		0x3110,"2UD", 1070, 0x41,
		0x3110,"2UD", 1070, 0x50,
		0x3110,"2UD", 1070, 13)

(assuming you moved on to FSUIPC version 3.852).

Here this does actually work (which surprised me!). It selects a Piper Cub and returns to flight mode.

Log the working sequence with the Lua program, and then log the same with your Gauge. Comparing them might show what differences there are that could cause your problem

Regards

Pete

[Capt_Geoff]

Hi Pete - I'll answer first, as I just got back - and then implement the Open2.... which obviously I had not changed - I'm still using FSUIPC_Open(). Maybe that's the problem.

Yeah, I'm still working on the old stand-alone version of my software, though I jumped to a gauge, oh, about 2 weeks ago. I made *really* good progress, and so I'm not doing any more work on the old program. I hadn't realized that I needed a new Open...

For the parachute what we did was take a parachute we have used and changed the manufacturer to "p" (I think it was "parafoil" but I'm not sure). While you can't select a particular aircraft - your can get the first aircraft of a manufacturer, so by using "p" it is guaranteed to be the first "p" manufacturer. It's a trick one of our pilots found using the keyboard. And yeah, I added the 13 or 0x0D.

Sorry about the confusion wrt to gauge and external program.

And yes the gauge is opened first. Before the eject button can be used the switch which makes a connection to my server must be set ON - which also guarantees the gauge is fully loaded. So that works out very well. And I only close it when the user disconnects from my server. This also is required because my server saves the state of the player's aircraft for when he/she restarts Underway!.

Now onto the Open2....

[Capt_Geoff]

Hi Pete - OK, I am now using the ModuleUser.c with the FSUIPC_Open2() function.

Here are the snippets of the log - I put a couple of blank lines in to distinguish between the first part which is code generated and the second which is a joystick button initiated set of keypresses. The Lua works perfectly. the code/3110 still refuses to work. I put a set of stars around the 173000 area where there seems to be extra keypresses? taking place. But I also note that the Lua sequence doesn't actually load the aircraft until the joystick button is registered as having been released. At least that's what I make of the log file - in the for what it's worth department. Oh, and yes, I am using the fsuipc you made for me .852

   172641 FSUIPC Control Action: Ctrl=1070, Param=4161
   172641 SendKeyToFS(00010041=[alt+A], KEYDOWN) ctr=0 
   172641 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2
   172688 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1
   172719 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1
   172766 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1
   172766 FSUIPC Control Action: Ctrl=1070, Param=65
   172766 SendKeyToFS(00000041=[A], KEYDOWN) ctr=0 
   172797 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1
   172844 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1
   172844 FSUIPC Control Action: Ctrl=1070, Param=80
   172844 SendKeyToFS(00000050=[P], KEYDOWN) ctr=0 
   172891 Sending WM_KEYDOWN, Key=80 (Scan code 25), Ctr=1
   172922 Sending WM_KEYUP, Key=80 (Scan code 25), Ctr=1
   172922 FSUIPC Control Action: Ctrl=1070, Param=13
   172922 SendKeyToFS(0000000D=[Rtn], KEYDOWN) ctr=0 
   172969 Sending WM_KEYDOWN, Key=13 (Scan code 28), Ctr=1
   173000 Sending WM_KEYUP, Key=13 (Scan code 28), Ctr=1
   173000 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4
   173000 .. Key not programmed -- passed on to FS
  ***********************************************************************
These next 173000 keys seem to be extra??? which the Lua does not generate
   173000 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=4
   173000 .. Key not programmed -- passed on to FS
   173000 KEYUP: VK=65, Waiting=0
   173000 KEYDOWN: VK=80, Waiting=0, Repeat=N, Shifts=0
   173000 .. Key not programmed -- passed on to FS
   173000 KEYUP: VK=80, Waiting=0
   173000 KEYDOWN: VK=13, Waiting=0, Repeat=N, Shifts=0
   173000 .. Key not programmed -- passed on to FS
   173000 KEYUP: VK=13, Waiting=0
****************************************************************************************

   178438 Button changed: bRef=0, Joy=1, Btn=10, Pressed
   178438 [Buttons] 1=P1,10,CL1:R,0
   178438 LUA: beginning "E:\Program Files\Microsoft Games\Flight Simulator 9\MODULES\testmenu.lua"
   178454 FSUIPC Control Action: Ctrl=1070, Param=4161
   178454 SendKeyToFS(00010041=[alt+A], KEYDOWN) ctr=0 
   178454 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2
   178454 LUA: ended "E:\Program Files\Microsoft Games\Flight Simulator 9\MODULES\testmenu.lua"
   178485 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1
   178532 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1
   178579 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1
   178579 FSUIPC Control Action: Ctrl=1070, Param=65
   178579 SendKeyToFS(00000041=[A], KEYDOWN) ctr=0 
   178610 Sending WM_KEYDOWN, Key=65 (Scan code 30), Ctr=1
   178657 Sending WM_KEYUP, Key=65 (Scan code 30), Ctr=1
   178657 FSUIPC Control Action: Ctrl=1070, Param=80
   178657 SendKeyToFS(00000050=[P], KEYDOWN) ctr=0 
   178688 Sending WM_KEYDOWN, Key=80 (Scan code 25), Ctr=1
   178735 Sending WM_KEYUP, Key=80 (Scan code 25), Ctr=1
   178735 FSUIPC Control Action: Ctrl=1070, Param=13
   178735 SendKeyToFS(0000000D=[Rtn], KEYDOWN) ctr=0 
   178782 Sending WM_KEYDOWN, Key=13 (Scan code 28), Ctr=1
   178813 Sending WM_KEYUP, Key=13 (Scan code 28), Ctr=1
   178813 Button changed: bRef=0, Joy=1, Btn=10, Released
   178813 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4
   178813 .. Key not programmed -- passed on to FS
   178813 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=4
   178813 .. Key not programmed -- passed on to FS
   182829 AIRCRAFT\ParaFoil\ParaFoil.air
   182922 Aircraft="ParaFoil"
   184063 KEYUP: VK=13, Waiting=0

[Pete Dowson]

Yeah, I'm still working on the old stand-alone version of my software, though I jumped to a gauge, oh, about 2 weeks ago. I made *really* good progress, and so I'm not doing any more work on the old program. I hadn't realized that I needed a new Open...

Not JUST changing the Open call -- you link with the module users library, not the normal FSUIPC library. It does things completely differently internally. And in the Open2 call YOU provide the static memory to be used for the data transfers.

Pete

[Pete Dowson]

Here are the snippets of the log - I put a couple of blank lines in to distinguish between the first part which is code generated and the second which is a joystick button initiated set of keypresses. The Lua works perfectly. the code/3110 still refuses to work. I put a set of stars around the 173000 area where there seems to be extra keypresses? taking place.

I think they are just the logs of the keypresses arriving -- i.e. the actual KEYDOWN and KEYUP messages. They seem to be incomplete, which may explain things, possibly.

I'd like to be able to compare the Lua program results with yours, side-by-side, so I can see all the timing and order differences, to try to understand it. That's what i meant when I asked. If you can do two logs, one with Lua and one with your gauge then I could compare them line for line.

There is an alternative, of course. if your Gauge is reasonably free-standing you could send it to me for testing here. i can trace through what is happening in FSUIPC then. petedowson@btconnect.com. Zip stuff, please.

Regards

Pete

[Capt_Geoff]

I need to make sure I understand something :

Do I need to link in the ModuleUser.lib?

I've never done this in my three years of programming with FSUIPC. I do however, have ModuleUser.c (well, actually it was IPCUser.c until just today) included as source code. I took ModuleUser.c out and put in the .lib - and my compiler (VC++ studio express 2008 version 9) is complaining about libc.lib which is not available to this version - although I tried to use libcmt.lib (which is recommended) but then the compiler complains "MSVCRT.lib(MSVCR90.dll) : error LNK2005: _atoi already defined in libcmt.lib(atox.obj)" I do not link to MSVCR90.dll, so I believe that may be in the ModuleUser.lib. I think the ModuleUser.lib is not compatible with my compiler - and maybe there in lies problem? I will send you the output of the two runs without ModuleUser.lib but with ModuleUser.c . They sure look darn near the same to me.

Btw thanks for your help on this vexing problem.

[Pete Dowson]

Do I need to link in the ModuleUser.lib? I've never done this in my three years of programming with FSUIPC.

Well, of course you wouldn't for an external program. You'd use FSUIPC_User.lib instead. That's if you are a C/C++ user, of course. Other languages have other methods.

I do however, have ModuleUser.c (well, actually it was IPCUser.c until just today) included as source code.

That's fine. That's an alternative to binding in the same code as a static library -- the lib files are simply pre-compiled versions of the same source code you are using. You'd normally use the source code instead if you needed to make any changes, or get deeper into things for any reason. The lib files are merely provided as a convenience.

I took ModuleUser.c out and put in the .lib - and my compiler (VC++ studio express 2008 version 9) is complaining ...

Right. Of course that's another excellent reason for using the source instead, or even making your own Lib from the source provided, one which matches your compiler.

Regards

Pete

[Capt_Geoff]

Whew! good. I'll put the source back in then. I'll get you the gauge as soon as I can.

EDIT; On it's way. Get to it when you can - I'm moving on in the development process to other gauges I need to build...

[Pete Dowson]

Whew! good. I'll put the source back in then. I'll get you the gauge as soon as I can.

EDIT; On it's way. Get to it when you can - I'm moving on in the development process to other gauges I need to build...

Okay, i've done all the testing I can here.

I don't know why it isn't working from your gauge. It works, as you know, from that Lua program, and it works also with a button programmed like this:

1=P1,1,K65,24

2=P1,1,K65,8

3=P1,1,K80,8

4=P1,1,K13,8

The Lua program is doing EXACTLY the same as your gauge, except that it terminates as soon as it is done (and it runs in a different thread to FS in any case). A button programmed as above isn't using offset 3110 or control 1070, but it is merely sending keystrokes direct.

The sequence from your program logs EXACTLY the same, almost to the millisecond, as the Lua program. The whole sequence is dealt with in 281 or 282 milliseconds in both cases, every time. Where they differ is in the ARRIVAL back in the FS window procedure of the sequence of WM_KEYDOWN and WM_KEYUP messages. And that is outside of my control. They've all been sent within the 300 milliseconds. They all arrive differently in the two cases.

I suspect this must have something to do with what your Gauge is doing immediately after sending the sequence. Does it then exit and wait for then next normal Gauge wake up call, or whatever? (Sorry, I know next to nothing about writing gauges). I think it may need to. If you are continuing to keep control of the main FS thread after the sequence is sent, you are not allowing FS to process its messages correctly and this messes the timing of the ARRIVAL (and therefore interpretation0 of these keyboard messages. FSUIPC cannot give control back during the processing of your request, of course, as this is within a windows message already (from the SendMessage in the interface code). It has to exit, back to your code.

In the case of the Lua program, it is terminating (and it uses a different thread in any case). In the case of the button programmed to send keystrokes, FSUIPC goes directly back into dormant mode waiting for new requests immediately afterwards. So, in both cases, FS's message processing proceeds normally directly after.

If, looking at your gauge, you cannot solve this by rearranging things, then I suspect the only answer will be to program a virtual button to do as above, or else use a Macro or a Lua plugin like the one we've tested. However, if these are activated from your Gauge I suspect the same problem may arise if it then keeps control.

Note that, if all this is merely in order to load a different aircraft, a possible alternative method which might be worth investigating is renaming aircraft files somehow and using the "Reload User Aircraft" control -- assuming the details aren't being cached by FS, of course.

Regards

Pete

[Capt_Geoff]

Wow! Interesting. The only thing that occurs after the message is a debug statement. I'll try taking that out, but I seriously doubt that is causing a problem. After that, it's pure FS magic. Actually the eject routine is probably one of the smallest callbacks I have....

EDIT: Nope no change. Oh well, button or keypress it is then.

Edit 2: mmm I wonder about that "runs in a separate thread" statement...

[Pete Dowson]

Edit 2: mmm I wonder about that "runs in a separate thread" statement...

But I tend to think that's not really relevant. The logs show the sequence is identical up to the point where it finished executing the final 1070 control. The thread running the Lua program is dead and gone by then. All of the "SendInput" actions to FS are done in the main FS thread.

And the keypress encoding for the button isn't from a separate thread.

I really don't understand why there's a difference, and, unfortunately it is impossible to trace it or even log it more finely without changing it (a touch of Heisenberg's Uncertainty Principle)! I did try some small timing changes, mostly to the speed at which the SendInput calls are made, and doing this I could get all three ways acting the same -- but they all simply then obeyed the ALT+A (displaying the Menu (yes, even yours)), but lost all further keys -- or possibly stored them and released them to FS after. That is actually what i expected to happen in any case, but now I know that the multiple keysends and the Lua action works so well, I put the code back so that those complete sequences still work okay.

Regards

Pete

[Capt_Geoff]

Well, I guess we both learned something then from all this work. I really do thank you for all the effort you've put into this. At least we can have a joystick ejection button and maybe a joystick rubber raft deployment button. I tend to agree with you about the timing as I can see no difference at my end either. But we sure have beat a dead horse eh? :shock: :roll: :wink:

If I ever get over to Jolly 'ol England I'll buy you a beer or two. Same if you make it over to this side of the pond.