Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Depends on what you fly. For a jet you don't really need Prop and Mixture, so you can control 3 engines (maybe a 727? 😉 ). For a single throttle lever, don't mess with complications in the Assignements tab. For reverse zone calibration with a single throttle, check "map to 4 throttles" on page 1 of Calibration, then go to the later page, the one for 4 throttles, and calibrate your throttle with "no reverse zone" unchecked. Just follow the numbered steps in the Calibration chapter in the User Guide. Pete
  2. Strange. I could check, but I definitely need the FSUIPC version number, please!
  3. It sounds like you want to use the throttle with a full forward thrust to full reverse thrust range, and a centre (or offcentre) idle zone. To do that you need ot assign calibrate on the 4 throttles tab ieither by using the map to 4 on the first tab, for a single throttle, or by assigning 2 or more levers to separate engines in the first place). On the 4-throttles calibration page you can make sure "No reverse range" is unchecked, then simply do yuor proper calibration for a max reverse, centre, and max thrust position. If by 'To" you mean trying to calibrate a specific place for Take Off thrust, surely that's normally max, or very close, with a desired N1% which varies by conditions (weight, weather, runway length & condition). Pete
  4. Okay. So all fSUIPC does with those is send the relevant control to the Sim. Nothing else. Use FSUIPC Event (non axis) Logging and check that your button/switch operations result in the correct controls being sent. for the flaps inc/dec you can also just use the default sim key assignments -- F6 and F7. See if they work. So if you weren't using FSUIPC, how would you operate Gear and flaps in that aircraft? Not with default FS methods I assume? I think you might really have a question for Carenado, as it seems very odd if they don't obey those basic commands. Pete
  5. Are you using the FSUIPC Monitor in the Lgging Tab to check? Else how? If you think there's a problem we need FSUIPC version number and exact details of what you are doing. Pete
  6. 'General use' means it is free for you to use however you like. If you write to it, the value you write just gets written. What else are you expecting to happen? Pete
  7. Are you trying to assign from an axis (lever), or buttons/switches? Some aircraft do the own things for some sub-systems, but to advise you further we need to know exactly wwhat you assigned. Pete
  8. I think you'll need to make the simulator folder, where MakeRwys is being run, the current folder. Pete
  9. After some problems here (my development system suffered a fatal crash, which I'm in the process of recovering from), i managed to test the WX Radar facilities with the latest Beta of Active Sky (released within the last couple of days -- sorry I don't have access to the build number at present). That works only with P3D4.5.14 (= HF3, the last update), and the radar image is perfect with that combination. Note that ActiveSky is now quite complex. There are three parts -- the ActiveSky program itself, plus a program called "ActiveSkyUtils.exe", plus the module in P3D (AS_CONNECT_64.DLL). All three must be running okay. If you still get problems i suggest you use the "Log" option in the main ActiveSky options to generate logged details and send them off to ActiveSky. I can assure you that all is well in FSUIPC. Pete
  10. WideFS is onlt an extension of the FSUIPC application interface to client PCs on a Network. Of the programs you list only ProATC/X is an FSUIPC client application. In fact some of those you list aren't even interfacing to P3D in any case: MSI Afterburner and Google Chrome for instance. I think Navigraph charts can link to P3D, but it provides it's own interface. "FMS" is a general term for any aircraft's Flight Management System. it isn't a specific program. Pete
  11. If you can spare the time, please see if this version fixes the problem: Install_FSUIPC4975b.zip If you need to retreat again to 4.971, please remember you will then need to delete the FSUIPC4.DLL from the Modules folder before re-running the 4.971 installer. Pete
  12. But the Log shows the reason for the control being sent or not sent, based on the conditions. Everything you showed me in the log looked correct. The conditions told it whether to action the assignment, and when the conditions were correct, it did so. Sorry, I don't see that. buttons B 8 9 and 10 are all indicating off, that's why the command isn't actioned: 736855 [Buttons] 102=CP(+B,8)(-B,11)B,1,C66483,0 736855 .... Condition (+B,8) = FALSE 736855 [Buttons] 202=CP(+B,9)B,1,C65580,0 736855 .... Condition (+B,9) = FALSE 736855 [Buttons] 302=CP(+B,10)(-B,11)B,1,C65567,0 736855 .... Condition (+B,10) = FALSE Aha! So you are saying that one of 8, 9 and 10 should always indicate as pressed? I see. But sorry, the logs didn't tell me that. That's why I was puzzled. It does seem odd that what FSUIPC receives changes depending on whether another Windows App is also monitoring. There is an extra logging you can enable in FSUIPC which will show exactly what is received from Windows via DirectInput. I think it is still active -- I'll check. But meanwhile you could monitor the state of the buttons via the FSUIPC Monitoring options (right-hand side of the Logging tab in FSUIPC Options). Perhaps log extracts similar to those you provided above wityh the actual button state changes shown at the same will tell us more. I'm assuming joystick B is still device ID = 1, the Saitek Yoke: Monitor 03C4 as U32 and check the hex checkbox. Then check 'normal log' below. Just show one example please, as in that small extract above. Pete
  13. There's nothing wrong with continuing with 4.971, excepting for support I may have to ask you to update again, should you have other problems. I have an updated version under test here, which may or may not work on your system. I just made some small improvements so it tries more versions of the SimConnect DLL. However, although I did manage to dig up and get working my old copy of FSX-SP2, I couldn't reproduce anything like the problem your log showed which I do not understand and which I still think indicate a problem in the Registry. But the update might be worth trying, nonetheless. If you'd like to try it, with no guarantee of success, please let me know and I'll attach to to a reply here. Maybe, but surely that aircraft will work in FSX-SE (which has many bugs fixed compared to the last version of FSX), and it should also be okay in P3D3. Either would be worth upgrading to. Pete
  14. Yes. "single floating points" are called Floats (FLOAT or FLOAT32) whereas the Doubles are called DOUBLE or even FLOAT64. Note also that some "integers" are really fixed point values, eg the integer in the high part and fraction in the low part, with the point considered to be at the boundary. But these variations are always described. This mish-mash is historical. FSUIPC started with FSW95 as a program by Adam Szofran of Microsoft -- I took over with FS98 and later. In the early days FS was designed with memory constraints considered, and data was kept in its most compact form, using units and formats which gave the maximum precision for the least space, at least for all values for which a range or boundary could be determined. As versions of FS developed this was relaxed, but my ambition with FSUIPC was on-going compatibility with as many of the add-on programs as possible. So, new data formats for new programs but don't stop the older ones working. So FSUIPC still converts most values to their old formats, even though SimConnect supplies (or can be asked to supply) them almost all in standard forms (usually doubles for numerical values, for example). In many cases FSUIPC now supplies values more than once, in different forms. Pete
  15. Well, there certainly must be users now using them with P3Dv5. The driver i made originally for FSX and converted over to P3D4 also works in P3D5, alongside FSUIPC. What I think PFC will mean is they don't support such use, so you are pretty much on your own. i might be able to help a little, with the software, but I've not had such hardware in my hands for many years. I do have some PFC HID devices in my PFC cockpit (which is otherwise mostly older style COM serial port gear), so I have a vested interest in maintaining the driver, but that doesn't qualify me to answer every question and certainly not things more hardware oriented. So, I'd be most hesitant advising you to buy one solely for use with P3D. it would be different if you were also planning to use it with it's currently intended platform, but it's a big investment. Pete
  16. If you think you might one day see a negative airspeed maybe you would read it as an SD. But i don't think it is possible in the Sim. So it's best really as a UD. For positive numbers the only difference bretween a uD and an SD is the maximum value, as the top bit is reserved as the sign. Floating point and double values are always noted as such. All others are integers in some format or other. No, a plug-in has no idea what the data is supposed to mean, so it can't do anything automatically like that. Pete
  17. Sorry, again clarification needed. This says to me that everything is okay in FSUIPC -- that the buttons and axes are seen and can be assigned / calibrated, but you aren't seeing the results you expect in FSX. Is this correct? That all looks fine. What are you expecting there instead? Yes, so all that's good too. I'm sorry, but you appear to be quoting these bits as if they illustrate something wrong, but they don't appear to. uit all looks good. What difference? Every example you illustrate looks correct. what do you think is wrong? FSUIPC's comments are added to the end AFTER yours. Just use the normal commenting system for your own -- i.e. ; followed by text. FSUIPC identifies its comments by its special delineations. Pete
  18. Wouldn't it be a good idea first to test your theory? Try turning off autosave way before touchdown so you can see if you stil get your stutters or not. If you have autosave operating at, say, 30 or 60 second intervals, wouldn't it be a rather remarkable coincidence for it to always occur just at the same point in your flight? In my experience stutters on final approach are due to things like airport buildings being rendered, AI ground traffic appearing (even just out of sight), and even possibly textures being freshly sharpened If there is any stutter at all when the Sim is saving your flight, this will really be one long one, not several. And, in general, unless your memory is full so there's no room to cache the file data and your disk is slow or badly fragmented, the only thing which makes for noticeable pauses during flight saves is when using a complex add-on aircraft like those from PMDG which also save all their own data to their own files. Anyway, if you really want the facility you suggest it would be possible for you to implement one as a Lua plug-in now that both FSUIPC5 and FSUIPC6 offset the "auto-save toggle" control. Unless you have a non-retractable gear I would suggest you make it contingent on the Gear being lowered rather than the AGL value. You could do the same in reverse when raising the gear after lift off. You don't want autosaves whilst taxiiing do you? Pete
  19. Okay, thanks for letting me know. I'll have to think about what that implies. Carry on using 4.971 for now. If I manage to work out what could be going wrong for you with 4.975a I'll get back to you -- but it is unlikely to be soon. Alternatively, in the case that I'm sure I've made a difference I'll post a newer version in the "Download Links" subforum - "Updated Modules" thread above. BTW, not that it matters now, but it looks like you didn't run the 4.975a Install "as administrator", so it failed to copy in some of the files. Pete
  20. Whilst it does open up even more possibilities, you don't really need to get into Lua programming. FSUIPC offers "Profiles" which allow for different button, key or lever assignment and calibration for different aircraft or class of aircraft, changing automatically based on what you've loaded. Lua scripts can allow more complication but for all the functions built into the aircraft models there are usually simpler methods -- for input control, that is. The display, however, is another matter. The PMDG Boeings have their CDU display data mapped into a form that can, with programming, be transferred to another screen such as the one in your hardware CDU. I would assume that FDS provide some suitable driver software to allow this to be done vitually painlessly, but FSUIPC itself has no specific facilities for outputs, though there are provisions in the Lua support,. Extra keyboards are problematic. You need software which can tell the difference between the same keys on the separate keyboards. Windows treats every keyboard connected to a PC the same. I know there is a way, but it isn't easy and I'm not aware offhand of ready-made software for this situation. I did try it once for my two CDUs (captain's and first officers) but it got messy and fraught when both pilots accessed at the same time, so I decided to just use separate mini-PCs, one for each. that also made it easy for the screen -- the CDU screen is the PC screen. If you do come across any reasonably easy to use keyboard driver which can automatically differentiate between two (or even more?) keyboards on the same PC, please do let me know! Yes. I used to use Project Magenta -- for a long period, in fact (from FS98 days). But I now use ProSim737 which is more dedicated to the detail for the specific aircraft, and still under live development. ProSim (and the SimAvionics suite too, for that matter) has drivers for popular makes of kit (such as your CDU) built in. And of course they can operate over a network of PCs (my cockpit system currently occupies 7 PCs, 5 small ones internal to the cockpit, and two external (including the simulator program P3Dv4 moving to v5, and the display system). Pete
  21. That doesn't work. If doesn't indicate that it is running, it doesn't provide radar data either. HiFi are checking for me. So far they think it might be an installation problem. but I did the same for P3D4 as for P3D5 when installing the updates, and P3D5 radar images are fine. Exchanges with HiFi are slowed by the time difference. I'm in the UK, they're in California I think. Pete
  22. Do you mean Device Manager, in Control Panel? You need to go through each of the lines under USB down near the end. i think it tends to be those labelled as "hubs" which have the Windows power management. Well something is sending those 68065 controls. i realise they are probably nothing to do with your problem, but they don't make sense so make one suspicious. Ah, so it's something internal to those. We'll forget those then. And only the two hub devices keep powering off? Well, that's very suggestive of power problems for sure. Are you sure they have enough power? The electric trim operation will consume more power of course. No. The power management I'm talking of isn't against a specific device. Open Control Panel - Device Manager. Scroll right down to "System devices" then, within that, "Universal Serial Bus Controllers". Look in the right-click Properties of every single entry. Some, not all, will have a Power Management tab (mostly the ones labelled as Hubs - there are 13 such entries on this PC I'm using right now). Make sure the "Allow the computer to turn off ..." checkbox is unchecked in every case. That's suspicious. Sounds like there's not really enough power in any case. You might need to beef it up. But PFC are the folks you should ask about the needs of the Cirrus. I don't know. i have a full blown PFC cockpit and that needs almost 3000 watts worth, a cooling system, and an air conditioning plant!, and that's before i get to the computers! All your problems most certainly look related to power in one way or another. I can't think what else could do that, excepting stupid obvious thinks like bad connections or faulty interfaces. That would mainly be a matter of trying different USB sockets and different cables. Pete
  23. I don't see that in the log section you provided. This is repeated control is a concern in that part of the log: This isn't a control I've ever used, nor is it programmed into any of my drivers. All my PFC radios only handle the usual frequency spacing in any case. At the time the PFDHid driver was made, control 68065 was beyond the highest numbered one known -- "ADF2 STBY SET" at 68039. I think it must be new for P3d5 because it isn'tin my P3D4.5 list. However, the question here is: why is is being sent and why so often? Looks like about 12 times per second. Is it something you've programmed? I don't suppose that's the reason for your problems, though it could well be related, but I don't really see anything else in that log segment. That device reconnection at the end of your log extract is presumably relevant, but that is actually 10 minutes after you started off. Do you have more, closer, later on? Could it be that with hands off the controls the USB devices are going to sleep? Have you turned off power management for every USB device you can find in Windows device manager? If not, try that -- Windows has a habit of turning off power for less used USB devices unless you stop it! Pete
  24. You posted this support requests in a reference subforum clearly marked in red NOT for support requests. Please do look before placing messages! You are lucky I saw it. I've moved it to the proper Supoort Forum. ------------------------------------------------------------------------------------------------------------------------------------- Very many parameters, expecially those not very often needed to be changed, are not pre-included in the default INI file. They then simply take on their documented default action, the one most normally required. If you want to change that, just add the parameter yourself. As documented, in goes in the [General] section. Pete
  25. That sounds like it must be something on the USB channel being used for the device locking up Windows drivers.. Have you used the Cirrus before? is it a new purchase? If not, if you've been using it with no troubles before, what changed which might result in something so unpredictable? Enabling FSUIPC Event and Axis logging just before engaging a mode which will introduce electric trim activity might help show what is going on, though that could get pretty big depending how long you allow it. Please don't try sending us huge logs. Try looking at them yourself and perhaps quoting chunks t illustrate matters. Pete
×
×
  • 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.