Pete Dowson

You probably set an option in LRM to get it to load automatically, or it is loaded by an entry in MSFS's EXE.XML (like FSUIPC7). It isn't being started by FSUIPC7. LRM is using FSUIPC to operate. When your system is loaded your aircraft is placed on the runway, and I expect LRM treats that as a good landing. If you don't run FSUIPC7 then LRM can't get information from MSFS. Pete

It might be the SimConnect client count problem. There are parameters you can change -- for SimConnect (increasing client count) and for FSUIPC's re-connections. You can either wait for John to reply (after the Easter break) or check through the other threads as I'm sure there are answers here. Pete

The logs show nothing except that WideClient cannot connect to the PC with IP address 192.168.1.62. So either that's changed, or it is being blocked by a firewall, on either PC. The software itself hasn't changed, neither, I assume, has your INI file, but evidently something in your system has changed. You'll need to track that down and fix it. Pete

In that case you also need to state whether ProSim was configured to use FSUIPC, or Simconnect directly. Pete

You would have no problem with the black console window if you removed all of your "printf" function calls. The one that does the damage initially is the "FSUIPC OK" message. If you must have messages you should create a log file and write to that. FSUIPC can also have a console Log (as well as the file LOG) -- it's an option on the Logging facilities. Well, all READY is doing is waiting until FS is ready to fly. FSUIPC cannot possibly stop your aircraft taking off. That's down to your code, as everything has been. You simply will not believe me that your program is not programmed properly for what you want to do. Better has been achieved with a simple Lua plug-in (see the pair MasterClient.lua and SlaveServer.lua plug-ins in your Example Lua Plugins ZIP). Yes, but that's the only way your program terminates. These two lines in your program are just waste as they can never be executed: FSUIPC_Close(); //Closing when it wasn't open is okay, so this is safe here return 0 ; If you didn't use printf you'd not get one in any case, as I keep saying. Use a log file instead, or use printf for errors not "FSUIPC OK"! I'm closing this thread now. I've nothing more to say. I keep trying to help but you ignore my advice, and keep blaming the simple Run facility for your erroneous program.

Hi Vernon, FSUIPC7.EXE is a separate program. If it crashes, why not just restart it, not MSFS? Anyway, John will need a lot more information: at minimum the FSUIPC7.LOG and FSUIPC7.INI files from the FSUIPC7.EXE folder, and the Windows crash data from the Event Viewer. It would probably also be useful to say what aircraft you had loaded, and what other FSUIPC or SimConnect client programs are running. Pete

One thing just occurred to me. Looking carefully at your “black window” is see that it isn’t entirely black. There appears to be a message in it. Looking again at your code I see you use printed statements. Where do you think those messages are going? I now think that window is a console window being created to receive your messages! I also see that you have an FSUIPC close call and a return 0 at the end, outside a loop which can never end. So what are they for? How do you expect the program to end? Only by being KILLED? Pete

FSUIPC saves the SiMConnect window in case you ever use the facilities to restore them after moving them. Nothing to do with your program, unless you are using Simconnect Windows directly? As the documentation tells you, the HIDE (and other initial Windows options) doesn't override what your program wants to do. it can only affect the default -- i.e. what Windws will do if you don't declare a Window position or state. Same thing. I think you just may need to learn some basic Windows programming. I'm sorry, but this is not the place and I’m not the person . Pete

All that is doing is asking Windows to load that program! Everything you have going wrong is to do with that program! Just try running it yourself using a desktop shortcut. That will load your program too. Having it loaded automatically by FSUIPC just saves you that bother. It does nothing else!!! You seem to be completely misunderstanding. You asked how to load the program automatically and i told you! Loading the program does nothing but load the program. Everything it does then is your doing, your program! I suggest you get your program working properly first, before having it automatically loaded! Look at your code! After EVERY "FSUIPC_Write" you do an "FSUIPC_Process". Each time you do that you are asking Windows to switch processes. Each of your written values will arrive separately, and things are terribly inefficient with all the process switching. Just remove ALL of the FSUIPC_Process calls and put just one at then end, before the final } of the loop. Then all the values will be written inb one call! Pete

Sorry, I've no idea what this is about. And that black window is obviously created by your program, it is NOT from FSUIPC. You need to know how to write a program which sits in the background -- for instance, defining its window as a Message Window. Check Microsoft programming websites. FSUIPC in an interface. It merely sends your requests to the Sim. Everything thgen is up to you. I cannot tech you Windows programming. Pete PS you are still doing too many FSUIPC Process requests. Just do one per loop.

It is not one of our programs. You should not have multiple FSUIPC_Process calls for a set of data to be written together. Just use one Process call after Writing each value. Additionally, if this is to set the initial position you should use the "INITIAL POSITION" as described for offsets 0558 and 055C. For this method you must write all of the values with one Write call -- i.e. put them into a local structure of the correct length before writing the whole area. Finally your loop has no time allowed for any reaction to do what you are requesting. You need a Sleep in there somewhere! No idea. It's related to what you are doing and what P3D makes of it. FSUIPC is not doing anything but what you ask it. Try improving your program as per the suggestions above. Pete

You use the one from your FSUIPC4, FSUIPC5 or FSUIPC6 installation, as described in the Installation document. If you haven't yet purchased WideFS7 then you'd need to go and do that to get a key. Pete

Sorry, I don't understand what you men. The P3D window has nothing to do with other programs which may be run via [Programs] -- unless those programs themselves are causing a problem. I do not know this "FSUIPC_YIN.EXE". I have many programs loaded in this way, and P3D still loads and displays perfectly. For example, this is an older version from my cockpit setup: [Programs] RunIf1=AM=x88,CLOSE,MIN,"E:\REX Sky Force 3D for Prepar3D v4\rexskyforce.exe" RunIF2=AM=x4C,KILL,"E:\mcp\pfcmcp.exe" RunIF3=AM=x3C,READY,CLOSE,"E:\ProSim737\prosim737.exe" RunIF4=AM=x4C,READY,CLOSE,"E:\ProSimMCP\prosimMCP.exe" RunIF5=AM=x48,KILL,"E:\pmsounds\pmSounds.exe" RunIF6=AM=x24,CLOSE,"E:\ProSimAudio\ProsimAudio.exe" RunIF7=AM=xC4,CLOSE,"C:\Program Files (x86)\HiFi\AS_P3Dv4\AS_P3Dv4.exe" RunIF8=AM=x50,CLOSE,"C:\Program Files\AivlaSoft\EFB2\Server\AivlaSoft.Efb.Server.exe" RunIf9=AM=xA0,READY,CLOSE,"C:\Program Files\FSPS LTD\FFTF Dynamic P3Dv4\FFTF Dynamic P3Dv4.exe" RunIf10=AM=x48,READY,CLOSE,"E:\SimSounds\SimSounds.exe I think you need to check exactly what that "FSUIPC_YIN" program is doing. Pete

Okay, found it and fixed it. Simple change, daft error on my part. i've sent the fix to John for him to incorporate in another Beta release (or maybe full release, soon). It will be needed in FSUIPC7 as well. Pete

But that's certainly not what I would expect with it being assigned to "Pan Left". Panning goes a little at a time (which is why you have it set to repeat I assume). It won't change its behaviour after being pressed once. It can't change from a View Left to a Pan Left when it is assigned to Pan Left. Please check again, with version 13 if you like. These are your assignments to that POV: 19=RB,32,C65734,0 -{PAN_UP}- 21=RB,34,C65672,0 -{PAN_RIGHT}- 16=RB,36,C65735,0 -{PAN_DOWN}- 22=RB,38,C65671,0 -{PAN_LEFT}- Basically you can achieve the same, only smoother, assigning the POV as an axis to Pan View. The 4 panning controls you are using are all embodied in the Pan View axis assignment. The only problem with this in build 14 is the signalling of a button press 255 when it's released. I'll work out why and fix that. Pete

When you removed one did you uninstall it properly in Device Manager? If not, the registry entries for it are probably still there, with the ID of 1. This doesn't matter really, as John says, unless of course you attach more that 15 joystick devices in which case you'd need that wasted ID. Pete

Buttons 32-39 represent the 8 possible switches of a POV (Point of view) control, one of which is also seen as an axis. So, not true buttons, just the way FSUIPC interprets the angle of pressure. However, when released it should revert to "unpressed" (which is signalled internally as -1, so could be interpreted as 255 in 8 bits). I'll check this. If there's no allocation, how did you get a weird response? Sorry, I don't understand that. How would you describe this "weird response". As there's no allocation why would you get any response? [LATER] Yes, I can reproduce this. I'll look at the code later today -- it's evidently taking the -1 from Windows literally. Thanks for the report. I see also that the POV is assigned to the 4 main PAN controls, with Repeat enabled. So with no release I can understand why the repeat is causing a problem for you. Isn't this POV control recognised in the Axis assignments tab (it should be)? If so, for panning, you'd be better off assigning there and to 2PAN VIEW". You have two other POV's assigned as well. on Joys A and C, and many of those assignments are also with repeat enabled. Pete

You could try assigning in the "send to FS" mode to the Axis Left Brake and Axis Right Brake controls (instead of "Direct to ..." mode). Then calibrating (using the slope if needed), and / or you could set UseAxisControlsForNRZ=Yes in the [JostickCalibration] section (or the one for the Profile for your A320). But I'm not sure the latter option works with brakes. I've no other reports of brake calibration problems with the A320, so you might ask in their Forum. Pete

This is due to a previous FSX crash (CTD). When FSX closes because of a crash FSUIPC often gets "blamed2 by windows as it have a number of threads which take longer to close down, so it tends to be the last DLL still running. Once it gets marked as a possible cause, it stays marked. If this is the problem, then this FAQ subforum reference thread may help: FSX automatically mistrusts modules (FSUIPC not loaded) - solution Unfortunately the Install log you supplied is not relevant, as FSUIPC is already installed so it isn't an installer problem! The relevant file to check would be the FSUIPC4.LOG file, which will show how far FSUIPC gets before the crash. This will probably indicate that it is about to get the weather data. a crash there is ALWAYS due to a correct weather file in your system, one which causes SimConnect to crash when it tries to read it on behalf of FSUIPC. For this possibility see This FAQ thread: FSX or Prepar3D crashes when FSUIPC reads weather data from SimConnect Pete

For a complete explanation of all the parts as well as facilities for programming buttons with coditions, you should refer to the FSUIPC7 for Advanced Users manual. On page 16 a section called FORMAT OF BUTTON DEFINITIONS begins. There you'll see there are 4 alternatives for the "action" (the first letter), not just two. Pete

You posted the same thing to two Reference sub forums clearly marked NOT for Support Requests!! Do NOT spam this Forum or you will be blocked! Your FSUIPC options Window is appearing behind the Sim Window, which should go black anyway. This is normally a video driver problem. You can still get to it via the task bar or using Alt + Enter to switch to Windowed mode. And pressing ESC will exit the options and continue the flight. Pete

Most likely that addon model is processing the brake directly and doesn’t see the calibrated input sent direct to the Sim. Pete

For COM devices, or USB devices which are not classed as HID by Windows, you need to refer to the Windows Device Manager. Pete

Does the PMDG have its own clock, or are you referring to the default sim facilities? The default clock is a self-contained gauge which just reads that same time as you. If you are programming your own clock you'd need to do the same yourself, including acting on the buttons to start the ET and timer modes and so on. Subtracting the time at which the button was pressed to start it from the current time will give you the Elapsed Time. This is how i've programmed the clocks in my cockpit. There's a possibility that the on-screen clocks may have L:Vars for the various displays and modes, but I don't know. You'd need to list them and see. I don't use PMDG models. Pete

Okay. I didn't understand that. Did they also create the A320X profile, which only has and [Auto ... ] section to load a Lua program called "PMCO"? If they need those two throttle assignments (with the action for reverse engagement at idle), they you'd have thought that they would have also added assignments for the other flight controls. Also, really, if the assignments they have added are supposed to be specific to the A320 then they ought to be in a specific assignments section for the A320 profile. I find it rather odd that FSLabs depend on FSUIPC. I thought it would be the opposite. Anyway, reading back a little I see you said So, whilst FSUIPC may not have such assignments, the fact that controllers are enabled in P3D will mean that it is probably active there. Check what P3D is assuming with these connections. At least, I assume "T.A320 Pilot" is not the "sidestick"? Anyway, I do hope that your endeavours since then prove fruitful! Pete