Pete Dowson

Ah, the "Revised list of FSX controls" was superseded a long time ago. I'll look into updating that reference. If you mean for up-to-date reference, then you do have to install a current version. The Advanced User guide doesn't list sim events inany case. What is it you wish to do with this without any sim installation? Pete

Just that no matter whether MSFS or FSUIPC7 has the focus, key assignments in FSUIPC still work. Pete

The JoyScan shows a very strange Registry mess with your devices. It lists these: 13 "Glareshield-API" devices 1 Saitek Yoke 2 Saitek Rudders 2 "CptSidePanel" devices 2 Throttle quadrant USB Worse, two of the "Glareshield-API" devices have exactly the same GUIDs as the Throttle Quadrants! That should be impossible (GUIDs are guaranteed to be unique), so it certainly indicates a messed up Registry. Do I assume the "computer upgrade did not include a fresh install of windows? Otherwise how on earth have things got so messed up? I think you may need to do some serious "cleaning". But first, can you tell me what you actually have connected? And which one(s) can't you program -- all or just some or just one? And by "cannot be programmed" do you mean the buttons and switches give no reaction in the Button & Switches tab and/or the axes give no reaction in the axis assignments tab? Or what? Also, next time, please also show the FSUIPC log file. Not the Installer log -- that's only for investigating installation problems. Pete

You really need to ask such questions on the MSFS Alpha forum. If you are a registered developer for MSFS then you can get answers, but otherwise folks must abide by a strict NDA and so really cannot help you at present. We are aiming at providing the same main application facilities in future versions of FSUIPC, but cannot guarantee all the facilities you might be using now. Pete

That's a rule imposed by the Lorby Scenery utility needing to be able to access otherwise protected folders in order to deal with the Add-On xml and Add-on CFG methods of installing scenery. It usually wasn't needed for MakeRunways' original need to only read the Scenery.cfg file. Pete

Every time? And never succeeded? Why persist without asking for help? Generally, nothing in FSUIPC copes with non-ASCII characters. It isn't Unicode friendly I'm afraid. We'd probably have to make an Anglicised version of the name. But I cannot do a thing without knowing more. I need FSUIPC version number, and your SimMarket order number. Pete

Yes, if there's absolutely no way to distinguish them by program then they will be assigned according to the order in which they happen to be scanned in that session. With most good USB joystick devices the windows calibration is normally pretty much identical. Are your two yokes very different, then? With two inputs to FSUIPC for the same assigned axis, then assuming they are calibrated in FSUIPC, the one with the largest deviation from centre is the one used for that scan. Provided no one is moving the other and you have calibrated a bit of a centre zone to avoid any jitter problems, then the one in use should always win. My cockpit is by PFC, and has dual flight controls, but linked, so moving one moves the other too. Only one side is connected to the sim. Of course it was originally connected to their serial port interface system, not USB, and handled by my PFCcom64 driver. But my friend Thomas recently replaced the pots for yoke, pedals, brakes and tiller with new pots, including several Hall effect sensors, and connected them via a Bodnar board. I am not aware of anything complex in the wiring. It's different to how the old pots were wired -- PFC only used 2 wires, so using them simply a variable resistors rather than a proper divider. All the new wiring is using the proper 3 wiire connection, to make more reliable use of the pots and give a better range and resolution. The Bodnar boards require this in any case I think. It must be okay with Windows identification as it all works here. FSUIPC doesn't currently use the serial number. Pete

What's "lua-edit"? If there's any error it will be logged in FSUIPC's log file. Look there! Pete

If you know that the airport addon you are using is up to date with the change in runways, then either that scenery layer is being overridden by the default, or some other scenery layer is interfering. You need to look at the Runways.txt file. Search thought it for the airport ICAO ID and see how many layers are involved. The very last one listed will be the one taking precedence. You could also use the Lorby-Si AddonOrganizer to see the layer priorities, and also use it to ensure the layer you want is above any others for the same area. Pete

Who is "are there any plans ..." addressed to? You must realise that there's a huge variety of hardware folks use, with an equally huge variety of interfaces and driving software. How is any "functionality" to be engineered for all that when it isn't known how to detect all such switch states? No, this sort of thing has to be planned and implemented according to the specific build of your cockpit. In my case I always load up "cold & dark", and when ending the previous session i always turn all the hardware switches and selectors to match. It isn't too hard -- make a checklist if you wish, but I always know how they should look so it has fast become semi-automatic for me. I did think once of programming it, but it simply isn't worth the hassle, especially if like me you have a real hodge podge of hardware from different sources connecting in different ways to different networked computers using different drivers. And much of it handled directly by ProSim rather than FSUIPC in any case. Pete

Okay, let's look. here's your code to read the LVAR: first = true while true do if first then initialALTVal = ipc.readLvar("L:alt_sel_num") ipc.writeUD(0x66C0, initialALTVal) first = false else currentALTVal = ipc.readUD(0x66C0) ipc.writeLvar("L:alt_sel_num", currentALTVal) end end I can't make a lot of sense of this. You are reading the L:Var just once and setting that value into 66C0. Then you read 66C0 and WRITE to the Lvar as fast as possible (no delays, just a continuous loop not allowing anything else to get a look-in! And the plug-in never terminates and only ever reads the LVar once. Writing to the L:Var was not mentioned in what you are trying to do. I thought you just wanted to read it? You said you updated the value using an encoder and the event to do the updates (you said "the encoder is using the event ID and works fine"). So, I think you need to explain a bit more about how you arrived at this code and what you thought it might do for you. then maybe i can show you how to rewrite it. Then you have: if ipc.readSTR(0x3D00, 10) == "QualityWings 757-200F QW House Livery RR" then ipc.runlua("Lua:b75200") end That can't work on two counts: First you read 10 characters from offset 3D00 and then try to match it to many more than 10. Second, the ipc.runlua function needs the name of the plugin -- just "b75200". The "Lua:" in front of it isn't valid. Anyway, "ipcReady.lua" is only run once per session, when the sim is first "ready to fly". To load and run a plug-in when a specific aircraft is loaded to need to use the [Auto.<profile>] section, with the <profile> name of your Profile for this aircraft. Then, in that section, you just have: 1=Lua b75200 Pete

As some sort of interface between the Sim and hardware -- any sort of hardware, or does it only support certain makes? No, but then most such aircraft use the built-in Sim systems, unlike say PMDG and FSL, and probably the Aerosoft A320, which implement their own systems making most of the standard Sim offsets redundant. That's very strange -- it's usually the other way around. The Increment and Decrement Events pile up and are still being actioned in the Sim when you stop turning, which makes it very difficult to stop on the required value. The hardware display should be a lot quicker. What is slowing it down? If you Monitor 07D4 in FSUIPC (right-hand side of the Logging tab), does that value show the same as the panel on screen? If not then the aircraft probably isn't using the Sim's A/P system, in which case one asks why in 07D4 being changed at all? (You can view the changes in real time either by selecting the display option, or "normal log"-- in the latter case using the Monitor log option to see the logging on screen). From what you say it seems to me that the problem is not using 07D4 but the route from the offset being read to when the display is updated is taking too long. If that's the case then using 66C0 or any other offset won't make any difference. So, is it "Mobiflight" managing the display for you? Where does an Arduino come into it? Was there some reasoning behind this recommendation? From someone who got it working properly? I can understand using an L:Var to obtain a value if it isn't available more directly, as in the standard offset, but if you are only going to use it to slow down transmissions to the digital display hardware which is so slow, then I think it would be better to simply only read the 07D4 value every so many milliseconds, say giving 4 or 5 updates per second, or whatever the hardware can cope with. Well, if updating the display is where the problem is, my solution isn't applicable. My solution applies to the more normal case there the Sim can't keep up with the hardware. Pete

Most likely problem is that the PCs are in different WorkGroups, so the broadcasting from the server doesn't get through. In the WideFS User Guide, find page 4, the section headed: Configure your Network IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! There should be enough information there for you to get it working. It may be matter of using the ServerIPAddr and Protocol parameters to allow WideClient to connect without waiting for the broadcast info. Pete

Oops! My misunderstanding then. Quite strange they've selected parameters which look very much like custom controls. I was going by the statement "All of these are as above (rotor_brake) commands" as meaning controls for the "rotor brake", whatever that is.

Those look like "custom control" numbers. You can assign to those in the Buttons and Switched tab by selecting <custom control> from the drop down list (I think it's the first item). Then you can enter a control number (thosde above) and a parameter, if needed. You can have any number of assignments to the the same button, but to do this you have to edit the INI file and add them there. Assign the first action. Then open the FSUIPC settings file (.INI) and find that assignment -- eg search for that control number. Then duplicate it with a different entry number (the number before the =), and change the control number to your second action. For this make sure you do NOT have repeat selected. Please see the Advanced Users guide for more details of what you can do with button assignments. You can edit theINI file with the Sim still running, and get your changes recognised by using the "Reload ..." button on the Buttons & Switches tab. Pete

Sorry, I can't help with that part. A CPFlight configuration problem? Have you used ProSim's "Input Debugger" to see the switch change detected? Pete

Well, seems odd that would make a difference. You're only selecting one bit of it. Maybe it's just the way it's been designed. I've only use 8-bit bytes for bit selection because it's too easy to lose count of the bit position when too bar up then wonder why the wrong bit was changing. Pete

Check that ProSim is actually seeing whatever it is which triggers that gate.

I use virtual buttons extensively, but I've never tried any ProSim outputs to a virtual button. I do, however, use virtual buttons for many operations from within my cockpit, using the WideClient "ButtonScreen" facility which makes full use of virtual buttons. If the bit you selected is being changed, FSUIPC will most certainly recognise it and allow you to assign to it, so I don't think it is being set. Did you check? Use FSUIPC's offset Monitor (right-hand side of the Logging tab) to log any changes to 3340 to the 'normal log'. I think you need to check that the signal is indeed being seen by ProSim. Have you asked on the ProSim forum? How does CPFlight send that switch to ProSim? i know things are very busy now with ProSimV3 Beta (I am testing it myself, eager to take advantage of all the improvements), but someone may be able to spot what is wrong. Pete

That's strange. it is almost always the other way round -- the inputs from the encoder pile up whilst the display keeps up easily. Anyway, the normal way of dealing with these things, and one which i've used in several case of encoder+display going back many years, is to update the display locally, directly from the encoder changes, whilst also feeding the latter to the sim, only reading values to display when the encoder changes have paused for a measurable time, like half a second or so. I don't know if that's possible using this "mobiflight", whatever that is (software or hardware?). Sounds like something is badly wrong there then. Sorry, what do you mean "not stable"? Changing on its own without relation to the encoder or sim value? What LVAR? I thought you just said you were using the offset! If you are reading an L:Var instead then I'm not surprised it is slow. Accessing local Gauge values is very slow by comparison. Neither are any good as they are, and you certainly don't need two in any case. But it isn't worth going into any details to help you further until you clarify two things: 1. What has an LVAR got to do with it. what is wrong with the offset? 2. Why is offset 0x66C0 being used? What does that have to do with anything? Pete

You need to supply more information, like version of P3D and version of FSUIPC. If FSUIPC is not up to date, please update it before coming back. If you mean with P3D4 or P3D5 then the mouse macro facility is completely dependent upon facilities in P3D. The code in FSUIPC is very simple. So it may well be a problem between that aircraft implementation and P3D. To determine further we would need a lot more detail -- 1. The exact sequence of keypresses and what is displayed after each. 2. Does P3D carry on working but you can't enter FSUIPC options, or what? Explain in detail please. 3. What happens if you don't try pressing TAB, just naming and pressing return? It might be the attempted execution causing the problem. 4. If by avoiding TAB the macro is created, does it work, or hang P3D or FSUIPC when used? 5. Most importantly, is it just with that one switch in that cockpit? If so then i think it needs reporting to FSL. Pete

What seems to be wrong with it. For the years I was using FSX, FSX-SE and P3D1-3 I always had the menus and other texts displays shown on a small screen in my cockpit via WideClient. What is the problem you think you've got, exactly? Really? Please give me a reference. Considering I'd used it so much before FSUIPC5 was even developed, that seems really odd. I'd like you to explain, please. Incidentally, there's no way I'll be adding or enhancing features in FSUIPC4 now. Pete

Seems that you have both a poorly calibrated joystick in FSUIPC (did you follow the numbered steps for calibration?), and an assignment left in P3D, giving conflicts. If you want to stop FSUIPC calibration you need to go into its calibration tab and reset those axes. Easy one button press! Sorry, there's no way of removing or changing FSUIPC settings in the "control panel", whatever you mean by that. If you want to reset it completely to default just delete the INI file. Pete

And in any case, I just used your WideClient.INI with version 6.76, the closest version I can find to your old 6.94, and it worked perfectly for a 2 x 8 matrix. I had to first delete the Window=1952,-1183,600,301 line as that puts it well off both of my two screens! Do you have a vertical stack of display screens? How else do you get a top 'y' coordinate of -1183? Pete

Sorry, i didn't explain well. I meant using your ipcReady ome renamed as, say, ipcLast and started with a keypress -- testing whether it was just some weird timing thing, or being somehow related to one Lua starting another. Sorry, I don't understand. How is anything "syncing" anything else. Your script simply seems to be setting different L:Vars selected by the parameter in the calling assignment. A more direct way would be a macro for each assignment. Not sure why you are going to the trouble of having a long Lua plug-in. How is anything "syncing"? By "all in one" do you mean setting all of the L:Var values with one assignment? Have you tried that? You might need a delay between each to allow the gauge time to implement the previous setting -- gauge code is not designed to be re-entrant. Sorry, you'll need to explain what you mean there too. BTW i'm out till Saturday, so there may be a delay. Pete