Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Content Count

    35,482
  • Joined

  • Last visited

  • Days Won

    116

Everything posted by Pete Dowson

  1. Pete Dowson

    Logitech throttle set up

    Even if the inputs from the axes are dissimilar, then proper calibration in FSUIPC will match them all to the range expected by FS9. That's the prupose of calibration. So the minumum and maximum will be made to match. How that is spread across the movement of the axis will not necessarily mach across all of the throttles, however. That will depend more on the quality of the controls, how well matched they are. With such an old FSUIPC version (FSUIPC3 for FS9 and before has been out of development for years) there are less facilities for trying to scnchronise the throttle positions, so you have to compensate by simply adjusting the levers to their needed position for the desired thrusts. This is quite realistic -- real throttles rarely match up unless the aircraft is factory-fresh. Pete
  2. Pete Dowson

    trouble with bank angle

    I used Ardino once, but I don't remember a lot about it, but the folder with the Arduino software contains Arduino_debug.exe as well as Arduino.exe I seem to remember debugging my little program before using them in practice. Maybe I'm mis-remembering. it was a while back and I am getting old! Okay, so the Lua program is working, though I still think you need to consider what the \n terminator is actually doing. Maybe making the messages fixed length and only sending and reading that number of characters would be better. Well, if the clocks in both Arduino and the PC were also somehow synchronised, and ran at exactly the same speed, and P3D and other threads in the PC didn't interfere with the Lua timing, and the value you are reading changed often enough to guarantee a new value at least on time, and you somehow started the Arduino loop running a millisecond or so after the Lua sending started, then, yes, they might stay synchronised. But no, that isn't possible for most of those reasons. So, if the Arduino read just waits for more to arrive before diving a result then the Arduino loop should be running faster that the Lua. However, none of that explains why the Arduino end isn't seeing the data. Is there no way you can log what it gets -- as you say it is obviously getting something. But I think it will be the Arduino side you need help with. If you want to see what is going out of the COM port you can either use logging in FSUIPC (see below) or a port monitor program. To log COM data add these lines to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=x40 The data will be in hexadecimal of the ASCII byte values. This will be all from me till 19th, earliest. Pete
  3. Pete Dowson

    trouble with bank angle

    Sorry, what is "OACSP"? Don't you have any means to track what the Arduino is actually receiving? I thought there was a program which could show you everything your program did? I really don't know Arduino. Is "lcd" a standard Arduino library? Sorry, I don't understand the terms used here either. Consistent with what you intend, you mean? So you know the Lua part is okay, then, right? In the Arduino code I assume "Setup" is automatically run on loading. Does the "All Good" message get displayed? How does the "loop()" function get called? How many lines does the LCD have? If only one, wouldn't the '\n' character at the end of each string cause it to scroll off? One other thing I do notice: you are sleeping for 200 mSecs in the Lua, presumably to prevent a pile up of messages in the Arduino. In the Arduino code you seem to have defined the \n as "endmarker" but i don't see that being used anywhere. And in your loop reading the serial data you also delay 200 mSecs. Couldn't having the same delay both ends possibly cause a clash, where you get the last half of one message and the first of the next? I suspect you want to have the Arduino code reading a lot more often. Is there a good reason to have a delay at all? I assume the "readString" will wait till there's something to read? ========================================== Please note that FSUIPC is really just a utility program, not a hardware driver. Specific hardware support does really need to be addressed by the corresponding hardware maker or it's included software. Possibly there's an Arduino support forum which can help, if you are seeing the data logged by Lua matching what you expect. Pete
  4. Pete Dowson

    Joystick number

    I'll let Paul answer the questions about the facility in his DLL, but the example picture you show is from a WideClient-connected Joystick, not one local to the simulator PC. Jpysticks 0-15 are the only ones representing true DirectInput joysticks which are scanned regularly on the Sim PC. 64-72 are "virtual buttons" only. These are really just offsets which are changed by FSUIPC applications. You can monitor those using Offset reading facilities. For the correct offsets please check the Offsets list PDF in your FSUIPC Documernts folder. Pete
  5. Pete Dowson

    Makerwys v4.801 fails to make data files

    Well, the LorbySceneryExport program is merely a special version of that AddOnOrganizer which MakeRunways can call directly to do the same processing, -- generating the scenery list you see in AddOnOrganizer, and writing it out to the MakeRunways-chosen filename. The same sort of export can be produced also by AddOnOrganiser (I think you just right-click and select export). So, without being able to see the details in the log ("runways.txt"), I think you need Lorby-SI support to resolve your problem. Pete
  6. Pete Dowson

    Makerwys v4.801 fails to make data files

    I am away from early tomorrow until the following Friday (the 19th), but maybe John or others can help. But you can also try Lorby-Si support, because the MakeRunways_Scenery.CFG file is built by the Lorby-Si scenery export program, and that needs to be correct for MakeRunways to process the scenery files added via the Add-Ons.XML methods. If you have the Lorby AddonOrganiser, run that free-standing and see if that finds all your sceneries okay. If not, then the problem is to do with your folders not found under the correct names. You haven't renamed the Prepar3D.exe file have yo? Just check that it is there is the same folder you placed MakeRunways into. I get the feeling that you are placing it into the wrong folder. Another test: if you remove the scenery export EXE from the MakeRunways folder, then execute MakeRwys, if the folders are correct it should find all of the default scenery layers and any add-on sceneries added the old way, via Scenery.CFG. Pete
  7. Pete Dowson

    Makerwys v4.801 fails to make data files

    The Runways.txt file, which will certainly be there, is the log file showing everything it did. How big is that? Were any of the expected files produced? Also: are you using version 4.801, as per the title of this thread? If so then that will probably explain it. The current version is 4.872! If the Runways.txt file is short enough, or you can cut and paste just the first page or so, then please show us what it says. Pete
  8. Pete Dowson

    Useful additional programs

    Full FSUIPC SDK up to versions 3.999 and 4.80 FSUIPC SDK Updated 22nd December 2018 with: -- New version of the Python section of the kit, courtesy of István Váradi 64-bit Module User kit on its own ModuleUser64 64-bit External User kit for C/C++ on its own UIPC64 SDK C maxx's free SPAD: Saitek Panels Advanced Driver Go to http://fstools.weebly.com GPSout version 2.61 for use with FSUIPC3 only (FS2004 or before) GPSout 2.61 -- Adds option for Sim Mode field added to the RMC sentence (for Apple devices) -- Signature removed ShowText by Rob van der Wiele ShowText TrafficLook accessory program TrafficLook NOTE: Currently this utility does not work on Windows 10. Version 1.551 includes an Airport filtering option Version 1.56 displays nearest traffic information in the title bar (needs FSUIPC 4.966 or later). WeatherSet accessory program WeatherSet WeatherSet2 only, Version 1.60 WeatherSet2 Version 1.60 of WeatherSet2 handles FSX Global Mode multiple visibility layers, and "GapAbove" surface wind. HidScanner: A little program for scanning connected (or even just Registered) Joysticks and other HID (Human Interface) Devices and providing full details. It can stay running and monitor changes too, if needed: HidScanner GFdev64.dll for GoFlight users (P3D4 only) GFDev64.dll This is version 2.2.2.1 (January 2013). For the very latest versions please check over at GoFlight, link: http://www.goflighti...m/pages/support GFdev.dll for GoFlight users (FS2004, FSX, P3D1-3) GFDev.dll This is version 2.2.2.1 (January 2013). For the very latest versions please check over at GoFlight, link: http://www.goflighti...m/pages/support Older GFdev.dll for GoFlight users (FS2004 or FSX) Older GFDev.dll GFdisplay version 1.30 for Goflight users (FS2004 or FSX) GFdisplay 1.30 (Now including GF-MCP Pro support) Flight plan converter, FxmlToFLT, FxmlToFlt.zip This utility, written and copyrighted by John Nunez in 2014, converts the new format "FXML" flight files into the older format "FLT" for use by unmaintained programs such as RCV4 (Radar Contact version 4). RCV4 provides restart options from saved flights but can only read the old FLT format. Make Runways utility version 4.872 MakeRunways 4.872 -- For P3D3 and P3D4, this version uses a Lorbi-SI's AddonOrganizer derivative called "LorbySceneryExport", (included with MakeRunways) to create a scenery.cfg fil it can use even when the scenery add-ons are distributed according to various XML file. Please see the document included in the MakeRunways ZIP! -- Version 4.835 just adds a new command line option, used by SimStarterNG, for programs which pre-generate the MakeRwys_Scenery.cfg file, so not needing MakeRunways to call upon the Lorby program.. -- Version 4.84 fixes a problem with getting runway threshold offsets. [Note this may still not work with sceneries compiled using the latest P3Dv4 tools] -- Version 4.85 adds the command line option /Jetway to make the Gares file to include a flag for those gates with a built-in jetway (i.e. one in the AFD BGL). -- Version 4.86 uses a special version of the program from Lorby-Si to generate the MakeRwys_Scenery.cfg file. This version is included in the ZIP, with kind permission. -- Version 4.861 improved the reliability of using the Lorby program output. -- Version 4.863 removes the use of P3D4AddonOrganiser, depending only on the included exporter instead. -- Version 4.864 puts more information at the top of the log (Runways.txt), including any error information relating to the use of the Lorby program. The documentation also now reminds you to run MakeRwys "as administrator". -- Version 4.865 handles Taxiway names of the maximum of 8 characters better (only a Logging change, i.e. runways.txt) -- Version 4.871 fixes runway MagVars to match Airport ones when the latter have been updated by a later BGL containing no runways -- eg by FSAerodata or Herve Sors update pacages. -- Version 4.872 includes a fix for a very obscure bug which causes it to crash after completing all the main files, but whilst assembling the Comms frequency files, f4.csv and f5.csv. It occurs when a scenery folder contains many AFDs re-defininig the same airport data and accumulating those frequencies. For the earlier data duplicates are rooted out early. Comms were dealt with differently, by search a built list for selected frequency types. FliteStar plans exporter, FStarRC, version 2.31 FStarRC.zip This update works with versions of FliteStar/FliteMap up to and including 9.5.2.1, and with the latest FStarRC.rws and F5.csv files produced by MakeRunways 4.52 or later. -- Signature removed EPICINFO5 Beta version 4.941 for FSX/ESP EPICINFO5 Beta 4.941 For use only by experienced EPICINFO users. This is the DLL only, which was etrieved from archives after an unintended absence of 6 years, but without any documentation at all. It cannot be supported at this time. MixW freeware virtual port simulator (not for Vista/Win7 or 64-bit) MixW Freeware HHD freeware virtual port simulator at http://www.hhdsoftwa...al-serial-ports (works with bioth 32-bit and 64-bit Windows 7) (Alternatively, for Vista and Win7 try the Eterlogic one, 32-bit version is free, 64-bit reasonable at $25 (U.S.): VSPE Website
  9. Pete Dowson

    FSUICP NEWBIE

    and So the throttle unit is a normal Windows-recognised throttle, or does it have specific drivers? What make is it? Check Windows "Game Controllers". Is it seen there, as throttle, and will it show its actions there? If not then that's what FSUIPC doesn't see it. Well the slave PC change would have no effect at all on the main PC so that's not the main problem. And it really isn't possible for things to get messed up by only a change from P3D3 to 4 and FSUIPC4 to 5. They are completely interchangeable as far as FSUIPC is concerned -- well, except for isolated facilities like "mouse macros" which won't apply to ProSim aircraft in any case. So i'm sure something else must have changed in your changeover process. It would be useful to know what, but never mind. Let's move on. I don't think there's much to worry about on the 'slave'. I think we're now only trying to work out why the throttles aren't seen. Incidentally, have you considered assigning and calibrating the throttles in Prosim instead, in any case. I'm sure it suits it better -- as i say, i've been using this method through all ProSim 1 and 2 versions. Why? Prosim is becoming more and more capable. What other cockpit software would you consider? Pete
  10. Pete Dowson

    FSUICP NEWBIE

    FSUIPC5 always created the FSUIPC5.Joyscan.csv file. It will certainly be there, in the same folder as your FSUIPC5.INI and FSUIPC5.Log files. I'm finding this a bit confusing. If the Bodnar board is connected to the same PC as your P3D Installation, then that's where the throttle axes will be seen, and directly, not via WideFS. If your throttles are connected to a Bodnar board on a different PC, then WideClient does not send the axis inputs through to FSUIPC, only buttons -- these will be seen as connecting to joysticks with numbers with a client PC number first. Client numbers are listed in your FSUIPC5.INI file, here: [ClientNames]1=SLAVE122=SLAVE133=SLAVE14 I don't know what troubles you are having with connection, or which WideFS client your Bodnar board is connected to (if it is), but the WideServer.LOG you posted showed a healthy connection with "SLAVE14": ********* WideServer.DLL Log [version 7.076] *********Blocksize guide = 8192 (double allowed)Date (dmy): 07/07/19, Time 21:17:29.187: Server name is MASTER11 15085 Initialising TCP/IP server 15085 Initialising UDP/IP server 17082 Connected to computer "SLAVE14" running WideClient version 6.860 (IP=192.168.15.120) UDP 726028 Auto send for 0 stopped before sending all data (0 of 47 sent), Error=10013 (IP=255.255.255.255) UDP 732549 Close signalled to clients 733657 Closing down now ...Memory managed: Offset records: 244 alloc, 242 freeRead buffer usage: 6932 alloc, 6932 free, max in session: 1Write buffer usage: 31690 alloc, 31690 free, max in session: 1Throughput maximum achieved: 20 frames/sec, 789 bytes/secThroughput average achieved for complete session: 4 frames/sec, 137 bytes/secAverage receive rate from "SLAVE14": 9 frames/sec, 552 bytes/sec********* Log file closed ********* The error 10013 is only the disconnection when you closed the P3D session. It was obviously quite happily exchanging data for nearly 12 minutes before this. However, WideFs is not involved in your throttle axis problems. If the only change was from P3D3 to P3D4 and so FSUIPC4 to FSUIPC5, and no changes were made to the hardware at all, then everything would have worked exactly as before. That's always been one of the whole points of the FSUIPC interface -- continuity right through FS versions since FS98. Changes to the USB connections would mean the assignments have to be re-matched, for which I see John has helped sort out for you. Also, re-installs of Windows changes things too because it will generate new "GUIDs" -- the unique identity assigned by Windows to everything (all devices, all objects, even all internal textures and so on). Incidentally, I assume you are using the old version of ProSim (v1)? The latest versions of Prosim v2 do require you to assign and calibrate all flight controls in ProSim. But i have been doing this for my throttles successfully now since first using ProSim, which was then an early version 1. I've only just recently moved my flight controls (yoke, rudder, till0 to ProSim. Pete
  11. When a device is connected, FSUIPC will automatically re-scan the devices in case there are are any assignments which will now work, necessitating a regular devices scan. This is really an essential action, so it shouldn't be inhibited. The answer is to determine why you have disconnections/reconnections occurring so you can fix them. It might be a bad connection in a device, a bad USB connection, a faulty HUB, or even a problem in the USB port on the PC. You've eliminated the last by trying on a different PC To find the culprit among the others will need a process of elimination. The logs and other results John has asked for would also help. Pete
  12. Pete Dowson

    FSUICP NEWBIE

    In order to assign any controls in FSUIPC, then FSUIPC must see them! You say they do not work, but maybe you haven't assigned them anywhere? If you didn't use your FSUIPC4.INI as I said you could, then you won't have ANY assignments in FSUIPC if you haven't used the Axis tab to assign them in FSUIPC Options, which, since you don't seem to know about it, you have not. (Please look in the FSUIPC documents subfolder in the Modules folder. there you will finf DOCUMENTATION. Please read through the relevant chapters of the User guide you'll find there. I shows it all with pictures too). Really? In that case I can be of no help as I know nothing about SIOC. You would need help elsewhere. WideFs talks to FSUIPC directly. It doesn't care which version of P3D it is nor which version of FSUIPC. Provided you entered your WideFS key when you installed FSUIPC, then, without any network changes, it will work as it did with P3D3. Perhaps you'd better clarify. Does WideClient, running on the client PC, show that it is waiting for something in the title bar when P3D is running? If not, what does it say? Well, yes, you have to delete it -- otherwise Windows won't let you rename the FSUIPC4 version to the same name. I'm afraid I'm away now for over two weeks. or more questions on FSUIPC5 + WideFS John or others can help here, but for SIOC and ProSim you'll probably need to go elsewhere. Try the ProSim support forum first. Pete
  13. Pete Dowson

    FSUICP NEWBIE

    BTW I moved your post to this, the Support Forum, so it can be answered. The FAQ subforum is for long term reference material. By "working" do you mean the AddOns menu has FSUIPC listed, and that b clicking on it you get the options screen showing? If so, then that's fine. Did you use your FSUIPC4.INI file renamed as FSUIPC5.INI? If so, and you didn't re-install Windows as well, then the assignments will be the same. Does FSUIPC recognise the throttles in the Axis assignments tab? The Network settings in your Windows won't have been changed just by installing P3D4 and FSUIPC5. So what else have you changed? Yes, and you can use that with FSUIPC5 just by copying it into the P3D4 Modules folder and renaming it FSUIPC5.INI. That way you retain all your settings. I'm afraid I know nothing about SIOC. I thought ProSim had its own SIOC drivers. Where does FSUIPC or WideFS come in? No, it is a DLL, a module which runs only inside P3D4. It can't be used outside of P3D4 at all. WideFS client PCs just have WideClient.exe installed and configured to recognise the server (the P3D PC). But if that was all working with P3D3 and FSUIPC4 then it doesn't need changing. It stays as it was. The version of FSUIPC doesn't matter. I'm afraid I don't know SIOC at all, or how it uses FSUIPC. You do really need either SIOC support or, probably more appropriately, ProSim support. But as I say, provided you've not changed the Client PC, and provided you've not reinstalled Windows or changed the Network, then it should all work as it did before. The version of P3D and FSUIPC is not relevant to this. Pete
  14. Pete Dowson

    WideFs and Matlab

    It is possible, but only with some programming. FSUIPC with WideFS does this sort of thing, but then you'd need to write a program to interface to FSUIPC. If you wanted a more direct method you'd need to write a program running alongside P3D to use Simconnect to extract the data you need and send it in whatever format you are expecting. I don't think there are any features actually built into P3D in the way you imply is provided directly in X-Plane (with no add-on like XPUIPC?).Possibly with P3D you could adapt to their multi-PC network linking system. it isn't really an area I've ever invetstigated. You'd be better off asking Lockheed Martin over in their Support Forum -- https://www.prepar3d.com/. Pete
  15. Pete Dowson

    Joystick calibration

    They don't change, not until you set them using the associated button! Then they stay at those values and are saved in your settings file (FSUIPC INI) as the calibrated values to be used. Pete
  16. Pete Dowson

    Offset's 3160, 313C and 3148.

    Are you using Paul Henty's .NET DLL here? If so, I should move this into his Subforum just above. I can't really with programming his DLL. There are ways you can check that the offsets do contain what you expect. Eith use the "monitor" facility on the right-hand side of the Logging tab. just enter up to 4 offsets, select the type, and the values (up to a limited length, at least) will show in the FSUIPC LOG. You can also check any (or all) offsets by using the utility program "FSInterrogate" which you'll find in the FSUIPC SDK. Please also always state which versions you are using -- version of FS, version of FSUIPC, and, if used, version of the .NET DLL. Provide the full version numbers. Pete
  17. FSUIPC itself never tries to "control" AI. That's just a facility for external applications -- RCV4 in your case, AIseparation for others (or both of course). Pete
  18. There will no doubt be another release from John soon. He's not available today, but I worked on the problem this morning and found the bug. Turned out to be a relatively simple (read "stupid") error which only shows up when large numbers of AI controls are sent via FSUIPC. In fact this error has been there for as long as the facility has existed -- so FSUIPC4 as well as FSUIPC5. It just happened that the error only causes a crash with a certain memory arrangement which of course changes with each build. Pete
  19. I've moved your support question to the support forum so it can be answered. I'm afraid you provide no information to enable us to help you. Version of Flight Sim? Version of FSUIPC? And the FSUIPC install log, FSUIPC log and FSUIPC INI files you have found should be appended please. They contain vital information to help us see what you've done and what is happening. Pete
  20. Pete Dowson

    Make a Function Toggle LUA

    Must be the function that LVar performs in the aircraft model -- for the AP ALT adjustment. you were changing that setting and iterpreting the change for your toggle as well. My MCP is part of my PFC cockpit, and my own driver for it handles all that by program. The only rotaries i have which are outside of the cockpit are a couple of GoFlight RP48's, which have 4 rotaies each. The GoFlight firmware in the device looks after acceleration -- turn it fast and you get a different button number indication. Sothey effectively have 4 button presses each. The acceleration using a rotary is really the same as for a single button provided you remember two things: 1. The button indications you see alternate between "on" and "off" for each successive "click". So you need to handle the change not whether it is on or off. 2. The presses will arrive fast if you turn it fast. May be too fast for your aircraft gauges to keep up. You might need to start with a parameter you can easily change when testing to only act on every nth change in the 'fast' mode (i.e. when they are arriving with less than say 500 mSecs apart). With Lua it is likely that you'll miss some anyway, because only one occurrence is queued for each event registered. To handle that a bit more predictable you might want two event.button calls registered per button -- one for "when pressed" and the other for "when released". They can refer to the same function in your program of course. Pete
  21. Pete Dowson

    Joystick calibration

    Which numbers "stay the same"? The axis value being read is displays at the "IN" value, on the left. Is that "staying the same"? If so then the axis is probably not assigned to that function. Check in the Axes tab. Move your joystick and see if that sees it, and the IN numbers there change. Then look below to see what you assigned it to. Pete
  22. Pete Dowson

    Make a Function Toggle LUA

    Two things I noticed in your Lua. You define "LVarSet" several times but then use the literal name in your ipc.Lvar calls anyway -- except once. Second, are the LVars already existing in the aircraft you have loaded? They are shown by the Lvar logging? If "AB_AP_ALTSTEP exists, are you sure there isn't a matching "AB_AP_HDGSTEP"? Because I would have thought just "HDG" without the AP prefix would really be the actual current aircraft heading, not the AP dial. You can't create LVars in Lua, they are created by the code in your add-on aircraft. If all you want is a value for your use, to remember what mode you are in, you should use a Lua "GLOBAL" -- see the ipc.set and ipc.get functions. They use a global thread, parallel to your Lua thread, and shares those values to any running Lua thread. They will be remembered over each event calling your Lua functions. Pete
  23. Pete Dowson

    Make a Function Toggle LUA

    With a one button press for alternately using 1 step or 10 step, use the button flag and make it conditional. There's an example of toggling the button press action in the Advanced User's guide, thus: For every possible “normal” button (16 joysticks x 32 buttons = 512 buttons) FSUIPC maintains a “Flag” (F). Each time any button is pressed (goes from off to on) FSUIPC toggles its flag. This makes the buttons flag a sort of “latching” switch. You can test it in any parenthesised condition by preceding the condition by F, thus: N=CP(F+j2,b2) … This says the rest of this parameter is obeyed if the Flag associated with j2,b2 is set. A condition (F–j2,b2) tests for the Flag being clear. Note that the actual current state of the button j2,b2 is not relevant. All that matters is whether it last left its Flag set or clear. So for example 1=CP(F+4,2)4,2,C12345 2=CP(F-4,2)4,2,C54321 says alternately send control 12345 and 54321 each time Joy 4, button 2 gets pressed. Ah, maybe I didn't read it so deeply. Without me spending time trying to decipher the code, why doesn't the Lua tracve logging help you. The line numbers and variable values are shown. They don't help me because the Lua section you posted doesn't have enough line numbers -- the logged ones don't match. If you help me look at the part you think should "toggle" then I can maybe help. The LeoBodnar cards I use work with standar rotaries which send o press or release indication ("ground" or "live") for each click. They're the easier ones to handle. If your rotaries are of the phased type which need more decoding then I don't know whether the Bodnar microcode does the decoding or whether you have to. Assuming they are the former type, or the board does handle them okay, then obviously you can use the same method as in Triple Use to decide on the interpretation of the button on/off changes based on how fast they arrive -- slow = signle, fast = 10's. Though in the latter case you would probably discard some of the changes as on/offs will be arriving too fast for decient control. Pete
  24. Pete Dowson

    Joystick calibration

    If you mean when you click the button to register the positions, then you have the order wrong. The numbers need to increase from left to right -- it won't accept any attempt to enter a number out of order. Left and Right on the calibration screen does not always correspond to left and right positions, eg for a Yoke. The left most number is the "minimum" value, which must be less than or equal to the "centre" values and those must be less than or equal to the "maximum" value. That's why they have those labels. There is no other cause of any "beeps" in that section of the options. Please follow the numbered steps shown in the User Guide for proper calibration. Pete
  25. You are using the very first, buggy, version of FSX, released in 2006. You should really update to SP1 art least, or better SP2. i think these are still available for download. for example SP2: https://www.microsoft.com/en-us/download/details.aspx?id=8986 The Install log will be more informative for me. You'll find that in the Modules folder too. If you installed the currect SimConnect (the 60905 one or "RTM") then it should be fine. If you installed them all, just in case, then something went wrong. The error you are getting is described as meaning: Error 0x80004005 is translated as an unspecified error and is usually seen when the user cannot access Shared Folders, Drives, Virtual Machines and also when the Windows Updates fails to install. What's been changed? Do you mean you've been using FSX RTM with FSUIPC4 with no problems and have only now had this problem? Pete
×

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.