Pete Dowson

Well, that's not so according to the logs. FSUIPC ran properly both times since you removed the Lua plug-ins. Who produced this "GoFlight Interface Tool"? Why does it use an Network connection? Pete

The "gitlua" you are running appears to be dealing with other Lua files in your modules folder -- sending details over a Networked connection to a Client program. I tried to find details of "GIT" but the only things I can find by that name are all to do with programming and programming tools. Are you a programmer? Unless you know what these Lua plug-ins are doing for you I suggest to leave them out of the system. If you do need them for a known reason, rename the "ipcIni.lua" file as "ipcReady.lua" so it doesn't cause the GIT part to snarl up FS initialisation. Pete

If it hung with no CPU activity, how come FSUIPC ran quite happily, started correctly, as shown by: and ran for a total of 578 seconds before being closed quite normally, showing a decent average frame rate for the whole period? What you say and what you show don't match! Since both times, after removing those Lua files, FSUIPC has started correctly according to the logs, I believe something in one of those Lua plug-ins does things which shouldn't be attempted before FS is finished initialising. So, could you please paste their contents here, or attach them (Zipped) please? Evidently the reason things apeared okay when FSUIPC isn't running was because the damaging Lua plug-ins then weren't being run. Maybe the other problems you now see are due to something you are running needing those Lua plug-ins running? You say you don't know which program installed them ... so, is it not now about time to go through a process of elimination, not running any other programs initially then adding them back one by one. Pete

The log as shown isn't complete! It doesn't show it was successful -- if that's the complete log, then again FSUIPC never managed to start! You need to see at least the "Starting everything" message. Can you try removing your Lua plug-ins from the Modules folder, please? The log shows 37579 LUA.0: beginning "D:\Prepar3D v3\Modules\ipcInit.lua" 37579 LUA.0: ended "D:\Prepar3D v3\Modules\ipcInit.lua" 37594 LUA.1: server: waiting for client connection... Not sure why you are using "ipcInit", which is forced to run BEFORE everything is ready. Is there a good reason for this, rather than using ipcReady.lua, which runs when the system is ready? Pete

Did you try starting P3D with a default CFG file? If so and it didn't help, please show me the fSUIPC4 log. Pete

But it did run, and it couldn't stop P3D running. It was running fine till you closed P3D, as shown here: What appears to be missing is the "Starting everything now" line, which means FSUIPC never got a signal from SimConnect to tell it things were ready to go. How long were you in the initial menu where you choose flights, or do you bypass that? When the correct signal arrives, FSUIPC logs these lines (obviously with different data): 48220 System time = 31/08/2016 15:52:25, Simulator time = 12:22:30 (12:22Z) 48391 Aircraft="Prosim 738 British Airways" 50217 Starting everything now ... The lines are logged as soon as SimConnect responds with the User's Aircraft data. Without this FSUIPC cannot proceed. I've really no idea what could cause that. I've never known it happen before. Could you try starting P3D with a default Prepar3D.CFG file (i.e. temporarily rename the current one, so it makes a new default one). If that's okay then it might be something to do with the Flight or the Aircraft it is trying to load above, i.e. 35218 C:\Users\Arndt777\Documents\Prepar3D v3 Files\Start Duke B60.fxml35218 D:\Prepar3D v3\SimObjects\Airplanes\RealAir Duke B60 V2\RealAir_Duke.air If you are loading that flight from the menu, try another, or just select an airport and different aircraft. You say: If you can work out what you've changed or updated before these "last days", and what the difference is between the 50% which work and the 50% which don't, that would certainly help a lot to narrow things down. Pete

Well, yes, but you'd have to assign the axis to a lua script instead of any FS control, then decide what to do in that script. You can send the value to the correct FS control there. On this: This is very very strange indeed. The AutoAssignLetters is not in any way related to wither Reloasd or Rescan buttons. It simply isn't involved unless a new USB device is seen. Maybe it would be a good idea to show me your FSUIPC.INI file. Paste it into a message. I'm afraid FSUIPC3 is really out of full support now, but if there's something obvious you can fix you end I can let you know. I don't even have FS9 any more, let alone CFS2. Pete

To deal with this oddity first, could you explain what you mean by variables "monitoring" features? I don't understand the reference. On the main point, if FSUIPC really did "forget" to load the axis assignments then there would have been a lot of other support messages arriving here. FSUIPC3 has not been changed for a long long time and is no longer under development.. Even FSUIPC4 is now 11 years old, but still being developed because of FSX-SE and Prepar3D. I think about the only thing which could make it appear to do that is if the USB device were disconnecting and reconnecting with a differently Joystick ID. If you are using Windows 8 or Windows 10 I do believe this is possible as Windows itself now no longer sets those IDs -- only the drivers do, and many of those don't either. All I can suggest is using the JoyIDs program to set a joystick ID yourself. Also, use Joystick Lettering (page 25 in the user guide). That might help track it. The JoyIDs method is referred to in the FAQ subforum, see the topmost thread, entitled " Fixing joystick connections not seen by FSUIPC". Pete

Well, you should be able to do what you want using the Lua GF library to make a plug-in for FSUIPC, but only if you can get the values you need out of the Q400. It may not be possible. Pete

just installed MakeRwys v4.699 in fsx main folder , double clicked the MakeRwys.exe, the window that comes up runs ok but at the top it says v.4.692? If it says 4.692 then it most certainly is NOT 4.699! You've evidently not replaced an old version! Er so where do YOU double click it if not in Explorer? How do you see it to run it? You said How are you seeing contents of folders if not in Explorer? I don't understand! Pete

Each section -- Axis, Calibration, Buttons and Keys have their own "Profile Specific" checkbox. Just because the aircraft has a profile in one section doesn't mean it needs to have one all the other sections. That would reduce the flexibility of the system. You simply need to select profile specific once in each section you want it to be specific! Pete

The WideClient log shows a normal termination, no "death". And the averagler performance looks good too! So, you ran it for 23 seconds and had good performance throughout! The Client log is only one half of the story. Please always show both client and sever logs! (WideServer.LOG from the FS Modules folder). Pete

Just select the relevant profile for each aircraft (when loaded) in the Calibration tab and do a basic calibration and "OK", and the calibration section for that Profile will go into it's own INI file. Same for buttons and keypresses and axes -- no different! The Profiles INI's contain all sections which are specific to a profile. If you've not chosen a profile for calibration then naturally it will apply to all aircraft. Pete

No. The Installer searches for ALL versions of P3D, so it looks for both! You aren't reading the Install log correctly. Well, 4.853 doesn't support P3D version 3 at all! It is very old. There are no files on the site where the license is purchased, there's only a link to the Schiratti site where there's a link to my files here, and they are most certainly up do date! Just re-run the installer. Pete

Thinking about this a bit whilst walking the dog, I realised I still may be misunderstanding you. Looking right back, I am now wondering if your description above is really correct and complete? A normal toggle switch is a latching switch with (usually) on or two poles and one or two "throws" -- like a light switch. When switched on two contacts are joined, when off they are separated. The closing of the contacts would be detected by your game controller which sends a button press indication. Since you say it is "momentary" I assume the controller sends a button down and a button up. In the video you seemed to be showing that the switch is spring-loaded to "off". Is this correct? Was this your choice of switch, or is it out of your control, because it is certainly the wrong type of switch for this action. However, that shouldn't stop it being used as a toggle in the way I said above. What remains to confuse me then is that you seem to be saying, in the video, that whilst holding it, against the spring, doesn't cause any new events, just releasing is causes the button press again! Is that right? Same button number detected when pressed down, and when released? Is the toggle switch perhaps wired with the 'off' position and the 'on' position both connected to the same place on the controller, thus giving two identical button presses with one press and release? If so, why? I think a better way of showing me what is going on would be to enable Button/Key logging in FSUIPC, then operate the button once down and release, and let me see the resulting log. Of course, the button flag method I showed in my previous message can easily be used to ignore every other identical button press, and then you could use another button flag condition to determine whether to send "battery on" or "battery off". (If the PMDG aircraft supported Battery toggle instead then this would obviate the need for this extra condition). Pete

Rather than a video, why didn't you simply say you need to make a button send Battery Off and Battery On on alternate presses? The PMDG aircraft have their own "custom control" numbers (NOT "offsets" -- calling them offsets simply confuses things completly. Offsets are references to data in memory. There are a large number of offsets added for PMDG 737NGX and 777X aircraft, and they are listed in documenrs found in your FSUIPC Documents folder. Offsets contain data which is used to feed displays and so on. The PMDG offsets control nothing. All the PMDG custom controls are extensions to the normally assignable FS controls, and the latter are, mostly, ignored by PMDH -- as you found with "Toggle Master Battery". It's a little odd that the battery switch on your panel is spring-loaded to off. On the real aircraft it's either on (down) or off (up). So I assume what you want is for the identified button to send "battery on" and "battery off" on alternate pressings. If you know the correct custom controls for Battery on and battery off, then in FSUIPC this is easily done using the button's "flag". Here is som text from the Advanced User's manual (page 24): Since the button flag changes on each press, you can use the same j, b button identification as the button you are using. So, if it is joystick 0 button 14: 1=CP(F-0,14)0,14,<custom control number1>,<parameter1> 2=CP(F+0,14)0,14,<custom control number2>,<parameter2> All you need to do is find the correct custom control numbers and parameters for Battery On and Battery OFf. I don't have or use any PMDG aircraft so I can't help you there, but from the video it seemed like you found them. Pete

No need to delete. But use MakeRunways 4.699 now -- a bug was found and fixed in 4.698! Pete

If there's no FSUIPC4.KEY file then you've never actually entered a registration in the Installer. Just run it again and do it correctly. Pete

You certainly must be doing something wrong. I'll check it for you. Please find the FSUIPC4.KEY file in the Modules folder, make a copy renamed as FSUIPC4.TXT then ZIP it and send it to me at petedowson@btconnect.com. Do NOT publish it on the Forum. Pete

Oh dear. The verdsion of FSUIPC you are using is long out of date and is not compatible with P3D 3.3.5! The latter came out long after that version! You really do need to check for updates! Pete

Not in FSUIPC, but I can't say P3D hasn't changed as I don't know. I can't really help in any case without details. Please find the FSUIPC4.LOG file (in the P3D Modules folder) and paste its contents here. This assumes you have a plug-in called "DynamicFriction.lua" in the Modules folder. Have you? Pete

The Registration details are entered in the installer window when prompted, not during download. If your registration isn't accepted then either the date in your PC is wrong, pre-dating your FSUIPC purchase, or you are making an error when entering the details. All three parts -- name, email and key MUST be exactly as written. If you think you've done things correctly, please close P3D and find the FSUIPC4.LOG file, also in the Modules folder, and show me that, complete. That file is the run-time record of FSUIPC running. Pete

I actually said the "next version". You don't yet have the next version! I hope to release the next version in the next week! Pete

Fixed in 4.699. Sorry about the mistake! Pete

Sorry, I don't understand the "code above". What did you intend by it? You seem to be making a simple thign very complicated. Why all the conditional stuff? Have you tried FSUIPC logging at all? Sorry, I really can't see why there's a problem in the first place! Why not simply assign to what you want to do? Pete