Pete Dowson

One thing immediately apparent is that the FS9 actions seem to show a different [buttons] assignment list to that which you showed for FSX: 61277 [buttons] 5=CP(-0,6)0,7,C1004,10 61277 [buttons] 6=CP(-0,6)0,7,C1003,12 61277 [buttons] 8=CP(F+0,11)0,7,C1004,11 61277 [buttons] 9=CP(+0,6)0,7,C1003,13 61558 [buttons] 1=CU(-0,6)0,7,C1003,10 61558 [buttons] 7=CU(F+0,12)0,7,C1004,12 61558 [buttons] 10=CU(F+0,13)0,7,C1004,13 However, that said, it is rather odd that no button action is recorded in the FSX log. I'll do some testing here. Regards Pete

Oh, that one. Yes, I had that -- a long long ago. Still have the manual around someplace. There was a program to link it to FS so you could get proper scenery visuals and so on. the Sim screen was almost all cockpit -- not in realistic arrangement, just so you could access all the relevant switches and view the gauges. Regards Pete

Unlikely. I'm really trying to do less these days. I'm 69 this year and want to spend more time actually using the cockpit it's taken me so long to get the way I want it! BTW, who are Aerowinx and what is PSX? Regards Pete

Well, then, I assume the mode buttons are only visible if you make some tweak to the Saitek drivers. Sorry, I cannot support Saitek -- I'm just pointing out that the facilities in FSUIPC are no different in this. The Lua approach would require some amount of programming know-how. I don't think that will be necessary judging by the other replies here. Maybe you should follwo Andy's pointer? Regards Pete

Sorry, but I've little to no control over that site, which is owned and updated by Enrico Schiratti. I do manage to get him to update it now and then -- usually on major releases -- but I update everything much more frequently here, in the SubForums where I have control. Regards Pete

If the mode selector switch is visible as one or more button numbers in FSUIPC4 then it will have the same button numbers in FSUIPC3. There's no difference -- 32 buttons numbered 0-31 are supported in both. Only the axes are more restricted in FSUIPC3 -- 6 instead of 8. If the mode selector switch is not visible in FSUIPC3 or FSUIPC4 then the only way it could be programmed in FSUIPC is by use a a Lua plug-in using the HID (human interface devce) additions to the com library. However, looking back in this thread I see that Tamas_MAH180 already stated "It can see the three mode states as Joy#1 button #8, 9 and 10", so there's no problem. Why not just try for yourself? Regards Pete

As stated in the list of changes for version 4.51, in the Download Links subforum, it already works with ESP and P3D as well as FS9 and FSX. That was released in November. Regards Pete

The PFC driver uses the FS "ThrottleN_Set" controls. But you said those didn't work with the aircraft you are using with autothrottle engaged. So I suggested assignment in FSUIPC to Axis_ThrottleN_Set controls instead, sent via FS. Those are then indistiguishable from normal hardware throttles assigned in FS. It seems that the aircraft you are using is not intended to be used from hardware throttles at all if neither method proves satisfactory! Either that or you simply are not calibrating properly, to ensure a proper stable zero thrust idle position. That seems much more likely to me, I must admit! Try calibrating with a larger idle zone. Maybe your throttles are jittery. Regards Pete

You seem to have posted the same question identically in two separate identically titled threads. I've deleted one to avoid confusion. Er ... two answers. First you yourself state that "i went to axis assigment and i selected the rudder set". If you assign an axis to the rudder then of course you must expect it to move the rudder! The second answer, in case you meant that you assigned to the tiller axis FSUIPC provides, is that the steering DOES use the rudder axis even then. The tiller is just a separately calibratable axis for the rudder. Before FSX the only way to steer was by rudder. FSX does actually provide a separate steering axis but I don't know whether it works, nor whether it moves the rudder too, having never used it myslef. Regards Pete

Really? There's no reason for that. All requests made to FSUIPC by applications are honoured just as quickly when paused. That's not an exanple for "FSUIPC applications! And it isn't anything to do with FSUIPC -- the same would happen in FS assignments. Your USB ports are switching off. you need to turn USB power management off -- by default Windows stops power to USB devices when they aren't used for some time. Regards Pete

What on Earth has the autobrake got to do with it? You've got something really mixed up there. Pete

Hmm. Please show me the FSUIPC log you got, the one showing both key presses and the offset monitoting, and the [Keys] section of the FSUIPC INI file. Something is preventing the ipc.write from achieving what it should do. There's something simple that we are missing asnd I don't have all the evidence to hand at present. Pete

One thing to try, just as an experiment. If you are running FS in full screen mode, try windowed, just to see if the error still occurs. Or vice versa of course. ALT+ENTER switches modes. Regards Pete

I can understand your feeling on this, but nevertheless I don't know any other way crashes occur in NTDLL. the fact that the addresses of the crashes vary so much do indicate that it is very timing dependent. if there were a true bug in one particular part of FS or FSUIPC or Air Hauler it would be at a more consistent address, and almost certainly not in NTDLL. Seems best, then, if you are not willing to try to fix it via driver updates to stop using Air Hauler. I'm sorry, but there is really nothing else I can do for you. Regards Pete

You posted a support question in the "Download Links" subforum, which is reserved for ... download links, of course. Lucky I saw it. I'm moved it to the Support Forum, which place please use in future! There's already an offset for handling the doors, and in the latter case you can send any FS controls you wish via offset 3110. Please check that. Regards Pete

Why are you double-clicking the FSUIPC module? It isn't an executable program, but a module which is run by FSX when FSX is started. You just place it in the FSX modules folder, as instructed. If you want an installer, download the Installer not the individual module. Please do read what it says when you go get updates. It clearly says "The FS modules here need copying into the FS modules folder once extracted"! As instructed in that subforum, download and run the Installer first. then optionally copy in the later update. Regards Pete

Not relevant. Also ".1.log" files shouldn't appear unless you've been messing pressing 2new log2 buttons in the FSUIPC options screen. I don't expect an error to be shown, only the last few thngs your "air hauler" was doing before FS crashed. All this: 5740969 WRITEex 6D60, 32 bytes: 41 69 72 48 61 75 6C 65 72 20 4D 65 73 73 61 67 5740969 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5740969 WRITEex 3380, 127 bytes: 34 30 30 20 55 53 47 20 2F 20 32 2C 36 37 38 20 5740969 6C 62 73 20 46 75 65 6C 2C 20 32 2C 33 34 33 20 5740969 6C 62 73 20 6F 66 20 43 61 72 67 6F 20 4F 6E 20 5740969 42 6F 61 72 64 2E 0D 0A 0D 0A 50 6C 65 61 73 65 5740969 20 4F 6B 20 74 68 65 20 50 61 79 6C 6F 61 64 20 5740969 44 69 61 6C 6F 67 21 0D 0A 20 00 00 00 00 00 00 5740969 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5740969 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5740969 WRITEex 32FA, 2 bytes: 0A 00 is Air Hauler displaying a message on screen, beginning "400 USG - 2,678 lbs ..." You can decode it from the above data if you like. Then this: 5740969 WRITEex 0262, 2 bytes: 01 00 5741031 WRITEex 6404, 1 bytes: 01 merely pauses FS and does something in Air Hauler's own area. The reads aren't relevant (I only asked you to log the writes anyway). NTDLL.DLL is a core part of Windows and should certainly never be tampered with. This all points to a driver problem, probably the video driver. It most certainly isn't an FSUIPC or Air Hauler problem. Since it occurs when Air Hauler is asking for a window to be displayed, the video driver seems the most likely. You need to find and install a better driver for your video card. Regards Pete

So, you are not talking about making mouse macros, but using already-made ones? Maybe the ones you made were for a different version of the aircraft? Maybe it has been updated or there is an update for forgot to apply? Because mouse macros actually record the position in the Gauge code, in memory, which is to be called to execute the function, even small changes to that code invalidates them and means you need to re-build them to suit the revised code. To take an example from your own posting above, I assume by "EFIS TRFC" you mean the same as the one called "TCAS" in the PMDG MD11X contribution already posted in the User Contributions subforum. In that it shows as: [Macros] Module="PMDG_MD11.DLL" 1=EFIS TRFC=RX5860*X8b00 whilst you have 41=ND-TCAS=RX58b0*X8b00 See the difference? I thnk all the others have changed too -- so there are obviously at least two versions of "PMDG_MD11.DLL" around. Regards Pete

FSUIPC does this automatically for rudder and tiller axes assigned directly to FSUIPC's calibration, except that it doesn't suddenly switch at 40, but gradually transfers control up to 60 knots (default -- can be changed), so the crossover isnearer 30 knots. You can send axis values direct to calibration in one of two ways: Either use offsets in the 3ba8-3bcf range to send the axis value, then assign the axis "direct" when recognised in FSUIPC's axis assignments, or use the general FS controls facility at offset 3110 to send the special FSUIPC "direct" axis control (one of 64101-64140 -- see latest changes document for the list), along with the parameter for the axis value. The latter method requites you to write 2 32-bit words, eitrher at the same time or parameter first, control number second. I don't know if SIOC can do that. Regards Pete

That should work fine. Are you sure you've not got the keypress in the FS PC repeating, so writing '1' many times? Try using the Logging facilities in FSUIPC to see what is happening. Check the Button/Key logging option, and also, on the right-hand side, monitor 66C0 as U8 to the'normal log'. Regards Pete

What are you using for the offset? You don't need quotes "", just 0x66c0 will do -- it's a number in hexadecimal. You can put that in quotes if you wish but there's no point. Regards Pete

That clearly says thst all Lua programs found in the WideClient folder are run -- all when connection is made, with Initial.lua being the only exception, being run as soon as Wideclient is loaded. It doesn't cause a problem because the events on the offsets won't trigger until FS is connected. However, it isn't doing anything at all until FS is connected, either, so there is no point in naming it "initial.lua". By calling it something else you would have the advantage that you could amend it, alter it, develop it, and so on, whilst WideClient and the FS connection is running, because WideClient watches for changes or new Luas and re-loads them when it sees them. Do you have multiple plug-ins running on the Client, which communicate using these Global variables? If not it would be more efficient to use local definitions, i.e. Cinture=0 Turbo=0 Aiuto=0 and not use ipc.set and ipc.get. Regards Pete

Please go to Saitek support. I will not support them. They use FSUIPC illegally, having refused to pay the license fee originally agreed. Regards Pete

Does the MD-11 support mouse macros? I have no idea. Not all aircraft gauges do. It depends how they are written. I'm afraid that without a version number quoted this statement is meaningless. Folks have said that when what they meant was "the newest one they've seen". Check the main Options tab for the number, or the Log file, or right click on the DLL itself and select Properties-Version. The very latest is 3.998q for FS9 and 4.754 for FSX. Note also that although mouse macros work with FSX RTM they cannot be created using the automatic method wthout at least SP1 installed. Regards Pete

Can you tell me how you arrived at this conclusion? Because evidently I've made a coimplete hash of the documentation somewhere if that's what you think and I'd need to revise it! The only thing unique about "initial.lua" is that it is loaded as soon as WideClient starts, whewreas all other lua files, no matter how they are named, are loaded only after FS is ready to fly and connected. Thereafter such files are loaded whenever they appear or are changed, throughout the session. No, certainly not without any parameters. Obviously you'd need the offset, for example x66c0 (or one of your choice among those available, as I said), AND the value you want it set to -- how can FSUIPC guess what you want to set? No! you do not read what I write! The initial lua plug-in is executed before FS is connected, therefore it cannot read offsets!! Name your Lua anything BUT "initial"! Also, it isn't an "event.offset" for "each of the buttons/keys", but only for the offset you chose. In the function you test the value of the offset, provided in the function parameter 'val', for the value you set in the FSUIPC parameter to "offset byte set"! Yes, as documented. Think about it: where else can macros be run? Certainly not in the Client. No, certainly not. That's what you need to use the offsets. Everything in WideFS works via FSUIPC offsets (including in fact the ipc.macro option which simply writes to the macro execution offsets in FSUIPC). Pete