Pete Dowson

Well, if you want to post what you are doing and say what you want to do with it I should be able to help. Don't attach files, though, just paste them and use the <> button above the edit area to enclose them. Pete

If they are all event based or looping type plug-ins, not ones loaded and unloaded each time they are used, then the difference is only that multiple small ones will be using multiple threads. If they are dormant (sleeping or waiting for events) most of the time this will not really matter too much, though Windows does have an upper limit to the total number of threads in the system you wouldn't get anywhere near that. I think that design considerations -- ease of use, ease of maintenance, clarity - would be more important here than the neglogible difference in performance. I'd group functions dealing with variatins of the same things, but separate those with very different purposes or destinies. Pete

Ouch. It is as I feared. It looks like I've only succeeded in moving it on a bit. Drat! I'm afraid it may not be as easy as the old G3D patch I did for FSX. There is one glimmer of hope. Possibly the new crash you got isn't related to the one I'm patching. There's no entry in the FSUIPC log file saying it "fixed" one, and there should be, though one reason for that might just be that there wasn't time for the output to get into the log before the crash. Thanks for testing. Pete

Okay, thanks. I’ve now seen three crash reports with exactly the same crash address, so I’m hopeful that my fix might help. Just not sure of the consequences of letting the sim try to carry on – it might just result in a different crash later, depending on what the corruption really is. If it does recover from one and carry on, the incident will be logged in the FSUIPC4.LOG file. After closing FSX-SE there will be a total count at the end of the log. I'm off to bed now -- i'll check back in the morning. [LATER] I think I might have wasted your time. Sorry. The test version I uploaded won't install the patch. I made a error building the ZIP. :sad: I'm just redoing it now. The link will br FSUIPC4938hTEST.zip [LATER STILL] I fear it isn't going to work. The corrupted data may be too extensive. However, it does no harm to leave the facility enabled. Then, after any good (crashless) flight, after closing FSX-SE, look in the Modules folder for FSUIPC4.LOG. Open that in a text editor (Notepad) and look for any entries about TERRAIN.DLL. It just may be trapping some!? If so I'd like to know so I can decide whether to retain the patch code. Regards, Pete

Download and run the FSUIPC 4.838f installer. Pete

I can add it if MakeRunways already extracts it. Do you mean the highlighted value in these entries in the log file 9Runways.txt)? Start 1 : N68:20:38.1833 W166:48:17.1941 12ft Hdg: 22.3T, Length 3985ft If, a new tag, like <FSStartHdgT> ? Pete

Er, the thread you attached this to is 26 months old. Could you be more specific? What file, what section, what structure? I'm a bit lost. Sorry. Pete

TEST VERSION OF FSUIPC4 FOR FSX-SE TERRAIN.DLL CRASH AVOIDANCE [sTOP PRESS] I don't think it is going to work -- it looks like this crash is not patchable -- too extensive! ================================================================ A number of folks have been reporting crashes in FSX-SE's TERRAIN.DLL, These are probably results of a similar bug to the more common one in G3D.DLL in FSX, and they are probably exacerbated by folks managing to get settings up a lot higher in the Steam edition. So far not many of these reports give any details, but I've seen two with details and both point to the same offset in TERRAIN.DLL for the access violation which is occurring. The offset is 00059BE8. It's only a small sample, but the fact that the only two with details are both at the same place must surely be more than a coincidence. So, though I don't yet know if this is the main or only one. I can still implement a temporary workaround in FSUIPC as I did with he most prevalent G3D.DLL crash in FSX. So, first off, could all of you experiencing this crash please post the actual crash details -- the module offset is really all I need, and confirmation that the error code is C0000005 (= access violation). Meanwhile any registered user who does get (or knows he can get) the Terrain crash at 00059BE8, please try my interim test version -- download link: FSUIPC4938hTEST.zip. Read the "read me" inside for details on how to enable the fix. Let me know how you get on, please. Regards Pete 26th January 2015

Yes, the left hand side of the "Button & Switches" tab, where you assign keystrokes to button presses, exactly as documented in the User Guide. Oh, and it works for GSX too -- I use it for GSX. Pete

No. You misunderstand completely I'm afraid. You assign your BUTTONs to whatever KEYSTROKE(s) you want. There are no "controls", we are talking about making keypresses happen when you press buttons!!! The keystroke assignments for RC are set in RC. Pete

if you run the GoFlight software you will have interaction problems between FSUIPC trying to do things and the GoFlight software doing it to. This applies to all of the GoFlight devices which their software handles automatically, like the MCP and the LGT. You don't need their software for all your other units, so why load it at all if not for the LGT? Just remove their DLL. Pete

You are making an error, then. Maybe you registered WideFS with a different email address? The name must be the same as for FSUIPC,but the email can be different. Pete

Strange it isn't so associated here. I'll associate it next time I see one. Ah, so ".wer" is synonym for ".txt"? How odd. Thanks, Pete

It is always better to use events in any case. The plug-in is then only read and compiled the once, and it is dormant until the event(s) happen(s). With it being reloaded and recompiled each time you are fragmenting memory unnecessarily as well as causing the processor overheads of unnecessarily repeating the same thread creation, file access, compilation and thread destruction each time. And for similar reasons it would be more efficient to have one plug-in, one thread, one area of memory occupation, for all similar things always used together. Pete

RC for certain okay. I don't see why not GSX too. It would actually be quicker for you to try it than send a message here and wait for a reply! ;-) Pete

Please see the Changes document included in the ZIP for 4.938f. Documentation takes longer to update. All recent changes are always covered in the Changes document. Pete

"Killing" Lua plug-ins is NOT really a good idea. The facility is provided for occasional use when this proves necessary, but there are much safer and more effective ways to dealing with program control. Killing threads can leave things in a strange state sometimes. I've taken lots of steps to try to ensure it doesn't actually crash the sim, but I'm not sure even then I can cover all circumstances. It all depends what the plug-in is doing with other parts of the system. A much better idea is to have the plug-ins event driven, so they loaded, but dormant until they need to do something. There are event functions for activating them on button press, key press, or just flag or parameter changing. If you really want them to terminate, setting one of the 32 available flags for each plug-in should suffice, programming it to test it and is set to ends by simply exiting the loop or using ipc.exit(). If you really must do something like that, there is nothing stopping you assigning as many actions as you need to each keypress. You have to do this by editing the INI file, as the in-program dialogue can only assign one thing to each. Pete

Best to just paste the text into a message. You can use the <> button above the edit area to enclose them. This works best for text files and saves the uploading / downloading process. Got them anyway. Thanks! [LATER] ... except I don't know how to open the "evtx" and "wer" files you included! :-( Pete

Good! But I'm at a loss to know why this was related to the Wind Smoothing change! Ah well, all's well that ... you know the rest! ;-) Pete

I've just released 4.938f. Maybe try that too, please? I'm very VERY puzzled by this night/day difference. It makes no sense to me. I've checked all these recent versions here and the only differences are whether wind smoothing is hooked or not -- that's the change in 4.938f Maybe when you update to 2.5, it being a complete re-install in any case, the problem will fix itself. Pete

Okay, thanks, that's good. But I'm just releasing 4.938f which fixes wind smoothing for 2.4 also. Looks like I broke it in 4.938d.& e. Pete

It was in the message where I asked you to try it!!! Pete

I'll need the log, and any Event Viewer details, for your test with 4.938e, not with one which works! Please? Pete

Aha! I was about to put the code in for the Anti Skid Brake offset, when I saw it was already there! Loks like it was added a long time ago, but just didn't get into the Offsets List!!! I shall remedy that, but meanwhile, the details are: Offset 0BFD, 1 byte, Non-zero = Anti skid brake active. Can be written to change it. Oddly, it isn't even recorded in the History document of changes. I must have had an off-day! Pete

It sounds like there must be some sort of corruption in the other (maybe default) sceneries or textures. Are you sure there's no error information in the Wideows Event Viewer? Please, anyway, show me the FSUIPC4.LOG file. Maybe that will show where it's getting to, though as I said FSUIPC cares not a whit about night and day and wouldn't even be aware of any difference. Just in case, try the earlier version of FSUIPC,FSUIPC4938c. But show me the Log and any crash details first, please. If that also fails I can't help thinking you need to try a re-install of P3D. You might want to wait till 2.5 because that will need a complete new install in any case. It isn't far off now! BTW I'm still working on some changes, and some will affect P3D for sure, so look out for another version too, later .... Pete