Pete Dowson

Sorry, i don't get the point of this sentence. What are you saying? FPS or VAS monitor plug-ins only exist to display values, so, yes, they have a display window. But most plug-ins just do stuff in the background. A display isn't needed or welcome for many uses for plug-ins. If it doesn't need to display anything why should it have a window? I don't understand what you are getting at, sorry. Pete

You only have one Elevator, one Aileron, one Rudder and one set of toe brakes actually assigned. The only thing you have two of is Steering Tiller: [Axes] PollInterval=10 RangeRepeatRate=10 0=0X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=0Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=1X,256,D,3,0,0,0 -{ DIRECT: Rudder }- 3=1R,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 4=1U,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 5=2X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 6=4X,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- The yoke is on one device, the rudder pedals on the other, and the two Steering Tillers on two other devices, one of which (device 2) no longer exists (maybe you only have one tiller and the ID has changed? You should use Joy Letters so devices will be tracked. Without assignment in FSUIPC or in P3D, your other yoke cannot possibly be used or interfere. Pete

But WHY are you using the "display" library, which isn't needed and which isd notihng at all to do with using COM to talk to your Arduino? Why? what are you trying to test? The lua API is the standard Lua language as at version 5. The lua compiler / interpreter is public domain and can be incorporated into any program. The language isn't changed. FSUIPC just adds many useful functions in additional libraries. Thjose are all related to thing you might want to do specifically in a flight Sim situation. The PDF files we provide only document the FSUIPC (and WideClient) implementation of Lua and the extra libraries we implement. Whilst you can learn by looking at all the Lua examples we provide, the prime resource for the Lua language is Lua.org as highlighted in the main installed Lua PDF document. If you want to learn the language itself, that is the place to go. You can also buy books on the subject. Pete

You posted this in the "Download Links" subforum, which is NOT for Support Requests, as it clearly says. I've moved it to the Support Forum so it can be attended to. Also, you always need to state Simulator and FSUIPC version. There's not enought information otherwise. The second pair are wrongly installed -- the registry entries for it are wrong. The Saitek installer seems to have a nasty habit of doing this. See this thread in the FAQ subforum for information on how to fix it: Pete

I really can't see what would be different with your code reading values to the way Windows and FSUIPC does it. In the axis assignment window in FUIPC the "IN" value IS the input value, unmolested. If you have one of your devices apparently misbehaving but only in the Sim, not when it is checked and scanned, it is much more likely to be an additional assignment in the Sim. Have you made sure controllers are disabled in the Sim? We haven't seen your FSUIPC settings (the INI file) yet, either. Best to check through that to see if there are any rogue settings. Pete

Yes, if you are calibrating in FSUIPC. Because otherwise you don't get to use the full movement of your axes, not get their full resolution. Why get decent controls then treat them as if they are cheap toy ones? You aren't calibrating properly then. You should have an idle null zone and perhaps use the Slope facility to adjust the feel. Pete

Do you mean an FSL add-on aircraft? How very strange! We would certainly not recommend doing calibration numerically. it's done by positioning the actual lever/yoke and recording the position. Follow the numbered steps for good calibration in the chapter on this in the FSUIPC User manual. For yoke the "null" zone, if needed, is the part calibrated between the two Centre values. You have Min, two centres, and Right. Many folks have a small centre zone but a slope with a flattened centre. You calibrate to get the feel YOU want and suited to YOUR controls as well as the specific aircraft. If you must do things numerically, then you can see the numbers on the calibration screen, or, if you really prefer, you can edit them in the calibration section of the settings file (the INI file). Pete

What version of WideClient are you using? It must be very old if the Display library is not included. It was added in version 6.895 (as shown on page 41 of the Lua library PDF). Of course, the display library doesn't exist in FSUIPC -- you aren't trying to use it there, are you? Pete

Yes, that's the point. Lua plug-ins run in their own thread. There can be many running at the same time, but each one is only single-threaded, not multi-threaded. If you need several things going on at once then use more plug-ins. They can communicate using ipc.set and ipc.get. Pete

You can change the polling interval in FSUIPC. It's controlled by the PollInterval parameter in your FSUIPC INI file's main [Axes] section. The number in that parameter is the number of milliseconds between polling. Pete

Actually just running it again will kill the previous incarnation. Pete

Nothing's changed in FSUIPC registration, nothing at all. I think you must be making a mistake in one of the entries. Don't forget all parts must be exactly as originally notified by SimMarket. If you think you are getting it all correct but it is still not working, send your details -- order number plus the details you are entering -- to me, by Private Message. Pete

There are some folks apparently using ProSim with MSFS, but with v2 I think, if not even v3. Note that ProSim uses SimConnect too, more than FSUIPC I think. And frankly I'd be surprised if v1 even recognizes FSUIPC7 A SimConnect log might help you identify whether a specific sequence is doing it, but I don't really see how you would follow that up with unsupported software in use. Pete

What would you want to see logged apart from those things listed in the Logging options? There are many specialised logging facilities, but you cannot enable them all at once. You need to know what you are looking for in the first place, and the problem here is that we have no idea. I'm just sorry that i am not in a position to try to reproduce your problem here, else i could possibly help more. I think it would be easier, in fact, for you to update from WinXP. Pete

Yes. But may be if that wasn't happening, the additional HID access would be fast too. As I said before, perhaps it's more to do with having two accesses or more running. The problem is likely that the COM port buffer is getting quite full due to records arriving faster than you are processing them. That is why com.readlast was provided, to discard all the interim queued records. I suspect you are expecting too much from a plug-in facility. Lua plug-ins are interpreted, and also deliberately "slowed" (i.e. deliberately not given as much time as they would utilise if allowed). This is part of FSUIPC's purposeful concentration on providing facilities without impacting on the flight sim performance. For all the purposes the Lua plug-in facility was added I think it does well. It is really not a substitute for a real driver. If you need time-critical application of your controls, I suggest either using only the standard facilities, or finding or writing a suitable driver. Questions and observations, as well as 'bug' reports, are always welcome, and, yes, forum posts are really the only acceptable way. Please don't start resorting to Private Messages or emails. Pete

The event.button facility is actually derived from FSUIPC's joystick scanning, so it's part of the mechanism using the regular interface. Using it causes FSUIPC to scan the device just as if you'd assigned to it in FSUIPC. The com library functions are, however, treating the device as a normal serial device, with some special decoding functions added for regular HID devices which have defined data formats. So the difference is in the interface being used. Why the lower level HID interface gets so delayed by the vJoy software I don't know. That's a good question for the author. Pete

I'd need to see the slope setting to check. You are assuming it is set linear. Maybe Thomas, like myself, prefers a flatter centre at the cost of a sharper extreme. Haven't you tried it to check yourself? Pete

No, sorry. You'd need to persuade L-M that what they think are spot on are not for you. When I asked L-M for facilities to change them they said they'd rather get them right in the first place, instead. We aren't going to start hacking into P3D4 or 5 as we had to in FSX -- P3D3. Pete

No, I plan to TRY. I've been looking at the task, and even just finding all the scenery files is a complete nightmare, let alone then processing them in a sensible priority order and decoding the changes. I'm rather inclined to wait till ASOBO publish proper documentation on both the file structure and the BGL formatting. At my age i cannot easily deal with such complexity and i think i need to assistance. Fathoming it all out with no information is a nightmare. Pete

Why not use a similar environment at your other establishment, then? I'm sorry, but i am really not in a position to offer any additional help with a WinXP installation. Pete

Okay. FSUIPC6 + P3Dv5. Same device, same Lua plug-in. 411328 Button changed: bRef=0, Joy=0 (B), Btn=1, Pressed 411328 [Buttons] 1=PB,1,C65557,0 411328 FS Control Sent: Ctrl=65557, Param=0 SLEW_TOGGLE 411328 *** EVENT: Cntrl= 65557 (0x00010015), Param= 0 (0x00000000) SLEW_TOGGLE 411328 ### Mode: SLEW on 411328 *** EVENT: Cntrl= 65549 (0x0001000d), Param= 0 (0x00000000) PLUS 411328 *** EVENT: Cntrl= 65719 (0x000100b7), Param= 0 (0x00000000) ZOOM_PLUS 411437 Button changed: bRef=0, Joy=0 (B), Btn=1, Released 411453 LUA.3: Data Read= 00 00 80 FF 7F 00 80 FF 7F 00 80 02 00 00 00 411453 LUA.3: ##### Timer Trigger: Button 1 411468 FS Control Sent: Ctrl=66300, Param=0 TOGGLE_STARTER1 411468 LUA.3: Buttons=2 411468 *** EVENT: Cntrl= 66300 (0x000102fc), Param= 0 (0x00000000) TOGGLE_STARTER1 So, from the time the button is detected pressed in FSUIPC to when the Lua plug-in has sent the TOGGLE STARTER1 control is 140 mSecs. That's an overall time. Of course with the event.timer set to 25 mSecs, that could contribute to that between 0-25 mSecs. It should be more consistent using your original method of even.com. Also the first thing my Lua does is log the data (the "Data Read= line above). There's another 15 msecs before sending the control. So at the best, and without logging (especially to screen as i was) even the fastest looks like being of the order 80-100 mSecs. As far as I can see the higher timings for MSFS with FSUIPC7 are commensurate with them being separate processes. Yes, I think i'll have to 'move on' as you say. I don't see there's a lot more I can do. Incidentally, if you want to get deeper into using vJoy with FSUIPC you might want to take a look at my freeware "vjoyOffsets" program, which you can find on FSUIPC.com. If allows direct access into the FSUIPC offsets from vJoy axes, buttons and POVs. The offsets are documented in the offsets list, part of the main FSUIPC documentation package. (Of course not all yet apply to MSFS -- the document with FSUIPC7 lists their status). Pete

No, it won't. I had to use more devious internal means to record the time. Aha! I'm using a cheap Game Controller. I used to have vJoy installed on this PC but it got lost when I changed from Win10 1903 to 2004 version. So, I'm left wondering how the vJoy software might affect the timings. Perhaps a good test would be to remove all assignments to the device from your FSUIPC7.INI, so that FSUIPC is not scanning the device, just in case two entities trying to read the same software interface is slowing that down. As another step, make sure you create an empty profile for the joystick in MSFS so that it isn't scanning it either. Of course you won't have a log entry showing when to press the button then, so you'd need to time it some other way. But your > half second is probably noticeable without measurement in any case. I'm just about to check timings on P3Dv5 with FSUIPC6. Not that it is really relevant now, without vJoy. Pete

Very odd. I don't use that fiddle to maintain battery power. I use ProSim and don't have any problems. But then i always connect Ground Power within a few minutes of switching on the battery, or I start the APU if there's no ground power available. Once you turn things on in the cockpit the battery power doesn't last all that long on its own. You definitely need to enable one of the other sources of power, long before the time you try to start engines. Check your battery voltage when you are trying to start engines. Pete

I've always received multiplayer traffic -- but only when I allow on-line (real) traffic, which arrives as well.As the world is at present at least with so little real traffic, there's much more traffic all told when you select the local AI traffic option, but then nothing from anything on-line. The options seem to be: local AT traffic OR on-line real plus multiplayer traffic. Isn't that what you experience? However it may work, FSUIPC can only report what it receives. Pete

I see that the delay you mention if in the region of 450-550 mSecs, rather than a full second. however, that isn't food. I found a little time this morning to do some tests here. This was on my development PC (not a Sim PC), with loads of other things also running. Using exactly your later test, and with the latest FSUIPC7 but without MSFS running yet I see a delay of around 30-35 mSecs, which is probably commensurate with the logging I have on screen (the console). With an up to date MSFS loaded ready to fly with the Cessna 152, I measure a delay, certainly -- but nowhere near yours (my Button 1 is assigned to SLEW_TOGGLE in FSUIPC). More like 140-160 mSecs as shown here: 4660813 Button changed: bRef=0, Joy=0 (B), Btn=1, Pressed 4660813 [Buttons] 2=PB,1,C65557,0 4660813 FS Control Sent: Ctrl=65557, Param=0 SLEW_TOGGLE 4660828 LUA.14: ##### Button Event Trigger: Button1 4660953 LUA.14: Data Read= 00 00 80 FF 7F 00 80 FF 7F 00 80 02 00 00 00 4660969 LUA.14: ##### Timer Trigger: Button 1 4660985 FS Control Sent: Ctrl=66300, Param=0 TOGGLE_STARTER1 Here's my test Lua: handle, rd, wrf, wr, init = com.openhid(0x045E, 0x028E, 0, 0); prevdata = 0 function logdata(data) if data ~= prevdata then prevdata = data logstr = "Data Read=" i = 1 while string.byte(data,i) do logstr = logstr .. string.format(" %02X", string.byte(data,i)) i = i+1 end ipc.log(logstr) end end function processButton() local data, n = com.readlast(handle, rd) if (n > 0) then logdata(data, prevdata) local buttonState = com.testhidbutton(handle, 1, data); if ((buttonState == true) and (previousButtonState == false)) then ipc.log("##### Timer Trigger: Button 1"); ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonState; x = com.gethidbuttons(handle, data) if x ~= 0 then ipc.log("Buttons=" .. x) end end end function processButton1() ipc.log("##### Button Event Trigger: Button1"); end event.timer(25, "processButton"); event.button("B", 1, "processButton1"); ipc.log("Started up"); I'll compare this with FSUIPC6 + P3D later. Pete