Pete Dowson

Okay. I confirm that in the outside spot view (at least -- not tried the others), Pan Left and Pan Right do nothing, whilst Pan Up and Pan Down swap ends -- nose or tail. However, Pan View, the normal axis assignment most folks use for views on hats, works okay, same as in FSX. I have to wonder why you don't use that? It is still worth reporting to LM, though I can see why no one would have noticed. Pete

Fist, check the box saying "NRZ" or "No reverse zone" (though from what you say I assume you've done that). . Then follow the numbered steps for calibration, making sure you have a good stable idle zone -- an area, not just one position, which is giving zero for the output value. When done correctly there is no possible way to get reverse from the throttle levers themselves -- it will then only be the reversers .... so: It's the same thing. You need a null zone, NOT just a single position, which is giving 0 as output for a small range of the reverser. The problem is that the same position, even at the end stops, is not always giving the same input to the sim. Variations occur due to minor variations in temperature, humidity, voltages, etc. You ALWAYS need max and min areas, not points, same with hands off positions on yokes and pedals. Again, it's exactly the same reason Pete

Definitely file a bug report -- not about a hat, but about the controls which should work but don't. I'll try to corroborate that when I've had a chance to try them. There are probably many little problems in P3D which are still to come to light. The only way to get them fixed is to get them on LM's list. Regards Pete

It wouldn't be the com library, for sure. that is so wrapped up in the standard Windows i/o functions it would be a nightmare to mix into that. Looking at the existing server/client examples, I don't really see a lot wrong with using the socket options as they are. The serial stuff is done using a separate thread from the Lua threads to monitor the devices in real time, accumulating stuff in buffers and so one before initiating the event. The sockets stuff is different -- the thread is held suspended automatically by the accept and receive calls. So they have to be executed in the Lua thread in any case. No events are needed to awaken a thread which is merely waiting for something to occur. The loops in those aren't bad loops because the requests I mention do the suspension and the event is their return. Honestly, I don't think there's a lot to be gained in changing things. Putting another layer on top of the sockets system calls just seems to make things less efficient and less flexible. However, I've kept your suggestions on file and may look again when I find myself with less to do than usual. Regards Pete

No, I have NEVER provided anyone with a patched SIM1.DLL. It is actually not legal to post Microsoft files for all to download. That is because with the previous version it was not being logged, but the check was still there. I added the log entry to make it clear to me and others when using the assorted P3D versions and patches whether something needed changes. Pete

The reason it's WideClient only is that it is for the ButtonScreen, which is a WideClient facility. If there is no WideClient there is no ButtonScreen! Why not just use a user offset, such as 66C0, and the assignable offset controls to set values there which can be easily read by your client-run Lua program? WideClient automatically runs any Lua script it finds in its folder. Use events to determnine when those scripts should actually do somethnig. Pete

You cannot have lines like 23= in an INI file. They count as non-lines, they are simply ignored. For a blank button space you must specify the blank, so: 23=B" " or even just 23=U as per the example in the doc. Pete

Do those controls work when assigned to other keys in P3D? If they work in FSX but not P3D then you will need to report it as a bug in the P3D forum. FSUIPC will simply be sending them as they are. Let me know and when I get time I'll try them in my P3D -- are you up to date, P3Dv2.1 with the latest patch for the panel problems? If not, do that first. Pete

Hmm. The problem appears to be that FSUIPC isn't actually getting started in flight mode. There should be a log entry saying "Starting everything now ...". Assuming you were in flight mode, ready to fly, at some point before you closed down, I think there's some messages from SimConnect, essential to FSUIPC, which are not arriving. Are you starting up in Paused or Slew mode at all? There are some logging options which I can get you to switch on which might tell me more. Pete

Yes, it is all okay. All the errors are for the installation of FSUIPC for P3D version 1. You appear to have version 1.4 entries in your registry now pointing to the same place as P3D v2. I suspect you uninstalled V1 incorrectly, so registry entries were still left pointing to the wrong place. Then when you pointed the Installer to your V2 EXE file after it couldn't find the V1 EXE there, it updated the V1 path to point to V2. See this part of the final log which is referring to P3D v1 not V2 (which follows successfully, later in the log). INSTALLATION FOR Prepar3D: SetupPath="D:\Lockheed Martin\Prepar3D v2" Checking version of the Prepar3D EXE: ... Version 2.1.9936.0 (Need at least 1.0.677.0) Pete

What version of FS? What version of SIM1. All this means is that the SIM1.DLL you are using is probably patched already. Some folks took advantage of a patched SIM1 from somewhere on the Internet, and the friction values in it were not original. Replace it with the correct SIM1 for your version of FS. Pete

There's absolutely no change in any such area. The difference you are seeing is merely that Axes and Calibrations are either Profile related or not, whileh keys and Buttons are both operating together -- general and profile options apply. The profile ones only override the general ones for the same key or button. This is what allows you to have all common things generally assigned with only differences in profiles. You can't do this with axes because unlike buttons and keys, axes are always alive. And it has always been this way in FSUIPC for more years than either FS9 or FSX have been available. .Where are the Log files -- WideServer.LOG and WideClient.LOG? Without information I cannot help! Pete

What for? If you have a question wouldn't it be better to state it clearly in a new thread? Pete

What events are you thinking of? The com functions already have the event ("event.com") specifically for getting control when there's received data to be processed. Rather than have any loops, better to use the timer event to wake you up to process things at regular intervals. Pete

Well, I've not changed your install of FSUIPC whilst I've been on holiday, so someone else must have done it! ;-) Is the Pan View assigned in FSUIPC? Let's see. The log file you supplied appears not to be a current log (which would be named FSUIPC4.LOG) but an archived one (FSUIPC4.1.LOG) from October 2013. So that's not helpful at all. The INI file shows you are using an out of date version (4.927a). The current supported version is 4.929. It also shown a great many assignments to joystick 0, which is: 0=Saitek Pro Flight Cessna Rudder Pedals and only one per profile to device 1: 1=T.Flight Hotas X so I woud guess that you've disconnected these at some time and plugged them in differently, or in a different order. If you want to do things like that I strongly suggest that you use the joystick lettering facility (see contents list for the FSUIPC User Guide). Just change this section: [JoyNames] AutoAssignLetters=No 0=Saitek Pro Flight Cessna Rudder Pedals 0.GUID={2F122DF0-5981-11E2-8001-444553540000} 1=T.Flight Hotas X 1.GUID={05B0A020-0713-11E1-8001-444553540000} to this: [JoyNames] AutoAssignLetters=Yes 1=Saitek Pro Flight Cessna Rudder Pedals 1.GUID={2F122DF0-5981-11E2-8001-444553540000} 0=T.Flight Hotas X 0.GUID={05B0A020-0713-11E1-8001-444553540000} Pete

Just grab it, size it, move it. If you like you can undock it and move it outside the FS window. Alternatively you could have it displayed in the title bar. Pete

K90,8 is not "ShiftZ" but merely "Z". ShiftZ would be K90,9 Pete

I have seen other folks say this is the case, but I don't understand why it should be so as FSUIPC pretty much uses the same DirectInput methods as FSX. No, not exactly. you must not have axes assigned in both FSX and in FSUIPC or they will conflict. So what other folks say about Win8.1's problem fixed by using FSUIPC isn't actually true? Hang on, there's some ambiguity here. Are you saying the controllers work but get lost later, as before, or that you don't get them to start with? If the latter you are making an error somewhere, so you'd need to tell me exactly what you are doing. If you are assigning direct to FSUIPC then you MUST also calibrate. Also, always test with default aircraft. Some add-ons don't like some ways of assigning FSUIPC controls -- there are at least three ways of doing everything in FSUIPC and they are all different. Pete

Those are the default values, so you don't appear to have actually claibrated the trim at all? There are 4 values in any case, not 3 -- the centre null region is defined by 2 values. One value can't define a region. Please check the Calibration chapter in the User Guide. You'll find a series of numbered steps. Follow those. It seems the centre is actually well off-centre, than. Obviously if there is more movement available for the wheel one side of the "0" input that the other, then each movement will be worth more in input values. This is precisely why you need to calibrate correctly. Find the centre of the actual wheel movement and calibrate the centre around that, do NOT just leave it to default at the ipnut 0 position as you have done! Pete

4.929 is the current supported version. Please use that. If you still get a problem I need to know EXACT details. RC reads the weather from FSUIPC which it turn gets it from FSX's Simconnect. If you are only concerned with runway assignment, be aware that RC selects runways using different criteria to FS. Tell me the differences you see in the ATIS, don't just say "they are not the same". And are you talking about departure or arrival? I use ASN + RC and it is always spot on. Pete

Software doesn't change by itself. It sounds like you've lost or deleted the settings in your INI file. Hmm. So not all your settings are lost. So you have an INI file but with some conflicts or corruption. I'd need to see it. So, only one section of your INI file is corrupted, which is good. Uninstalling and reinstalling changes nothing whatsoever -- how can it? The settings are NEVER removed -- that would be disastrous for many folks who've spent a long time setting things up. When "reinstalling" you should always use the current supported version -- you are out of date. 4.929 is current. Pete

The "same thing"? Same as what? Your post is isolated, so I've no idea what you want to know. Pete

You need to assign BEFORE calibrating. Perhaps the particular controls you assigned to aren't implemented in the specific add-on aircraft you are using? without more information detailing exact;y what you are doing, I can't really help further. If you like you can paste your FSUIPC4.INI file here ad I can see from there what you have done. The manual clearly states that to confirm changes you merely press OK. If you exit by 'Cancel' or pressing ESCape then settings are not changed. This is the way all Windows programs work and is quite sensible and normal. Why do you nee separate assurance? There is never EVER any need to "restart FSUIPC4", and in fact there is no way to do so without restarting FS itself. Pete

Is there auto-refuelling? Do you mean when you pull up a GA aircraft to a pump? You could have a Lua program monitoring the fuel quantities and not allowing them to rise, only fall -- i.e. read the values, keeping the previous ones, and when an increase is detected, re-write the previous value. Pete

This is more a question for PMDG support than FSUIPC -- I don't use any PMDG product so I can't help directly. However, there are plenty of helpful submissions in the User Contributions subforum where folks have solved pretty much everything for the 737NGX. All of the PMDG controls are accessible through FSUIPC, but you'd need to look up the numbers in the documents supplied and installed with the NGX. Alternatively you may be able to assign keypresses in the PMDG options, and then program buttons to send those keypresses. Pete