Pete Dowson

The Lua program must go into the same folder as WideClient, on the Client PC. It will run automatically when WideClient connects. If you've only got one T8 on that PC its ID will be 0, of course. Make sure you are using an up-to-date version of WideClient. Older versions did not support the GFD library. Regards Pete

WideFS will not operate without registration. After registering WideFS you just need to enable the Server in the FSUIPC options dialogue. Evidently you've not looked at the FSUIPC option dialogue else you would have seen that you needed to register WideFS. Pete

Djeez is correct, but you don't actually need to Kill" the Lua first -- when you re-execute it the previous one is automatically killed. You can add new macros, Lua scripts, edit the button, keys ad axis assignments and calibrations in the INI, at any time with FS running. You just need to go into the FSUIPC options and use the relevant Reload button. For macros and Lua scripts the reload on any of the Buttons, Keys or Axis tabs will re-index them. Regards Pete

I normally would advise against attempting to re-install FSX, because the uninstall process is not very good and can make things worse. When I had serious SimConnect problems I eventually had to re-format the disk and start by reinstalling Windows. At least this gives you a nice clean and efficient system (for a while! ;-) ). Before going so far you could try a few easier alternatives. Have you got a lot of add-ons installed, for instance? You could try renaming your DLL.XML and EXE.XML files, for instance, and re-run the FSUIPC4 installer. Then rename also the FSX.CFG file, so FSX makes a new one. Save the original three files so that, should this fix matters, we can try to determine what the cause was. You will find those files is C:\Users\Treleaven\AppData\Roaming\Microsoft\FSX Regards Pete

You are mixing up two different things. the joystick numbers are arbitrarily assign numbers designed to be different from real joysticks, and to include a client PC differentiation when sent from a WideFS client (to allow the same types of GF units to be distributed on a Network). In the Lua GFD library the unit number used is the one assigned by GoFlight on that PC. Each different type (P8, T8, MCP, RP48, etc) starts at id = 0 and then upwards for as many of each type as you have connected. So if you only have one of each all the unit numbers are 0. If you have two P8s, one will be 0 and the other will be 1. You can use the GFDdisplay lua example to find out. The ID of the light may or may not be the same as the button it is next to. Obviously, in cases like the MCP, there's not necessarily one LED per button and they aren't always arranged together. In the case of the P8 I don't remember, but they probably do align. Regards Pete

Well, it IS the heading, but it is TRUE. For the MAG heading as more generally used (except above lat 60) you'll need to subtract the Mag Var (02A0). Regards Pete

But as is documented, 05D0 is the current viewpoint direction, not the aircraft heading. your view direction could be anything. Also as documented, that offset doesn't work in FSX. The aircraft heading is provided in offset 0580, for all versions of FS, along with the rest of the aircraft position and orientation data (LLAPBH == Lat, Long, Alt, Pitch, Bank, Heading). Regards Pete

There's something really strange with your FS installation: According to Simconnect, FSX was stopped (in menus or similar) loading till 408 seconds later (i.e. nearly 7 minutes!). What on Earth is it doing all that time? 2839 ## EV_SIM=stop ... 408847 ##: ST_SIM=stop 408925 ## EV_START 408925 ## EV_SIM=start 408941 ## WHYSTART: SOON: (0366=Y || (0264=N && 3365=Y)) && (3D00=N || (0580=Y && 0264=Y)) 408941 ## ... and no class #32770 window! 408941 ## WHYSTART: NOTYET: (No#32770=Y && time=Y && 3365=Y && seeStart=Y && startime=N) 409627 System time = 03/03/2012 15:59:19, Simulator time = 15:52:33 (23:52Z) 409627 Aircraft="Aircreation582SL red" 409939 ## Starting everything now ... [/CODE] Then, it was all okay. If it takes 7 minutes to be ready with the default flight, with a simple aircraft, it could presumably take a few hours with your complex add-on aircraft? In the end, in that session, your total actual running time was 162 seconds (less than 3 minutes out of the 11 minutes elapsed time! [CODE]Average frame rate for running time of 162 secs = 29.9 fps[/CODE] I'm sorry, but i can't imagine what is taking so long in your FSX installation. It certainly seems to need a thorough repair! Regards Pete

Please emails me -- petedowson AT btconnect DOT com. Regards Pete

Well, as a perpetual tinkerer I certainly know what you mean! Even when enjoying a flight i'm thinking of the things I could change! ;-) Pete

SIOC can't send 32-bit numbers? That's bad. Since the AP Altitude is 65536 x metres, you could try just sending the whole number of metres as 2 bytes to offset 07D6. You'd only get 3.2 feet accuracy of course, but most autopilots round to the nearest 100, or at least 50, un any case. Regards Pete

I only use auto-shutdown on Client PCs, -- mainly because they have no keyboards or mice. I do that with Ctrl+Shift+E, but close FS manually using the usual Att F X. Ctrl+Shift+E is a signal to the WideServer part of FSUIPC4 (build in from the original DLL for FSUIPC3). It isn't aware of the Programs run by the FSUIPC4 parameters. It was different with WideServer.DLL in FS9 and before, because that also had its own program loading and terminating facilities. However, I'll have a look to see if I can make the WideServer part send an appropriate signal back to the Programs part of FSUIPC. It shouldn't be a problem. Why aren't you switching the aircraft battery off before closing down, or don't you like starting up 'cold and dark'? Regards Pete

This looks exactly like the usual SimConnect trust bug. Please see "FSX fails to run after FSUIPC4 first installed" in the FAQ suforum. This is the only cause if there is no FSUIPC4.LOG produced in the Modules folder. If there is a log, show me that please. Regards Pete

I like to have practical examples, so when you've solved your needs with appropriate mouse calls in a Lua file, I'll include that in the Lua examples collection, with your permission, of course! ;-) Regards Pete

There's no "mouse" library example at present, and I wouldn't call it "mouse.lua" but something more explanatory. What i said was that in addition to all the other libraries already supported, there's now a library called "mouse" which provides functions for moving and clicking mice. Please look up the mouse library section in the latest Lua documentation. Pete

The "direct to calibration" is 'better' in terms of being more efficient, but being direct it does bypass a lot of add-on aircraft code which, in the case of the PMDG implementations, evidently matters. Okay, all as it should be, though if you aren't calibrating idle and full thrust dead zones, and the inputs are so perfect at -16k to +16k, then such calibration isn't doing anything for you, of course. If it is doing that it is most definitely a bug, but as I said earlier i can't reproduce it here, so I'm a bit at a loss at present. I could do with that logging i mentioned. Really there's no point in sending just the INI, best wait till you've had time to do the logging too. No. FSX will ignore them if controllers are disabled, but watch out for FSX automatically re-enabling if it thinks the controllers are new, e.g. plugged in a dfferent USB. I'd like to fix it though, so thanks for continuing to help. Once I can reproduce it here I can fix it. Thanks, you too! Pete

Hmm. strange, because that extra logging option was cleared: 174908 LogOptions changed, now 00000000 00000001 which should never happen by itself. Can you please try loading the default flight, which appears to be the standard FSX default. We need to see if it is something to do with that aircraft or the flight file. Yes, as you said earlier, but that's not because FSUIPC isn't running, but because FSUIPC appears not to be getting that information (nor much else) from SimConnect. the fuller logging i suggested woukd be useful too. Regards Pete

The latest and supported version is 4.8. I've no idea what i did to you to make you so abusive, but I suggest you exercise your own advice next time you pay a visit, or just not bother. You obviously don't look at many of my responses or else you'd see that not only do I try to be as helpful as i can, in a constructive way if possible, but I regularly add new facilities and make changes on individual requests. Go find another product with as good support. I also support non-registered users just as much, and you can't say that about many others -- you can't get into many of the Support forums until you buy their product! Pete

They are not 'options', they are just the standard FS controls, and since they start with "Axis" they appear near the beginning of the drop-down assignments list, not much further down like the "ThrottleN Set" controls you previously assigned. Those are the controls you should have been using all along, as advised. I don't know why you chose the others. It sounds like you have dual assignments to that lever so they are conflicting. Pete

The ability to move the mouse pointer and click the buttons and move the wheel was added to the Lua facilities in a new "mouse" library, just this week. Versions 3.999d and 4.804 include these facilities, and the latest Lua downloadable package includes the documentation for it. See the Download Links subforum. Mouse operations have never previously been supported by FSUIPC because, really, it is a last resort. Mostly you cannot predict where the mouse should move to unless you always use a fixed 2D cockpit view, or have undocked and fixed gauges. With most folks these days favouring virtual cockpits in which they move around there's no way mouse clicking can be programmed to do anything useful. Regards Pete

Wow, nearly three minutes to load FSX? Does it always take as long as that? The log shows that you weren't actually in normal flight mode for very long. Here you appear to get into flight mode (i.e not in menus and not loading): 158856 ## EV_START 158856 ## EV_SIM=start 161227 ##: ST_SIM=start 163754 ##: ST_SIM=start 166297 ##: ST_SIM=start 168871 ##: ST_SIM=start but then, within 13 seconds you are either back in a menu or loading something else: 171211 ## EV_STOP 171211 ## EV_SIM=stop 174908 LogOptions changed, now 00000000 00000001 Looks like you went into the FSUIPC menu and changed the logging options? Why? I suspect that not enough time has elapsed in Flight Mode for FSUIPC to guarantee correct operation. I think you need to explain exactly what you are doing here, please, because the logging shows merely that there was no attempt to actually use FS in the period of the log? Maybe you just waited a few seconds and decided that was enough? But why change the logging? Please don't, and try to let it run a little longer. FSUIPC needs to see a few things coming back from SimConnect in order to operate normally. These are the ID of the User Aircaft, and the FS time, both local and zulu. It uses these to determine that the Simulator is actually ready to fly -- many things FSUIPC needs to do either don't work or a precarious if it does them too early, hence the checks it makes. Could you let the Sim boot into flight mode without selecting a different flight or aircraft etc? In other words just click on "Fly Now" immediately the start menu appears. I'm wondering if there's something about the aircraft or flight you are loading which is causing the problem. If that doesn't work, I need yet more logging. Please add the following line to the two you added last time LogExtras=x400 so that you now have: Debug=Please TestOptions=x800 LogExtras=x400 This will make the log very big, so ZIP it up and email it to me at petedowson AT btconnect DOT com. Regards Pete

Sorry, but I've no idea why you are getting hot starts. Maybe you can check with the support forum for the aircraft you are using? I can help with FSUIPC questions but I can't relate this back to FSUIPC facilities at all. Regards Pete

The most likely problem is that you have a corrupted weather file (.WX) or station list. FSUIPC is stasrting okay, and it looks like the crash is when it asks Simconnect to supply weather data. This sort of corruption can occur especially if you use FSX real weather downloads from the Microsoft site. Try removing the .WX files from your Flight Simulator X Files folder (in your documents folder). I see also that you have only applied the one update (SP1) to FSX. I strongly recomment applying SP2 as well, as it fixes a lot of SimConnect problems. Regards Pete

I didn't go for any "recommended" ones, at least I don't think it was. I just searched for samples and decided on Daniel from Scansoft, which is very good indeed. The female one is Emily. I only just noticed that the Daniel voice was selected by Apple for its UK iPhone 4S "Siri" application (see http://www.telegraph...is-silence.html) I think Robert recommends that folks look at the AT&T voices, which aren't anywhere near as good as the Scansoft ones in my opinion. I've been using Radar Contact ever since it was an Adventure generator for FS95. I don't remember Windows 95 supporting speech synthesis? RC has certainly used recordings as long as i remember. Since it has to keep changing voices for different controllers, as well as those for the pilot (if you opt for auto-read back) I can't imagine it ever working with synthesised voices, it would have been far too expecnsive. I think VoxATC does, and comes with a few cheap ones, but it is a lot more expensive than RC and you do need to buy more voices if you aren't simply doing short VFR hops without venturing through many levels of ATC. Regards Pete

You assigned to the wrong FS controls then! The correct ones are the ones I said -- Axis throttleN set, not ThrottleN set. The former ARE the FSX controls, the latter are the ones FSUIPC uses for a reverse zone. You certainly do NOT have to uncheck the "ignored throttleN set" option if you do the correct thing as I suggested! By assigning to the wrong controls you are still fooling the PMDG code which is obviously looking for the normal FS Axis controls, not the others!! :sad: Also, I worked on this: And ... as far as I can see here, it is not actually even possible to get a value less than 0 displayed for "OUT" if the "No Reverse Zone" option is ticked. The action of that option is sepcifically to map the whole range to only the positive values. I am therefore left wondering how you arrived at this result. Also, I cannot reproduce the discrepancy between throttle1 and throttle2 that you show here at all, even by unchecking the NRZ option. So, unless you think you may have been mistaken, I need to determine what circumstances can lead to what you saw so I can fix it. if you can definitely reproduce that error, could you do so, but first enable some extra logging, like this: In the [General] section of FSUIPC4.INI add: LogAxes=Yes Debug=Please LogExtras=x8 This won't log the values seen in the Calibration settings, so please write those down. Thanks! Oh, it might be a good idea to use the same FSUIPC version as me -- 4.804, from the Download Links subforum. Thanks Pete