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

Hi Pete, Very strange indeed ! I will do some more tests later today, my results are confirmed everytime I test, so ghere must be something else going on ! Björn

Hi Pete, I've been using offset 3F02 for a while for loading flight data settings in FSX, and it works fine: the counter increases each time a flight is loaded.... but the counter also increases the first FSX switches from windowed mode to full screen mode, giving very undesireable results off course. Is there any way to differentiate FSX actually loading a flight vs a change in window state ? Thanks, Björn

Thx Pete, Yes I got it working now ! There was a problem wit the aircraft.cfg file probably as it was pointing to a defective effects file it seams. Strangely enough this caused the fires not to go out . Not sure why that is ! I removed the reference to the effects file and the problem was solved. The FSInterogator returning 0x0D when the number one engine is on fire, is correct, that's also what I get back from offset 3366 in FSUIPC. Thanks for the help Pete, really much appreciated ! Björn

Hi Pete, Tried the FSinterogator approach and still doesn't work, in fact the same thing happens as through the code that I sent. In the "normal" situation offset 3366 returns 0x00, I then set it to value "1" (with FSINterogator) and FSInterogator will return "0x0D" (13), engine 1 is now on fire and the Failures dialog shows that engine 1 fire is in a failed state. Fine... Setting 3366 back to "0" also works fine, and the failures dialog will show engine 1 fire is off. Great ! Except that the XML and the C variables that I mentionned in my previous posts are still showing that the fire is burning. Note that in the piece of code that I sent: engine_fire ^= 1; ==> switches engine_fire bit 0 from 1 to 0 FSUIPC_Write(ENGINE_FIRE, 1, &engine_fire, &dwResult); FSUIPC_Process(&dwResult); I don't understand why it works in your setting and not in mine. Anyway, I will try the same thing tonight on the standard FSX aircraft and see what happens there... probably something else in my panel which is not working as it should... Kind regards and thanks for the help, Björn

Thx Pete, Sorry about the incomplete code, I just wanted to give you a general idea of what I was doing, wasn't trying to be complete. Here's what I found out: Using the code (via offset 3366) will start a fire but it wil not stop the fire if you read the "ENGINE2_ON_FIRE" c-variable, nor the "ENG ON FIRE:x" XML variable, it will stop the fire if you check offset 3366 again. Also if you look at the failures dialog, the failure can be turned on and off again through code... Must be something internal to FSX. Björn

Hi Pete, OK, I gave it a try, I'm trying to kill an engine fire in the below code: FSUIPC_Read(ENGINE_FIRE, 1, &engine_fire, &dwResult); if ( kill_fire == 1 && ( engine_fire & 1 )){ engine_fire ^= 1; kill_fire = 0; FSUIPC_Write(ENGINE_FIRE, 1, &engine_fire, &dwResult); FSUIPC_Process(&dwResult); } (kill_fire is a local variable to indicate when the fire extinguisher handle is pulled) I can read offset 3366 and bit 0 and 1 give the correct value for burning engines or not. If engine 1 is on fire and I set the respective bit to "0" however that doesn't do anything to the fire burning. The bit is correctly set to "0" but the engine is still burning. Guess this is an FSX related related issue rather than FSUIPC related. Björn

Hi Pete, Tim Gregson from MS has confirmed that the "ENG ON FIRE:index" SimVar is read and write so I was wondering if I can write to the FSUIPC 3366 offset to set an engine ablaze ? Thx, Björn

Thx Pete, tried that one and it works even though the values are not 100% as I don't callibrate my joystick through FSUIPC and I don't want the users of the panel to do so neither. Björn

Hi Hervé, That is in fact exactly what I am doing now but... then I learned that in the German version of FS9 the folder was called "Flight Simulator - dateien" ! Possibly FSX doesn't use these localised folder names anymore but to be sure it would be much better if I could retrieve the folder name directly. Kind regards, Björn

Hi Pete, Can I retrieve the FSX flightplan folder path via FSUIPC (e.g.My documents\Flight Simulator X Files) ? I now get the path to the My documents folder from the registry and add "Flight Simulator X files") but then I may miss the localisation differences... Thanks, Björn