Pete Dowson

Separate axis calibration (on the 4 throttles page) has always features reverse, centre, and forward ranges -- 4 different points of the axis. If you aren't seeing this you have the "No reverse zone" option selected -- top left on that page. Pete

No version has ever processed whilst the Sim is stopped for a dialogue. Too many unwanted complications would ensure! Pete

Yes, as always. FSUIPC doesn't process whilst the Sim is in a dialogue. Pete

No. How could there be? Everyone has different needs, different s for performance and response, which would liker ly vary according to aircraft type in any case. You don't need to delete anything. Just DISABLE controllers in P3D altogether. You cannot make assignments to buttons or axes in both. They will conflict. You also need to be clear WHY it is you want to assign in FSUIPC. Do you want the Yoke to behave differently for different aircraft? If that's all you want, you do NOT need to assign in FSUIPC. Just assign in P3D and calibrate in FSUIPC. Same if you merely want better calibration, or to adjust the response. The main reasons for assigning in FSUIPC are: 1) you want to assign to functions not directly offered in P3D, and/or 2) you have two different sets of controls -- eg joystick for fighters and Airbuses, yoke for other aircraft., and you want the appropriate controls to be activated when you load the relevant aircraft. Pete

Yes. Stop using an add-on aircraft which freezes the sim whilst it collects all of its subsystems data for saving. Or don't use Autosave -- do it manually, when you are responsible for the freeze and so expect it. All AutoSaves do, whether FSUIPC by or any of the other add-ons offering that facility, is call the Sim asking it to save a flight, just as you do when you use the Menu to do it. Those clever add-on aircraft (PMDG for example) detect the flight being saved then freeze the sim so they can save their data, and with such aircraft there's a lot of it, and probably a number of threads to synchronize first. Pete

Use event.offset for the airspeed offset. You can find the offset details and format in the Offsets Status list included in your FSUIPC Documents folder. Take a look also at the supplied Lua plug-in examples, especially "record to csv" which reads a lot of offsets, but uses a timer event to do this at regular intervals instead of when they change. Pete

Rotary encoders are either easy, or hard. There are two different types. The example in the FSUIPC Advanced Users guide is for the hard type. The "easy" type merely give you one button press or release per "click" in one direction, and a different button pree or release per click in the other direction. So you just assign to the two buttons separately, assigning both to press and release so that each click does something. The "hard" type give the same two button press/release in both directions, and you have to determine the direction by the phasing of the changes. I can't explain that here -- you need to see a waveform type diagram to understand it. The example in the Advanced Guide is all about that type, and is there to show one interesting use of Compound Conditional) button assignments. Easiest way, probably, but not necessarily the cheapest, is to use read-made units like the Goflight ones. FSUIPC supports GoFlight switch and button panels directly, including the rotaries on devices like the RP48 -- those provide 4 buttons, two per direction (slow and fast operation). (The same can be done for other rotaries, via a Lua plug-in -- rotaries.lua, in your FSUIPC Documents folder, does this. If is for the RP48, but can be applied to any device quuuuuite easily). Well, not close in UK terms -- a different country, even! 😉 But, yes, close compared with our American friends. Well, why not go to the FS Show at Cosford. I go with Ray Proudfoot every year. We're also going to Lelystad again this year. both excellent events for Flight Simming hardware and software. And good aircraft museums too! Pete

This problem was solved in FSUIPC by allowing LETTERS to be used instead of ID Numbers. All the assignments are made to LETTERS and the [JoyNames] section in the INI file defines the relationship between possibly changing ID numbers and your assignments. There's a chapter about this in the User Guide. Please do read it. You can either choose your own letters (e.g Y, T, R) which may be more meaningful, or let FSUIPC assign them automaticaly (A, B, C ...) Pete

What are these "functions" Can you give the actual name of whatever it is you are assigning to? The controls with the word STARTER in are: JET STARTER TOGGLE STARTER1 TOGGLE STARTER2 TOGGLE STARTER3 TOGGLE STARTER4 TOGGLE ALL STARTERS TOGGLE MASTER STARTER SWITCH Now, I've no idea wat they all do, nor if they all actualy do anything. FSUIPC just allows you to assign to them as you wish. Those that are also assignable in P3D would be the same, or more likely a subset (FSUIPC exposes the whole internal list, using the internal KEY EVENT names, but the assignments dialogues try to use a more user friendly name. There's really no way FSUIPC is not sending what ever you assign on to the Sim -- note, NOT to the plane specifically. All controls, or events, go to the main simulation engine, no matter what add-ons you use. Some addons may intercept these, though. To prove to yourself that FSUIPC is sending whatever you assign, just enable the Event logging (FSUIPC Options, logging tab). that logs all events it sees.-- the FSUIPC5LOG is in the Modules folder. I seem to remember I used to use JET STARTER with parameters 1 - 4 for the engine number, but that was a long long time ago. Maybe you are using TOGGLE STARTER1 and TOGGLE_STARTER2. Pete

Are there some advantages using a Domain instead of a Workgroup. I must admit ignorance in this area. Good. Glad that works. Maybe broadcasts don't work in domains. Pete

I'm afraid I've no idea what that means. What's a "domain"? What's "SOHO"? Can that block things? Try the explicit server method as I mentioned. Pete

The logs merely show the Server sending out Broadcasts, none of which arrive at the Client. This is covered by the User documnetation provided. You either need to make sure the WorkGroup names are the same of the two PCs (Windows won't broadcast to PCs on a different orkGroup), or use the ServerIPAddress and Protocl parameters in the Client INI file so it knows where the Server is. The anti-virus shouldn't have anything to do with it. if things are actually getting blocked it will be a firewall. Pete

You don't "press a hat" you move it around like a joystick. It sounds like it isn't actually a Hat! Worked fine to do what? What else could you do with a Hat? No, that wouldn't mess up FSUIPC's use of Pan View. The Pan axis is not a binding, it is inbuilt code withing the main parts of P3D. FSUIPC (but not P3D) can also treat a true "hat" as up to 8 buttons. Check in FSUIPC button assignments to see whether that sees a different button number for each direction of the hat. There's no "script" involved in an assignment. You just assign. if you make a different assignment it changes. It is just one line in a text file, and records your assignment. that's it. no point in finding it and deleting it. Since I've no idea what you are actually doing, i couldn't possibly comment on this. Sorry. If you have problems with P3D you really need to be asking in the AVSIM P3D forum. If you think you've broken P3D (very unlikely) you need to ask in the Lockheed Martin P3D support forum. Pete

You wouldn't get help in the User Contributions forum, which is a reference repository for useful stuff from users. Please always post questions in the Support Forum. I've moved it for you. Rather than entitle your question "Joystick Grief!" you need to state the specific problem so that you get folks who might actually know the answers to respond. e.g "1600M FSC hat problem". I'll see if i can change it for you. Either you changed something, orit is broken. What are you trying to do with the hat? If you want to use it for Panning the view, assign to Pan View, either in P3D or in FSUIPC axis assignments. If it doesn't work in P3D then it won't in FSUIPC. FSUIPC provides more options, but it can't do things which P3D refuses to do. Pete

I see you have a Saitek joystick as well. Is it only the T.1600M which isn't working? The problem appears to be that both the Throttle and the T.1600M are assigned the same JoystickID, 0. I assume this was imposed on the throttle previously. It should be 3. Either use JoyIDs to change the TWCS ID to 3, ir edit your INI file to change it in [JoyNames], thus: 3=TWCS Throttle 3.GUID={3839EDD0-1652-11E8-8001-444553540000} If you do the latter you'll need to change the assignments you made to the Throttle axes and buttons too. To avoid such problems when IDs change you should be using oy Letters. If you don't want to set your own letters, as shown in the User Guide, just change AutoAssignLetters=No to Yes. Then run the Sim to get the existing assignments changed to the letters, THEN you can safely change IDs for future sessions. Pete

If this came about with only the update from P3D 4.2 to version 4.3 then it can only be one of two things: 1. A new bug in P3D4.3 -- report this on the P3D support site. 2. An incompatibility between the add-on aircraft you are using and P3D4.3 which wasn't there in 4.2 -- contact the add-on aircraft maker. Of course, before anything, test with a default aircraft and with both P3d assignment and mouse action. That's not informative is it now? How am I to guess which one you installed last? I only support the current version in any case, which is 5.132. Pete

I do like folks who answer their own questions! 😉 Pete

Where did you get "1=Run1= ..." from? Please refer to the section in the Advanced User's Guide entitled Programs: facilities to load and run additional programs where you will see the format. The parameters are named "RunN", or RunIFN", not "1=RunN", when N runs from 1 to 16, separately, in each case. Pete

Without seeing what you tried, i can't say what you did wrong! It doesn't work like that. the entry could be as simple as [Programs] Run1=C:\MyProgram for "MyProgram.exe" in folder c:\ But nothing is ever that simple! You need ot post what you tried then i can interact with you to get it right! Pete

I don't know FS Time. I used to use "FSRealime", but not for a long time. FSUIPC has a built-in time synchroniser facility. Without seeing what you tried to do in [Programs] I can't help in any case. Pete

I can't help unless you shpw me what you've tried to do, and what the name of the program is. If you don't know the name of it then perhaps that's why the incorrect entry isn't working. Always check the FSUIPC log file, because that is where any errors will be reported. But for some reason you are using 5.122 when 5.131 and even 5.131a have been available for quite a while, and 5.132 was released to coincide with P3D4.3. You need to keep your FSUIPC up to date. Pete

Well, both Press and both Release actions will be executed as you could see for yourself by enabling Event logging and checking the log after using the switch. I don't know the aircraft model, or even the version of FS and FSUIPC you are using. Maybe the aircraft needs a delay between the two operations? If so oyu cannot do itby simpy assignment like this. You'd need a little Lua plug-in. See if it works with the two actions on separate switches, so you have to operate the two one after the other. If so, it is probably a matter of a delay. if that doesn't work, you need to look elsewhere. Maybe the support forum for that aircraft? Pete

Thank you! Pete

LVars are only known by name, as should be clear from the FSUIPC Lua Library document entry for it! Please do check that document. As it says, you can include the L: part or omit it. Yes, assign the axis to the Lua:<name> entry in the fropdown. If it is only for certain part of the range you'd need to do this on the right-hand side of the axis assignments tab. But bear in mind that Lua plug-ins are loaded, compiled, and run, each time you call them UNLESS you pre-load them and use events instead of calling them explicitly. Ths might be a consideration if your axis is sending lots of changes, but isn't so important for "one-off" actions. I'm not going to check your pseudo-code. Sorry. Please use the reference materials provided. There's quite clear syntax detailed in the Lua documents, and plenty of examples. Note that numbers are NOT "names" and vice versa. Built-in Sim events ("controls") for setting axis values and operating switches are actually NUMBERS and a complete list is provided for you. The names are used in the drop-downs and correspond to those in the list, but you must use numbers in programming them in Lua. Please do try looking at the examples, and relate them to the Lua Library reference documentation. I don't provide Lua language reference or help. That is part of the Lua documentation and reference on the Lua website. There are also some excellent books on Lua, including one called "Beginning Lua Programming". And a reference called "Lua Reference Manual", but the latter tells you no more than the same stuff on the website. Lua is subtly different from Basic, C, C# etc. But being a script-style language and compiled each time used, it is easy to debug. You can make changes, try again, until you get it right, very quickly -- no need to keep reloading the Sim. So write your first Lua plug-in, and try it. Errors will be logged, in the FSUIPC log file or optionally in its own file, and there's a trace facility too (both options are in the Logging tab in FSUIPC). Pete

Yes. I am releasing today a new version, but the differences are mainly to take advantage of new facilities in 4.3 (without making FSUIPC incompatible with 4.1 or 4.2). That change is to do with WideFS distplays of SimConnect menus. There are also a couple of bug fixes. As the update information said in the existing release, because of the way FSUIPC5 interfaces to P3D, it will remain fully compatible with new P3D4 versions unless L-M change those interfaces, which is extremely unlikely for point increments -- so not until P3D5, if there will be one. Of course there might be some killer facility added by L-M which I simply must take advantage of but which would make FSUIPC incompatible with earlier versions, but that's a different matter. That happened between 4.0 and 4.1, which is why current versions of FSUIPC will not run in 4.0. Should something change which does actually derail FSUIPC for a new version I will be sure to give advanced warning here. Don't worry! Pete