Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Do you really mean the "no reverse" checkbox on the left? Not surprising, as Windows automatically scales them all to -16k to +16k. Only "RAW" mode reads the true values. Don't forget to try assigning to the Aaxis throttleX set controls, as I suggested. Pete
  2. As Thomas says, you aren't providing emough information, but whatever it is it is clearly related to the way the CRJ is written. Are you assigning throttles in FSUIPC, and calibrating? Are you calibrating with reverse zones? It is possible that the CRJ gauge code is intercepting the throttles and assuming a -16k to +16k all for forward thrust, which is what it would get from default assignments. When calibrating with reverse you are saying -16k to 0 is reverse, so only 0-16k is forward. However, theoretically that would give you the upper half of the throttle range, 50% to 100% Anyway, as well as what Thomas suggests, try 1. not calibrating in FSUIPC, and/or 2. assigning to the regular FS throttle controls (axis throttleN set) instead of "direct to FSUIC calibration". Pete
  3. So you are restarting the sim, so LINDA starts agan too. So everything is the same as before, but no crash? Something's not making sense, if your AppCrash is consistent after 45 -90mins as you say! Whay am i misunderstanding? As I said, there's no change to Lua between 5.103j and 5.11. What else have you changed? Pete
  4. Looks like something to do with LINDA. When you say What exactly is the difference -- what is "my own LUA script"? An alternative to LINDA? The crash location is deep inside the Lua interpreter, which is an area completely alien to me. The interpreter is just the standard one from lua.org wedged into FSUIPC. I'd need the location of the error narrowed to the actual Lua function being used at the time, something I think only LINDA support can do, unless you can enable Lua debug/Trace in the FSUIPC Logging options and tolerate the huge log you'd get. Then I'd only need the part of the log leading to the crash. Nothing in Lua has been changed for 5.11 (it is tthe same as in the last interim update being made for LINDA, version FSUIPC 5.103g). Did you jump direct from 5.103 to 5.11, with no interim updates? That would surprise me as Scott and I sorted out a number of LINDA problems with the 64-bit Lua in those. Or it may be that your problem has always been there, but has never been serious enough to cause a crash. Those types of changes can occur just with things moving around a bit on re-compiling after totally unrelated changes. Places which were previously innocuous become inaccesible or dangerous. I accept it is likely an FSUIPC problem, but I need the Lua side to be narrowed down for me. Can you report with all the details to LINDA support. I'll see if I can also get Scott to look at this thrread. To that end I'll edit the title to refer to LINDA. Okay? Pete
  5. Hmm. You are right! That's odd. It should be in the "Useful Additional Programs" thread along with the 32-bit versions. It is definitely uploaded, and I did edit thst thread, but something must have gone wrong with that. Sorry. I'll fix that immediately, but meanwhile here's a link to a freshly Zipped copy, for you to download it directly: GFDevDLL64.zip Pete
  6. As Thomas says, it is available in the Download Links subforum here. But I'll be checking with GoFlght themselves before the next release of FSUIPC Installer, because in the past their own installers have installed GFDev.DLL (the 32-bit version) already, so you didn't really need to download anything at all as FSUIPC should find it as before. Really the version I have is a "Beta" they sent to me for testing. It worked okay so I used it. Maybe their installers do now install it, but it's in a different folder? Perhaps you could, please, do a search of your GoFlight folders? They used to install the 32-bit version (GFDev.DLL) in the Install folder for GFConfig.exe. Let me know if you find it and where so I can fix my search. If it isn't installed by their own installers I'll ask them if it's okay for me to include it in mine, so I can place it in the FSUIPC Documents folder for easier access. After all it is their software. I did ask permission to host it here for download. Pete
  7. Thank you. Yes, it definitely looks likeanother omission in the fixes L-M are supposed to have done to rectifysome of the mess converting to Unicode made. I'll use your screenshots and my coding in a full report to L-M ready for them to read on Monday, and will expect a fix in a forthcoming P3Dv4 update. Pete
  8. I can't enlarge the images enough to make out what the display shows! If you or I are going to report this inconsistency to L-M we'll need something rather more readable. Please just do it again but grab only the area around that display you are creating. As I said, all I've changed is the selection in the SimConnect_Text function. There is no option to specify encoding. I think this is another bug in P3D which revolves around their update to using Unicode. This change was responsible for major SimConnect problems in the Beta releases leading up to their first user release. I'm sure it wil be an easy thing for them to fix. Please do supply the pictures of the two windows in a way the text can be compared. Pete
  9. Sorry, I do not understand what you are doing. Are you using FSUIPC for the "SimConnect Message Window"? Did you use the "Message Window" with 5.103? I changed because the SimConnect Message Window is a much nicer one, and matches better the Lua windows I could make in FSUIPC4. And it doesn't get tangled up with the messages produced by ATC and so on. If you are using facilities in FSUIPC, the I can only point out that FSUIPC does NOT tamper with any text being displayed. Therefore, if it has changed it is a SimConnect problem. If you can please clarify what you are actually doing I can determine whether to report this to L-M -- though you should do too, as you have first hand evidence. Pete
  10. Check the FSUIPC5.LOG file (in the Modules folder). That will happen if FSUIPC stops receiving data from SimConnect. It isn't "disappearing", but failing to get the menu entry re-added when attempting to re-connect. This is sometimes a sign of SimConnect overload, though it seems odd that this would not occur for 4 hours of a session. Would there be anything particularly intensive happening then? Looking at your log, this error is occurring every 30 seconds: 309125 **** No SimConnect events or states being received! Re-connecting now **** It looks like you are using AutoSave with a time of 30 seconds. With PMDG aircraft the Sim freezes whilst they collect data from all of the aircraft systems so they can save their own files. FSUIPC merely calls SimConnect to get the main Flight file saved. It does nothing more itself. The damage is done by the PMDG method of saving everything esle. A fix consisting of a much longer timeout was implemented some time ago to fix this, and it is included in the currently supported version of FSUIPC, 5.11. You are out of date and using an unsupported version. Please ALWAYS check that you are using the current version before reporting problems. It can save both of us time and trouble. You can also keep in touch with interim updates, such as the earlier one with this fix in it, by checking the Download Links subforum above. Autosave files don't "vanish", but the oldest is deleted everytime a new one is saved. So if, so instance, the SimConnect failure occurrred 10 times and you are saving a cycle of 10 files, and each Simconnect failure stopped the new file from saving ... well the result would be what you see. Generally I'd advise against using any form of Autosave with PMDG aircraft. I don'ty know how folks put up with the noticeable freezes in the sim. It must surely spoil the ilusion of reality? Pete
  11. No. Nothing in FSUIPC for sure. It starts them when it logs it is doing so, and closes them one after the other, without waiting to check, when it says it is doing so at the end of the log. There is quite a long delay after you confirm to P3D you want it to close until FSUIPC receives the "DLLstop" call after which it can start closing everything it did down. I don't know why. The P3D window itself may have gone seconds before. Is that what you mean? Starting up using "READY" is probably slower because it is probably still a very busy part of P3D startup. the programs i have starting at the beginning -- ASCA, AS16 or ASP4, and some of my own drivers, start up immeidately, whilst the P3D flash picture is still up. Er. So it is start-up that concerns you? Obviously if P3D has crashed FSUIPC isn't involved in closing anything itself. You'd have to do that yourself. Nothing to do with any of that. More the timeout till I restart AI Traffic scanning, or close and restart SimConnect connection. Pete
  12. So your problem is only that the RC voices aren't heard. Otherwise it is working correctly, going through the correct stages? FSUIPC is in no way involved in the voice production. RC does that directly. It seems that it is going wrong. FSUIPC is involved in providing RC the radio frequencies set, and servicing its requests for keystrokes, and of course things like aircraft location, speed, etc. But it is in no way involved in sounds for it. I suggest you try the RC support forum on AVSIM. it is better than emailing RC support as there are a lot more experienced users in the Forum, including my good friend Ray. Pete
  13. There is absolutely no difference for pure FSUIPC applications such as RC4. It won't even know you changed sims. Voices from what, P3D or RC4? What is "automatically" tuning ground? FSUIPC most certainly won't be, nor P3D. sounds like you have some RC settings wrong, or have some other software running. Maybe you are using some RC key assignments which conflict with something else? Try using more unique ones. When I used RC4 I have everything on "Ctrl+Shft+1" ... "Ctrl+Shft+9", etc. not simple keypresses like 1 - 9, which lots of programs use. Pete
  14. Previous crashes reported in that DLL have been eventually attributed to other problems in P3D. The Install log isn't relevant unless you have an install problem, which it doesn't sound like. i'd need the FSUIPC log and the Joyscan csv files. However, the Install log shows that you deleted any previous registration and didn't enter another. so you aren't even registered? Registration dialog exit: selected FSUIPC DELETE Deleted previous registration ... Providing FSUIPC registration dialogue ... Registration for FSUIPC5 was cancelled or failed! (result code 40) Pete
  15. Do you mean CDU data readable via offsets? Of course, over a year ago! Why not use the documents installed with FSUIPC? The data for CDUs is listed in the PMDG offsets documents. Pete
  16. Strange. What size are they, as shown in Windows Explorer? There was a problem with one relese of the installer where the files were being installed with 0 length. You are using the latest version, I hope, FSUIPC 5.11? Re-running the installer ALWAYS installs again. It would only refuse to replace a LATER version of FSUIPC with an older one, but it ALWAYS installs all of the other files, including those in FSUIPC Documents. Maybe you should show me the FSUIPC Insall Log file, which shows exactly what it does. There's no message at all saying it won't install again because it is already installed. That sounds like an installer for some different program altogether! If you ever read much of the documentation supplied you would see that FSUIPC and its parts are ALL only contained in that Modules folder. no where else. Why? Where's the log file from the Installer. Nothing you've said makes sense at al I'm afriad. nothing of what you said relates in any way to the Installer I supply. FSUIPC doesn't have any entruy in the Registry. It's a very simply install, into the Modules folder and no where else. It couldn't be simpler in fact. The ONLY other file affected is the DLL.XML file where it adds an entry to tell Simconnect to load it. Without seeing the log, which is produced speficially to help me answer such strange questions as yours, I cannot really help fursther at all. As I said, nothing you say seems to relate to any software of mine! Pete
  17. Yes. That's why the FSUIPC4 Offsets reference document is installed with FSUIPC5. See the FSUIPC Documents folder. Yes, almost all will work ok without problems. The Lua "display" window isn't so good as it was in P3D3 or FSX (awaiting some facilities from L-M), and you can't have more than one such Window open (so the "owndisplay" facility is no different from the normal display). The only offset which comes to mind as being definitely different is the one used for VAS (memory) displays which will remain at zero, since 64-bit memory is not being measured by FSUIPC5. Pete
  18. That will likely be interecpted by PMDG's code before FSUIPC gets to see it. Good. Pete
  19. Sorry, SimMarket have an exclusive arrangement with me. Pete
  20. FSUIPC most certainly doesn't touch any autobrake or brakes unless programmed to or asked to by a client program. In fact it probably couldn't in a PMDG aircraft since probably doesn't even uses the FS autobrake system. Test in a default aircraft to see if it happens there too. It seems more likely that you or LINDA have programmed the wrong code for autobrake, one actually being used for the brakes instead. I don't use PMDG aircraft or LINDA, but maybe by enabling button/switch and non-axis event logging in FSUIPC you'll be able to see precisely what happens when you operate your autobrake. Obviously if FSUIPC isn't running, neither is LINDA. That should be a clue in itself. You can work out the PMDG custom control numbers from the .h file in the aircraft's SDK folder. The list is near the end. You have to add two numbers together to arrive at the control number which needs programming. Pete
  21. You would need a registration, yes, but you wouldn't need to have a second PC to have the client part (WideClient) running on the same PC as your sim. However, if you don't already have WideFS then it wouldn't be worth buying it just for bigger fonts in an FS window. The font size from ipc.display is the same as that used in all FS windows, and I think menus and dialogues, and it is set by the system font size in Windows, which of course you can make bigger -- but then it affects everything. Pete
  22. That was part of the start of the Install log. Please do not edit files before pasting them into messages. I cannot access your DLL.XML -- when uploading files it is best to ZIP them. Is there an FSUIPC5.LOG file (and an FSUIPC5.INI file) produced in the P3D Modules folder? For the Installer problem, please try the version just released, 5.11. You can get it from the Download Links subforum above. Sorry to hear that. I've been registered part disabled since I was in my 40's (over 30 years progressively worse). mine is severe tunnel vision due to Retinitis Pigmentosa. It does rather limit your scope of activities to indulge in. Pete
  23. It uses SimConnect facilities which don't give many options I'm afraid. Certainly not font type or size. You can run Wideclient alongside FS/P3D -- just change the ClassInstance to 1 or more in its INI. Then use the display library. Of course that does mean having a WideFS registration. Pete
  24. Is it a private problem? I don't support via Private Messages and very rarely even check if there are any. Why are you adding to this particular thread, and even quoting my reply? Is your problem related? If not please post a thread of your own with a relevant subject title. Pete
  25. It's worth a try. Sorry, but I've no idea what parts, if any, EZDOK uses. Maybe it needs updating for P3D v4? You really need EZDOK support. 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.