Jump to content
The simFlight Network Forums

Daniel Delande

Members
  • Posts

    27
  • Joined

  • Last visited

About Daniel Delande

  • Birthday 01/01/1970

Contact Methods

  • Website URL
    http://

Daniel Delande's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
  13. Absolutely, I forgot to mention the other one which sticks desperately to 0. Best regards, Daniel Delande
  14. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.