Pete Dowson

Assigning in FSUIPC to FS controls is effectively identical to assigning in P3D. The exact same controls are sent to the sim. Only the dedicated "direct to FSUIPC calibration" controls are processed differently. The P3D steering axis control is also assignable in FSUIPC. Pete

None of those load and run the plug-in. Please do take a look at the Lua plug-ins document in your FSUIPC Documernts folder. The FSUIPC control which loads, compiles, and executes the plug-in is: Lua 321ECAMS Well, whilst LuaDebug does load the plug--in, using rather superseded debug code (use the Debug option in FSUIPC's Logging for that), I think one possible reason is that your plug-in line is: ipc.writeLvar("ECAMS Display", ipcparam) whereas, as you can see, the parameter is called ipcPARAM. Like most programming lanugages, Lua is case sensitive. Of course, other possible reasons include a misspelling of the L:Var name, and value 5 not meaning anything for it. Pete

Yes, though the ProtocolPreferred parameter in the server will only apply to clients which you let connect to a server automatically, not to those where the Client is fixed in its connection as in your case, as then there's no choice in the Protocol used -- the Client has already decided by the Protocol parameter.. And you can use ServerIPaddr instead of ServerName if that works better.

Actually, FSUIPC uses "SetFocus" followed by "SetForegroundWindow". This has always worked fine. Not sure what a "flashing icon in the taskbar" means. Anyway, I've just tested it with P3D4 in a Window and a button assigned on a joystick device to Key Focus Restore. I go to a different window on my desktop (one overlapping with P3D4 as it happens), and pressing the button puts the P3D4 Window on top AND gives it keyboard focus. This works every time. Now I am using a later Beta version of P3D4 that the one currently released, so maybe it was a P3D4 prblem now fixed. Seems more likely, though, that it is somehow related to something his program is doing. The flashing icon sounds suspiciously like there's something taking focus back when FSUIPC tries to set it. Pete

I'm pretty sure this is what that control does too! But I'll cross-check. Pete

No. ProtocolPreferred parameter is a SERVER option. You've not read the importasnt bits properly! Please read this part in the second paragraph of the "Configure your Network" section: The Server automatically operates with any clients that connect, whether they be using TCP, UDP or SPX. You can mix them, to suit the specific individual client PCs. Better, leave the protocol choice out of the Client INI file altogether and just use ―ProtocolPreferred= …‖ in the Server INI to select your choice. The part you should have read was this bit later on: ... However, if you find the connection is still not happening, or you have more than one Server and it is connecting to the wrong one, then you will need to add these lines to the [Config] section of the WideClient.ini file (add the [Config] section too if your ini file hasn‘t even got one!): ServerName=NameOfServer Protocol=TCP Pete

FSUIPC only passes the parameter on to Windows. What then happens is up to the Windowes coding and, presumably, the driver for your sound device. Pete

It's a library written by another Lua user, not one of the official libraries from the Lua organisation. There are many third party libraries and the documentation for those belongs with them. The only reason I provide the file system pdf is that the library is built into FSUIPC. There are also many standard Lua libraries built in (string, math, etc). The documentation for all of those is provided by the Lua organisation in both printed books and on their website (see https://www.lua.org/docs.html). The only reason I supply the LFS PDF is that it comes with the complete code package, which you don't need to download because the code is built in. The Lua library document I publish is solely concerned with NEW functions added only in FSUIPC. None of those are to do with other authors or the Lua organisation. Pete

The FSUIPC log files aren't relevant. But this part of the WideClient.log file shows that you haven't put the correct parameters into your INI file: 141 Attempting to connect now 141 Trying to locate server: Protocol not yet decided 141 Failed to connect: waiting to try again 2200 Attempting to connect now 4259 Server = B737-222-FS When you give the ServerName or ServerIPAddr you MUST also specify the Protocol tp be used. It does tell you this clearly in the part of the WideFS document it urges you to read. Pete

You'd need to use one of the system functions ffor files available in the supplied filesystem library. Please check your FSUIPC Documents folder for "LuaFileSystem". Pete

I've checked, and you should be okay accessing offsets if you prefer to use a program rather than a Lua plug-in. However, this won't deal with Text Files as the potential size of those will not match the offsets available. For programmed display of normal text files you can obviously simply read the directly files yourself. If you are still interested in the offsets, here is a preview of the amended and new entries in the FSUIPC offsets list: B000 4096 FSX and beyond: METAR weather reading and writing (i.e. using the special FSX extended METAR strings of up to 2000 characters each): B000–B7FF = Weather writing area (WRITE) Just write string in FSX METAR format. B800–BFFF = Weather at requested location (READ) For ICAO ID or Lat/Lon written in CCxx area. Note: see next entry for other use of B000-B7FF when READING instead of WRITING Ok-SimC (but see next entry for reads of B000-B7FF) Ok-SimC B000 2048 FSUIPC4 and FSUIPC5: This area is used to hold the event.textmenu() data for WideClient Lua plug-ins. It can be accessed by FSUIPC applications wishing to process menus and messages themsellve, without having to use a Lua plug-in. The format is as follows: B000 4 bytes changed indicator (tick count at time) B004 4 bytes type value (as documented for Lua) B008 4 bytes display duration in secs (32-bit float) B00C 4 bytes the ID of the SimConnect event B010 4 bytes the length of the data following B014 the text data received (<= 2028 bytes) The text data is in the format provided to SimConnect for text displays and menus. The latter is a series of zero-terminated ASCII strings, with the title as the first string. The numbers displayed on screen are not included. 4 bytes N/A (see previous entry) Pete

Sorry, but FSUIPC4 development has finished (after 13 years!) You can publish your script anyway for users with instructions on using Wideclient for it. Those who have upgraded to P3D4 can of course make use of it with FSUIPC5. Pete

Ah. If they only change the display local to the panel then they are local to that panel so have no real input from the rest of the simluation. The panel simply grabs the values and displays them. Unfortunately, with FSX (FSX-SE is the same of course) Mouse Macros only work on panels which have been written to Microsoft's SDK rules for C/C++ panels. Very few of those produced by Microsoft themselves do so. But it is worth trying. Some panels are written in XML. They use "Local variables" (L:Vars). You can get a list of those using the assignable control in FSUIPC called List LVars or simular. You can also get a real time display of them changing by using the provided Lua example plug-in Log LVars. Pete

Sorry, no. You'd really need to write your own Android app. We only program for Windows. Pete

Do you mean the panel ID? Or do you mean assigning events to buttons or keys? Panel IDs are specified in the aircraft's PANEL.CFG. What do you want to use those for? Not sure what you mean by "submenus". If this is in the sim's main menu dropdowns then there are probably no "idents". If you really mean buttons or switches on the panel, then enable event logging in FSUIPC's Logging tab, then operate those buttons or switches. If the panel uses an FS controls to trigger the action then the the name will be logged. Then you can assign to it. But some panels have internal processing for their switches. In that case the only way might be via mouse macros, or local variables (L:Vars). If the A321 is an add-on, then you should be able to get more help on the add-on maker's support forum. Pete

I'd really rather not. No other controls have messages, and many folks (those using cockpits for example) wouldn't like it. You can do it via a Lua plug-n of course, and for that matter you could add messages to AIFreezer.lua (it logs the changes at present). The KLM may not have been in Taxi Out mode, of course. Pete

I just noticed, the instructions for that plug-in's use are actually included in it, as comments right at the beginning, so: -- This small plug in, which should be pre-loaded: for example, by adding -- [Auto] -- 1=Lua AIfreezer -- to your FSUIPC5.INI file. ... and reading the description there reminded me what the Freeze AI FSUIPC assignable control does -- it only affects those AI stated to be in "Taxi Out" state. I think that answers your telephone question about freezing aircraft on the runway. You should also see this description in the FSUIPC5 history document: 17. To help stop unwanted runway incursions, traffic freeze controls have been added to FSUIPC’s repertoire, operating on ground AI traffic in “taxi out” mode. These are: 1148 Traffic freeze toggle 1149 Traffic freeze on 1150 Traffic freeze off The way it is done is by sending Slew toggle controls to each relevant aircraft (i.e. those in taxi out state). There are no "on" and "off" slew controls, so FSUIPC keeps a note of what state you've set. If you load a new flight then the aircraft will all load in unslewed state in any case, so it is reasonably safe. However, you may occasionally need to use the toggle control twice. Because of this it is best to only use the on or off controls. Also, in my tests, it can sometimes happen that the control doesn't actually get to an aircraft. I’m not sure why. There may be so many and SimConnect so busy, that is misses some in the queue. However, this seems to be a rare occurrence, and for me it only happened when I sped the sim up to 4x so that the traffic got a move on! Pete

Just assign a key or button to "Lua AIFreezer", in the assignments dropdown. All the Lua facilities are there for assignment, always have been! (Like Macros) See the first page in the main Lua document in your FSUIPC documents folder, where all the supplied documentation is installed! Pete

The [LuaFiles] section is not for human editing, it is only a list of references to Lua files for assignments, and is maintained by FSUIPC. You have an empty [Auto] section, which is where you place macro and lua commands to be executed on start-up. This is actually how it is shown in the documentation! The command to load a Lua file is "lua" (just as in the assignments list), so you need 1=Lua AIfreezer in the [Auto] section. Pete

If the profile option is greyed out then the Profile whose name is displayed is already loaded for the current aircraft, as its name matches! Seems you have two aircraft with either the same name (?) or more reasonably names with the common substring you edited the [Profile.<name>] section entry down to. To start afresh delete the unwanted names in that list and instead ensure that a longer, more specific, name, is provided for the one you want the profile to apply to. We can't really help much more without details -- the INI file and the names of the two aircraft you are concerned about would help enormously. Pete

No. the 0x in front signifies hexadecimal, not decimal. i.e. base 16 not 10 (just as binary is base 2). Each digit goes from 0 to F (0-9 then A, B, C, D, E, F), with F = 15. So 0x0010 = 16 in decimal, 0x0100 = 256 and so on. ox8000 = 32768. Your list would be correct without the 0x (i.e. decimal), but masks are much easier to understand in hexadecimal. For example 0x005A = binary 0000 0000 0101 1010, or bits 1,3,4 and 6. Testing for those bits in decimal would be a mask value of 90, much more difficult to see exactly the bits being tested. Pete

Yes. (That's why that value is added to all the others to get the true value to use). Pete

Good. I merely changed to a simpler version of a Windows function call to get the P3D EXE path. I think Win10 1809 has a bug, though seemingly only affecting root folder installations (which are rare) as there are really no other reports (at least here, where they should be). Pete

There's the problem, though I've no idea what is causing it. A function asking Windows to tell FSUIPC where its containing Process is (that's Prepar3D.EXE of course) is saying it is in "\Device\HarddiskVolume4\Prepar3D.exe". That isn't a valid path in any case, hence the error 3 which is "path not found". If "Device" was the name of your PC, there should be \\ in front of it, not a single \. And having a shared path called "HarddiskVolume4" seems very odd. I note from earlier that your P3D is installed in the ROOT directory of drive D, not in any folder at all. That is very odd. Is there a reason for that? And do you have a PC called "Device" and a shared folder called "HarddiskVolume4"? Perhaps some description of exactly how you have configured your system would be useful, please, because we are really at a loss. It is as if standard Windows functions calls are returning unusable nonsense! [LATER] I've made another build which may or may not throw more light onto this mystery. Please try FSUIPC5150d.zip Pete

Okay. I've added logging to the part where FSUIPC requests the File Version information. Please download FSUIPC5150c.zip and run that, then show me the Log. (The ZIP only contains the DLL to place into yout P3D Modules folder). Pete