bcs112

Thx Pete, I'll figure it out ;) Björn

Hi Pete, Ah yes, haven't tried that yet ! Will give that a go also... can you also capture multiple keypresses that way (e.g. shift-Ctrl-Tab-A) ? Can you give some hints on how to set up this subclassing ? I understand it involves using CallWindowProc but I have no idea how to set this up... Björn

Hi Pete, I've been working for the past few weeks on setting up a system to capture keyboard commands to send them to my panel. I had created a system using SimConnect that works like this: if ( CheckInput(KB_INPUT_FD2)) { hr = SimConnect_MapClientEventToSimEvent(hSimConnect, EVENT_KEY_FD2); hr = SimConnect_AddClientEventToNotificationGroup(hSimConnect, INPUT_GROUP, EVENT_KEY_FD2); hr = SimConnect_MapInputEventToClientEvent(hSimConnect, INPUT_KEY_FD2, KB_INPUT_FD2, EVENT_KEY_FD2); hr = SimConnect_SetInputGroupState(hSimConnect, INPUT_KEY_FD2, SIMCONNECT_STATE_ON); hr = SimConnect_SetInputGroupPriority(hSimConnect, INPUT_KEY_FD2, SIMCONNECT_GROUP_PRIORITY_HIGHEST); } So first I check if there is a valid key combination set for the command (in this case pushing FD2 button) and then I do the (un)usual SimConnect mumbo jumbo to make sure SimConnect fires an event when the keys are pressed. case EVENT_KEY_FD2: // Do stuff break; First I noticed that if I added 5 keyboard commands, the last one in the list wouldn't work, when I added a sixth, the fifth would work again but the sixth wouldn't. So I added a dummy key command capture at the end. After adding some more commands, however even this approach wouldn't work anymore. I ended up with > 40 keyboard commands and the last 25 or so simply never get cought. And yes my "hr"'s always return S_OK. now there is off course the "old" system of capturing the keyboard in FSX using DirectInput so I started from scratch and tried to get that to work but there I have 2 issues: - DirectX always treats the keyboard as if in Querty format! - I noticed that (at least on my setup) DirectInput "hangs" and never forgets previous keyboard inputs. So press "A" and then "H" and after you release the button DirectInput will still return that A and H are pressed! I found one forum entry on the internet of someone complaining he has the same issue, but this was never resolved. The only way to fix this (at least as far as I found) is by stopping dinput each time a key is pressed and restarting the connection So what to do now ? Is the SimConnect keyboard system not meant to be used with more than a few keyboard commands and therefore inherently flawed or is there a trick that I missed ? Is DirectInput the way forward but what to do then with the hanging keys and even more importantly with the Qwerty format issue ? Hope you can help me out ! Björn

OK thx Pete, clears up many things... Björn

Hi Pete, I only recently noticed that you have added a LUA based add-on system for FSUIPC. At first sight this seems to have great potential... I'm not very familiar with LUA and before I get involved I have a few questions: - Do I understand correctly that for the user to be able to access any LUA add-on he/she needs to have a registered version of FSUIPC ? - If I was to include a (pre-compiled) LUA module with my add-on airplane, is there any way this module can be loaded automatically without intervention from the user, I tried calling one of the demo module "ipcInit.lua" but that wasn't the solution. - Are LUA applications (if you can call them "applications") running in a separate thread or inside the main FS thread ? In other words, would doing calculations like for instance for INS navigation give me better FPS ? - Can you confirm that through LUA I only have access to the FSUIPC interphase, no direct access to FS variables or customs XML variables? So if I want to communicate between a LUA add-on and my gauge in FSX (for instance my gauge has to let the module know if the HDG mode of the autopilot is engaged) I would need to use some of the unused offsets available in FSUIPC as a means of connecting both? Kind regards, Björn

Thx Pete, works like a charm...

Hi Pete, I installed FSUIPC 4.53, ran FSX => works fine, then I copied the latest update (4.533) dll over the 4.53 version but now FSUIPC is no longer loaded in FSX. Sorry for my ignorance but did I forget to do something ? Björn

Thanks a lot Pete for continuing to look at this ! I'll download the new built tonight and give it a try. I'll keep you posted. Björn

I included the FSUIPC_Process to show that I use standard technique... The last results of my tests showed that setting the offset can be made to work fine (well more or less) except for the "0" value. I ended up setting the byte 4 to "on" and the other bits to off as the only way to set all the bits to "0" quickly, after a few seconds bit 4 will then also go to "0", trying to set all the bits to 0 in one go simply doesn't work for me and always results in a delays. Björn

I found a solution which seems to work fine: When I set bit 2^3 alone the reaction is extremely slow (maximum recorded reaction time 42 seconds!) but when I set bit 3 together with any other bit e.g. 6 and 7, reaction is instantanuous. So now I set 3-6-7 to on and off when turning the A/T on/off. Strange ... Björn

Hi Pete, Yeah, I know it should be instantanuous, I tried it in FSInterogator but I can only write a value 1 time and that doesn't change anything in FSUIPC and from your documentation I understand the value needs to be rewritten frequently, hence me writing data to the offset every 0.5 second. Here's what I do, very standard I think ? BYTE joystick = 0; //Check if any of the A/T functions is ON if ( ( srs_pos || n1_on_exp || ga_exp || spd_pos ) && sim_pause == 0 && sim_slew == 0 ) { if ( ( AIRCRAFT_ON_GROUNDvar.var_value.n && throttle_both > 12000 ) || AIRCRAFT_ON_GROUNDvar.var_value.n == 0 ) { joystick += 8 ; } } FSUIPC_Write(JOYSTICK, 1, &joystick, &dwResult); FSUIPC_Process(&dwResult); I was wondering, I read approx 30 variables from FSUIPC every TICK (+/- 18x per second) + the TCAS array. To make sure I have enough memory reserved I declare a rather large BYTE FsuipcMem[5120]; In my open sequence to establish a connection with FSUIPC: FSUIPC_Open2(SIM_ANY, &dwResult, &FsuipcMem[0], 5120); FSUIPC_Write(0x8001, 32, ®, &dwResult); FSUIPC_Process(&dwResult); Could the size of the array be too big for FSUIPC to deal with ? Resulting in some strange behavior ? Is there a maximum size for the memory assignment ? Björn

Hi Pete, I'm pretty sure this is not something you have much control over but OK... I use Offset 310A to turn off joystick input axes to avoid the joystick interphering with my Autothrottle input. I set 310A to value 8 to turn off the joystick throttle axis (2^3) and I redo this approx every half a second or so. The problem is that it takes anywhere 2 and 20 seconds between the first time I write value 8 to offset 310A and the time the value actually changes. The same delay happens when I try to set the offset back from 8 to value 0. Is there anything I could do to speed up this process ? If it always happens within 2 seconds I would be happy but 20 seconds is a long time when you need your throttles back... Kind regards, Björn

I can't seem to find anything wrong in my code, but I found found code snippets that tells you the current window state of the FSX window. There are two procedures: WINDOWPLACEMENT wd; UINT nCurShow; HWND hWnd = FindWindow("FS98MAIN",NULL); if (GetWindowPlacement( hWnd, &wd )){ nCurShow = wd.showCmd; } Will return the current window state but can not differentiate between full screen and windowed modes. bool IsFullScreenMode(){ int w = GetSystemMetrics(SM_CXSCREEN); int h = GetSystemMetrics(SM_CYSCREEN); HWND hWnd = 0; while (hWnd = FindWindowEx(NULL, hWnd, NULL, NULL)) { if (GetWindowLong(hWnd, GWL_EXSTYLE) & WS_EX_TOPMOST) { RECT rcWindow; GetWindowRect(hWnd, &rcWindow); if ((w == (rcWindow.right - rcWindow.left)) && (h == (rcWindow.bottom - rcWindow.top))) return true; } } return false; } Returns wether FSX is in full screen versus windowed mode. I tried it and it works fine ! Björn

Hi Pete, Must be something I'm doing that's for sure... Here's some more things I found, probably not related but maybe they ring a bell with you... - When FSX starts and the panel is loaded In the FS "PANEL_SERVICE_PRE_UPDATE:" I check the connection: if (FSUIPC_CONNECTION != FSUIPC_ERR_OK){ FSUIPC_Open2(SIM_ANY, &dwResult, &FsuipcMem[0], 5120); FSUIPC_Write(0x8001, 32, ®, &dwResult); FSUIPC_Process(&dwResult); FSUIPC_CONNECTION = dwResult ; } With: DWORD FSUIPC_CONNECTION=FSUIPC_ERR_NOFS; DWORD dwResult; BYTE FsuipcMem[5120]; dwResult is "0" after the connection is established which is fine off course. - Every time the FSX window is resized or switches from Windowed to Full screen mode and back dwResult is set to "9" and I have to reconnect. Do you happen to see anything irregular ? Björn

Hi Pete, I checked again and indeed with my panel the counter goes up 1 when I switch from windowed to full screen mode the first time, but this doesn't happen when I use a default FSX aircraft. So the problem must somehow be related to my code. Although I have no idea how I could make this happen myself !!!! Kind regards, Björn