Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Did you first check that the correct SCENERY.CFG file was being read? It is identified in the first few lnes. That is the default airport and will naturally come first. You now need to search further in the file for the add-on airport entry. Search for "Airport 65S" again. Just showing the first occurrence doesn't tell us anything about what is happening. Okay, that's good. If the ORBX one contains a correct AFD BGL then it should override the default perfectly well. No no! NEVER place any of the defaults on top of add-ons. And what you say makes no sense to me I'm afraid. It simply isn't right. If an addon airport definition is replacing earlier (lower priority) defined airports, like defaults or whatever, then unless the replacements are genuinely identical it has to include certain "Delete" codes to remove the earlier entries and avoid duplicates. As an example, here's the deletions for EGLC included in an add-on for London City airport, as logged in the RUNWAYS.TXT file: Deletions check for Airport EGLC: Delete all taxiways! Delete all runways and starts! COM: Delete all frequencies! Of course if the defaults for any of these are still okay, the add-on simply doesn't delete them nor redefine them so the originals stay intact. Well, MakeRunways has now been in successful use by many applications and with many FS versions since way back in FS2000 days and whilst there have been changes along the way they have mainly been to try to deal with some odd practices by scenery designers. If you think it is not doing with ORBX sceneries (of which I have none) what it should be doing I need more information and probably one or more of the BGLs which are causing the problems so I can see what odd tricks they are doing which aren't catered for. If you cannot figure it out from the Runways.txt log file (and it seems you've not looked far enough yet), by all means ZIP that file and email it to me along with one or two of the affected AFD BGLs (as idenitfied for the airports in question in the log file), and tell me the relevant airport IDs. Then I can check it here with the actual data. petedowson@btconnect.com. Regards Pete
  2. 64-bit systems are in the majority now. I personally don't know any users still using a 32-bit version of Windows. I have certainly heard of device problems with Windows 8. I'm staying well away from that. Windows 7 64-bit is very good. And in any case there's no difference which should affect anything near the joystick button and axis facilities between versions 4.90 and 4.91. The only differences are very minor and concerned with other things altogether. Regards Pete
  3. FSUIPC itself does not provide any display capabilities. It cannot because each type of display hardware is unique and needs specific programming, unlike buttons and axes for which there's a standard Microsoft-defined interface. I don't know how you've connected your home-made fire panel, but presumably you know how to program it if you made it? The Lua plug-ins library collection does have facilities for programming GoFlight hardware displays (in the gfd library), and more general USB "HID" devices (in the com library. In fact the com library could be used to program any serial port device, or USB device masquerading as a serial port device. But only you know your hardware. Regards Pete
  4. MakeRunways processes the scenery layers according to the active SCENERY.CFG file, which will be this one (if Windows is on the C: drive): C:\ProgramData\Lockheed Martin\Prepar3D\SCENERY.CFG You can see exactly what files it gets what data from by examining the Runways.TXT file, which will be in the main Prepar3D folder where you should have placed MakeRunways.EXE to run it. Provided the addon airports are enabled and follow (i.e. have a higher LAYER= number than) the defaults, their data should override the data from the defaults. sometimes you get both when the later layer doesn't inclued the correct "Deletes". you say you have disabled the default airport, but to do that you'd actually either need to edit one of the default P3D BGLs or rename it altogether. The default airport BGLs each contain many airports, so that is not usually done and in't needed at all for any add-on airports I know of. I suggest you check the Runways.TXT file because that explains everything being processed, in the order it is processed thanks to the SCENERY.CFG file. Pete
  5. Odd then that my Saitek throttle quadrant works fine and i've never installed any Saitek software. Also the OP has no problem with FSUIPC 4.90. It makes no sense. Maybe installing the drivers will make some registry changes that may help, but i still wouldn't understand why that could make any operational difference FSUIPC 4.90 and 4.91. Thanks for trying to help, though. Let's see what happens next. Pete
  6. Okay. After that, please download FSUIPC4913c and test again, same things to do. The log will not be so big. I've removed the last lot of logging which told me nothing, and simply added error reporting for every single DirectInput call I'm using. It's a sort of last gasp. I've looked and looked and can think of nothing further to check. Regards Pete
  7. How would it be an FSUIPC problem? If you are not calibrating the thorttles in FSUIPC then how does it come into this? Note that I am pretty sure there is a solution using Lua plugins to set the throttles directly. I'm pretty sure that works judging by other users. Have you checked the User Contributions subforum at all? There are quite a few threads relevant to the Aerosoft Airbus. Try this one in particular: http://forum.simflight.com/topic/65720-aerosoft-airbusx-commands-throttle-upd-16th-sept/ The problem with FS add-ons is that every "clever" developer has his own idea about how to do things "properly" and perverts the standard FS controls to suit that aim. FSUIPC does have a lot of options to try to cope with them all, but in the end it is impossible. The addition of the Lua plug-in facilities was the only answer, but then it is up to others to find out how to fix things in whatever way it can be done. I can provide the tools, and have done, but i cannot possibly provide the solutions for every different add-on. Please always check the Subforums on this site. You'll find lots of useful stuff there. Maybe when you do solve it you can go back to the Aerosoft place and tell them so they can provide the correct advice in future? Regards Pete
  8. They can't both run -- FSUIPC detects this. And in any case even if i allowed two to run together, they would both be able to read joysticks because they are one of those resources which multiple users can access all the time. same applies to any USB connections. Only COM and LPT ports are exclusive. He has 4.90 saved from a previous install, that's all. Regards Pete
  9. Yes, that's fine. You might want to watch out for version 4.92 which fixes some things. i'll be releasing it this coming weekend, I hope. Regards Pete
  10. That's why i referred you to that FAQ thread some 4 messages back, if you recall. Seems the change in timing gets over a clash with one of the other DLLs you are loading. Pete
  11. Hmm. That wasn't much use. As i suggested, it was merely the same stuff repeated over and over. Did you actually press any buttons during that session, especialy in the Button assignment options tab? If you did then they are simply not being seen at all. The log clearly shows that FSUIPC is doing the right things, it is reading all of the devices it can and never gets any changes back from them. If you didn't press any buttons then the test was a waste of time, so I have to assume you did. Why did you not do the same for Axis assignments -- at least I can't see any trace if you did? Could you do the same using 4.90 please, i.e. with the same INI file and logging. Then show me the log. I'm finding it very hard to believe what appears to be hapening, because apart from the extra logging I've been adding there's absolutely no difference in any of this part of FSUIPC which could explain it. I'll try for a bit longer, but I am running out of ideas. Others seem fine. There's nothing unique about Saitek joysticks. If 4.91 couldn't read any joysticks, any axes, there's be a lot of support reports coming in about it, and my own system would be unusable. It makes no sense at all. There's something unique about your system, but I can't see how 4.90 vs 4.91 can operate differently on it.. :sad: Pete
  12. Oh dear. There are instructions in the FSUIPC Installation document for rectifying the stupid default settings in Explorer -- see the "ADDENDUM: IDENTIFYING FILES IN WINDOWS EXPLORER" section at the end. The document is only 4 pages long, it shouldn't have been hard to read it all! There's also a section on this in the FSUIPC4 User Guide, "Finding and Editing files relating to FSUIPC and WideFS". It's on Page 7 usually. Yes, but ZIP it first please. I expect most of it is repetition so you could simply extract unique bits, but never mind. ZIP it and send to petedowson@btconnect.com. Pete
  13. It would have been more precise if you had shown me the actual error message. I had to extract your code, save it as a Lua, and try loading it to find the actual line. The error message is: *** LUA Error: E:\FSX\Modules\GFMCP.lua:50: unexpected symbol near '==' In other words, Line 50, not the line 46 you quote! The line in question is therefore: else ipc.readUD("07DC") == 1 and ("07E42") == 0 then which has a meaningless statement between the else and the then, with several errors. Looks like you might have omitted an "if" and an "ipc.readUD" and inserted an extra character in "07E42" !!! And I think you've repeated this further down. I do not provide a code debugging or checking service, sorry. Please use the tools available. Once you get the syntax correct throughout, use the FSUIPC built-in tracing facilty to find execution errors (see the Logging page). Pete
  14. The same crash, in DINPUT? With that parameter in place WideClient itself isn't using DINPUT -- unless you have some Lua programs running which do so. Pete
  15. Something you are running is really clobbering FSX performance good and proper, and it looks like it gets progressively worse over time. Even at the start an average frame rate of around 9 isn't really flyable. What then happens, after 2 hours, is that gradually even Simconnect can't provide data to those programs (like FSUIPC) which need it. FSUIPC manfully tries and succeeds in restarting the connection many times until after 6 hours the situation is so bad that even the initial Open call never gets a response. You'll need to work out what add-ons you are using are doing this. The gradual effect slowing down suggests something with a memory or other resource leak. 6 hours is much longer than any single flight I'd like to do, but I have had successive flights in the same session getting on for 3-4 hours will no sign of slowing down or other such problems. Regards Pete
  16. You posted your support question from the FAQ subforum. Please always post support questions to the Support Forum! The cutoff/idle levers do not operate the throttle! The throttles in an aircraft are separate levers. You need to pull your throttles back to the idle postion! The FSX fuel levers operate the MIXTURE control as you have said, so you must realise that! If you want the fuel levers to also reduce the throttle to idle you need to add the command to do that too -- i.e. "throttleN cut". You would have to edit the FSUIPC4.INI file to add more commands to the same buttons. Regards Pete
  17. Where did you get that illegal Registration from? Pete
  18. That is NOT the LOG file! It is the INI file, the one with your settings!!! The log file has file type ".LOG"! The point about going to the assignments tabs and at least pressing some buttons and moving some axes was to get some extra logging! Pete
  19. You appear to be using FSUIPC with an invalid KEY. Even your "User Address" seems very odd. That's not an email address! I suggest you delete the FSUIPC.KEY file from the Modules folder. Then FSUIPC can provide its normal free application interface service. Pete
  20. It will be right next to the INI file and the DLL, in the Modules folder. you found one, why not the other? Pete
  21. Yes, this is what i was thinking. It might certainly apply to the radio, switch and multipanels, but I have had the yoke and i still have a throttle quadrant from Saitek, and i never had anything installed for them for FSUIPC to use them. Also he has said it works with 4.90, which is very very odd because there's no change in any way related to joysticks between 4.90 and 4.91 I'm assuming there's something odd going on somewhere and adding lots more logging is the only way i have of narrowing it down. Unfortunately the process seems to have stalled since a few days ago. Regards Pete
  22. If you really do mean 3.99 and not 3.999z5 then you are out of date. Please update for continued support. The file you pasted is the FSUIPC.INI file containing your settings, not the Log file. Regards Pete
  23. Please now download FSUIPC4913b.zip and test assigning buttons in that, with those logging options still in place. There should be LOTS of logging, but only whilst you are in the Buttons or Axes options tabs. (This version is no different apart from the extra logging). Pete
  24. Okay. I followed that up and went through the code carefully. I think I've found a place where a thread deadlock might occur, mainly because the modification i talk about above doesn't go far enough. If i'm right this affects FSUIPC3 too. Could you download version 4.913b from this link and let me know if it fixes it, please? FSUIPC4913b.zip Thanks, Pete
  25. One more thing to try. Download FSUIPC 4.90 from this link and try that. If this fixes it then it narrows it down considerably because there are few changes from 4.90 to 4.91. FSUIPC490.zip The change i'm think of is this: "Fixed a rare but still possible crash within the Lua kill/reload sequence when a plug-in is repetitively executed instead of using the Event system or loop." though at present I can't think what you might be running which would do this. It may be related to the number of Lua plug-ins LINDA runs. Do you know? I'm not familiar with LINDA at all I'm afraid. If you show me the FSUIPC4 INI file at least I can see what Lua files FSUIPC4 can see in your Modules folder. However, there could be others in other folders run directly from LINDA or one or more of the other Lua files. 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.