Pete Dowson

Please explain what you mean by "stopped" -- no response, or just bad response? Were you using P3D assignments instead of FSUIPC before? Because if P3D doesn't see it, then probably FSUIPC won't either -- though you say you managed to assign it and calibrate it? Check also in the Windows game controllers. See if it needs calibrating there first. Also check with a default aircraft jst in case it is an add-on aircraft fault. And you need to supply more information: FSUIPC INI and LOG files (ZIP and attach) in particular. Pete

Yes, I know. You posted it in your first message!! Your DLL.XML file is more interesting, but I can't determine whether it is corrupted, or those '-' signs in front of the start of every add-on is just an artefact of whatever editor you used to paste it or not. However, this line is most definitely not wanted: +<Launch.Addon> That will prevent all those following being added. i.e. all these: <Name>SquawkBox Transponder</Name> <Name>SquawkBox AI Control</Name> <Name>SquawkBox Internal Version</Name> <Name>RAASPRO</Name> <Name>Addon Manager</Name> <Name>PMDG_Interface</Name> <Name>FSUIPC 4</Name> So, first off, delete that line. But be careful what editor you use! If it still doesn't work, ZIP the DLL.XML and attach it to a message here, and I'll fix it for you. Pete

I assume you mean there's no "FSUIPC" entry in the Add-Ons menu when FSX-SE has finished loading and you are ready to fly -- correct? If there's a FSUIPC4.LOG file produced in the FSX-SE modules folder, i.e. in C:\Program Files (x86)\Steam\steamapps\common\FSX\Modules then please show me that file. If not then in all likelihood you had a corrupted DLL.XML file so the addition of the FSUIPC4.DLL entry isn't working, so FSUIPC isn't loading. I can check that for you if you show me that. It is found in: C:\Users\Corey\AppData\Roaming\Microsoft\FSX Pete

Okay, thanks. Please state if you are running these on the same PC as P3D or not. It looks like the default of 100 mSecs is well capable of dealing with local interrogations, as it works for 737-SimGuy over a WideFS connection, which obviously makes more of a demand time-wise. Pete

Does the ThrottleManager play sounds? Seems rather odd to me. However, the line sound.path("C:\Users\Myname\Documents\Prepar3D v5 Add-ons\FSUIPC6") needs to be sound.path("C:\\Users\\Myname\\Documents\\Prepar3D v5 Add-ons\\FSUIPC6") because the \ character is what is called an "escape", used to say the next character has special meaning (eg \n means "new line"). "\\" means 'yes really a \'. Quaint, eh? That's programming for you! 😉 That, mind, is assuming that the sound files (".wav"s) are in the FSUIPC6 folder. It's generally better to create a Sound folder there and put them into it, making the line sound.path("C:\\Users\\Myname\\Documents\\Prepar3D v5 Add-ons\\FSUIPC6\\Sound") Note that it would have been rather tidier, and simpler for paths, if you had installed FSUIPC6 into a folder such as D:\FSUIPC6. But now you are set-up there I'd leave it. However, best to clean up and remove your added Modules folder in P3D, unless some other add-on is also using it. I see you are also using LINDA. Is that okay since you moved things or did you uninstall it then re-install? Pete Ooops. I see John posted simultaneously!

Ah, right. Thanks. Then, yes, the 100 mSec default is more suitable and what I thought should be safe with WideFS too. I’ll let John know it’s okay to include in his next release. Pete

Okay, thanks. But I assume this is on the same PC as P3d, right? So if 50 mSec isn't quite enough, I'm wondering about WideClient access. Maybe it needs to be higher. I have my GSX displays on a WideClient PC but i've never noticed any problem. Maybe i just don't use GSX enough. I don't suppose you use WideFS do you? If so, perhaps it would be possible to try your application on a Client? Pete

As John said, no version of FSUIPC has ever started any Lua plug-in automatically except those specifically named for this -- see this part of the very first page of the supplied Lua plug-ins document, which you have: There are currently three explicitly reserved Lua names, for programs which are run automatically if present: ipcinit.lua automatically run as soon as FSUIPC has connected to the FS. ipcready.lua automatically run when FS is really “ready to fly”. ipcDebug.lua automatically loaded before any Lua program which is started in Debug mode. Pete

I still think you are making inappropriate use of the Lua plug-in facilities and you would find a much better solution if only your thought about it more. I am no longer the developer of FSUIPC and I know John has got a lot on already with the current needs of most users, especially for MSFS. So, I suggest you make a specific list of those Lua functions you need exporting -- not a general "all of this type ..." request, and either John or (maybe I) will look to see if there are any implications in terms of the changes we've made. Do this is a new thread, more appropriately entitled (eg "request for Lua functions to be exported") with perhaps some justification for each -- i.e how you will use it. Then, if John decides to go ahead, it will be on his timescale according to workload, and in all likelihood will be subject to a "at user's risk" statement. John cannot afford any increase in support workload. I'm closing this thread now. Pete

Because the calibration values are all default. All axes behave a little differently so the values are almost never the same as default values. Only if calibrated in Windows Game Contollers. They are the values recognised by P3D for minimum and maximum. The true values DirectInput gets from your device are only seen in Raw mode (selectable in FSUIPC if you really want to). This only applies to throttles, obviously, and DirectInput doesn't change anything, it's the calibration. -16384 or whatever your real minimum value is, is calibrated to 0, and then complete range -16384 to +16383 is calibrated to the forward thrust range of 0-16383. It's part of calibration (please read about it). LM are not Microsoft. If L-M prefer Raw mode that is the way they are programming their assignment system. RAW mode is a DirectInput option, it is part of the Windows HID device interface system. In FSUIPC RAW mode is advocated for use when an axis is being used to directly set a value, like a heading to be set using a POV axis. The Delta is then set to 1 so that every value is used. Please read the section in the User Guide which explains in some detail the pros and cons and uses. In my FSUIPC6 user guide this text starts part way down page 36, but easily found by searching for "Raw". Pete

Hmm. very strange. Okay. Let's see whether 737-SimGuy gets any useful results. Pete

Hi John, He's referring to the fact that in many real aircraft (Boeings for certain) the electric trim switch on the yoke is actually two switches side-by-side. Operating only one of them does nothing, you have to use them both together. (On my PFC yoke they are wired to only operate together in any case). He can program this by a simple conditional prefix on one of them, and only have that one assigned. e.g. 1=CR(+A,5)A,6,65607,0 for trim down, assuming joystick A, switches 5 and 6, Same sort of thing for trim up, and it's accomplished. Pete

Sorry, but i think you should seriously look at the possibilities with a separate EXE interfacing to FSUIPC / WideClient. It would be more efficient and more flexible for the users, including your good self. Pete

Why? Do you think my fix will not work? Did you try with different timings (adjusting TimeToDelayTexts)? Pete

It is not an "incompatibility" as such, but a result of your FSX crashing in a previous session. FSUIPC is normally the last thing to close (it has threads running to enable it to close plug-ins, WideFs connections and other autonomous activities), so sometimes Windows wrongly identifies FSUIPC as the problem and marks it so. Reinstalling FSUIPC never makes a difference -- you are simply replacing a DLL with exactly the same DLL. You could instead have downloaded the latest verison (4.976) and installed that, which would probably have caused Windows to reset the flag. Usually this is fixed by simply re-trying a few times, but please also see these FAQ threads: Pete

You evidently still haven't bothered to read the user guide section on Calibration! Of course the "Rev" setting takes effect if you have set calibration. Your iNI showed that you have enabled calibration (pressed the left-hand main Set button, but not bothered to actually do the calibration (other than setting "Rev" it seems). To disable calibration just go to the tab and press the Reset button! It is complex and different for each device. Best not to try editing the Registry unless there's no alternative. We can go through that later if it looks necvessary. Pete

Well, yes -- they would be two separate buttons so both are seen as different entities. And for button events the use of event.button is more appropriate. Pete

But "Mouse macros" are only a type of regular macro, and any macro can be invoked from any FSUIPC or WideFS client by simply writing its parameter and name to offsets 0x0D6C then 0x0D70 respectively. Not sure which are the "mouse macro" references in your example? But both FSUIPC and WideClient are prefectly capable of automatically launching application programs and the offset interface provides all you might need. On top of that the facilities now offered by Paul Henty's .NET DLL library makes everything really easy if you want to use a .Net managed interface instead of C++. But that talks about the Lua HID library. Why do you need to use a separate HID access for standard joystick devices? Are you saying there's a noticeable delay in FSUIPC's native joystick detection? Mainly because many of these have been changed to suit the internal machinations in FSUIPC. But also I don't see any justification. I think yours is a misuse of the whole idea of the Lua plug-in facilities we provide. Pete

It is simple to understand. The second overwrites the first. It is a simple parameter value, stored in the global reserved as IPCparam. Were you expecting multiple values to be queued up? For how long? I really don't think it is reasonable to operate such queues. How are you managing to send two successive LuaValue controls in the same millisecond? That sounds rather crazy! Are your fingers and keyboard or button device really so fast? There is a separate ipcPARAM value for each plug-in. Perhaps having separate plugs would solve your problem, however you managed to create it? Pete

Just deleting the FSUIPC5.INI file before starting P3D does the same job and it is far easier! Pete

Those are the normal maxima for a correctly registered and windows-calibrated joystick axis. They are related to entries in the registry. The "IN" values shown in Calibration are the actual values received from the DirectInput driver in Windows. They are not interfered with in any way whatsoever by FSUIPC. You can also select, in the assignments tab, a "raw" mode, which causes those DirectInput functions to bypass any registry impose Windows calibration, so allowing the actual USB-received values to be seen in FSUIPC. You have seen that your throttles are not all behaving in the same way. Does that not suggest to you that something is wrong? I really strongly suggest that you try uninstalling the device completely, drivers included, via the Windows Device Manager. Unplug it first. Then re-boot the PC and plug it back it and re-check. That should clean up the registry -- unless there are multiple entries, which we would have to tackle separately (that involves some serious logging to identify the entries involved). Incidentally, the 256 increment change is the "Delta" value set in the assignments tab. You can change it if you which, but, really, 256 is the minimum P3D is likely to ever see as a real change and lowering it just reduces performance as it gets many more inputs than it can deal with and any slight natural jitter in the values can make that worse. BTW, for PMDG Boeing aircraft most folks have found that FSUIPC calibration is not good. it seems it can cause conflicts, as PMDG code seems to scan devices itself in some cases. Mostly just assigning to the Axis Throttle ... FS controls and not calibrating seems to work best for most folks. Pete

I am still puzzled by your request. You are evidently capable of writing a C program, yet to seem to want to use what is and always has been intended to be simple scripting facilities to allow users to make relatively minor additions to FSUIPC's capabilities. Don't you think you are misunderstanding this, still? Why not, instead, write a separate application which interfaces to FSUIPC in the way it was originally provided for? This would be free of the constraints you are complaining about, and be easier to start, control and amend in any way you wanted. What is the real reason you are trying to exceed the controlled environment imposed on an FSUIPC Lua plug-in? BTW I note contradictions in what you are asking for -- "lua_" functions and "LuaL_", or just "Lua_"? And precisely which ones and why? I'd need to know in any case because some of these functions have been changed to suit the way FSUIPC's environment works. Your examples posted earlier don't accomplish anything which can't be done within the current provisions in any case, so don't really add anything to your request. If this was because you don't want to expose details of your plans because you intend to offer it commercially, then try using email. Mine is petedowson@btconnect.com. I don't mind discussing programming with a programmer, and maybe we can arrive at a more suitable way of achieving what you want. Pete

It would be interesting and probably helpful to know which SimConnect client each of those came from. This is identified by the numbers like [515] in each line. To determine those, please find each case of "Open:", for example: > 55.19912 [253, 1]Open: Version=0x00000002 Name="SquawkBox_Transponder" identifies [253] as "SquawkBox_Transponder". At the time SimConnect failed it looks like 3 separate add-ons were manipulating objects in the Sim, and all three were acting on the same object (ObjectID), presumably fighting each other. What ID numbers were allocated to FSUIPC? The would probably be two, one for the main interaction, the other for AI traffic data (unless this has been turned off). Pete

What about testing with the keyboard first? Possibly the add-on aircraft is doing something different. You could enable Event logging in FSUIPC's Logging Tab, and see what gets logged when operating the parking brake -- with keypress, button and mouse. It may be something such as the toe brakes seeming stuck on. You may not have toe brakes, but it is possible that the flight saved for that aircraft has them on. A more sophisticated add-on aircraft might release parking brake when any pressure is placed on the toe brakes that's quite a normal way of releasing it in a real aircraft). Maybe pressing the '.' key on the keyboard (default assignment for the brakes) will release them if so. and it would explain a possible difference between your P3D4 and P3D5 (because not much else could be different). Pete

You don't need to create a profile for all aircraft individually. You already have a profile entry for one of the A320's: [Profile.Aerosoft A320] 1=Aerosoft A320 professional EASYJET G-EZTC Just shorten that to 1=Aerosoft A320 and perhaps add 2=Aerosoft A319 etc. i.e. a short name recognisable for each Airbus. Then the same profile will apply to all. Currently you have no Profile-specific assignments. In fact you've not really done much at all -- the INI file is almost all default. So you could change the Profile name to "Aerosoft Airbus" for clarity: [Profile.Aerosoft Airbus] 1=Aerosoft A320 2=Aerosoft A319 Just make sure that whatever names you add are a part of the aircraft name and unambiguously so. Any way of assigning controls will result in instructions for them being sent to P3D. That's what it is all about. The "direct to FSUIPC" mode simply sends the controls only to the Calibration section of FSUIPC, which then alters the values according to your calibration (which you've never actually done!), and only then are the changed values sent on to P3D. With the normal FS control method, the assigned controls are sent direct to P3d, but if you have calibrated they are then intercepted by FSUIPC just before they reach the aircraft itself, and calibrated then before being returned to the Sim. The "direct to FSUIPC" method is obviously more efficient, but some aircraft (Aerosoft Pro range, and PMDG Boeings) sometimes don't like it as they do their own interception. This doesn't apply to all controls -- in the PMDG ones it's mostly with the throttles. But none of that explained why your Aileron control works, but your Elevator control doesn't. That's why I strongly suggest you start with a default aircraft, not an add-on one. Get it working properly there first. Then we'll know what to change for the Airbus. And if you are going to bother to use FSUIPC properly, I suggest that you do read up about it first. It is like a bag of tools. Find out about each one before using it. If you do decide to use the calibration then you should most definitely follow the numbered steps in the Calibration chapter. So far you've not calibrated anything -- excpet apparently the rudder where you've stopped it working altogether (all values = 0). Finally, you should really read up about "trim". The elevator trim is one of the most important controls in an aircraft and has to be learned and understood by all trainee pilots -- it is very important and is NOT the same as the elevator whose use is more immediately obvious. Pete