Pete Dowson

At some stage before this there was probably a crash on FS termination. So there WILL be a crash log in the Windows Event viewer. If you believed that was not a crash, why didn't you simply press the "Ja" button and let it run? You had the option there in front of you! That would either have worked or crashed. Then you would have some useful information, which at present you don't. Anyway, you are using a pretty old and unsupported version of FSUIPC. If you want further assistance please first install the current version, 4.963. And if and when you do submit a problem, please include the FSUIPC4.LOG file, not the DLL.XML file, which is only relevant if it won't load at all. Pete

Oh, okay. I notice that just before the events are defined it says "check every 500 msec", but no sign of any timer anywhere. Is that an old comment now not relevant? Pete

48, all running or waiting for events! Phew! That seems really excessive. What sort of events are they waiting for? If they are all small things just reacting to button presses or the like, wouldn't having them combined using the parameter facility be more efficient? Pete

The reason the log is so big is that you are logging things you don't need to log. just log Axes. The axis log entries shown are ONLY for the Ailerons, and you pretty much either didn't move them or you did and they are not calibrated correctly, because ALL of the values are within a small percentage difference from each other. Just look for yourself! All around -3500 apart from one -3900 for a few milliseconds at the beginning. Such changes won't be noticed at all. I had another quick look at your INI file and it looks like, whilst you enabled calibration, you haven't actually done any calibration at all. The values are all defaults! I also only just noticed -- your only assignment there, to the Elevator,is to just send a fixed value of 0 in an unspecified range. You've messed about i the right-hand part of the Axis assignments tab without completing it, or subsequently deleting lines, and have not actually don'e any proper axis assignments! Well, I do NOT want to see any logs taken whilst you have controllers enabled in P3D. That just wastes my time. And if you are going to supply logs relating to different INI settings I need to see the INI file used too! I have not seen an INI file with ANY proper axis assignments made at all, yet. Please use the <> button above the editing area here to frame your files when pasted here. Do that with the INI file too please. And you still have not answered my other question: what changed? Are you only just starting to use FSUIPC? You did say "first ever problem" I believe. BUT the first priority is to show me a proper INI file, with your assignments and calibrations, not one like you attached earlier which was just not usable. Pete

Why is the log too big? Have you enabled logging options without me asking for them? There's no way I want to pore over huge logs! You should easily be able to paste a log here, into a message, not as an attachment. You can use the <> button above the edit area to provide a scrollable section for it. What about my other points, as in what changed, and about the lack of assignments in the first place? Pete

Is the Lua stopping the close the same one or related to the one with problems just before? PetE

I don't like those log entries below. I'll have to fix that: 358 Using existing joystick id: 255

<< Obviously you have changed something here, because comparing to my LOG file in the backup, I don't see these messages there >> I simply made an existing "LogExtras" log option default. That was done in 4.963a. It doesn't affect anything but the log. The only change in this version is to the device check and registry business at the beginning. Pete

Okay. I think this one should do the trick properly. Please don't edit the registry. Just revert to your original saved INI file and run with.FSUIPC 4963b_TEST installed. It should automatically revert to your original Joysick ID numbers and fix the registry accordingly. The log should say so. Thanks & Regards Pete

So, what has changed? Your INI file shows just 4 button assignments, on the Yoke, and only one axis assignment, to the elevator on the X52. You've not provided an FSUIPC4.LOG file showing the actual activity in the Sim and in FSUIPC -- the Install log is completely irrelevant if FSUPC is running and accessible. Also you are still using FSUIPC version 4.962a which was replaced by the supported version, 4.963, a few days ago. Please always check before reporting a problem, just in case. Pete

Actually, I think all you need to do, when I provide a "fixed" version, is restore your previous INI file, with the ID numbers in their original assignment, and FSUIPC should then enforce that in the Registry. That's part of the change and the part that doesn't work. The non-registry way of finding the GUIDs seems to be working okay, so FSUIPC is no longer dependent on locating IDs in the registry. Still working on better code and testing ... Pete

You simply read it from FS using the ipc.readSTR function. The data you can read from FS is all listed in the Offsets Status list. I just searched for it and found: 3D00 256 Name of the current aircraft (from the “title” parameter in the AIRCRAFT.CFG file) so name = ipc.readSTR(0x3D00) Pete

Not unless it is or was also assigned to some other function you use. FSUIPC will be intercepting it before it gets to anything else. Pete

This used to happen to FSUIPC with another addon too,. It seems to do something in SimConnect which allows FSUIPC to requests "DialogMode" (as it needs to to display the options dialog), but then SimConnect never enters that mode. It think that was a version of "copilot.dll", which was eventually fixed. There was one time when certain video drivers were messing it up too, but I've not heard of that happening for a long time. However, just in case try in both full screen and Windowed mode. The fact you've eliminated vPilot as a culprit is a useful start, but please list all of your SimConnect using add-ons. I think it will be a process of elimination to determine the culprit. So, are there other DLLs and EXEs being loaded or running on the same PC and using SimConnect? Pete

Does the AddOn menu contain any other entries? That shows a perfectly good session with FSUIPC normally closing after a session lasting about 24 minutes, Why do you suspect it as an FSUIPC issue? That doesn't make sense. I do see you are running vPilot. Someone else here has also reported a problem when using that. It doesn't use FSUIPC as far as I know, but folks always choose FSUIPC as the potential culprit initially. Try without vPilot. If it is all then okay I suggest you visit their support forum and see what they say. Pete

Yes, any keypress OR button press can be assigned to KeySend. The nature of the actuator isn't relevant. KeySend is simply an internal code sent from FSUIPC to the Client, and the arbitrary number it contains (from 1-255) is assigned locally, at the Client, usually to a keypress there. Pete

Wow! That was fast! Too fast for me, actually. I'll have to analyse this in the morning, but it has done the thing I didn't want it to do -- change the numbers. That's okay for those using JoyLetters like you, but it will definitely mess others up. My code was supposed to reinforce the numbers it saw already assigned. That is hasn't means there is a bug in my new code. I hope you saved the previos settings os you can restore, because if you don't mind I'd like you to try that again after I ,make some changes. Og, I just thought. It wil have "corrected" your registry as well in order to reflect te new numbers, so a new test won't work ... at least not unless I fiddle it. I'll need to thing about that. i might have to change it, for testing only, to set numbers from 15 down instead of 0 up, so the registry entries don't accord again. Hmm. Back in the morning! Flaking out a bit here -- too much good wine with the superb dinner my wife provided! Pete

Well, an Arduino needs some programming too. In the part which runs at the PC end you'd detect signals from the Arduino and use them to set "virtual button" flags in FSUIPC offsets. I think I programmed an Arduino to send simply short messages when a button was pressed and then had an FSUIPC plug-in written in Lua which read it on the COM interface and set the offsets accordingly. It would be MUCH easier for you to use a Leo Bodnar board which had switch and axis inputs which can be directly assigned like for any joystick device. Pete

The interface for the PMDG aircraft is included in their installed files, in the SDK folder. There's all you need there to write your own interface using SimConnect and its SDK. Pete

The price in Euros in Europe stays constant, but the VAT added in different countries in Europe varies. For other currencies (USD being one), the price at any time will depend on exchange rates, though I wouldn't have thought by as much as 21-30. As for "when t will be cheapest", I suppose you'd need to become an expert in predicting exchange rate movements. FSUIPC has never been in a "sale", but there is a discount for the bundle FSUIPC + WideFS bought together, and there used to be a discount for FSUIPC3 users upgrading to FSUIPC4, but I think that was only if they bought FSUIPC3 within a certain period beforehand. Pete

I have at last found a way to get the correct device GUIDs without recourse to using Joystick IDs which may or may not be found correctly in the Registry. The problem with the registry method of locating the correct GUIDs to properly identify a device is that, since Windows 8 at least, the joystick ID number, the only sure way I had of locating the GUID, was not always being set. The Saitek devices seem to have been notorious for that, but this may only be because they are the most prevalent. Either the HELP provided on the MSDN websites has improved, or, more likely, my skills and patience in searching have improved, because I have now found I can get hold of the GUIDs by using DirectX enumeration, after all. It is the DirectX enumeration which provides the Joystick scan list logged by FSUIPC during initialisation, as opposed to the Registry method used to produce the [JoyNames] section in the INI file. This change is not subtle, though to most users it is hidden 'behind the scenes'. The only overt change is the logging, now, of the GUID, in the scan list. The change actually really makes FSUIPC independent of the joystick ID method of tying them up, the one limiting the number of devices to 16 numbered 0-15. So, now, really the JoyLetters are just as much identification as the numbers, and if it were not for existing installations everywhere still not using JoyLetters I could dispense with the numbers altogether. But that's just wishful thinking. It could also mean that the number of devices handled could be increased beyond 16 (though if single letters are used it would be limited to 26, or 36 with numbers 0-9 as well. However, such a change would mean a major restructuring of so much in FSUIPC that I am not willing to risk it. If I were only 20 years younger I might be braver and also be willing to spend more time on it! So, the change offered now is effectively just a more reliable way of identifying joystick devices, without folks having to resort to re-installations or setting IDs via JoyIDs. The problem for me, before release, is to prove my code changes. I don't have many devices (just 2) and the ones I have aren't used much except for basic tests. My cokcpit has no regular devices, everything being handled via specific drivers for PFC and so forth. Hence I need some volunteers please to test this update on their system, one preferably with several joystick devices and a good number of assignments to them, possibly in Profiles. If you are willing, please first make a safe copy of your Modules folder so you can easily revert should things not work out, then download version.4963b_TEST and copy the DLL into the active Modules folder. Feedback here, please, with INI files and LOGs if there's anything wrong noticed. Thanks & Regards Pete Dowson

EZDOK does not use FSUIPC. The two are not related at all. If you don't run EZDOK, is everything okay? i see you are usung P3D 3.3.5. Are you sure EZDOK is compatible with that? Maybe there's support offered on an EZDOK forum? If not it might be worth asking in the AVSIM P3D forum. Pete

Make sure your SODE matches your rather old version of P3D 3.4 (I see you are on 3.4.9, whilst the current one is 3.4.22). I don't know if SODE is kept backward compatible, and all sorts of add-ons update it. Pete

Yes. This JoyID business seems to be a recurtring problem with Saitek devices, especially since Win8 and Win10 -- wasn't so bad on Win7. I am actively looking for ways of using the DirectInput methods as I currently do without needing an ID number. If I find a way t will be quite a change from now. The numbers will only be used to tie the names and GUIDs to the assignments, just as with the letters where they are used. In fact you'd only need one -- letters or numbers. But so far I've not found a way of finding the GUID without using the ID number. Pete