Pete Dowson

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

Okay.I see what is happening, but I din't understand why. It is not scanning the macro file initially in order to register the fact the there's a matching macroname. I don't know why it is missing that -- it does it here every time, and that works with or without a "real device" to connect to. Could you try changing aircraft, please? Maybe that will make it scan. I know the aircraft-specific selection of MCRO fles now works -- it seems to be missing that part at the beginning on yours. If that doesn't work, rename the [Config] section to be correct for your aircraft, [Config.Cessna] or whatever. I'll also try here without aircraft specific sections. Maybe it is only the default [Config] part it has a problem with. i must admit I'd not paid much attention to that in my testing as it was the selection of the correct MCRO file which was central to the original problems. Pete

The version of FSUIPC makes no difference. The FS altitude readouts have always worked, never changed. You need to go to support for your ACARs program. Pete

Please get the log again with this one (small logging changes to get more info): Same options. http://fsuipc.simflight.com/beta/PFChid140a.zip Thanks, Pete

No, don't get me wrong. I've not heard from him yet regarding 1.40. Earlier some things were working on his which didn't appear to be on yours. But the log doesn't show enough wrong (if anything wrong) with your firmware to explain how such a simple macro is being ignored. It's this latter aspect i find bewildering. It's deriving the right macro name yet not executing it. I'll do some changes in the logging and see if I can elicit more info about what is going on. Probably not today though. Pete

Okay. Something is VERY VERY strange going on. Using simulation, here, all macros are correctly obeyed. I'm waiting for a response from my friend regarding 1.40, but even with 1.39 he was getting positive results in circumstances where you get nothing. I think I'm going to have to change the logging actions substantially to find out what is going on. I find it quite unbelievable the differences at present. :-( I've obviously got a real problem having on way to test on real hardware. I'm not sure when i can get to this. I'll let you know in this thread when I have something. BTW my friend actually did find that the macro entry "1=Avionics", with no actual macro action specified at all, did succeed too in avoiding the default action. Pete

Sorry, that's the same as before. Please use these logging options: [Debug] Console=No LogComms=no LogData=No LogDecode=Yes LogDevices=yes LogDeviceChanges=no LogToDebugger=No LogIPCwrites=Yes LogTxData=No LogReadCounts=No LogMacroNames=Yes You'll need to restart FS of course. Also, it's using PFC.MCRO. Are you sure that's the one you showed me? Pete