Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. If you have a real serial port (the 9-pin D socket) on your PC then use that. It will be more reliable. The USB-serial adapters are for modern PCs which no longer have serial ports. I have tried the cheaper such adapters and found them to be less than reliable, and I eventually changed to a serial card fitted inside the PC. BrainBoxes make good, reliable PCI and PCI-Express cards with one or two serial ports. I've been using those for years with no trouble whatsoever. But first, before spending any more money, make sure the hardware is capable of use with FS. It won't be if it isn't using the standard PFC protocol which my DLL supports. You will need to determine the actual COM port number to which you connect, and maybe also the speed the connection is set to in the hardware (9600 or 19200). Regards Pete
  2. Glad you find them useful. Regards Pete
  3. Does an FSUIPC4.LOG file get produced? If so show it to me. If not, then it is still the SimConnect trust bug which is occurring. Once FSX records that FSUIPC is trusted it will be okay. But apparently, on some systems, it takes some persistence. Please see the FAQ subforum thread entitled FSX fails to run after FSUIPC4 first installed . BTW, Microsoft were aware of this bug long before they stopped FSX development. In fact it was much worse in the original release. They managed to reduce the risk of it occurring quite substantailly by the time SP2 and Acceleration was released, but it seems to occur on a few folks' systems very persistently. No one's ever got to the bottm of it. I have FSX installed on six completely different systems here and have never even had it occur once, let alone persistently. Weird. Regards Pete
  4. How are you expecting the computer to recognise it? If it is a serial port device, like all the older PFC units, it needs a driver. FSUIPC is not a hardware driver! Serial port devices have no standard means of identifying themselves, unlike USB -- one of the reasons USB is replacing them. If the devices use the PFC protocol then you need PFCFSX.DLL installed. See the Download Links subforum, or the www.schiratti.com/dowson web page. However, if it was al made explicitly for OnTop then it may not use this protocol at all, but a proprietary one for that specific product, in which case you've got no chance with FSX unless PFC can offer you some conversion. Regards Pete
  5. By answering "No" you are telling it not to run those programs, that's why they don't run. What if you said "Yes"? It is starting to sound like a corrupted installation of FSX. Don't "repair" FSX, but try an uninstall and reinstall of the FSX SP2 update, or Acceleration (whichever it is you have). Pete
  6. Thanks, Andy ... you beat me to it! Pete
  7. No idea, though if this is with a prop aircraft I would think there'd be tiny accelerations in pitch due to torque and prop backwash. You could probably eliminate them by reducing the aircraft realism settings to zero. Pete
  8. The log looks okay, except that it is full of axis readings because you have Axis logging enabled -- makes the file bigger than in need be -- and you didn't close FS before getting the log, which is a shame because extra information is provided at the end. So I'm 99% sure your FSUIPC is okay. Pete
  9. Really, questions about the PMDG SDK should be directed to the PMDG support forum. I'll help this once, but I'm not even a PMDG user so I'm certainly the wrong person. Anyway, all you need to do is add 534 to the value defined for "THIRD_PARTY_EVENT_ID_MIN", which you can easily find at the top of the complete controls list in the PMDG SDK document ("PMDG_NGX_SDK.h") which you must have if you've installed the latest NGX update! It is defined in this line: #define THIRD_PARTY_EVENT_ID_MIN 0x00011000 // equals to 69632 So, if you add 534 to 69632 and get 70166 (as you should), then that is the number you enter as your "<custom control>" value in the FSUIPC assignment of that name. You should really have a look at the PMDG SDK. I think you have to enable its actions too, in an INI someplace. Regards Pete
  10. It looks like something you installed before these things corrupted the DLL.XML file. That should be easy to sort out. You said: but you evidently did not fix the DLL.XML because you go on: All of which merely shows that the DLL.XML is in a mess. All those PMDG DLLs are loaded in the DLL.XML file. No need for that, it is okay. Just paste in your DLL.XML file and I can fix it for you. FSX is VERY fussy about XML files. It is possible you edited it with the wrong sort of editor. Only ever use either a proper XML editor, or something like NotePad. Never WordPad or any sort of Word Processor. Regards Pete
  11. Ah. That fix was in the version I released this afternoon -- 4.842 or 3.999u. Regards Pete
  12. What EXACTLY does the error say? Is an FSUIPC4.LOG file produced when this happens? If so, show me it. If not, then FSUIPC4 is not even started, it is an FSX problem. Does the Windows error log show any details? If so show them to me. There is no possible link. It is either a bug in FSX / SimConnect, or in the nVidia driver. The only difference FSUIPC being loaded is making is in the timing of events. If there is no new FSUIPC4.LOG file made when it fails, then FSUIPC4 is not even starting, so there's nothing at all I can possibly do. So, if there's no new log, try different drivers. If there is a log, show me it and the details of the Windows error log report. Regards Pete
  13. This problem cannot be anything to do with FSUIPC. You have some video driver problem, or simply a configuration error. Try deleting your FSX.CFG file and reconfiguring it. Please use the Support Forum for any future support requests. This is not the place. Thank you, Pete
  14. I've taken a look at the code (it is quite old now and not easily remembered!), and I've found a bug which will only affect process names which contain extra '.' characters, as in: AivlaSoft.Efb.DataProvider.exe I should really be looking for the last '.', the one before the "exe", so I will fix that. BUT the result of this bug is that this sequence: RunIf5=READY,"L:\Microsoft Flight Simulator X\AivlaSoft\EFB\AivlaSoft.Efb.DataProvider.exe" RunIf6=READY,CLOSE,"L:\Microsoft Flight Simulator X\AivlaSoft\EFB\AivlaSoft.Efb.DisplayUnit.exe" will start DataProvider, but not DisplayUnit because a process which looks like "Aivlasoft" is already running. It's the action of the "If" when FSUIPC detects the process already running which would cause exactly the problem you reported. The other way round, with DisplayUnit first, will always work for DisplayUnit unless DisplayProvider is running, and vice versa. So, i suspect you misinterpreted the reults of your tests you did when you said: Certainly using "Run" not "RunIf" should start it, or leave a message as to why not. Can you please re-check that, because if this is really true there's sdomething fundamentally different between your system and mine. Maybe you were misreading which had started? If the DisplayUnit one is running and you have a RunIf for the Provider, then the latter wouldn't have run. I will fix the bug I found, but i need to to clarify what you said, because if it is really true what you said, literally, then we have problem which is going to be very difficult and long-winded to investigate, as the paths for normal Run parameters are very simple. Regards Pete
  15. No, no way. Anyway, if there was any problem in starting the program the log would log the details with the Windows error number. For example, I've just copied and pasted your lines into my INI file and the log shows: 266422 FSUIPC couldn't run: "L:\Microsoft Flight Simulator X\FSMap\FSMap.exe" [Error=267] 266422 FSUIPC couldn't run: "L:\Microsoft Flight Simulator X\rcv4x\rcv4.exe" [Error=267] 266437 FSUIPC couldn't run: "L:\Microsoft Flight Simulator X\HiFi\AS2012\AS2012_Exec.exe" [Error=267] 266437 FSUIPC couldn't run: "L:\Microsoft Flight Simulator X\GoFlight\GoFlight PMDG Interface.exe" [Error=267] 266437 FSUIPC couldn't run: "L:\Microsoft Flight Simulator X\AivlaSoft\EFB\AivlaSoft.Efb.DataProvider.exe" [Error=267] 266453 FSUIPC couldn't run: "L:\Microsoft Flight Simulator X\AivlaSoft\EFB\AivlaSoft.Efb.DisplayUnit.exe" [Error=267] Error 267 = directory name invalid (naturally, as i have no FSX on L:). One essential piece of information you didn't supply is the FSUIPC version number. I always need to know that. But if you aren't using the current version , 4.84, I suggest that you update and try again, just in case. The fact that it isn't even mentioned is the log can only mean that your line 6= is not even being read. But you said it doesn't load with any line number? Not even if you put it first, 1= ? Or on its own? Regards Pete
  16. I don't know FMGS. I assume it does actually use FSUIPC? If the FSUIPC entry is in the Modules menu, then it is installed and running. If something cannot connect to it then it can only be one of three reasons: 1. You are running FS9 "as administrator" but not the client application, or vice versa. Programs running at different privilege levels cannot talk to each other using shared memory. 2. You have an invalid registration for FSUIPC, or the computer's date precedes your purchase date. 3. There is something missing or a bug in the program you are running which prevents it interfacing. Maybe it needs access to other data first. If you want more help I need to see the FSUIPC.LOG file, which you will find in the FS9 modules folder. Paste it into a message. I don't think FSInn uses FSUIPC -- it has its own interface module called FSCopilot, doesn't it? On your questions: FSUIPC can actually be connected to by correctly written applications almost as soon as it is loaded by FS9 -- long before you get to flight mode. When in flight mode the only proof you need that FSUIPC is running is that its menu is there and operative. Same answer. FSUIPC doesn't seek out and talk to programs, it merely responds. I've not idea about anything related to FMGS. I've never heard of it. Sorry. No idea, sorry. This is a question for FMGS. I don't know what they need to make it work. Regards Pete
  17. Hmm. I don't know the Lua file you refer to, and I don't really know why it would need a Lua plug-in when all the functions you need to carry out can be assigned directly to the CDU buttons, using the numerical custom control codes definedby the PMDG NGX SDK document. Why would you make it more complicated than simple assignment? Regards Pete
  18. Good. And today I released an update fixing that bug you reported. ;-) Pete
  19. I'm afraid I'm still not much more informed. Which version of P3D? If not 1.3, update please. When does P3d "not respond"? What is showing or not showing at the time? Is it still running but stuck, or crashed? Are there any entries for it in the Windows application error logs? Is an FSUIPC4.LOG file produced or not? If so, show me. If not it is simply the trust bug in SimConnect and you need to be persistent. FSUIPC can't do anything differently at that stage as it isn't even running. There's not been a single case of that that hasn't been solved by persistence. And once it clicks, it stays clicked. These questions should be asked in the Support Forum, by the way, as i asked. Pete
  20. It should certainly be. are you changing the parameter BEFORE running FS? It won't change whilst FS is running. Check the parameter in the INI to be sure you've changed it, THEN run FS. The value FSUIPC is using is read from there. Just as a test, to be sure you are not just misjudging the dstances a little, try a much larger radius, say 10 -- and also increase the vertical difference. a 500 foot difference might be noticeable for something 1 nm away, but less so for 2 and so on. Try 1000 feet. Obviously if these aircraft are on the same approach as you they are descending, like you, and will be higher the further behind you they are. Let me know if increasing both factors doesn't seem to delete more aircraft. I'm using FSX and can't easily test with FS9 these days, but the code is the same in both FSUIPC3 and FSUIPC4. Regards Pete
  21. The FS force feedback feature is an output via DirectX for force-freedback drivers and devices. It will be determining what it sends by using all the usual velocities and accelerations, which are available in offsets. Just search on the word "acceleration". Pete
  22. No, not at all. You must be reading something in my replies which is not there. You need to increase the ZapAirRange parameter. The acceptance angle is not relevant in Cylinder mode -- for that you must delete the ZapCylinderAltDiff parameter so that FSUIPC reverts to its normal "target shooting" in front of your aircraft. In cylinder mode the defining factors are the range (=diameter of the cylinder) and the alltitude difference (=half cylinder height, centred at the aircraft in all three dimensions. With those parameters. Are you saying you think it does not work? It always has here! Er, if it isn't a conflict with you I don't see the problem. You think it better to Zap an aircraft rather than see a Go Around? How odd. You could also investigate programs like AISmooth and AISeparation which adjust AI positions rather than murder them out of hand. i don't see how it is ambiguous. You seem to be mixing up the two modes. The cylinder mode is not the "shoot the guy in front" mode! But as it says, the ranges still apply. BTW, you still actually have to use the Zap control to do the zapping. You do realize that, I hope? FSUIPC doesn't operate a "auto-kill anything in range" policy! ;-) Pete
  23. Sorry I've no idea what you are talking about. What does "it does not respond" mean? What is "it"? And when doesn't "it" respond, and to what doesn't it respond? More information is needed, including important things like version numbers -- Prepar3D and FSUIPC. Please use the Support Forum, though, not here. Pete
  24. VRInsight buttons are actually working as toggles which switch on and off on alternate presses, not simple on/off buttons, so you need to assign the action you want to both 'press' and 'release' in FSUIPC. I'm afraid I've no idea what you mean with your Lua questions. Lua is a programming language used in FSUIPC for plug-ins. There are no "Lua codes" associated with any aircraft or anything else for that matter. The term makes no sense. I thought everything on the LevelD 767 was catered for by Nico Kaan's interface program? Regards 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.