Daniel Delande

Solved! Thank you, Pete. Daniel Delande

Thank you for answering, Pete, I tested version 4.212 that behaves the same, regardless whether 'Exclude MIXTUREn SET' is checked or not. Checked. [JoystickCalibration] SepRevsJetsOnly=No ApplyHeloTrim=No FlapsSetControl=0 FlapDetents=No ReverserControl=66292 Reverser1Control=66422 Reverser2Control=66425 Reverser3Control=66428 Reverser4Control=66431 MaxThrottleForReverser=256 AileronTrimControl=66731 RudderTrimControl=66732 CowlFlaps1Control=66162 CowlFlaps2Control=66163 CowlFlaps3Control=66164 CowlFlaps4Control=66165 SteeringTillerControl=0 MaxSteerSpeed=60 LeftBrake=-7810,10774/16 RightBrake=-7683,11807/16 MapThr12to34=Yes MapProp12to34=Yes Throttle1=-15224,-12386,-9806,14478 Throttle2=-13805,-11741,-8515,14859 PropPitch1=-12902,-10580,-7097,14732 PropPitch2=-12644,-9419,-5935,15621 Spoilers=-13970,-13335,-9271,-508 MapMix12to34=Yes ExcludeThrottleSet=Yes ExcludeMixtureSet=Yes ExcludePropPitchSet=Yes No '[Axes]' section. I reverted to version 4.10 and I confirm that mixture controls work OK. Regards, Daniel Delande

Hi Pete, Problem with Windows XP, FSX SP1, FSUIPC 4.20. I have 2 levers for throttles, 2 levers for prop controls, and 2 levers for mixture controls. I have checked the 3 relevant options Map 1->12, 2->34. Flying a 4-engine aircraft (connie), throttles and props work OK, but mixture controls work as follows: - lever 1 controls mixtures 1, 2 & 4. - lever 2 controls mixtures 2 & 4. Of course, I have assigned, in FSX, lever 1 to mixture 1, and lever 2 to mixture 2. I have been using this feature with no problem for years, presumably there is a problem since a recent version of FSUIPC. Before I had a severe PC crash, I was running FSUIPC 4.10 and I had not noticed this issue. By the way, when I re-installed Windows and FSX from scratch, I met the SimConnect/ZoneAlarm blue screen problem, so you now have a second "Problem Type 3" reported; note that I do confirm that it is a SimConnect problem, not a FSUIPC-specific one, for I got also blue screens when my home-made module connected to SimConnect. Best regards, Daniel Delande

Thank you for answering, Pete. I have installed FSX SP1 for long. I actually used the SimConnect logging facility and observed that everything was OK, i.e. the expected events showed (e.g. AddToDataDefinition, ObjectData: RequestID=..., Menu: EventID=...), a menu was actually added in FSX menu. But there was no other effect. My debugger showed no call to my DispatchProc, clicking on the menu had no effect. I'll check what happens when the SP2 is released. Anyway, I have a work-around to make both FSUIPC and my module work. Regards, Daniel

Hi, I have developped a module for FSX that connects to SimConnect, of course. I had difficulties to make may module work when FSUIPC is enabled in dll.xml: in most cases, my DispatchProc (passed to SimConnect in SimConnect_CallDispatch(...)) was never called back. Finally, I discovered that everything worked OK, provided in dll.xml, the section relevant to FSUIPC4 was placed after the section relevant to my own module. Note that my own module can also connect to FSUIPC, but connection to FSUIPC or not has no impact on this problem. Can you explain this? Can this be due to some kind of hook made by FSUIPC to FSX? Regards, Daniel Delande

I have used the 3 kinds of joysticks for a home-made pedestal: - an analogue joystick to USB converter (4 axes, 4 push-buttons and 1 4-way coolie hat). The advantage is that the axes do not require pots (3 wires) but only rheostats (2 wires): the device performs a resistance measurement (range about 0 to 100 kOhms). This makes your life easier, because the levers require to rotate much less than the 270 degrees of a standard pot; using a 1 MOhm pot as a rheostat, you get the 100 kOhms in 27 degrees, and using a 470 kOhm pot, you get the 100 kOhms in 57 degrees. The drawback is that the resolution is very poor: I found 5 bits, i.e. only 32 different digital values. I used one axis for the airbrakes lever, another one for home-made pedals. Note that if you use the coolie hat, you cannot wire the 4 button inputs to switches, but only push-buttons, and that you'll have to wire a few diodes (because the coolie-hat function actually requires you generate a combination of several button presses). - a low-cost USB joystick (Trust's QZ501 predator, 4 axes, 6 buttons and 1 8-way coolie hat). Same advantage, 1 MOhm pots used as rheostats allow a rotation about 50 degrees. The resolution is 7 bits, i.e. 128 different digital values. I used that for the throttle and prop pitch levers (twin engine prop aircrafts) or the throttle levers (4-engine jets). - a more expensive USB joystick (Saitek's Cyborg USB, 4 axes, 12 buttons and 1 8-way coolie hat). I found that kind of proprietary pot that you have to use as is (also, I have a spare joystick, in case a pot fails). The rotation angles are not the same for all 4 axes (about 30 to 80 degrees), so they are not so easy to use. But the resolution is 8 bits, i.e. 256 different digital values. I used that for the mixture and flap levers. Keep in mind that if you need more than 1 joystick, you must use different models (otherwise, FS will only take care of 1 of them). Should I make a new pedestal, I would probably use another solution that I found recently, see http://www.mindaugas.com: you can get 8 axes and 21 push-buttons through a single USB interface. Best regards, Daniel

Hi Pete, Thank you for your update 3.422. I tested throttles, rpms and mixtures with 4-engine aircrafts, and I also tested throttles with a 3-engine aircraft. Everything is fine. Thanks again for being so responsive. A word about 3 and 4-engine aircrafts: I'm afraid it's a little bit different: 1->12, 2->3 actually applies to 3-engine aircrafts, and 1->12, 2->34 applies to 4-engine aircrafts. I remember this accurately because I am the guy who asked you, about 2 years ago, to extend the original throttle mapping for 4-engine aircrafts to the rpms, mixtures for both 3 and 4-engine aircrafts. Best regards, Daniel Delande

I certainly can wait until early December, and even longer. But, of course, I accept to test it if you think it helps. Best regards, Daniel Delande

I have a 4-lever quadrant, I confirm the problem. It occurs when Filter 2 is checked. This applies to throttle and prop pitch (as for mixture, I don't know). It does not occur when only Filter 1 is checked.

Yes, I can understand I could have worked it out. However, I have not, just because there was no real need: I had not to look at what is inside the functions; I simply noticed that the global variable and function names begin with 'FSUIPC_" (they now begin with "FSUIPC_IPCACCESS_" in the old library). I must admit that I have not tried to understand the IPC protocol and, by extension and laziness, the code of the libraries. Thank you for answering and being patient, Daniel Delande

Hello Pete, 2 questions: 1. In order to make the module I develop compatible with old versions of FSUIPC and not to waist performance with the newer versions, I have implemented the following strategy: - call the new version of Open2(); if it returns TRUE, that is OK, the version is >= 3.40. - if it returns FALSE, call the old version of Open2(), that should return TRUE. I have renamed the old functions and global variables, so the 2 versions can be present in the code. Apparently, it works fine. Is there any pitfall? 2. In some cases, I have to get several data from FSUIPC in one shot. So I first call Read() a number of times, then I call Process(). I check the value returned by every Read(). What should I do if the first Read() returns TRUE and a subsequent Read() returns FALSE? Call Process() so as to clear the buffer and discard the result? Note that my question applies to calls from a module loaded by FS and also to calls from an external application. Daniel Delande

Yes. I made some tests with different combinations of FS, Windows and DirectX: - FS2004+XP+DX9 - FS2002+XP+DX9 - FS2002+XP+DX8 - FS2002+98+DX8 - FS98+98+DX8 - FS98+98+DX6 The last case is the only one that has a short polling duration (about 40 microseconds) when the analogue joystick is disconnected. The other cases vary from 5 to 21 milliseconds. When the joystick is connected, the pollling duration is about 1 millisecond in all cases. I don't know whether this may help, it does not look consistent with the odd problems you stated. Best regards, Daniel Delande

I had no problem to move the code of my app from the thread where it was to the callback function, but this did not change anything, i.e. the frame rate was still far from constant, even when I made "thin slices". So I re-enabled some debugging code so as to get timing data and I found that the duration of a slice was generally ranging from 9 to 17 microseconds (that are peanuts compared to, say, the 33 milliseconds of a 30 Hz frame), but in a particular case went up to 21 milliseconds (this occurs when the slice intends to poll a disconnected analogue joystick)! Of course, such a figure affects significantly the frame rate, and synchronizing the polling with FS cannot help. When the disconnected analogue joystick problem is removed, there is no visible difference between the 2 strategies, i.e. synchronizing with FS or running in a separate thread. So, finally, as you said, the separate thread is actually the best solution, since it does not interfere too much with FS internals, and it does not raise questions about the next versions of FS. However, I do not regret having investigated FS callbacks, because I learnt about FS internals, and it makes me appreciate the work you have to provide to build FSUIPC. Thanks again, Daniel Delande

Absolutely, I forgot to mention the other one which sticks desperately to 0. Best regards, Daniel Delande

Bingo! As you said, I could easily spot the offsets 0x438/0x43C in various module Init/DeInit's. I found that 2 arguments are passed to FS: the address of the callback function (of course) and a 4-byte datum that has small values (0x10 is frequent); this must be the chain ID. I tried 0x10 first, then 0x13, as you said. I also found that the callback function has one 4-byte argument and returns nothing. The tests with 0x13 made my short callback function called at high frequencies (e.g. 280 Hz, for a shown 70 Hz frame rate). I observed as you said that the frequency is lower when the frame rate does not show. I also observed that the argument passed to the callback function takes cyclically a small number of different values (typically 3 to 6). I now have first to go through some more testing, and finally to modify my application. I think I'll simply check the current time at each call and decide whether the callback function has simply to return or to do something. I'll also cut the 'something's into slices as thin as possible so as to get a frame rate as constant as possible. Thank you Pete, your help made me save a considerable amount of time! When I am finished with modifications, I let you know how synchronizing my app with FS impacts the overall performance. Thanks, thanks again. Daniel Delande

I'm uncertain about what you mean. I guess the pointers to Chain and Unchain are adjacent in the structure imported by a module and filled by FS (by similarity with Init and Deinit addresses that are adjacent in the exported structure of a module). Also, if the Chain function is called in the Init procedure of a module, the Unchain function should be called in the Deinit procedure. For sure, if one has 2 PCs available for FS, running extra tasks outside the main PC is preferable. However, this works if one has 2 PCs, and if WideFS+FSUIPC support all the interfaces needed by the extra tasks. As an example, I need to get data from the joysticks (I know that FSUIPC can do that to a certain extent) and to write things to the parallel and serial ports. Also, adding tasks in the PC that runs FS certainly impacts the performance of FS, but in my opinion, it is a matter of taste of the user to accept the cost of lower FS performances, and have the benefit of extra functions (in my case: animate a small home-made pedestal). Note that this is a simple remark, I totally accept that you have full authority on what FSUIPC should do and should not do.

Thanks for answering, I anticipate hours of time in reverse engineering! For instance, as Chain and Unchain are apparently not exported symbols, I understand I have to step through the Init procedure of a simple module, and find a call to a FS function with an argument that is the address of a module's function (which is in turn called by FS from time to time). Anyway, it is a matter of time. Since you have already been through this process, and as you say, the portability to new versions of FS is an important issue, are you considering adding a synchronization service, or something similar, to FSUIPC, some day? Best regards, Daniel Delande

Hi, I have developped a module, for FS 2004, that gets data from FS and controls FS through FSUIPC. I would like now to synchronize some tasks with FS internal cycles such as frame drawing. I assume that it is possible to ask FS to call callback functions synchronized with its internal cycles... but I don't know how. - is it actually possible to get callback messages from FS, synchronized with its internal cycles? - what are the known cycles? Frame drawing? Others? - how to ask FS to call a callback function? What I know, up to now: - how to build the ImportTable, so that FS provides a pointer to a structure that contains a number of pointers to functions my module can call, e.g. for PANELS: DLLEXPORT struct { int fnID; PVOID fnptr; } ImportTable[] = { {0x0000000F, NULL}, // 0x0000000F for PANELS {0x00000000, NULL} }; What I dont'know: - to what extent the PANELS functions can be safely/efficiently called by a plain module (as opposed to a gauge). - whether the PANELS functions do contain functions that can solve my problem, and how to use them. - whether my problem can be solved by importing (undocumented?) functions with another (undocumented?) fnID (I only know 2 values, 0x0000000F for PANELS, 0x00000013 for GAUGES), and how to use them. Can someone help me? Best regards, Daniel Delande

Yes, that's what the Win32 API help page dedicated to ValidateRect reads, but unfortunatly the WM_PAINT help page has no direct link to the ValidateRect one. I am not familiar with this level of Windows API programming, so I really thank you again for sharing your experience. Daniel Delande

This is the right thing that actually solves the problem! My poor code (only 'return 0;') was not sufficient. :D Thanks a lot for your help, Pete. Daniel Delande

I noticed a difference between my window and yours, when FS is NOT in full screen mode: - with mine, from time to time, FS redraws partially its window. - with yours, FS never redraws its window. I concluded from this that I had not hooked the WindowProc of the right window (the only hook installed was on the main FS window). So I tested this: - enumerate the child windows of the main window of FS, and hook the WindowProc of those whose class name is FS98CHILD (there are 8 of them). - in the 8 new WindowProc's, just return 0, whatever is the incoming message. - of course, restore the original WindowProc's when my window closes. The result is that FS does not redraw its window(s) and that in full screen mode, the black screen problem is not there anymore. This is brutal a method, I think I had better refine it a little. Daniel Delande

Well, my window is supposed to be also a modal window within FS. It is created within FS (my application is a module, i.e. a dll loaded by FS) and seems modal as expected (FS hangs until my window is closed). The only non-modal visible effect is that damn black screen. Regards, Daniel Delande

Thank you for answering. I already tried tricks such as using LockWindowUpdate() with FS's window handle or trapping the WM_PAINT messages. The best result I could get is that I could move around my window for a while (with the same 'horrible result' you get when you move FSUIPC's window), but randomly, the screen finally goes black (that is not the case with FSUIPC's window), and I can recover from that situation by depressing Alt+Enter so as to exit the full screen mode. So, I suspect that there is something else to do to prevent DirectX9 from covering all windows with that black screen. Regards, Daniel Delande

My problem is not directly related to FSUIPC, however I found a number of posts related to it on this forum, but I could not find a post with the solution. The issue is how can a module (triggered by a menu item of FS) display its own window over FS window when the latter is in full screen mode? It was easy with FS2002 and DirecX8, but, as stated in different posts, it's not easy with FS2004 and DirectX9. Can someone who has found the solution explain it (or direct me to a site where it is explained)? Daniel Delande (d147@tiscali.fr)

I cannot test that, since I have never seen any panel with 2 ADFs, yet. Regards, Daniel Delande