Pete Dowson

As far as I recall (I did have a number of TRC gauges, and so used their driver, some time ago), it will all work through WideFS perfectly well. The difference between Win 7 and Win XP is easily resolved in one of the two ways I mentioned in my last reply. A network is a network is a ... If you have an Internet router it is usually easiest just to connect them both to that. If your two cockpit PCs are separate altogether, you can network them with a special PC-to-PC "crossover" Ethernet cable, not a normal type. Pete

Any version of Windows from XP SP1 onwards works with the current WideClient. The only thing to watch is that XP uses a different default network workgroup name to Win7, so you should change one to match the other for WideFS to link automatically. (Or you can always link inany case by giving the Client the IP address or name of the FS PC). For my cockpit I have the main FSX PC using Win7 64bit, and 5 other PCs on WinXP. Pete

I had a look at this today and it actually isn't possible to suppress controls the way FSUIPC currently intercepts them. I thought it would be reasonably easy, but it isn't. I would have to change the control interception to use SimConnect event handling, in the same way as happens for axis mapping and calibration, and I'm really not willing to make such drastic changes at this stage. Sorry to disappoint. The only way I can think of to fix your situation, albeit rather clumsily, would be to use event.control as you are now to see the offending controls being sent, and immediately sent the counter- or reverse control, to undo what it does. This is actually the way FSUIPC implements some of the systems inhibit options it provides via bits in offsets, like stopping flaps and spoiler actuations.. Without knowing which controls are causing the problem I can't really help much more. Regards Pete

Okay. Good. The Lua as quoted from the old message is totally corrupted by image references in your re-print, though. I hope you got it okay from the original. Pete

No. They've not changes at all since being defined in 1997 (FS98). Those are the Engine 1 and Engine 2 throttle control inputs, and setting them to any negative number within the aircraft's range will set FS's reverse thrust -- until and unless the values are overwritten again, possibly by normal throttle axis input. So, check several things: 1. The maximum reverse thrust on many aircraft is 25% of full thrust. It is defined in the aircraft.cfg file for the specific aircraft. A 25% reverse would have the value -4095. Your -5800 value is 35%, which is okay if the CFG file says the max is .35 2. Try is with -4095 and with the default FS 737, because add-on aircraft might behave differently in any case. Some sophisticate add-on aircraft manage their own throttles. 3. When applying the reverse you need to first make sure your throttles are in a stabile idle position, with no jitter to interfere. Make sure the throttle levers are properly calibrated with a good idle position. You can check what is going on using FSUIPC's logging facilities -- enable Button, Event and Axis logging. If you temporarily put FS into Windowed mode and enable the FSUIPC console log option you'll be able to see what is happening in real time. Pete

But I assume it communicates with ProSim via FSUIPC offsets? I think EHID is not ProSim-specific, it is used with other cockpit packages too, like SimAvionics and Project Magenta, is it not? But FSInterrogate is simply a utility to allow you to read and write FSUIPC offsets by hand, i.e. using the keyboard. It doesn't interface to anything but FSUIPC. There are no hardware drivers! FSUIPC knows nothing at all about hardware. The Lua com library does allow you to read and write to any USB or serial port device, but you have to do some programming. There's no other way unlist your EHID driver is writing the tiller value to an FSUIPC offset somewhere -- if it is, then the rest is very easy. XML is just a collection of data definitions. It is not a program in its own right. What program is using the data in the XML, and what then happens? Pete

You haven't understood what I told you, then. RC can only give you the weather as set in FS. The normal FS real weather downloads are localised -- each weather station has its own weather set, so the ATIS from each can be different. I think Opus is using GLOBAL weather -- setting the weather all over the world to exactly the same as it is at your aircraft. It is probably doing this in order to more easily smooth changes and prevent wind swings etc, which are a result of bad interpolations between weather stations in FS's code. Therefore there is no way anything outside of Opus can know the weather at the destination until Opus sets it into FS. Yes, because your aircraft is there, isn't it? It will work fine at the destination if you put your aircraft there!! Pete

No, it won't help, and it is not an FSUIPC problem. FSUIPC cannot foresee what weather Opus will be setting. All it knows is the weather set in FS, and Opus is apparently setting the same weather for the whole world, all the same, and changing it as you fly. Active Sky provided a workaround which is to set the arrival weather at a distance out from the destination. --50 miles, or maybe 80, I don't recall. Since you wouldn't expect to receive arrival ATIS until in range of its transmissions, that works fine. Just get ATIS when in whatever range Active Sky sets. If Opus is not providing such an option then you must ask for it. There's no alternative without changing weather programs. Neither FSUIPC nor RC can work magic. Pete

That's not an "example", it's a Lua function. The examples are programs, in the ZIP package, files with .lua filetypes! I may have misunderstood you, but I thought you were talking about interfacing a hardware tiller device which isn't a standard joystick type and for which therefore you needed to use the Lua HID facilities in the com library. Are you now saying you have a driver for the device and can make it write through FSUIPC to offsets? Perhaps you ought to explain more specifically what it is you think you need to do? Pete

Correct, it isn't a facility at present. Generally FSUIPC sees the control as it passes through the Windows messaging system, or, in FSX/P3D, if it is notified by SimConnect (I don't recall offhand where the event.control function gets it). I'm not sure how easy it would be to actually stop them reaching FS. It should be possible if they are going through the Windows message queue. I'll take a look and if possible I'll add it to the event.control function. If i did it it would be for FSUIPC4 only, I'm not extending FSUIPC3 any more. I'm too busy this week, but if you've not heard back from me in this thread in a week's time (Weds 25th) please post a reminder here. I have made a note, though, so i shouldn't forget. Pete

You'll need to look at the HID examples for Lua, in the Lua packages provided. I would find it very difficult to help at all with no information. you'll need to try, see what you get, then come back with your results and maybe then I can see what you can do. Pete

You'd need to see if Opus has a facility to freeze arrival weather further out. There's nothing FSUIPC or RC can do. The weather is read from FSX, and if that's what Opus tells FSX, that's what RC sees. It is different for ActiveSky where its local weather is read separately. Even then, that fiddle only applies to a WideClient remote RC. Otherwise you have to invoke the arrival weather freeze in Active Sky too. Pete

Put the current, supported version, back, run Fs and get the problem, then close FS down and show me the FSUIPC4.LOG file from the FSX Modules folder. You can paste the contents in a message here. Pete

I expect there's some way by directly interfacing to the FS-traffic facilities in FS -- much as the Microsoft AI traffic explorer module does, and presumably also programs like GSX. But I really don't know that area. The only way I know is to read the list of all the gate positions and check against those the list of all the ground AI, assuming positions are occupied if the aircraft coordinate is anywhere near the gate coordinate -- i.e. within the radius of the gate. Of course this does not mean a taxiing AI aircraft won't get there before you! It might be easier and more effective to simply select a suitable gate and clear it by deleting any AI daring to be parked there. You could continue to repeat that as your own aircraft is taxiing, to keep it clear till you get there. Pete

Super. I'll release is as version 1.41 ... Thanks for testing! Pete

Yes, ShowText has for a long time been the way to show things like the RC menu on a Client. AdvDisplay was made obsolete by FSX and the Window display option in FS took over in both FS9 and FSX. There's a Lua plug-in which does something similar to ShowText -- it's actually used as the example of the Lua wnd library in the Lua library documentation. If you prefer to use ShowText then you'd need to have a plug-in which read one location (the VAS) and wrote a text string, like those in the examples above, to the FSUIPC text display area. However, you should note that there is only one such area, so it would overwrite things like your RC menu display. The value of any FSUIPC offset can be shown. You just have to read it (using the appropriate ipc.readXXX function, where XXX defines the size and type), format it into correct units and characters, using Lua arithmetic and the "string.format" function, and display it as shown in the examples above. In fact there are examples of all that there for you. Offsets details are in the Offset Status guide installed with FSUIPC. I just checked, and unfortunately the zoom value is not readable in FSX. It was one of the items still outstanding when FSX development ceased. It can be written (because there's a control for that), but not read. Pete

The log looks fine, so FSUIPC is working ok. You need to ask the ACARS author what he is reading for the altitude. I see you are using Radar Contact too. Is that getting it right? You also mentioned you were using the PMDG 777. Why? Do you think that makes a difference? Is it okay with other aircraft? Also, since you are talking about Flight Levels, I assume you have set the altimeter to STD (29.92" or 1013. HPa displayed)? Pete

One of the examples (and they are only examples, for you to change as needed) is scalable. Please refer to the Lua library documentation for details of fonts, windows and displays. That one, using the display library, is using standard Windows dialogues, so the font etc is up to Windows settings. Not adjustable in Lua. Please just refer to the library documentation. Surely one of them is a good basis/. Else you are being very awkward. On your earlier post: AdvDisplay.dll was never moved to FSX. I've no idea how you got it working. It was abandoned many years ago in favour of the built-in Windows displays, the semi-transparent ones when docked, the opaque ones when undocked. Fonts and font sizes in those aren't adjustable. Anyway, I thought you were wanting a display on a Client, so you can't be using AdvDisplay.dll!!! For use outside FS, as on a Client, Showtext was provided by a third party. To use that for VAS numbers you'd need to write your own Lua plug-in to read the VAS value and write it as an FS text essage. Pete

What do you mean, "code"? Pete

Neither. It's a text file. Paste its contents into a message. Use the <> parenthesis facility to enclose it (see the <> button above this edit area). Pete

One of those three Lua programs has a re-sizeable and positionable window, and you can easily change the default size and position -- just look at the code. AdvDisplay is a long dead FS module which doesn't run on a client, it used to be part of the FS9 (and before) process. I hope you aren't still using that! WideClient runs any Lua program it finds in its folder. Adding characters to the end of a filetype never has changed the filetype -- that's a Windows function, not in WideClient's control. If you want to change the filetype so it won't load use a prefix not a suffix. e.g. 1lua, 2lua, 3lua. (I use ".xlua" to disable lua programs. Pete

Without knowing what he is reading, i.e. which offset -- if he is indeed reading one -- there's no way I can tell you. If we knew the offset it would be easy for you to monitor that and prove what is wrong. Are you sure it uses FSUIPC? Are you sure your FSUIPC installation is working correctly? Maybe you should show me the FSUIPC log file, from the Modules folder. Make sure you close down FS first, please. Pete

Okay. A last gasp for today. I think I found a possible reason for it NOT reading the default file (i.e. the file it starts off the session with). In most of my tests my default flight was with a 737 and it was using a B737.MCRO file pointed to by the [config.737] section. so, for the CSV list it read PFC.MCRO (default in [Config], then as soon as it saw it was a 737, it changed to the B737.MCRO file. This made is scan it okay. Now I don't understand why that didn't happen in your case when you were using different aircraft with different Config sections, but I found that if there was no Config.737 section, it didn't scan the default to construct those masks I mentioned! (The scan for the CSV file doesn't create the masks, as it would be a waste of time for specially configured aircraft). So, try this one please: http://fsuipc.simfli.../PFChid140aPlus.zip Not had time to change date/version I'm afraid. Trying to fit all this stuff between FIFA football matches! ;-) Pete

No logs for those tests? I'm just looking for specific entries which say that the MCRO file is actually being scanned. The logs so far merely prove it would be using "PFC.MCRO" if it was actually reading it, but there's no sign of any MCRO file being read. It's as if they aren't actually in the correct Modules folder! The only thing which contradicts that is this: 0: Listing macros from "D:\FSX\Modules\PFC.mcro" and the resulting CSV file you showed which contains this: 02,2,Avionics,Y,Y That second 'Y' is crucial, as it shows that the Avionics entry was seen in PFC.MCRO. Can I assume the CSV file is up to date with your last tests and still contains that line with Y,Y? When the macro file is read for the current aircraft, whether that be in the default [Config] or other, it logs something like this: 5007: Using macros from "E:\FSX\Modules\B737.mcro" selected 5007: Macroflag mask for "Avionics" = 00000001 5007: Macroflag mask for "Magneto" = 0000000C In that case I had "Avionics", "Magneto1" and "Magneto2" macros. The bits in the Mask value are set to tell the switch reception that there's a macro with that name, and what additions it can have. The 1 bit for Avionics says the name in "unadorned". The two bits (values 4 and 8 ) for Magneto indicate the 1 and 2 refinement. Then (and this is from my "simulated" device, where I'm feeding in actual switch codes using additional code), entries like this should appear for those switches with macros: 5007: Device #-1 received: Magneto[1] = 1 5007: Full macroname for decoded switch = "B737:Magneto2", mask = X0000000C 5007: Requested macro "B737:Magneto2",01 via offset 0D70 Device -1 is my "pseudo" device -- just code. Once the log shows the "Requested macro" line, the rest is up to FSUIPC action, and the action normally done in PFChid is suppressed. I'm running out of ideas at present. :sad: Pete

Several ways. Here are three Lua plug-ins. Try each and see which you like. JUst save them as .lua files in the WideClient folder. w = wnd.open("My Display", WND_FIXED, 30,300,217,50) wnd.backcol(w, 0x000) wnd.textcol(w, 0x0f0) wnd.font(w, WND_ARIAL,-2,WND_BOLD) -- Update the display at 500 msec intervals (see event at end) function mytimer(time) wnd.clear(w) fr = ipc.readUW(0x0274) if fr ~= 0 then fr = 32768/fr end fr = math.floor((fr * 10) + 0.5)/10 mem = ipc.readUD(0x024C) memmb = math.floor((mem/1024) + 0.5) wnd.text(w, "Frame Rate " .. fr .. " fps\nMemory free " .. memmb .. " Mb") end -- Adjust timing to taste: 500 = 1/2 second event.timer(500, "mytimer") or: -- Create the display window for 2 values, position x=800, y=400 h = display.create("My next display", 2, 800, 400) -- Update the display at 500 msec intervals (see event at end) function mytimer(time) -- display 1 = frame rate fr = ipc.readUW(0x0274) if fr ~= 0 then fr = 32768/fr end fr = math.floor((fr * 10) + 0.5)/10 display.show(h, 1, "Frame Rate " .. fr .. " fps") -- display 2 = memory left free mem = ipc.readUD(0x024C) memmb = math.floor((mem/1024) + 0.5) display.show(h, 2, "Memory free " .. mem .. " kb (" .. memmb .. " Mb)") end -- Adjust timing to taste: 500 = 1/2 second event.timer(500, "mytimer") Or: w = wnd.open("My third display", 2) wnd.backcol(w, 0x000) wnd.textcol(w, 0x0f0) wnd.font(w, WND_ARIAL,-2,WND_BOLD) -- Update the display at 500 msec intervals (see event at end) function mytimer(time) wnd.clear(w) fr = ipc.readUW(0x0274) if fr ~= 0 then fr = 32768/fr end fr = math.floor((fr * 10) + 0.5)/10 mem = ipc.readUD(0x024C) memmb = math.floor((mem/1024) + 0.5) wnd.text(w, "Frame Rate " .. fr .. " fps\nMemory free " .. memmb .. " Mb") end -- Adjust timing to taste: 500 = 1/2 second event.timer(500, "mytimer") Please yourself. Adjust at will. Pete