Pete Dowson

Why are you doing that when running IYP? Do the MakeRunways for RC's database before even starting FS or IYP. Run RC4 and tell it to update its data. All that is "off-line", not on-line whilst flying! I've no idea what that is. I use IYP a lot and have never heard that! What does Robert say it is doing? I don't know "IYP-extender", but i assume this is an internal name for IYP? Surely this must be an IYP bug. Can't Robert help at all? If it happened to me I would be 100% dependent on Robert's support to resolve it. Aha! It is trying to get the planned route data from your PM CDU. I assume, then, that this problem is occurring AFTER you have initialised and programmed everything in the CDU ready for your flight? Why are you running MakeRunways then? 5B00 is a PM-driven offset. It won't get filled in until the CDU is running. It'ss in the FSUIPC SDK, downloadable from the usual place. But you can also use FSUIPC monitor -- right-hand side in the Logging tab. Offset 5B00, type AsciiZ. But surely you only run MakeRunways once after installing new scenery? How does this get into this part of your flying? I would ask Robert why, even if it can't find ROUTE.BIN, it hangs unresponsively. That needs to be fixed no matter what the surface problem might be. Regards Pete

Okay. Let's see: -- require("sound") necessary ??? -- require("fsuipc")not necessary Neither are needed. All FSUIPC built-in libraries are built in and always available. sound.playloop("Y:\FS9\Sound\barn_fx.wav") ipc.lineDisplay("sound ends",5) The problem there is that in Lua strings, same as in many languages, the "\" character is used as an escape -- i.e. it modifies the next character. So your sound path becomes: Y: ?S9?ound?arn_fx.wav where the ? characters are probably non-printables. To get a \ in a Lua string you use \\, so "Y:\\FS9\\Sound\\barn_fx.wav However, if Y:\FS9 is the FS installation being run then you could shorten that to just "barn_fx" And please note that "sound ends" is not true as PlayLoop will loop the sound forever or until you issue a sound.stop call for it, quoting its reference. I've tried your Lua on FS9 here, and with that corrected it works on my Windows 7 PC. However, it only plays a short snippet on my XP PC. What version of Windows are you using? I'm wondering now whether there's something different in the sound calls for XP versus Win7 ... checking. [LATER] Okay ... I've found out what is happening. On Win7 (and, I assume, Vista), the sound continues playing even if the Lua program terminates. On XP it doesn't -- so since there's nothing else being done in that Lua program, you don't hear the sound, or only a short sharp snippet. If I add ipc.sleep(10000) after the sound.playloop call, I get the "narn_fx" sound playing for 10 seconds then ending, abruptly. This is rather unexpected. I'll see what I can do about it ... Regards Pete

Really? In what way? If there's no add-ons menu then you either have a broken SimConnect installation (i.e. your FSX installation is incorrect), or some other add-on installer has made a mess of your DLL.XML file. Please use a supported version of FSUIPC -- nothing earlier than 4.60 can be supported. From the posted Installer log I also note this: which seems to indicate that your FSX is only in its original buggy version (60905) yet you've have the SimConnect from the SP1 update installed. This will cause problems as the SP1 SimConnect is not compatible with the original FSX installation. Regards Pete

Sorry, I'm not making changes to this facility (which has been perfectly acceptable now for over 10 years). And in any case, in particular the destination airport and distance to go are not available for flights not using FS plans, and even then such information may not be easily available without the PLN file being located and read, making FS more likely to suffer jerks every time a file is saved. Surely you are referring to manually saved flights, not auto-saves? Else I think you are missing the point of the autosave facility, which is only to enable a restart at a suitable point during a flight should you suffer an FS crash -- or want to retry that landing which went wrong. If you really wanted to, it would be possible to do almost everything you ask via a Lua plug-in, instead of using auto-save. It could be button or keypress driven too, to avoid unexpected jerkiness. Regards Pete

1. The restriction in all RECENT versions of FSUIPC is only that the name is the same. You can have a different email address. 2. I cannot support such old versions as 3.96 in any case. Please update to a supported version and you will be okay. The oldest supported version of FSUIPC3 is 3.98. Regards Pete

Really? Wow! Does a Mustang actually have an MCP? The MCP with the Mustang? If the Mustang supports the functions of an MCP and has a way of operating those functions, then the answer would probably be yes -- but you need to ask someone who knows the aircraft. If (a) the mustang has an autopilot, and (B) the Mustang autopilot is controllable by keystroke or button press, then yes, of course. All FSUIPC offers is the ability to make such assignments. If the A/P is only mouse-controllable then you might need something like "Key2Mouse" and a fixed window. The displays on the MCP would only be updated if the Mustang A/P is actually based or is identical to the default FS A/P. If they have programmed an entirely independent A/P it is most unlikely that you could get the data for display, the there is a small chance they could be found as "L:Vars" and the displays programmed via an FSUIPC Lua plug-in. Regards Pete

The EFIS module is just a collection of knobs and switches -- no indicators or displays. So there is no "programming" involved! It is merely a process of assignment of "buttons and Switches" to the controls specific to your aircraft. Assigning buttons is covered completely in the FSUIPC documentation, along with pictures. Regards Pete

What does "FSUIPC doesn't dialogue with FSX" mean? How do you detect this? FSUIPC is not specific to any particular aircraft -- it does not know nor care about what aircraft you use. Really? What's a "DLL Helper"? I've never heard of such a thing. So FSUIPC must "dialogue with FSX" then! Sounds like a faulty install for that aircraft, then. Is it designed for FSX? You cannot simply transplant FS9 aircraft into FSX -- many of the gauges are incompatible, as a rule. Since an installation of FSUIPC merely consists of a single DLL in a folder, replacing it any number of times will obviously make no difference whatsoever. Since your problem is with an aircraft, not with FSUIPC, why not try re-installing that instead? Wouldn't that make more sense? Regards Pete

Yes, you are trying to create a mouse macro for a mouse area which does not call the standard C-structures used for gauges written via the standard Microsoft gauge SDK. As documented, mouse macros are often not possible -- particularly for Microsoft's own panels (because they did not use their own SDK), and for all modern gauges (particularly in FSX) written in XML. In general it would help if you stated the VERSION number of the FSUIPC you are using rather than just "latest" which is always pretty meaningless as different people have a different notion to what is the "latest". Regards Pete

That's a shame. Perhaps you can make that part of the brake pots completely unused? Even if you lose half of the range it should still be okay, or you could increase the pots value -- say 100k instead of 50k and only use half? Moving or merely not-centred? As I said in my previous reply, you could do it quite easily with a Lua plug in, though detecting a moving rudder instead of a non-centred one is more complicated, of course. You can have a Lua plug-in, loaded automatically when FS is ready to fly, which sits in a loop reading the rudder value. When it is non-zero (or maybe outside a small range near zero), disconnect the toe brakes (via offset 341A), and reconnect them when the rudder returns to centre. Pete

But there's no way assignments can be "lost". Can you tell me EXACTLY what you are assigning, where and how, please? That's an absolutely sure sign something is assigned which you obviously aren't aware of. FSUIPC cannot invent numbers to put in there, they are arriving from either another device or from an FS assignment! Or possibly even from some add-on program. Windows device manager, part of the "System" control panel applet. In the USB section -- check in all of the USB hub properties. I am pretty convinced you have dual conflicting assignments. However, I can't help you fix it very easily since you seem so adamant that you haven't. I suggest you temporarily remove your FSUIPC INI file (just move it or rename it), so FSUIPC makes a new default one with no assignments at all. Then see if anything operates, specifically throttle 2. If nothing, absolutely nothing, is assigned with a default FSUIPC setup then show me the FSUIPC INI file. Unfortunately I am away on holiday with no internet access, from this evening until October 17th. Regards Pete

It is NOT WideFS creating a "bogus address"!! The address is usually the Internet address of your ISP, or related to it, and when Windows supplies this to WideClient it is always a result of a wrong setting in your Router. If you cannot set your router up to work correctly then just override it by giving the explicit IP address in the INI file, as documented! Pete

Sorry, I don't understand, the movement of WHAT is greater that what movement of the toe brake? I cannot picture what you are talking about here. And if you cannot avoid pressing the top of the rudder pedals down when using the rudder itself, shouldn't you move the lever operating the toe brake pots? Of course, via a Lua plug-in. Almost anything can be done that way. But this would prevent asymmetric braking when turning, in order to achieve a tighter turn. Do you really want to prevent one of the more useful aspects of having toe brakes? I don't understand that one. Sorry. BTW I am away on holiday without Internet access from this evening until October 17th. Regards Pete

I don't know VasFMC well enought to say for sure. I assume it wants keyboard inputs. You have to connect the MCP to the FSX PC, not to the second PC. I have no VRInsight support in WideClient. Follow the instructions for VRInsight devices as given in the documentation. Check the Lua one for VTRI devices in particular. There's already a Lua program there for handling Mach speeds on the MCP Combi, Then you'd need to program all of the A/P related buttons and knobs, in FSUIPC, to use "KeySends" to get them over to the second PC, and in WideClient.INI there you have to convert all of those KeySends into appropriate keypresses for VasFMC. For the displays, it depends. Can you read the VasFMC displays in FSUIPC offsets? If so you'd need to add more filters in FSUIPC's INI to stop SerialFP2 sending FS values, and add Lua code into the Lua program to read the offsets and send the values to the displays. If VasFMC uses FS values then you could leave that to SerialFP2. It might be quicker and easier to get it all working on the FS PC first, then transfer VasFMC to the second PC and revise the assignments to use KeySend and WideClient keypresses then. It probably isn't going to be very easy, and I'm afraid I cannot help much as I don't use VasFMC. Also, from tonight I am on holiday with no Internet access until October 17th. Regards Pete

Well, the position is saved in the flight, so it must be that your controls are feeding an incorrect value initially. Maybe they are sleeping -- check that you have Windows USB power management turned off. Otherwise it likes to turn off USB power when there aren't any signals going to or from devices. Re-assigning should do nothing if they are already assigned. The only thing entering and exiting the assignments Tab would do is re-check the devices are still operating. It most certainly sounds as if there are duplicate assignments. Have you disabled ALL controllers in FS? You have to use the drop-down list and do it for each one. If it isn't this it can really only be a severely broken device. Why are you assigning in FSUIPC in any case? Are you using different controllers for different aircraft? You can calibrate controllers in FSUIPC for axes assigned in FS you know. Regards Pete

It's pretty much the same as you have already. You have those lines already. Release is just a "U" at the start instead of a "P". You know that already too! You don't "pass on" an offset. Whatever the value stored there is the value you get! Like a post box, or more a file. This sets 66C0 to zero, and calls up the ATC menu, when you press 0,0. So far, so good. But this increments 66C0 when you release 0,0. Why? This is a waste -- next time you press it it will be zeroed again, so why increment it on the ATC selection button? 13=B66C0=0 U0,0,C65564,0 You are sending the ATC select control AGAIN when releasing 0,0. Why? Won't that simply clear the menu? What are you thinking here? These are all okay -- but what about when 66C0 is 0, as it is initially? You weon't do anything UNLESS you increment 66C0 (with the other button). Is that what you want? If so, fine. So, you ARE incrementing on 0,9 as well as when releasing 0,0. Don't you think the 0,0 one is rather redundant? Regards Pete

Have you read the documentation for this option, where it tells you which option in Windows stops this working ("show window contents while dragging")? It defaults on, you need to turn it off. You probably did that before, on your previous operating system, but forgot. In Win7 the option is in the Control Panel "Performance Information and Tools" -Performance Options. In general it is quicker to check the documentation first, especially since, these days, I'm away from Internet access for several periods a year. In fact I'm away from tomorrow night for nearly two weeks. Pete

Hmm. That's very odd -- it should certainly not cause any sort of crash. Having them enabled and scanned in both places could lead to conflicting values when using the controllers, but it should certainly never crash FS. I would suspect the joystick driver if it did. Anyway, I am glad you managed to find it and fix it yourself! Regards Pete

It shouldn't be, unless you are using the wrong driver. My FSX PC is using a GTX 480 card, very recently purhcased and certainly DX11 enabled. Does it crash the moment you click on the "Axes" tab? Does it manage to draw the axis assignments screen? Or sometime later? If later, exactly what is shown? Can you enter the Buttons & Switches screen? What VERSION of FSUIPC are you using. When it says a fatal error has occurred, what is the exact message, and is there a place to click to get more information? There's never a "fatal error" with no information. You cannot restart FSX if it is still running, ever, fatal error or not. Pete

Three things: (a) You increment the byte at 66C0 before testing it, so the first option selected is the "14=B66C0=1" line, not the first listed. (b) You should reset the byte at 66C0 to 0 when you press the button for the ATC menu. © In order to select, say, the 4th option you seem to need to select the preceding three first. Is that what you are intending? If not then I think you need another button to increment 66C0, not have it increment each time you make a selection. After each button? How many others? You only show one button above, 0,9. Your description says you are using two buttonsif you mean reset the count every time, you'd never get past 1 would you? By "reset offset" you mean the "Offset byte set" I presume? There's no "reset offset" control. One way to do it with two buttons would be to program the ATC Menu button to do the above conditional actions on button release, and use the other button only to increment 66C0. So the sequence would be: Press and hold pressed the ATC Menu button -- this sets 66C0 to 0 and opens the ATC menu Then, whilst it is pressed, use the other button to go to the 2nd and subsequent entries (else you'll get the 1st) Release the ATC Menu button so that the correct conditional entry (as above) actions the selection. Regards Pete

I still need to know the VERSION number of FSUIPC, and a more detailed description of EXACTLY what you are doing when it "crashes" (i.e. what exactly is displayed, in what tab and at what stage), and also EXACTLY what you mean by "crash" -- what is Windows telling you? Without any information (and you've given me virtually none whatsoever so far, despite my asking this week as well as weeks ago, (as you will find if you refer back), there is no way I can possibly help you. Surely you must see that? That was only a suggestion based on such little information from you, apart from the fact you were entering FSUIPC options. Almost 100% of crashes occurring when you enter FSUIPC options are down to graphics problems, and the crash occurs before FSUIPC actually gets control back from Windows after requesting the options window be drawn. There was one other, infrequently occurring, problem of the same type which turned out to be some sort of clash with an add-on DLL called Actigate, but I don't think that is used in FSX in any case. The only other serious problem which has ever occurred in the options is a HANG, not a CRASH, when the buttons or axes tab is entered, and this hang has always been due to a bad joystick driver, often an old one for game ports. This should not happen with very recent versions of FSUIPC because it times such joysticks out and doesn't re-scan them. I'm on holiday next week and the week after, so please be aware the response time now might be two weeks. Regards Pete

FSUIPC cannot have anything whatsoever to do with preventing you running FSX. If FSX is crashing when the FSUIPC options menu is entered, then it will almost certainly be a graphics driver bug (the options menu is a standard Windows graphic). See if it happens in FSX Windowed mode -- usually these bugs only affect full screen mode. You don't describe specifically when it happens and what the crash report tells you, so I cannot advise further on that. Is this related to anything of mine? Sorry, it seems to be inserted without connection. Nothing of mine has any internet connection in any case. I certainly cannot even begin to help without more information. And the first and always necessary information is, as always, the version number of FSUIPC. If it is earlier than 4.60, you need to update first. You should then try with the latest Update in the Updates Announcement in this Forum. Pete

Erseems something missing between 2 and 3? If the battery switch is already on, how can you tell if step 3 switches it on? What is "SPAD" doing with virtual buttons? I don't know what you are thinking, but a virtual button is a bit which signifies "on" or "pushed" when it is 1 and "off" or "released" when it is 0. This is exactly the same as how real buttons are seen inside software -- Windows provides their status as an array of bits, just like the virtual buttons. Therefore they can be used in an identical manner. I've no idea what SPAD is doing though -- why not use FSUIPC's logging to show you (and me)? It seems rather odd to me that you talk about ("Event when switched ON"), (Joystick 64, button 0) for one action but ("Event when switched OFF"), (Joystick 64, button1 ). Why are you using two separate virtual buttons, but taking note only of one being turned on and the other being turned off? You must surely realise that initially ALL virtual buttons are "off" (why would they be otherwise?) so your step 2 can't do anything the first time. In both cases you'd have to press twice for any new action, wouldn't you -- to turn the button on then off, or vice versa? Wouldn't it be far easier to simply program the same virtual button for both on and off changes? Oh, and what is wrong with the standard FS Master Battery control? Doesn't this aircraft take any notice of FS's battery switch? Regards Pete

Only the original one being destroyed or rendered unreadable I should think. These types of INI and CFG files are actually maintained by Windows via a "Private Profile" interface -- there are no direct file accesses to them in FSUIPC's own code. Maybe Windows was in the process of updating it on FSUIPC's behalf when you had the crash -- if the "Free Flight" menu you mention is from the initial selection screen just after loading FSX then FSUIPC does write a couple of parameters back to the INI when it is reading all of the existing ones, keeping track of things. It's always a good idea to make backups of any of your data files especially after making serious changes. Not only the FSUIPC4.INI but of course also your FSX.CFG and SCENERY.CFG files. I make a very regular habit of such backups! Regards Pete

The attachment clearly shows that the program you are running has an error in itself. It is reading the FSUIPC version number and trying to use it as a "double" floating point number. The program is obviously buggy and needs fixing. Please contact the supplier or author. If he needs help working out why this is happening with one version of FSUIPC but not another, I will help all I can, but he needs to look in his program to see what is going on! Regards Pete