Jump to content
The simFlight Network Forums

BorisTheSpider

Members
  • Posts

    28
  • Joined

  • Last visited

BorisTheSpider's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Done. http://forum.simflight.com/topic/74745-fsx-automatically-mistrusts-modules-fsuipc-not-loaded-solution/
  2. I recently experienced a new (at least to me) FSX issue which Pete has asked me to document here. The problem was found when an updated version of FSUIPC wouldn't load into FSX even though the older one was loading fine, however the problem is actually generic and could affect any module. There is a Windows registry setting which will result in FSX automatically mistrusting new (or updated) DLLs, without prompting. If you have a DLL that just will not load, and you do not even get prompted whether to trust it or not during FSX startup, you may be experiencing this problem. If HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\State is set to a value of 0x63c00 then FSX will exhibit this behaviour. New DLLs (or updated modules) will automatically get added to the [TRUSTED] fsx.cfg with a suffix that indicates that they are untrusted and should not be loaded. In fsx.cfg, a line like: S:\fsx\Modules\FSUIPC4.dll.rooctoroqihwhtikitinolctiqihrnaqeqkbqcor=1 is the normal format to indicate a trusted module. Sometimes, the value at the end of the line is a 2 instead of a 1, I am unsure exactly when a 2 is appropriate rather than a 1, but it seems to be something to do with a 2 being associated with modules that are part of an aircraft. Mistrusted modules (modules marked not to be loaded) are indicates by a negative suffix, like: S:\fsx\Modules\FSUIPC4.dll.rooctoroqihwhtikitinolctiqihrnaqeqkbqcor=-1 The value at the end of the line could also be a -2. If you were to edit fsx.cfg, and invert these negative suffixes (just remove the minus sign) then your new or updated module would load correctly on the next start of FSX. Of course, this would just be a workaround, and would not restore the normal behaviour of FSX asking whether to trust unseen modules or not. The original MSDN documentation page relating to the possible values of HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\State and their meanings seems to no longer be available, however the default value is 0x23c00 and if you set State back to this value, the normal fsx prompting for trust behaviour will be restored. I am unsure what changed this value in my registry, but I suspect a piece of security software may be responsible. http://forum.avsim.net/topic/321790-trusted-section-weirdness/ and http://lkalamaras.blogspot.com/2007/06/was-this-for-our-own-good.html refer.
  3. Follow up, leaving the above intact for documentation - a bit more googling and I found the problem. http://forum.avsim.net/topic/321790-trusted-section-weirdness/ refers to someone who had the exact same problem - fsx not asking whether to trust modules or not, and automatically marking them as untrusted. http://lkalamaras.blogspot.com/2007/06/was-this-for-our-own-good.html has the solution, which is to change the value of HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\State back to it's default value of 0x23c00 (something??? had set it to 0x63c00 which changes some kind of trust policy in Windows, causing the problem). Maybe this will help someone else out some time - I feel rather fortunate I found the solution this quickly, as I suspect this is one of those problems that could have someone tearing their hair out for weeks.
  4. Well this is utterly bizarre. Your comment about removing the whole trusted section from fsx.cfg was what led me to a solution, but I'm as mystified now as to what is going on as I ever was before. After removing the whole trusted section, and running fsx, I got asked about absolutely nothing, despite having lots of stuff in my dll.xml as you can see above. So I looked in fsx.cfg, and found that a number of modules had been added to the [trusted] section. Among them, FSUIPC, in the line: S:\fsx\Modules\FSUIPC4.dll.rooctoroqihwhtikitinolctiqihrnaqeqkbqcor=-1 Now I'd never really thought before about what the numbers at the end of these lines mean, as of course fsx just adds them and you never need to edit them. But I figured -1 might indicate untrusted and a bit of googling seemed to confirm this, so I changed it to =1, saved the file and restarted fsx, and now fsuipc loads correctly. A fair bit of googling doesn't seem to reveal any documentation on the meaning of these numbers. After deleting the whole trusted section and letting fsx recreate it, I have entries with both -2 and -1 at the end (but none with 1 or 2). So it seems that when fsx sees a module it hasn't seen before, it's automatically marking it as untrusted. Of course I can now easily work around this by just changing the sign of the entry whenever I need to add a new module. Can anyone enlighten me on what -1/-2/1/2 mean at the end of the lines (ie. where should a 2 rather than a 1 be used). Also, perhaps someone can point me in the right direction as to why my fsx is automatically adding everything as untrusted without asking me. Perhaps I have a rare and ridiculous setting that's causing this. It may be worth mentioning that I also have Prepar3d installed - I don't think it can have anything to do with it, but it does occur to me that there is no [trusted] section in prepar3d.cfg and prepar3d seems to just trust everything by default, so is it possible that prepar3d has overwriten some dll or something so that the normal fsx behaviour of asking whether to trust modules or not has been disabled???
  5. Hello Pete, I did generate a simconnect log, and it doesn't give any indication why it won't load fsuipc.dll, here is the relevant part of the log where you can see the other modules getting loaded, but no mention of fsuipc: 0.00000 SimConnect version 10.0.61259.0 0.02451 Server: Scope=local, Protocol=Auto, Address=::1, Port=51773, MaxClients=64 0.03219 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.05451 Server: Scope=local, Protocol=IPv6, Address=::1, Port=51774, MaxClients=64 0.07887 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=51775, MaxClients=64 0.18377 Exe Launched: Path="S:\Program Files (x86)\FSForce 2\FSForce.exe" CommandLine="/FS" Version="2.6.0.4" 0.21591 Exe Launched: Path="C:\Program Files (x86)\EZCA\EZCA.exe" CommandLine="" Version="1.1.7.2" 0.23196 Exe Launched: Path="s:\Program Files (x86)\SPAD\Spad.exe" CommandLine="" Version="0.5.0.1" 0.37469 Exe Launched: Path="S:\Prepar3D\\Flight One Software\Ultimate Traffic 2\UT2Services.exe" CommandLine="" Version="2.1.0.0" 0.38057 Panels data export found and set to 20B319D8 0.38334 DLL Loaded: Path="S:\Program Files (x86)\FSForce 2\FSForce.dll" Version="2.6.0.4" 0.40081 Panels data export found and set to 20B319D8 0.44778 DLL Loaded: Path="S:\Program Files (x86)\FS Recorder for FSX\FSRecorder_FSX.dll" Version="2.1.0.0" 0.45456 Panels data export found and set to 20B319D8 0.45457 DLL Loaded: Path="Modules\rxpGnsDriver.dll" Version="1.6.0.1" 0.47013 Panels data export found and set to 20B319D8 0.53138 DLL Loaded: Path="Modules\A2A_Feel.dll" Version="<Unknown>" 0.54039 Panels data export found and set to 20B319D8 0.54256 DLL Loaded: Path="Modules\AccuFeelMenu.dll" Version="0.1.0.0" 0.55612 DLL Loaded: Path="S:\Program Files (x86)\Squawkbox\sbtrans10.dll" Version="<Unknown>" 0.56515 DLL Loaded: Path="S:\Program Files (x86)\Squawkbox\sbaicontrol10.dll" Version="<Unknown>" 0.59975 DLL Loaded: Path="S:\Program Files (x86)\Squawkbox\sbmod10.dll" Version="<Unknown>" 0.61786 DLL Loaded: Path="S:\Program Files (x86)\IVAO\IvAp v2\ivap_fsx_bootstrap.dll" Version="2.0.2.2773" > 14.12127 [191, 1]Open: Version=0x00000004 Name="TrackIR SimConnect Interface" > 14.12194 [64, 1]Open: Version=0x00000004 Name="FSForce DLL" > 14.12196 [64, 2]SubscribeToSystemEvent:EventID=0, SystemEventName="SimStart" > 14.12196 [65, 1]Open: Version=0x00000004 Name="FS Force" > 14.12198 [65, 2]RequestSystemState:RequestID=0, szState="Sim" > 14.12199 [65, 3]SubscribeToSystemEvent:EventID=0, SystemEventName="SimStart" > 14.12200 [190, 1]Open: Version=0x00000002 Name="FS Recorder" > 14.12213 [66, 1]Open: Version=0x00000004 Name="A2A Feel" Given that you can't support older versions, and that you are expecting (indeed hoping) for 4.86 and older to stop working in the near future, I really hope we can get to the bottom of this. As you said, it's as if it's not even in DLL.XML and not looked for, however I can be 100% certain the dll.xml is correctly formatted, since if I just change the module to 4.86 (without making any changes to dll.xml or anything else) it loads, but change it back to 4.90 or 4.907 and it doesn't. Is there any point in me sending you a complete simconnect log (not just the excerpt) in case I've missed something? I can do so via PM or email if you like, as it'd be rather long and I'd prefer not to clutter up the forum with it, unless that is what you'd prefer. Alternatively, I wonder if it's worth trying (if it's convenient for you to build one) one of the following a. A 4.86 dll, exactly as I have working now, but unsigned, to see if that loads. b. A 4.86 dll with the only change being that the signature checking is commented out or removed before compiling, to see if that specific change is what's causing it, or whether it could be something else. Thanks
  6. Thanks for the reply Pete. I did try deleting the trust line in fsx.cfg, and with stock (main release) 4.90 I got no request to trust the module. I also tried 4.907 from the latest download link, and again, after removing the trusted line from the fsx.cfg there is no request to trust the module when fsx starts and there is no fsuipc.log generated. I've rolled back again to 4.86, so I'm up and running for the time being. I'm pretty sure this must have something to do with the newer .dlls being unsigned, but what could be happening such that simconnect logs nothing at all about it, I'm not sure. How does 4.86 and earlier actually perform the signature check - is it all internal to the driver or does it use the windows PKI? I'm at a bit of a loss as to why 4.86 is still working if the signature has been revoked, so I'm concerned that at some point it may stop working and I won't be able to update to 4.90 and later. I looked in the certificate snap-in in the MMC and the Simflight (and GlobalSign CA) certificates show no sign of having been revoked in there, so maybe my machine hasn't downloaded the CRL (yet?)??? I note in your post about the globalsign CA compromise that you mention the CRL being updated via windows update, but I have no pending updates that could be relevant. Are you aware whether the update revoking the certificate has been pushed out via windows update yet?
  7. To follow up, I went back through a backup and found the fsuipc 4.86 dll file, so I tried that instead, and now FSX loads it OK and I get an fsuipc.log which I've pasted below. Everything seems to work OK - all I did was roll back the dll, without changing anything else. It may be worth mentioning also, that in my post above I neglected to say that when trying to fix 4.90 I had tried using the fsuipc4_loader.dll file (and changing the dll.xml reference accordingly) without success. Has anything changed between 4.86 and 4.90 in the loading code that could have caused the problem? For now, I'll just continue to use 4.86, but it would be nice to get it sorted so I don't miss out on future improvements and updates. I'm happy to troubleshoot and post/email logs etc. as necessary. ********* FSUIPC4, Version 4.86 by Pete Dowson ********* Running inside FSX on Windows 7 Module base=54C00000 User Name=REMOVED User Addr=REMOVED FSUIPC4 Key is provided WideFS7 Key is provided 10671 System time = 03/07/2013 18:41:07 10671 FLT UNC path = "R:\Users\Paul\My Documents\Flight Simulator X Files\" 10718 Trying to connect to SimConnect Acc/SP2 Oct07 ... 10733 FS UNC path = "S:\FSX\" 11108 LogOptions=00000000 00000001 11108 SIM1 Frictions access gained 11108 Wind smoothing fix is fully installed 11108 G3D.DLL fix attempt installed ok 11108 SimConnect_Open succeeded: waiting to check version okay 11108 Trying to use SimConnect Acc/SP2 Oct07 11139 VRI port 1 "com4" opened 16708 VRI FMER ("MCP Combi") detected on port com4 24695 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 24695 Initialising SimConnect data requests now 24695 FSUIPC Menu entry added 24758 R:\users\paul\My Documents\Flight Simulator X Files\Duke at Bournemouth.FLT 24758 S:\FSX\SimObjects\Airplanes\RealAir Duke B60\RealAir_Duke.AIR 28018 System time = 03/07/2013 18:41:25, Simulator time = 18:41:21 (17:41Z) 28205 Aircraft="RealAir Beech Duke N1873K Winglets Ventral" 102212 Starting everything now ... 102243 LUA.0: beginning "S:\FSX\Modules\ipcReady.lua" 102243 LUA.0: ended "S:\FSX\Modules\ipcReady.lua" 102243 LUA.1: 102243 LUA.1: [iNIT]LINDA:: Loading... 102337 LUA.1: LINDA:: Aircraft: RealAir Beech Duke N1873K Winglets 102337 LUA.1: LINDA:: Aircraft module detected: FSX Default 102399 LUA.0: LINDA:: AivlaSoft library loaded... 102399 LUA.0: LINDA:: FSX standard library loaded... 102415 LUA.0: LINDA:: IAO library loaded... 102415 LUA.0: LINDA:: RealityXP library loaded... 102431 LUA.0: LINDA:: A2A MAP library loaded... 104069 LUA.0: LINDA:: Module: FSX Default Started... 104069 LUA.0: LINDA:: Ready to go, Captain! 104069 LUA.0: LINDA:: 105800 Advanced Weather Interface Enabled
  8. I wonder if I might ask for a bit of help with a sticky problem. I tried to run FSX today after not having used it for a couple of months, and found that (registered) FSUIPC is not being loaded. No fsuipc.log file is being generated, so it never even starts to load. I have fsuipc 4.90, the DLLs are in s:\fsx\modules\ and s:\prepar3d\modules respectively. I've compared the DLL.xml files, and although I have different addons in P3D and FSX, I can confirm that the fsx version is properly formatted (I even tried copy-pasting the working p3d one into the fsx one, then removing all dlls other than fsuipc from the list). I even MD5 checksummed the dll's themselves to make sure the one in the fsx modules folder was identical to the one in the p3d modules folder, and it is. All the other addons in the FSX dll.xml file load properly. Reinstalling FSUIPC in desparation, here's an extract from the log: Checking version of FSX.EXE: ... Version 10.0.61637.0 (Need at least 10.0.60905.0) Checking compatibility with installed SimConnect: Found SimConnect build 60905 (Original) Found SimConnect build 61242 (SP1 May07) Found SimConnect build 61259 (Acc/SP2 Oct07) I also removed the section in dll.xml, so that the installer would recreate it, however it made no difference. Here's my complete dll.xml: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>FSForce DLL</Name> <Disabled>false</Disabled> <ManualLoad>false</ManualLoad> <Path>S:\Program Files (x86)\FSForce 2\FSForce.dll</Path> </Launch.Addon> <Launch.Addon> <Name>FS Recorder</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>S:\Program Files (x86)\FS Recorder for FSX\FSRecorder_FSX.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Reality XP GNS WAAS Hardware</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>Modules\rxpGnsDriver.dll</Path> </Launch.Addon> <Launch.Addon> <Name>A2A Feel</Name> <Disabled>False</Disabled> <Path>Modules\A2A_Feel.dll</Path> <DllStartName>module_init</DllStartName> <DllStopName>module_deinit</DllStopName> </Launch.Addon> <Launch.Addon> <Name>AccuFeelMenu</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>Modules\AccuFeelMenu.dll</Path> </Launch.Addon> <Launch.Addon> <Name>SquawkBox Transponder</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>S:\Program Files (x86)\Squawkbox\sbtrans10.dll</Path> </Launch.Addon> <Launch.Addon> <Name>SquawkBox AI Control</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>S:\Program Files (x86)\Squawkbox\sbaicontrol10.dll</Path> </Launch.Addon> <Launch.Addon> <Name>SquawkBox Internal Version</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>S:\Program Files (x86)\Squawkbox\sbmod10.dll</Path> </Launch.Addon> <Launch.Addon> <Name>IvAp</Name> <Disabled>False</Disabled> <Path>S:\Program Files (x86)\IVAO\IvAp v2\ivap_fsx_bootstrap.dll</Path> <Commandline></Commandline> </Launch.Addon> <Launch.Addon> <Name>FSUIPC 4</Name> <Disabled>False</Disabled> <Path>Modules\FSUIPC4.dll</Path> </Launch.Addon> </SimBase.Document> As I said above, I also did try removing everything from this apart from the fsuipc section, but that made no difference. I've also created a simconnect.ini to prompt generation of a simconnect log file, I won't post the whole thing here (for brevity), but the relevant section is: 0.00000 SimConnect version 10.0.61259.0 0.02451 Server: Scope=local, Protocol=Auto, Address=::1, Port=51773, MaxClients=64 0.03219 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.05451 Server: Scope=local, Protocol=IPv6, Address=::1, Port=51774, MaxClients=64 0.07887 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=51775, MaxClients=64 0.18377 Exe Launched: Path="S:\Program Files (x86)\FSForce 2\FSForce.exe" CommandLine="/FS" Version="2.6.0.4" 0.21591 Exe Launched: Path="C:\Program Files (x86)\EZCA\EZCA.exe" CommandLine="" Version="1.1.7.2" 0.23196 Exe Launched: Path="s:\Program Files (x86)\SPAD\Spad.exe" CommandLine="" Version="0.5.0.1" 0.37469 Exe Launched: Path="S:\Prepar3D\\Flight One Software\Ultimate Traffic 2\UT2Services.exe" CommandLine="" Version="2.1.0.0" 0.38057 Panels data export found and set to 20B319D8 0.38334 DLL Loaded: Path="S:\Program Files (x86)\FSForce 2\FSForce.dll" Version="2.6.0.4" 0.40081 Panels data export found and set to 20B319D8 0.44778 DLL Loaded: Path="S:\Program Files (x86)\FS Recorder for FSX\FSRecorder_FSX.dll" Version="2.1.0.0" 0.45456 Panels data export found and set to 20B319D8 0.45457 DLL Loaded: Path="Modules\rxpGnsDriver.dll" Version="1.6.0.1" 0.47013 Panels data export found and set to 20B319D8 0.53138 DLL Loaded: Path="Modules\A2A_Feel.dll" Version="<Unknown>" 0.54039 Panels data export found and set to 20B319D8 0.54256 DLL Loaded: Path="Modules\AccuFeelMenu.dll" Version="0.1.0.0" 0.55612 DLL Loaded: Path="S:\Program Files (x86)\Squawkbox\sbtrans10.dll" Version="<Unknown>" 0.56515 DLL Loaded: Path="S:\Program Files (x86)\Squawkbox\sbaicontrol10.dll" Version="<Unknown>" 0.59975 DLL Loaded: Path="S:\Program Files (x86)\Squawkbox\sbmod10.dll" Version="<Unknown>" 0.61786 DLL Loaded: Path="S:\Program Files (x86)\IVAO\IvAp v2\ivap_fsx_bootstrap.dll" Version="2.0.2.2773" > 14.12127 [191, 1]Open: Version=0x00000004 Name="TrackIR SimConnect Interface" > 14.12194 [64, 1]Open: Version=0x00000004 Name="FSForce DLL" > 14.12196 [64, 2]SubscribeToSystemEvent:EventID=0, SystemEventName="SimStart" > 14.12196 [65, 1]Open: Version=0x00000004 Name="FS Force" > 14.12198 [65, 2]RequestSystemState:RequestID=0, szState="Sim" > 14.12199 [65, 3]SubscribeToSystemEvent:EventID=0, SystemEventName="SimStart" > 14.12200 [190, 1]Open: Version=0x00000002 Name="FS Recorder" > 14.12213 [66, 1]Open: Version=0x00000004 Name="A2A Feel" Which doesn't seem to give any clues as to why fsuipc4.dll is not being loaded. I normally start fsx through a batch file, but to eliminate that as an issue I've been starting it directly from s:\fsx\fsx.exe for testing. I have double checked it's set to run as administrator, not that it should make any difference. I also tried removing fsuipc.ini from the modules folder, in-case something was wrong with it causing fsuipc not to start (although I'd expect an fsuipc.log to be created if that were the case) - in any event, it didn't help. I remember having a problem with prepar3d hanging on startup with certain nvidia drivers some time back, which seemed to be related to a problem that the nvidia drivers caused in the loading sequence for fsuipc. Accordingly, I've tried rolling right back to 301.42 which also made no difference. In the spirit of flailing about aimlessly, changing anything to see if it would help, I also disabled my antivirus and firewall - no dice. I'm completely stumped here, so if anyone can help point me in the right direction about what to try next, I'd be very grateful.
  9. Pete, thanks for the reply. I see what you mean. I may contact the author of SPAD and see if they can do something, since that already does the kind of thing I'm referring to (for example, the gear lever on my saitek switch panel is seen as two buttons on joystick 64, which I then assign through fsuipc) .
  10. Hi, I am aware of the joystick letter assignment functionality in FSUIPC to ensure persistence of joystick identification across replugs and changes of the windows joystick number. I have a bit of a feature request, or perhaps a request for help with figuring out how to do something without FSUIPC if it's possible. I want to try using a saitek trim wheel with fsforce. Fsforce uses the joystick number to identify an axis, if that's how you're going to trim it, and I'm concerned that the joystick number will inevitably end up changing regularly and will be a pain. What I'm wondering is if it would be possible to add a feature to fsuipc where it maps a joystick to a new, virtual joystick, the number of which does not change. So I could configure the trim wheel, which might really be joystick number 6 at the time of configuring, then it would be identified by GUID and mapped to joystick 206 on a permanent basis. I could then point fsforce to joystick 206, and not worry about the number changing. It also occurs to me that if this were possible in fsuipc, it might be necessary to restart fsforce after fsuipc had loaded, since if it loaded before the virtual joystick existed (it loads from exe.xml) it would probably just exit or fail to connect properly once the virtual joystick became available. Perhaps there's some way I could start fsforce later, via fsuipc? I have contacted the developer of fsforce, but I'm not really expecting he'll be able to help, since it seems to me that asking him to add the ability to identify the trim wheel by GUID is probably more onerous than asking Pete if it's possible to add this to fsuipc where most of the code for GUID->JoyLetter assignments already exists. Is there some other, existing way to achieve this that I may have overlooked?
  11. Andy, Thanks for the reply. I actually wonder if the limitation you refer to would be no issue for me - you see fsforce intercepts the trim commands before they ever get to FSX (or P3D). What it does is, it passes them through to FSX when you're on the ground (so you can set trim for takeoff) but as soon as you are airborne, all the trim now does is move the neutral point of the force feedback stick, the trim-wheel in the VC doesn't move at all as you trim with fsforce - because you're actually just putting the elevator in a new "no force required" position, just like you do in a light aircraft, so if the FSX autopilot gives the airplane back to you with the internal fsx trim a long way from where it was when the autopilot was engaged, it won't matter, because the next time the trimwheel is moved (or jitters) nothing will have gone out of sync. I suspect though this won't be much help to people with the problem you referred to, since most of them are probably using a spring-centred yoke rather than a force feedback stick. Now when it comes to jets with stab trim, fsforce isn't quite the ticket, and a bit of an adaptation is required, but in rather simplified terms the fsx internal trim system actually works as a reasonable approximation, so I just use that. Hopefully some time fsforce will be expanded to handle stab trim more accurately.
  12. EDIT: Pete, sorry to be a pain. Please ignore the post above - I discovered that fsforce can trim directly from an axis, so I don't need to use FSUIPC at all. Still interested to know if anyone has one and can tell me if it has end stops (I suspect it does) and also especially if anyone is using one with fsforce and has any comments.
  13. I am consider changing my setup, and could do with some advice. Currently, I am using a saitek multi panel with a trim wheel on it for pitch trim. I use FSForce, which replicates a real trim system (in other words, it changes the neutral point of a force feedback joystick, so you trim off the force and the stick settles in the new position). What I do currently is have SPAD generate keypresses for trim wheel movement on the panel, and those keypresses are picked up by FSForce. I'm considering getting rid of the multi panel, and buying the Saitek trim wheel instead, but I don't believe it's supported by SPAD, so I'd need some way to get it to generate keypresses. Can I do that in FSUIPC? PS. Can anyone also tell me if the saitek wheel has end-stops, or does it continuously rotate?
  14. Hi, Fresh install of Windows here, and fresh Prepar3D. I have successfully run Prepar3d in surround to check it was properly set up, I then closed it and the first addon I have attempted to install in FSUIPC 4.853 - I have exactly the same problem - it hangs at the splash screen following the FSUIPC installation. Please can anyone point me to anywhere that someone has mentioned specific nvidia drivers which worked for them? I have searched the forum in detail, but have been unable to find any post where anyone got it working other than the one NWittje mentioned where it started working without anything having been knowingly changed, and that post did not reference any version numbers. I am currently running 304.79 Thanks EDIT: Sorry, I just found a post refering to 301.42 working through a google search rather than through the forum. I will try that now and report back. EDIT 2: Again, sorry for posting too soon. I have indeed got it working in 301.42, however, this is a considerable regression since the 306.x WHQL and their beta versions introduced windowed 3d vision in SLI, which I wanted to use with Prepar3d. At least it's working in 2D, and in full screen 3D. NWittje - please can you report the problem to nVidia. I am about to do the same. I'd appreciate it if anyone else running surround can try and replicate the problem with the latest drivers then report it also so we can get this fixed.
  15. Ah, there we go. I suspected it might be something I was doing wrong. Thanks, I'll take a look later to see the "delete this entry" part and bear that in mind for future.
×
×
  • 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.