Pete Dowson

Yes, thank you. Is your interest more FSUIPC5, or FSUIPC4? it's just that I'm working more often on FSUIPC5 these days, of course, and don't expct to be updating FSUIPC4 so mch. Pete

I've been researching and experimenting here with possibly better ways of automatically setting permissions on folders (files within them can inherit these). I think I've implemented one which will add "EveryOne" to the Security list for the Modules folder, AND set full access. It works fine here, bit I'm not really able to test it in the proper circumstances on any system of mine as none have the sort of difficulty you had. However, the improvement will be incorporated in the next FSUIPC5 update and will hopefully prevent this sort of problem in future. So thanks for your report forcing me to look at it again! Pete

The ambient icing value is alreadyavailable in any case, at offset 8601. Please see the Offsets Reference section in the ASN WX Radar facilities document in your FSUIPC documents folder. That does actually list all the values I am currently aware of. The others aren't mentioned in my documentation. Mind you, I've not see an API document since ASN, so I assume there have been additions since AS16? I don't have a quick source for the API document for it (or ASP4 for that matter). Assuming I had the information I would presumably be able to add the others somewhere in the offsets, but I won't have time for the next few weeks I'm afraid. It would be middle of September. If you have the documentation, by all means send me a copy. it would be quicer than me asking HiFi. You can send it to petedowson@btconnect.com. I'll peruse it and let you know. If okay I'd put it on my list, but, just in case, you'd need to remind me mid-September. (I make so many lists). Pete

Please try this FSUIPC update (5.111). It will be released formally within the next few days. Among other things, not relevant here, it has the Lua interpreter only using unpacked Windows API structures. FSUIPC5111.zip Just unzip it and copy it into the Modules folder. Pete

Scott has written to me with his summary of the problems he is faced with trying to get to the bottom of your problem. He won't be able to take it further due to lack of time, but it does seem there is some very strange additions in Lua to what LINDA is actually doing. One thing in particular causing an issue is this code, apparently repeated every second!!! local count = 0 for _ in pairs(nomvar1) do count = count + 1 end file = io.open(Chemlog.."Linda777.log", "w+") for i = 1 , count do if valvar1 == nil then valvar1 = "nil" end file:write(valvar1) file:write("\n") end file:close() This is stopping the LINDA logging working usefully. It generates errors where on the file:write. One thing I should ask: why are you opening and closing the same file every second? Why not open it once at the start and close it at the end? (You should also check that file is not nil after the io.open). Also, why not use the logging facilities provied for you. i.e. ipc.log? Anyway, none of this explains why FSUIPC crashes in P3D4 but not P3D3. It must be something related to the 32- to 64- bit conversion, and the only thing I can think of it a structure alignment difference. FSUIPC normally packs all structures for efficiency, but it is noticeable that many Windows API structures are used in 64-bit with only things like pointers becoming 8 byte instead of 4 and creating holes 9unused bytes) within. So, I will look to re-compile the Lua interpreter parts of FSUIPC with default packing, Look out for a link to a test version soon. Pete

Good, but sorry about the "kerfuffle". You don't really have to change permissions for every user, you can just add "EveryOne" to the list in the top half, and allow EveryOne access. Didn't you try deleting the Modules folder before a re-install, running the Installer "as administrator"? However, none of this should be necessary at all. I don't know what is going on in your case as it has never happened before. Pete

These files are all written by the Installer. But the Installer also changes the read/write permissions on the folder too, so that any program, including itself, can write to it. Are you sure you, or some other program, did not create the folder beforehand. I think the Installer only does it when t creates it itself. Just in case, it might be worth deleting the Mdules folder entries, then re-running the Installer using run as ... administrator. There are plenty of installations for P3D3 in Program Files [x86]. I'm pretty sure there are many also with the 64-bit version in Program Files, but I've not know the permissions change not to work before. Let me know. I'll try some experiments on permissions here if you can't make it work. Are you using Win 10? Pete

If you are looking in the correct Modules folder, where FSUIPC5.DLL is kept, and there is no INI file and no LOG file, then FSUIPC has never actually run! I suspect that you have Explorer hiding known filetypes from you. The INI file will look like a "configuration file" or similar whilst the Log file will be a "text file". Do as the documentation says and change the folder options in Windows Explorer to not hide filetypes. The will also be a FSUIPC5.Joyscan.csv file, and a KEY file with your Registration. Pete

I don't understand either. It's as if the device was in a strange state which DirectInput didn't like, but which cleared itself -- or, since the actual device concerned seems to be irrelevant only whether there are two or more), something conflicting between them in the hub or mobo chippery which clears. Yes, i assumed so. Ouch! The Saitek software does seem to give more problems than solutions fo programs like FSUIPC which try to deal with the devices directly. Pete

Ah, in those there was not the same device checking at all. The system had to be changed since the older methods didn't work with devices like the Saitkey X-55 and x-56. And the new mehodes (4.969, 4.97 and 5.103 onwards) are far more logical and easier to sort out. That shows it hanging or crashing during a DirectInput operation to acquire the Saitek Pro Quadrant in order to check it is operating. If this doesn't happen with, say, the quadrant only attached, then it points to a hardware problem. You say you are using a hub. A powered one? If you don't have another to try, can you test with the devices all connected directly to USB sockets on the PC itself? If it's the same with more than one deive on the PC, then it sounds worse -- a motherboard problem. Otherwise, if it is only related to one or two devices, rather than whether you have two or more attached, then I think something is screwed up with your device installations. Can you uninstall any Saitek software you have installed, then all the devices, completely (in Device Manager, find each device, right-click, uninstall, including drivers when the option arises), then re-boot. Windows will find them all and automatically set them up for use with standard DirectInput drivers. Pete

The yoke is being recognised but you have a Registry error. You appear to hasve two devises called "Mjoy737", one of which appears to be a valid joystick-type device, but it has been addigned the same ID as the yoke. Try using the JoyID program to change one or the other: http://en.informer.com/pjps-joyids/versions/. Alternatively uninstall one or the other completely, using Device Manager, and reboot to get it reinstalled. As for the throttle, there's no sign of it whatsoever. Try using HidScanner to get a log of all USB devices connected, see if it is there (HidScanner is in the Useful Additional Programs thread in Download Links subforum). Maybe, if you can find it is Device Manager, uninstalling it and reinstalling it might get it registered, but FSUIPC can't really handle devices which appear not even to be connected. Maybe it's going to sleep all the time from lack of use? Dusable all USB power management in Device manager.

Aha! Thanks for the explanation. I had forgotten all that. I put it down to old age. I'm forgetting more and more! :-( Pete

What even all three without the PoKeys? The Pokeys are the only ones which have rather strange extra registry entries. There are lots of users with the other devices. Pete

Sorry, things like port and hub numbers are no use to me. What actual devices can you plug in without the CTD? This from your Log is worrying: 18609 ***** HID USB device reconnected: re-initialising FSUIPC connections 18609 ---------------------- Joystick Device Scan ----------------------- but then the same 5 devices are listed, in the same order. So something, possibly being eliminated, is re-connecting all by itself. Please add these lines to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=x200000 then try again. I need to see the log, upto the CTD, with those lines added. And please also test just without the PoKeys connected. Those seem to have three entries each in the Registry: Y, x1E, x1DC3, x1001, Virtual Joystick, 0, 0, 3, {42D1F9E0-7AC6-11E7-8004-444553540000}, {42D1F9E0-7AC6-11E7-8004-444553540000}, {42D1F9E0-7AC6-11E7-8004-444553540000}, Y, Y Y, x1E, x1DC3, x1001, Virtual Joystick, 3, 3, 5, {436EFD30-7AC6-11E7-800F-444553540000}, {436EFD30-7AC6-11E7-800F-444553540000}, {436EFD30-7AC6-11E7-800F-444553540000}, Y, Y N, x11, x1DC3, x1001, Virtual Joystick, -1, -1, 0, {NULL}, {42D1F9E0-7AC6-11E7-8001-444553540000}, {NULL}, N, N N, x11, x1DC3, x1001, Virtual Joystick, -1, -1, 1, {NULL}, {42D1F9E0-7AC6-11E7-8002-444553540000}, {NULL}, N, N N, x11, x1DC3, x1001, Virtual Joystick, -1, -1, 2, {NULL}, {42D1F9E0-7AC6-11E7-8003-444553540000}, {NULL}, N, N N, x11, x1DC3, x1001, Virtual Joystick, -1, -1, 4, {NULL}, {4320B620-7AC6-11E7-800A-444553540000}, {NULL}, N, N What version of FSUIPC4 was that with? The joystick scanning on current versions of FSUIPC4 and FSUIPC5 is identical. Pete

The IN range will be the standard -16383 or close to +16383 or close. That's the standard range for all joystick axes when not used in RAW mode. Assignment in the Sim would be the same as assignment in FSUIPC. No difference. The value of 0 for the INput should be reasonable near the middle of the movement. If it isn't then you either have a faulty unit, or, more likely, its registry entries are screwed up. The calibration stage can do anything you like to affect the OUT value. That's the whole point of calibration, which you seem to misunderstand! If necessary you can calibrate the 0 area as the "minimum" and your 16000 or so as the maximum. That would get over the anomaly in the unit itself, or its registry entries. However, it would be a lot better to re-install the unit altogether. If you are using Saitek software that will probably interfere, so uninstall that. Then go to the Windows Device Manager, find BOTH units there, and and right-click them to uninstall (including driver when the option is presented). Then unplug them. Re-boot the system then plug them back in so they get the correct Registration. Pete

You need to re-calibrate after any option change! The range you are sending to the sim is now different! Pete

Well, the reason it is different could possibly be something in the Lua code not properly 64-bit compatible (though there were no compilation warnings as one would expect), but it is actually more likely to be due to things moving around a bit in memory, and it was just luck before that it didn't crash. Considering that you get a crash on session close and the crash during flights varies in place and whether it happens at all, there seems to be a very good chance that something in memory is getting corrupted. The trouble I have is narrowing things down. I don't know LINDA or any of the other things you are loading, and I don't really know the insides of the Lua interpreter. I need it narrowing down for me, that's why I asked Scott to help. It would be nice to narrow it down so much that I could reproduce it here with less code and no complex add-ons to confuse matters. Then I would be able to fix it quickly. Pete

You are wrong there. Just test with a default aircraft to check. Neither of those aircraft like reverse mapped on the throttles. You should have the "no reverse zone" option checked on the calibration tab. Also, according to many accounts, none of the PMDG aircraft like any sort of calibration made by FSUIPC on the throttles, and instead need them assigning to the "axis throttteN set" controls. Otherwise, so I understand, you are likely to get conflicts. For all I know the same applies to your Airbus. Pete

Thinking about this later, I realised you were probably ONLY talking about the "TimeToSelect" parameter. I perhaps wan't clear on this earlier (mainly because I actually forgot! Sorry). But, as documented in the Advanced User guide (see extract reprodcued below, with the part I forgot highlit), there are THREE main modes for this value, and you cannot switch between them without diting the INI file. i.e. 0 Off altogether +n (n = seconds) normal time to select -n (n = seconds) same but not applied to radio controls Those are all separate "modes" in which the facility operates. So to test 0 you have to edit the value in the INI file. The reason for this is that the different modes need a different initialisation sequence between FSUIPC and SimConnect, and really it isn't a good idea to close everything down and reconnecting within the same session for this. Anyway, i've now re-installed Prepar3D 3.4.22 and tested the doors, and they all work perfectly. The aircraft I am using has 1 for both passenger doors, 2 for both service doors, and 3, 4, for forward and aft cargo doors. They all work independently, consistently. So I must conclude there's a problem in your system. Try with no add-ons whatsoever except FSUIPC then gradually re-enable the others. Pete ================================================== TimeForSelect: This specifies the number of seconds for which the SELECT controls (normally assigned to main keyboard keys 1–4) should remain operative for controls that need them (like Engine select, or Aircraft Exit toggle), despite the intervention of other, different, controls. To disable this, set the time to 0. Also note that whilst the time set does not influence the similar automatic facility for the FS pushback (which ensures that the pushback direction remains selectable), the latter will be switched off too if 0 is specified. Setting the parameter negative, for example TimeForSelect=-4, allows the 4 seconds to connect Select 1 -4 to all types of controls which can accept them, excepting radio related controls. The number of seconds can still be chosen to suit the user, and modified in the Miscellaneous tab in FSUIPC options. Note that you cannot switch between these three options in the FSUIPC options dialogue. You can only change the time when one of the enabling settings have been made in the INI file.

Sorry what do you mean? All of the FSUIPC Options selections are saved once you click OK. If you cancel or exit by closng the options, everything you've changed in that visit is discarded. Pete

That's very odd. The Installer actually creates that folder with read/write access enabled. This has always worked. Is there a Modules folder there already? Maybe something else created it, or it didn't get deleted when you last uninstalled? Try these things: 1. Run the Installer in admin mode (right click on the EXE and select "run as ..." and select administrator. That should do it. If not: 2. If there is a modules folder, right click on it, select Properties, uncheck "Read-only" if it is set, then the "Security" tab, the "Edit" for the Group/user name, and add Everyone (if it isn't there), then when that's confirmed, check "Allow" for "Full control" and "modify" below. If that doesn't work at all I can only think making the P3D folder itself accessible in the same way as in 2 above, but that's rather drastic. I can say that such a problem has NEVER arisen before, in any version of FSUIPC since the Installer was first introduced. (Long ago it was a completely manual job). Pete

No, sorry. They seem to be 100% taken up with P3D4 matters these days. None of the P3D3 questions seem to be answered. But thanks for reminding me. I clean forgot I was supposed to ge back to 3.4.22 to test. I'll do that today. But I must tell you that I've been using all versions of P3D3 on my own cockpit installation and have never had any problems with the door selection. Pete

Strange. I did confirm to them it was all working. Maybe they are actually waiting will they have a "better" reason to release a complete new package. Pete

Neither are any use to me I'm afraid. WEe need the LINDA folks to tell us what it is doing at the time, which Lua function. The "successful" log doesn't terminate correctly. It is still waiting for SimConnect to tell it to close down. Did the sim hang? It can take a while for P3D to close down -- the Window disappears but many threads are still running. FSUIPC is simply waiting at that stage, as it logs every step in the close down once it is informed. So the main difference is the location, continuing a flight. I realise it might seem unlikely, but since I don't know what LINDA is doing at all, it may well be important, couldn't it be some function in LINDA which is dependent on something local? I notice the log contains lots of stuff relating to where you are, how far you've gone, and so on. If instead of continuing the flight, what if you started it again. Would it crash again in exactly the same place? If so it is definitely related to position or conditions at that point. Scenery, weather, speed, altitude, etc etc. What about other flights, different routes? Do all crash? Is there anything in common. I cannot really progress this any further. It needs someone from LINDA to take a look, probably with the Lua debug/trace option enabled. Pete

And I'm pretty sure 3.999 ... IS higher than 3.72! So, maybe your key is illegal? Your log certainly shows you don't have FSUIPC registered, if that matters to your addon. I think you might need iFly support. Pete