Pete Dowson

Really? You don't look very far then. The Lua library document included in your FSUIPC Documents library contains details of all of the lua library functions offered by FSUIPC and WideClient! Have another look! Each ipc.readXX function has its own description clearly stating the type of value it is intended to read. (Pages 4-6, in alphabetic order!). I'm afraid I can't help with those. I have no idea what format Lekseecon uses, nor what "offset in the 0x..." is supposed to mean. You need support with that program, not FSUIPC. But 32-bits is either UD or SD depending on whether signed or not -- as described in the documentation. It says very clearly that UW is unsigned 16 bit. Pete

That's because for some odd reason you were posting in one of the subforums, not the main support forum. All the entries in the main support forum have a title and they tend to be all new topics, specific to a support question. Well, the first problem is that you are using an outdated unsupported release. Before asking for support you should always check to see that you are up to date. The current version is 4.958. The only error I see is an entruy you've made in the [Programs] section of the FSUIPC4.INI file That doesn't stop FSUIPC working, it just means your OpusFSI server program won't load.. Error 5 is a Windows error meaning "Access Denied", so you've got some permissions problem with that folder or file. Pete

Just download and run the current installer (it is 4.958 at present). It's available here in the Download Links subforum, or in the usual Schiratti web page. All this is more easily found by simply looking at the documentation in your FSUIPC Documents folder! Pete

Well, not exactly. There's only one altitude hold option in an autopilot. The Difference in the two controls is what they do first -- the Alt Hold control is to hold at the current altitude -- so it sets the current altitude to be held. The Panel Alt Hold says to hold when reaching the already set altitude. So, once at that altitude, they are of course indistiguishable. You can tell which one was pressed by checking if the current altitude is the same (or, probably better, very close) to the AP set altitude. Sorry, I don't know what you mean by this. I think you may be misunderstanding the whole point of the offset data bank. The FS controls are sent to FS as SimConnect Events. They don't write to any offsets. The offset you are reading is a RESULT not a CONTROL! Pretty much all FSUIPC offsets are there to provide information about internal FS values. They contain DATA, not CONTROLS or COMMANDS. Now for more flexibility and to implement many advanced functions, programs can write to FSUIPC offsets, but this doesn't do anything directly. FSUIPC sees the write and, for most of them, uses this to generate the appropriate FS control, or sometimes a sequence of controls. Pete

I think, for an Arduino, you might need software for the switch inputs too. I suppose you have someone lined up to write the programs for you? Best for an external FMS (rather than just one on screen, part of a graphics cockpit) you should be looking at an Avionics Suite of software like Prosim737. (http://prosim-ar.com/). Really you are asking all this in the wrong place. My software is an applications program interface in FS/P3D, not a hardware driver at all. It is actually a compatibility layer so that programs written to talk to FS98, FS2000, FS2002 and FS2004 can also work with FSX and P3D. For new applications it is more efficient to program directly to the interface Microsoft themselves added in FSX - SimConnect, which my software layers on top of. If you are looking to do your own programming then this is where you should be looking. -- SimConnect, in the FSX or P3D SDK. For better cockpit building answers you should look at http://www.mycockpit.org/. Pete

Ouch! That is way out of date and unsupported!!. You should be on 4.958 at least. Version 4.946 dates back to October 2015, over a year ago! It doesn't know P3D 3.4 and will not be working properly, it pre-dates it by many months! Please ALWAYS check you are using an up to date version before asking for support. Then PFXFSX.DLL is wrong. The only PFC USB driver I've ever supplied is PFCHID.DLL, intended mainly for their full USB consoles. But if your quadrant looks like a set of standard joystick axes then it needs no driver at all. Did you never get any information from PFC relating to your quadrant? Have you tried PFC support at all? Pete

I don't know Arduinos at all. I assume they have some sort of USB or serial port connection and drivers to make then look like, what, a collection of buttons and joystick levers? If FS can see them then FSUIPC should be able to as well. If you need outputs you'd need to do some programming, to extract the information and send it. In other words, to interface any hardware other than straight forward joystick types you need to write some software. Pete

There's a Lua plug-in supplied in your FSUIPC Documents folder called Log LVars, Assign it to a spare button or keypress and run it and see what values are taken on by that L:Var as you adjust your lever or slider. [LATER] sorry, I've only just realised. There's no / facility to divide. You can only multiply (*) and add (+). to divide you have to use the inverse. So in your case you really needed: *0.0030518,+50 Sorry. It was implemented long ago and my memory is aging fast these days. I should refer to my own documentation! Pete

That line is assigning some axis 2U to a macro. Calibration only applies to analog control axes which can be calibrated. So what values are sent? Pete

Not a good thing to do. I think a lot of add-ons are badly affected by that -- the response rate from things like SimConnect goes right down. Pete

There's no "PFC.DLL" for FSX or P3D. Is your throttle quadrant one of the old serially-connected units? If so you need PFCFSX.DLL. And check that you have the COM port set correctly. And please never just say "latest". I need VERSION NUMBERS! They are not hard to find. Folks have said "latest" and it turned out they were using a year old version, just the "latest" they'd noticed. If you really do mean PFCFSX.DLL, then no. That never needs changing for any FSX/P3D version as it just handles the hardware and passes everything on to FSUIPC. Pete

Sorry, but FSUIPC cannot be affecting that. If the ailerons and so on are moving, then you have something else wrong. Sounds like it's hung -- the sim I mean. FSUIPC is working absolutely splendidly in P3S version 3.4.14, the current version. Did you check if anything else was hung> Can you access any other menus? Alternatively maybe you are running low on memory (VAS). That can have rather odd symptoms before the outright crash. You seem to have disabled FSUIPC's OOM check judging by the log entry: Minimum available memory recorded was 32768Mb That value is just a space filler (I will have to change that). The logs don't show anything wrong at all (and please don't clcik the New Log button without good reason -- better to keep to one log file). You appear to have a lot of add-ons running. If I were you I'd start doing a process of elimination on those. Maybe some need updating for the later version of P3D. Pete

N0, not in the UI. You'd need to assign as usual, then edit the FSUIPC4.INI file to scale the entry in the Axis assignments section. To convert -16k to +16k to 0-100 you'd add something like /327.68,+50 because dividing by 327.68 gives you a range -50 to +50 and the addition of 50 rectifies it to 0-100. If the top result is 99 not 100 and you need 100 you may need to add 51 instead, depending on rounding, because the max on your original range will be +16387, not +16384. Pages 37-38 in the Advanced guide for FSUIPC4 covers scaling. Pete

Ah, yes. Well all FS contros are in the FS controls list. Pan View is not calibratable. Hats just return a value 0-360, or sometimes 0-3600 (1/10ths). Pete

You are using the specialist range setting side of the assignments options. Why? that's for experts - you'd need to study the documentation rather more than you appear have to make use of that, and it is no way applicable to your need in any case. If you otherwise have disabled cntrollers in the sim, how on Earth have you assigned oyur yoke and throttles? Or do you only use the keyboard for those? If you assigned them, didn't you do that on the left hand side, where ALL normal axis assignments are made? Have you ever just browsed through any of the User guide. it isn't that hard to read -- and it even has pictures. It shoes you how to assign axes. Please, just assign, NORMALLY, on the left-hand side, to the FS control "PAN VIEW". Pete

Have you tried Google? It isn't my program and I don't use it. Sorry, I can't keep track of other folks programs. I would have to search for you, but i think you should do that yourself, don't you? Pete

The hat switch is recognised and assignable in FSUIPC. You can assign it in Buttons & Switches as a set of 8 buttons, one for each direction, or as a panning controller in the Axis assignments - just assign to PAN VIEW, the same as it is behind the scenes in FS. Pete

Er ... FSUIPC4 doesn't talk to iPads, or any remote devices or PCs. It is an interface for application programs. I think you must be missing a program to install in your FS PC to connect to the iPad. Best to go to the support for the program that isn't working! BTW the log you attached is only the Install log. To show FSUIPC is actually running you need to find the FSUIPC4.LOG file, in the FS Modules folder. Yes, FSUIPC installed correctly but is it actually running? Pete

It sounds like you are misinterpreting the font. There is no way pasting changes anything in the text, and FSUIPC's registration edit box most certainly doesn't get changed by anything, only you. If, when pasting all three fields in correctly (do NOT try to edit them afterwards), you get a response that the registration is not valid, tell me your SimMarket Order number and I will check it here. Pete

As pointed out by Thomas, whether you interpret the 8 binary bits in a byte as signed or unsigned makes the different between a range of decimal values from -128 to +127 and 0 to 255. For example, -1 has all 8 bits set to 1 which is an unsigned value of 255. The highest bit is the sign bit in a signed value. Pete

The file hasn't been renamed, only the annotation -- because Lua file 53 is LTS Taxi. When editing the INI file, do NOT edit the annotation. That is placed there by FSUIPC to show its interpretation of the lines. If you want to add comments do so immediately after the control line itself, and precede it with a ; (semi-colon). The annotations, everything after the -{, are deleted and replaced everytime FSUIPC interprets the lines. Both of your original lines refer to the same Lua plug-in, number 53! How do you expect FSUIPC to do something different for an identical assignment? Both are " P109,5,CL53:R,0". Where can anything detect a difference? Use the correct number for the Lua file as listed in the [LuaFiles] section. AND please, next time you post a support question, post to the Support Forum, not to any old Subforum you find. They are for selected library reference subjects, not for ongoing live support. Pete

You need to assign two actions to that keypress then. You can get FSUIPC to send as manay controls as you like -- but you have to add the extra entries into the INI file yourself. To send a keypress with a keypress, use the FSUIPC keypress control. FSUIPC keypress controls are listed in the Advanced User's guide, page 31 on. Key press and release is number 1070. There's no "UserSendInput". Do you mean "UseSendInput"? You know this requires the target (your sim on that PC) to have the focus, right? I think this would be the case anyway, without UseSendInput, but then I've never tried it with P3D. With P3D I'm not sure what would be the best technique. You could try PostKeys instead, and put the ClassName on the KeySend line (it is "FS98MAIN"). And why 123,16? Have you not even referred to the WideFS documentation? The '16' says "Press but don't release" and the 123 is F12. Don't you want Ctrl+J, which, as documented, is 74,10. Please do make more use of the documentation supplied. Pete

As stated in the WideFS user guide, to allow WideClient to run alongside FS or P3D, or even another copy of WideClient, you have to set a non-zero ClassInstance parameter in its INI file. Pete

The only reason it didn't happen in the third case was because in this version of FSUIPC crashes during Lua closing are tapped. The log shows the details of the crash and it is in ntdll as before: 41954 EIP 771D6B89 is in ntdll.dll, Base=771B0000 Your original crash report showed the crash at "Fault offset: 0x00026b89 ". Well 771B0000 + 26B89 = 771D6B89, so the crash is identical to the one you were getting. Only the trap in FSUIPC saved the process from crashing. It still doesn't explain why, unfortunately. I am strongly suspecting some differences in the was the TerminateThread function works in Win10, because, as you found, Win7 doesn't do this, and i hve about 20 threads running using Events of all types and don't get a crash either in Win7. As I said originally, I found several of my programs, working without problems for years, crash in Win10, some consistently some occasionally. Interestingly all the crashes appear to be in NTDLL. So I'm putting this down to a Win10 incompatibility. At my age I've not got quite enough grey matter left to be able to, or be bothered to, investigate more deeply I'm afraid. I'd need better tools as well as a better (younger) brain. Your subsequent test, testing the main change I made in FSUIPC 4.985h, shows the change worked fine: This is it in operation: 55485 === DLLStop called ... 55485 === About to kill and Lua plug-ins still running ... Basically it is doing the same as you doing a LuaKillAll, so I expected it to work. The test was really to ensure I implemented it correctly. so thank you for that. Pete

Well, not much to derive really. The interesting log is the first which shows the crash occurring right at the start of the termination process, soon after DLLstop is called by SimConnect. That's when the signal to lua threads to terminate is sent. So it's something to do with one or other of the things running or instigated in your lua plug=ins. Since I've no idea what they do I can't really comment further on tht. Using normal Lua library functions only, or some external drivers? Interesting that the more ruthless method has the good result. I would have thought allowing the plug-ins to terminate tidily would be more likely to give a better result. However, that is interesting and maybe useful. In the current version of FSUIPC setting "TimeForLuaClose=0" would result in the default of 1 second in any case. I'm changing that so that setting it to 0 will immediately and ruthlessly terminate all plug-ins on session end, same as you doing a "LuaKillAll". Perhaps you could test it for me to see if it has the same effect. Please do it with that logging enabled and show me the log so I can see that it worked okay. The modified version is 4.958g, download link: FSUIPC4958g.zip That's only the FSUIPC4.DLL file. Just copy it into your FS Modules folder. That's definitely the tidiest solution (in the sense of "being kind to lua plug-ins") ;-) Pete