Pete Dowson

Yes, but it will be no use making a Lua plug-in for XPUIPC if it doesn't support plug-ins, so that's the first thing to ascertain. Pete

This was the change to how Lua displays were shown, listed for 5.110 last August (see the "History" documents: 7. The Lua and FSUIPC-offset controlled message Window on screen is improved by making use of new SimConnect window facilities. It is now similar in appearance to the one used in FSUIPC4. However, only one such Window is available at a time, and the title is fixed by SimConnect, not configurable. I'd like to know if that is the only change which is causing this problem, so I might find and send you version 5.110 to try. I doubt if adding more logging will help if 5.11 has the problem and 5.103b (only just preseding it) doesn't. It would certinly mean a SimConnect bug, so it might then be worth trying an earlier version of P3D. Do you have any? Pete

You'll need to find the XPUIPC support forum to ask about its Lua support. We don't deal with X-Plane here. To learn Lua the best place is the Lua.org website. There are several good books around too, available directly or through Amazon. For FSUIPC there are many Lua examples installed in the FS Modules\FSUIPC Documents subfolder. Pete

Hmm. That's interesting. Thanks. but it is still very odd that it is okay with other aircraft, just the PMDG 747 with this problem. I wonder if it is some sort of clash, that the 747 is trying to use the same facility at the same time. If so it may actually be a P3D bug. I'll check. Single line texts should be using the single line at the top of the window. No box. There never was a box as such. Multple line displays and Lua displays (as yours is) now use the SimConnect Message Window (not 'box' -- it shouldn't say 'box'). I've got to go out at present, but tomorrow I'll look to see if I can add a little logging around the SimConnect request being mad, to see if it is crashing in SimConnect. If so it will need a report to L-M.

That's strange, because the log shows it is definitely called (line 581). It has got to do with one of two things: 1. One (or more) of the Events. Many of them are L:Var events, which needs FSUIPC to continually read those L:Vars to see when they change. There's an example Lua plug-in which monitors L:Vars by reading them all regularly. Colud you test by loading the 747 then starting that plugin? Leave it running for a few sconds. (It is called "log lvars". 2. The ipc.display call, which should have done its job within the first second or two. could you try with that commented out (put -- in front)? Failing these actions we might need to try narrowing down what in the Lua could be setting up for the crash. That will be by taking half of it at a time, and keep halving till we find the culprit. (This won't work if there are more than one of them, of course). One other thing which might help is to run that same 777 Lua, with the 747 loaded, and the Lua logging on, using FSUIPC 5.103b, which you say doesn't crash. Don't run it too long as the log will get huge, just enough to get past where the failing one crashes (2-4 secs?). Then I can see what will likely be the first thing it does after the point where it crashes in the later version. Also I can then look to see if I can enable or add more logging. I think it must be related to the events being awaited as the log shows that the Lua execution comes to an end with it waiting for one, but none ever occurs. I'm running short of time at present -- off on holiday for 11 days next Wednesday. Pete

Aha! That is quite telling! Is your 747 fully updated? There was a PMDG problem with that particular update which, in the early days of FSUIPC5, I worked around pending a proper PMDG fix by disabling a feature it was calling with the wrong call type (a 32-bit call only executed in the PMDG code if it detected the relevant FSUIPC facility present). Your previous "working" version of FSUIPC, 5.103b, certainly qualifies as early enough. Unfortunately the Windows crash data shows an error in "KernelBase.DLL", a part of Windows, so it doesn't help very much except showing it's rather more complicated than a simple code execution problem in FSUIPC. I can't really do much with your Lua files. I thought of comparing the two but as they both crash with the 747 but neithe with the 77 there's no value in that. And that result alone also points directly at the PMDG 747. In the Lua(s) there is this, executed early on before any of the Events can occur. Does that display appear before the crash? ipc.display("Preparing Cockpit Boeing 747\nFILE: B747.lua", 7) Assuming that you cannot update 747 because it is already up to date then, though given what youve now said i think it wholly unlikely, maybe a Lua trace/debug log leading to the point of the crash will help -- enable that in the FSUIPC Logging Tab before starting the 777 Lua (not the 747 one, so I'll know it isn't something specifically in the 747 values). In those logging options, opt for a different Lua log file. Run till the crash then show me that log which will be named after your Lua file.. But the very first thing to do is make sure your 747 is up to date. I wan't expecting any different. It was just that if the crash was occurring in FSUIPC code them I needed to match your code to mine so I could see exactly where it occurred. Pete

More information most certainly is needed! The most relevant of course is the Lua file concerned, and possibly one of the other (similar?) ones for comparison. Then of course there are the crash details. Check in Windows' Event Viewer. Find the crash and show me the details. It'll be in Windows Logs -> Applications. It would also be good to download 5.124a and try with that, before sending me those files really. That is the current interim version -- see the Download Links sub-forum above. It is just a DLL replacement. That way we are both using the same. Oh, one other thing. Does it still crash if you don't load the PMDG 747 beforehand? Pete

Yes. This is to avoid over-complicating the user interface in the program itself for more specialised needs. The format of items should be reasonably self-evident, but those areas which can have more complex assignments do have the format explained, and examples provided, in the Advanced Users guide. With buttons and switches as well as multiple entries you can have conditional entries -- ones depending on an FS value perhaps (via its offset in FSUIPC) or on the pressing of other keys. There are flags which can be used to turn the button press into a locking toggle action - i.e. off->on on one press, on->off on the next, like the proper latching switch. Since ALL of your settings will normally* be in the INI file you should make backup copies now and then so you don't have to start again. Conversely, you can delete it altogether to generate a default one to start again, if you wish. Pete * The exception to all the settings being in the INI are when you use Profiles and opt for UseProfiles=Files. This puts all the profile-related settings into separate files per profile, and those go into the Profiles subfolder. In this case you'd want to make backups of that folder too. Such a complication isn't really worthwhile for most users. It is used by those whose INI file has become huge with different settings for different aircraft. Having separate Profile files makes it easier to locate and change things manually.

If an FS control (or "Event") resulted from clicking a button or switch on screen, and Event logging was enabled, then FSUIPC would log it. Yes. You need to add the other command, or commands, as separate lines -- with different numbers in front of the =. They would be produced in the order of that entry number. Pete

The data in the PMDG offsets is exactly as provided by the PMDG code in the aircraft model. I really have no idea how much of it works. My documentation for the offsets merely shows how their data is mapped, and is effectively a copy of the data in the ".h" file supplied by PMDG in the SDK folder in your PMDG aircraft folder. Maybe there's more information there, but otherwise you need to ask in the PMDG forums. Pete

I don't think there are built-in sim controls for those. They are probably mostly (if not all) local to the gauge itself, not affecting the sim engine itself. I assume there are no keyboard shortcuts provided for them by P3D itself? No controls for assignment listed in the P3D assignments lists? If not then they armed at mouse only use. Depending how the gauge was written there may be Local Variables (L:Vars) which you can write to in order to change the state. Try using the List Local Panel Variables control assignable in FSUIPC's drop down. It will list what's available in the current panel. There's a section in the FSUIPC Advanced Users Guide (about page 33) about L:Vars and how to change them using assignable macros. Note that this isn't a guaranteed method, and of course the macros you do for one panel are not likely to work on another -- Local Variables are local!It might take some experimentation to find the right variables to do what you want, even if they exist. Pete

Thats Button and Key logging, not Event logging! VK means "Virtual Key", and VK 80 is the "P" key. No idea what that has to do with the Battery. You need Event logging. Of course, but in FSUIPC only if you edit the INI file to do so. But if you haven't disabled controllers in P3D then that will probably be sending things. And maybe something else is. Since I can't see what you see, and you don't really describe it, I have no idea. You mean operating the "MFD" buttons on screen? Can you tell me what "MFD" functions these are? All MFD means is "multi-function display", it tells me nothing about what it does or what you use it for. Pete

In what way is it "stopping Prepar3D from starting"? What are the precise symptoms - i.e what happens? I also ALWAYS need version numbers: which version of FSUIPC5 and which version of P3D4? Re-installing will simply replace the same DLL with the same DLL, so there's no way you'd expect any change really, is there? See if there is an FSUIPC5.LOG file generated in the P3D4 Modules folder. if there is, show it to me please. Pete

Well, in that case it isn't FSUIPC doing it. There's no way it can. Possibly you have conflicting assignments, maybe in the P3D (if assigning in FSUIPC you should disable controllers in P3D). Or something else you have running is making this happen. Otherwise It sounds like your hardware is playing up! Pete

It sounds like you have the switch set to repeat whilst pressed, an option in the assignment tab. The battery control is a "toggle" (Toggle master battery) so it goes on or off whilst a button is pressed, and a latching switch 'on' is always pressed. I don't know what functions you want, but the easiest way to work that out is to use FSUIPC's logging facilities. Enable event logging (not the axis one) in the Logging Tab. Then when you operate a switch in your aircraft, eg using the mouse, if it uses a control at all it will be logged in the Log file in the Modules folder. To make this an easier process, temporarily run the sim in Windowed mode (ALT+ENTER) and enable the Console Log in FSUIPC's Logging tab. Then you can see what happens in real time, on screen. Pete

Well, there were two posibly relevant threads I just found by simply searching on vPilot. This one where something like your line worked but I note that the were no spaces in the pathname to vPilot. I think spaces make all the difference with Windows: and this one which is probably okay (when he gets the path right) because it has no parameters in any case: You probably need to hone your searching skills a little? ;-) Pete

That's only the assignment. Have you calibrated it? Check in the [JoystickCalibration] section. If you have then there will be a SteeringTiller line in there. By default that might contain: SteeringTiller=-16384,-512,512,16383 If you've not calibrated do that first! You can't "fiddle" figures you've not yet set! And better than fiddling you should first try setting a different slope! The slope selection is part of the calibration. If you've never actually used FSUIPC calibration, when (a) why not? and (b) follow the numbered steps in the Calibration chapter in the User Guide. BTW if you then still aren't happy with the built-in STEERING SET control (I don't use that myself) you can try the FSUIPC one, in the "direct to FSUIPC" assignment mode. That automatically reduces steering sensitivity as you increase ground speed, in favour of rudder control. Nice for take-offs. The only drawback with some aircraft is that the nose wheel is often linked to the default control, not to the FSUIPC one, so it doesn't visibly turn -- the FSUIPC one uses the rudder. But if you never watch your plane from outside whilst taxiing that doesn't really matter. Pete

This vpilot problem has cropped up before and a solution found. What is happening is that Windows is asked to load the program "vpilot.exe -host" which of course won't exist. It needs to load the program "vpilot.exe" with parameter "-host". I don't remember the earlier solution (you can do a search in this Forum), but there are two things you could try: RunIf1=READY,CLOSE,"C:\<complete_path_here>\vpilot.exe" -host which I have doubts about, or, definitely better, make a little bat file to run vpilot with that parameter, i.e containing start "C:\<complete_path_here>\vpilot.exe" -host and save it as, say, "runvpilot.bat" in C:\<complete_path_here> Then have your RUNIF like this: RunIf1=READY,CLOSE,"C:\<complete_path_here>\runvpilot.bat" Pete

FSUIPC, the same as all software, does not suddenly change on its own! You've either got a corrupted settings file (the INI), or, more likely, you are not using Joy Letters and have reconnected the units so Windows has changed the assigned numbers, or have had a big Windows update, which would do the same thing. One other possibility is that you are using Profiles for assignments and have loaded an aircraft not assigned ot that profile. It you wanted to do this to reset all your settings and start again then you are wasting your time. Installing FSUIPC never changes your settings. It it did there'd be a lot of angry users! If you want to start again you have to delete the INI file in the Modules folder. Pete

Not in the update I have. I thought I had the latest. Can you give me a link so I can get it please? Or, if it is okay, send it to me at petedowson@btconnect.com. (Please ZIP it first). Thanks! I will have a look at this, see what I can do. I'd prefer to add data to one of the existing files if possible, rather than make yet another -- there are too many already! Which items of that data are you needing? Note that I am pretty busy at the momet, so it may be a while before I get to it unless it is pretty easy. Pete

Is this data part of the AFD (Airport Facility Data)? I don't think I have any information on that. I see that ADE175 can list those gates which have jetways (though it shows none for Aerosoft EGLL!). The data it shows for Aerosoft EGCC includes jetways but I'm not sure what other data you get apart from what you get for gates. Have you got details of what there is, what it looks like and what you'd need? The AFD information I use is that documented by Winfried Orthmann, basically an FS9-based analysis with some updates for FSX provided by others (anonymous). The latest I have is as show below. Can you supply a later version with Jetways added? (Sorry about the format here -- the table structure gets lost in Forum text!) Pete 1.10 TAXIWAYPARKING [0x001b] This record type has a short fixed part for all TaxiwayParking records together and a longer variable part with sections for each TaxiwayParking. The fixed part is 8 bytes long: offset length format description contents 0 2 WORD ID 0x001B 2 4 DWORD size : variable 6 2 WORD number of taxiway parking records present The record sections for each TaxiwayParking are again of variable length, depending on the number of airlineCodes present:. offset length format description contents 0 4 DWORD bit 31-24: count of airlineCodes present bit 23-12: number bit 11-8: type 0x1 = RAMP_GA 0x2 = RAMP_GA_SMALL 0x3 = RAMP_GA_MEDIUM 0x4 = RAMP_GA_LARGE 0x5 = RAMP_CARGO 0x6 = RAMP_MIL_CARGO 0x7 = RAMP_MIL_COMBAT 0x8 = GATE_SMALL 0x9 = GATE_MEDIUM 0xa = GATE_HEAVY 0xb = DOCK_GA bit 7-6: pushback (00 = none, 01 = left, 10 = right, 11 = both) bit 5-0: name 0x00 = NONE, 0x01 = PARKING, 0x02 = N_PARKING, 0x03 = NE_PARKING 0x04 = E_PARKING, 0x05 = SE_PARKING 0x06 = S_PARKING, 0x07 = SW_PARKING 0x08 = W_PARKING, 0x09 = NW_PARKING 0x0a = GATE, 0x0b = DOCK, 0x0c = GATE_A, 0x0d = GATE_B, 0x0e = GATE_C 0x0f = GATE_D 0x10 = GATE_E .. .. 0x25 = GATE_Z offset length format description contents 4 4 float radius 8 4 float heading 12 4 DWORD longitude 16 4 DWORD latitude .. 4 STRING airline designator ( 0..n times repeated)

Not many these days. The PMDG Boeing airliners for FSX do, I think, though The facilities in those are probably better driven using the "custom controls" they added and listed in the accompanying SDKs. There are probably other examples and notes in the "User Contributions" subforum above. Pete

Not sure about the "calibration" ones -- what do they do? But certainly there are normal controls for regular things like the barometric adjustment on the altimeter (the "Kohlsman" window) and the heading bug. Did you not search the assignments dropdpwn or look in the list of Controls I provide in the FSUIPC Documents folder? Apart from looking them up? Well, you could log Events in FSUIPC (Logging tab) then operating them with the mouse and see what controls ("events") are logged. That's a good way. Sorry, I don't know what sort of aircraft you like or how much realism you pursue. I'd look at the market place if I were you, and read reviews. It also depends of course how deep you want to get into aircraft detail, into the realism. You can go as far as you like, but then you do have to learn things properly. Pete

Steering tillers are meant to be pretty sensitive. with airlines like the A320 you should be able to almost turn a full circle in your own space. How would that ne possible with a limited turning angle / cuircle? If you are calibrating it through FSUIPC then of course, using "slopes", you can make it less sensitive in the central area, at the cost of greater sensitivity at the extremes -- after all the full steering range should be achievable. If you really don't want the full range then you have to calibrate then "fiddle" the values in the Settings (FSUIPC's INI file). I'm sure FSLabs have designed their aircraft to be as realistic as possible. Perhaps its ground steering is something you need to get used to? What do other users say? I assume there's an appropriate support forum? Pete

Er, which part of the "whole script" is the problem? There's no function "depart" there! What has that got to do with "my" script? Have you tested the latter on its own? One weird thing I do see is this: until (ipc.readUB("3367") > 0 ) In other words a loop depending on an offset value! You are mixing up loops and event-driven functions. Are there more? Is your plug-in stuck in a loop someplace? You should be using an event on offset 3367 to detect it changing, not a loop within an event function. The latter makes little sense -- think about it. What happens to other events whilst you are stuck in such a loop? You seem to have several loops waiting upon offset changes. I've not checked but i wouldn't be surprised if what you are experiencing is a "deadly embrace" where one thing depends on something else which cannot happen because of some other action is preventing it being seen. I assume you've used the Debug Logging option in FSUIPC's Logging Tab to debug your appication? If not, don't you think you should? Surely you aren't expecting the Lua interpreter to tell you how your program isn't working? Errors are related to actual syntax being wrong, not the logic of what you are writing! Pete