Pete Dowson

The assigned traffic zapper controls take no parameters so any provided will be ignored. The default values for the INI file parameters "ZapAirRange" and "ZapGroundRange" have always worked for me in the situations you describe. They are described in the Advanced User's Guide. Just search on "Zap". There's also "ZapCylinderAltDiff", if you want to play with that. The "ZapAll" deletes all aircraft meeting the set values, whilst the normall Zapper just deletes the nearest. There's no point unless you want to do something which is not already catered for. As the descriptive documentation states, it' was added to allow folks to extend FSUIPC's capbilities -- i.e. to save me adding new facilities all the time. You could even use it to make your own Zapper, though that's a pretty complex thing to contemplate as a Lua starter! ;-) Maybe look at it when you actually want to use it for something, rather than out of idle interest -- unless you are curious (as, actually, I would be! ;-) ). Regards Pete

No, but I just spotted an error, which I've now corrected -- the last line should be event.timer(500, "checkalt") Please, when running any plug-ins, if they don't work check the FSUIPC log file -- also in the Modules folder. There would have been an error logged there because of my mistake. Pete

Didn't you take a look at the Lua documents in your FSUIPC documents folder? Try this. It checks the radio altitude every half second (should be ample?) and if below, stops the axis, if above enables it. function checkalt() radioalt = ipc.readUW(0x31E6) -- gets radio altitude in metres if radioalt < 30 then ipc.setbitsUB(0x32F8, 2) --set inhibit else ipc.clearbitsUB(0x32F8, 2) -- release inhibit end end event.timer(500, "checkalt")[/CODE] Save it as[b] ipcReady.lua [/b]in your Modules folder (or, if you are already using [b]ipcReady.lua[/b] for something else, like LINDA or whatever), save it as, say [b]"autospoil.lua[/b]" then add a line to the existingipcReady.lua like this: [CODE] ipc.runlua("autospoil")[/CODE] I've not tested it here, mind. But it looks right. Regards Pete

You realise no one can support an operating system which isn't officially released yet? You are effectively Beta testing for Microsoft. Sounds like Microsoft still have a ways to go before it's releasable then. There's nothing other than standard Windows methods used in the installer. It doesn't bode well for much else if you ask me! Anyway, I can't look at this without more information. I need the error details to start with. I've no idea in Win8. In Win7 you do this: Press "Start" and in the "Search programs and files" edit box, enter "event viewer" and press Enter. In the explorer-type window which appears, open the "Windows Logs" entry, and select "Application". In the list which appears, scroll down to find the relevant entry. Errors have a red "!" icon in the "Level" column, and you will be looking for the FSUIPC4 installer in the "Source" column. Double click it to get a Window showing the details, with a "Copy" button. Use the Copy button and then paste the result into a message here. Whether it will help or not I don't know, but i'll look at it. Regards Pete

If the axes are working (i.e. sending different vaues) throughout their range of movement, then all you need to do is calibrate, following the numbered steps for calibration in the FSUIPC user guide. There is no need to consider "ratio speed" (I think you mean "sensitivity"?), unkess you want more sensitivity in the central area and less at the extremes, or vice versa. Both the latter changes can be done AFTER calibration, by using the "slopes" facility in FSUIPC calibration. But first you must calibrate correctly to match the range on your axes. Sorry, I don't know what you mean by this. If you mean you are changing the slope, then DO NOT DO THIS until you have calibrated correctly. With proper calibration the surfaces will not reach maximum deflection until your axis reaches the maximum position you calibrated for that. So either you have not done this, or your hardware is faulty and the INput values are not actually changing beyond a specific point. Oh, one thing to double check also. If you are assigning in FS you should make sure the sensitivity slider in FS is at maximum (full right) and the null zone at minimum (full left). This is also stated in the User Guide. If these are wrong they will certainly limit your axis ranges. If you assign in FSUIPC these sliders aren't relevant. Regards Pete

I don't think Microsoft's "homegroup" system works properly. I don't think Win2000 is supported properly any more by anything. you need XP or, better, Win7. Win2000 predates even XP. There is no place in FSUIPC for a Server name. It doesn't care where the server is becausde it is the server. Try providing Wideclient with ServerName and Protocol. No. Evidently not, reading what you say. Pete

You mean the value in offset 3412? Pete

Okay. thanks. Pete

When you say you "set the Parameter to 2^1" you don't mean, I hope, that you entrered those three characters? The value of 2 to the power 1 is 2. The parameter you need is 2, and you should use the set bits or toggle bits control so the other bits aren't changed. How do you turn it off? Another button? If the same button then use toggle, not set. A small Lua plug in would do that quite easily. That older version has not been supported fdor a while now. You need at least the current main version, 4.827, and the latest incremental release is 4.839b (see the Download Links subforum). Regards Pete

No, I don't think it does, unless it's been updated. The one I use on Win7 64 is VSPE, which isn't freeware but isn't too expensive. Regards Pete

That one works as far as I know. At least it always did. Can you shown me what you've done, and tell me what version of FSUIPC you are using, and also how the spoiler axis is assigned? Pete

Only when armed? What about when it deploys automatically. Isn't that more the problem? The auto-operation by the motors surely isn't relevant till then? You can disconnect the spoiler axis, if assigned in FSUIPc, by using an offset. Search for spoiler in the offsets list. How you determine when to disconnect it is another matter. You could either do so manually, by a button press, or by an event, such as lowering the gear. This is assuming you'd never want to use the speed braking effect after lowering the gear. If this is not viable, then probably you'd use something like radar altitude being less than 100 feet or so, so the disconnection occurs by the time you touch down and the automatic deployment operates. Pete

"Right setings" for what aircraft, what controls, what intentions? FSUIPC is a like a box of tools. There's no "right" way to use the box, you chose the tool and method to get what you want to do done. This is perhaps why you do not understand the documentation, as it is as general as it needs to be for all of the different applications folks have for its capabilities. Sorry, but that is how it is. There are some specific guides knocking about for specific things, generaly written for particular controls and particular aircraft. I don't really find myself competent to produce those because i do not use any sophisticated add-on aircraft and all my "controls" are PFC cockpit ones driven by my own drivers, not by FSUIPC. I can answer specific questions about FSUIPC of course, so don't feel that's the end of it. Regards Pete

Virtually nothing that I'd investigated in any depth transferred over I'm afraid. Your area might possibly be more amenable then the others, but since I didn't have cause to find out such things in FS9 I never looked in FSX. Most of my hacking into FS9 and before was for weather stuff, and the weather module was completely revised between FS9 and FSX, so much as to become unrecognisable. Pete

Sorry, no, not I. Since SimConnect I've managed to avoid most hacking inside FS's convoluted code. Prior to fSX it was based on comparisons with earlier versions (which were C and ASM based, with much simpler code). As they moved to the horible "object-oriented" approach with convoluted C++ and impenetrable black boxes, I've avoided looking at it as far as possible. Sorry. Maybe using Prepar3D would lead to more satisfaction in this sort of thing as I think it either does or is proposed to be opened up more for individual core aircraft simulations. And being an ongoing development with a reasonably responsive support team, you might get along with it better. Regards Pete

It might not be today. I'm a bit ted up and have visitors. Pete

Yes but it will have to be an INI file option setting because I would be wary of upsetting all the other programs and devices it works with as it is. Pete

Nevertheless, the client is not seeing any broadcasts, so you need to double check. Did you yet try to add the ServerName and Protocol parameters as I suggested and as suggested in the documentation? Pete

Yes, but I don't think there's any FS control to operate that button from a real button. So my answer stands, I think. Pete

Have you changed the workgroup name in one or other of those PCs to make sure they are in the same workgroup, as pointed out early in the network configuring section in the User Guide? That's the part with a RED plea to at least read some of it! Vista and XP default to different workgroup names. The logs simply show that WideClient isn't receiving the broadcasts, and it certainly won't if the workgroup's are different. An alternative, if you must have different workgroups, is to edit the INI to tell WideClient the name of the server and the protocol. This is also explained in the User Guide. Did you try ANY of the suggestions there at all? Pete

I think a lot of folks found this problem. I don't know if any solved it. You might try different assignment methods -- you don't say how you assigned but try assigning to the axis throttleN set controls, see if that helps. I think the main problem is that the 737NGX is coded to read the throttle controls from SimConnect at a high level, not the post-calibration level you get from FSUIPC. However, if that were truly the case the main forward range would give a problem too if the calibration actually changed the value. So, i'm sorry, but i don't know. I suspect most folks using the 737NGX don't use a reverse range on their throttle axes, but use some variant of a button press (throttle decr) to engage reverse. No. The NGX addition since 4.82 is support for read-outs of NGX interbal values into FSUIPC offsets so that they can be used in cockpits etc. The latest interim release of FSUIPC4 is actually 4.839, but that won't help with this either. I do believe that some folks manage reverse ranges on axes, but i don't know what is needed I'm afraid. If you ask PMDG they shrug and say "don't use FSUIPC". You could try searching this forum, or maybe some kind soul will contribute to this thread and claify the matter. Regards Pete

What makes you think I'm mad? You keep asking if the RMC format is the one i use and i say yes. I don't understand what i can do for you if i don't know what you want different. The picture of the error you get doesn't help I'm afraid. I don't know what the Apple device is seeing or what it doesn't like. How can I? Even with a cable how could I work it out? I do not program Apple devices. I have no way of finding out. I've just linked FSUIPC4 via WideFS with GPSout enabled to WideFS, and logged what is received with RMC sentences enabled. Here's a typical line: $GPRMC,210740.00,A,5323.4026,N,00211.9986,W,40.0,50.9,040712,2.8,W*51 The course and speed check. What more can I do? Tell me. Regards Pete

I thought i'd answered this twice already? Yes,, except that your latitude and longitudes are wrong. they are either xxxx.xxxx and yyyyy.yyyy or, by more recent more accurate standards xxxx.xxxxxx and yyyyy.yyyyyy FSUIPC4 and GPSout both support both of these, by option. Everything else you have is exactly how it has been for many years. I still don't understand why you came here with all of this in the first place. Can you explain why? Maybe Apple have made some error? Can oyu identify what is wrong? BTW i've never seen any device which only gives 2 decimal places for the Lat/Lon values, so I doubt that this could be the problem. Regards Pete

Weird advice, but his was a different point of view to mine and folks seem sometimes to understand him more than me. Certainly if you've not actually disabled all controllers in FS, but only de-assigned their inputs, making FS think you've just connected a new device will make it do its default assignments to all the axes and buttons it finds. If that's what you mean by "reset", fine, but you'd still also need to delete anything for the device(s) you've done in FSUIPC -- eg by deleting the INI file.: Not without deleting the INI file or eidting all the settings. Ouch! I've never seen that here, at least not with Win7. But then I don't replug things differently often, if at all. FSUIPC uses the GUID to distinguish between devices with the same name. So if they all have different names it may not matter. Regards Pete

Sorry, you've lost me. What fix? What 3 and 4 difference? Not here, it isn't missing. How are you working this out? The RMC message always had these things in it as far as I'm aware, at least for the 12 years I've been doing this. Can you please explain where all this evident confusion arises? Pete