Pete Dowson

There's no difference in how FSUIPC's button programming and axis assignment systems work between FS9 and FSX or FSUIPC3 and FSUIPC4, so it might still be relevant. Regards Pete

Sorry, I cannot support any operating system older than XP. Win2K is well past its sell-by date. It just does not support the facilities now used. Regards Pete

So it is the LanMan part of Windows which is in error. So am I, on three separate systems, one of which has 8 Client PCs. None of them have ever shown this error. I'm afraid I've no idea what it means, but it will be some setting somewhere in the system, or possibly on your router. I suggest you Google it and see if there's any help that way. Or simply avoid the problem by turning off broadcasting as I suggested. You will need to put the ServerName and Protocol parameters into the WideClient.INI if you do this, but otherwise it has no adverse affect. No, I already have enough to know I have no idea what it means. Thanks anyway. Regards Pete

"Initial.lua" is only different from any other Lua file in the WideClient folder in that it is executed as soon as WideClient loads -- it does not wait for a connection to FS. WideClient will always automatically run any other Lua file it finds in the same folder as itself, but only when it is connected successfully to FS. I'm not sure why you'd want Initial.lua to run three others unless you want them all running even with no FS connection -- such Lua programs obviously cannot read or write FSUIPC offsets or send any FS controls or detect anything about FS. See them where? WideClient does not provide any assignment facilities except for keypresses and so on via the FSUIPC KeySend control. Client plug-ins need to be autonomous, and if they need to act on events in FS, detect them appropriately. If you want to link them to buttons or keys pressed on the Server you'd need to make them set values in an FSUIPC offset, and use event.offset in the client plug-ins to detect this and perform the actions you need in the called functions. There are offsets available to users for such purposes -- x66C0 to x66FF. You'd use offset byte set controls to change, say, the value in byte x66c0, and detect the change in the plug-in. Regards Pete

Well, it looks completely wrong, I'm afraid. Let's see: function AltitudeIncrease(keycode, shifts) end This does nothing at all, because there is no code between the function statement and the 'end'. So when it is called by the event, it does ... nothing at all. The whole point of a function is to do something, else you waste time and space. ipc.macro("LevelD767: ALTInc") This will execute once when the Lua is loaded. How are you running the Lua plug-in? If you think it is working, then I assume you assigned a keypress to it? You might as well assign the keypress directly to the macro! event.key(186, 8, "AltitudeIncrease") -- I use the ; key for this, since "A" is already assigned Because the function this calls does nothing (having no code in it), this line does nothing except waste time and space. The whole point of using event.key is for the plug-in to detect the keys presses and execute the action. There would be no assignment in FSUIPC whatsoever. You'd have the plug-in loaded either by the [Auto] mechanism in the INI file, or by naming it ipcReady.lua (which s run automatically on FS initialisation, when ready to fly). Or you could have ipcReady.lua run it. It's just a logical sequence: you'd reset a flag or variable first (eg KeySeen = 0), and have event.key lines for A and B. In the one function called by either, check 'KeySeen', if 0 just copy the keycode to KeySeen ("KeySeen = KeyCode") , otherwise check if KeySeen == the keycode for A and the new keycode is for B, if so do the A-B action, otherwise similarly check B-A, if so do the B-A action. for either reset KeySeen=0, but if neither just do KeySeen=KeyCode again. However, I think you may need a bit more time looking at Lua examples first. See some of those supplied in the package installed for you in the FSUIPC Documents folder, and those contributed by users in the User Contributions sub-forum here. Regards Pete

You posted your support question in the FAQ subforum, where it was lucky I saw it. I've moved it to the Support Forum for you. I cannot support other folks' add-ons, sorry. Have you tried asking them? There's no "payware version", only a registered or unregistered install. I assume you mean you paid for it and registered it? No, it cannot be the reason. first of all I doubt that all if any of the gauges in your aircraft use FSUIPC in the first place. Maybe they have a TCAS which does, but little else. And if the connection to FSUIPC wasn't working it couldn't possibly stop GAU files loading. It sounds as if you simply have not installed all the Gauges you need in the FS Gauges folder. Maybe you only copied the aircraft folders and forgot about the gauges? Pete

The quickest and most reliable way is certainly to delete each [....] section in the INI which mentions the aircraft specifically. Otherwise you'd need to delete each and every assignment individually. You need to calibrate them properly, following the steps ennumerated in the FSUIPC user guide. If you are assigning in FS, make sure the null zone is minimum (full left) and the sensitivity maximum (full right). Regards Pete

Why do you want to read it? What device are you sending the read value to? To read an offset you'd need to write a program or a Lua plug-in. Please explain what it is you want to do with the read value. You can have as many assignments to each button as you like, but it means editing the INI file to add them. However, it makes no sense whatsoever to assign a control for writing a value to an offset which is read only! I think you do not appreciate the difference between reading and writing? Regards Pete

Which section of the Event viewer is this error placed in? All the ones I ever look at always identify the program and often the module concerned. Surely there's a program identified there, somewhere? Why edit the computer name out? It's not a usable thing outside your network. Nevertheless, WideServer is still broadcasting an "I am here" message once a second, by default so that Clients can automatically know where the Server is and which Protocol to use, and so connect. You can turn that off if you wish (see the WideFS dox), but it should never give any errors. Something is wrong with your system, but I've no idea what it is with that weird message. What operating system are you using on the Server? Have you disabled any of the default Windows services? Maybe one which is needed for broadcasting support is disabled? Regards Pete

The Lua documentation installed with the FSUIPC documentation in your FS modules folder, of course. The ext library is a very recent addition, however, so you may want to refer to the Download Links subforum here too to make sure you have up to date installations and references. Pete

What event viewer? Are you running some event viewer at the same time as FS? Why do all that? FSUIPC won't run if it isn't in the Modules folder. you don't need to do anything else! Why would I want a screenshot? Surely grabbing the text for one of the entries and pasting it here would do? What's that "browser driver? What is your remote PC "SPEEDPORT.IP" doing? Does it actually say "..." (My computer name) or have you edited that part -- if so, why? Can you possibly describe what it is you are doing, what sort of multi-computer setup you are using? Doesn't this event viewer you are using identify the program or module at all? FSUIPC doesn't use any Network facilities whatsoever unless you enable WideServer. Are you doing that? Regards Pete

What is this "error coming from FSUIPC"? You forgot to mention it. I'd also need to know what version of FS (FS2000, 2002, 2004, FSX, ESP or Prepar3D?), what version of FSUIPC (if not the latest, try that first), and a sight of the FSUIPC log would be useful too. Regards Pete

All that sounds like poor calibration, or insufficient resolution of the axis values for differences to be noticed. If you are assigning in FS make sure the null zone is minimum and the sensitivity is maximum. I assume you are talking about assigning in FSUIPC. FS controls assigned in FSUIPC are sent to FS and act just like controls assigned in FS itself. If you calibrate them in FSUIPC this is done by FSUIPC then intercepting them, not knowing whether they were assigned in FS or FSUIPC. Assigning "direct to FSUIPC calibration" assumes you are calibrating and by passes the bit where they are first routed through FS. In general this is more efficient and gives better results, but some add-on aircraft then don't work correctly because they like to see the controls as coming from FS. Regards Pete

Assign the read value to what? It's read only. You can't write to it. You need something to read it. Assigning a button or encoder to a read only value makes no sense. Regards Pete

For the profile to be loaded with the aircraft the aircraft name must be associated with that profile. That is done by assigning the profile to the aircraft using the drop down. I've no idea what you mean by clicking on a button and ensuring a tick is is a box -- if you are using profiles you get an assignment list and you select the profile you want. The name of the aircraft is then recorded in the INI file against that profile, and from then on everything is automatic. Maybe you have a number of different aircraft names and not all are yet assigned? Please check the documentation about assigning profiles. There are pictures too. Regards Pete

What version did you install? Did you run the installer "as administrator" as instructed? Note that the latest installer installs version 3.998n. If that isn't the one you installed, try again with that. Regards Pete

The documentation is revised for each major version, and you are two major versions behind, so you should download the Installer, run that, then optionally install the later DLL over the one just installed. This is stated in the Download Links subforum thread containing the updates. You never need to re-register except after moving to a new PC or re-installing Windows, unless you delete the files in the modules folder by mistake. Regards Pete

One of those is to do with some problem with FSX, not FS9. They are totally different. The FS9 one refers to "microstutters" and "stuttering every 5-10 seconds", but it doesn't mention whether there's one micro-jerk or losts of little ones within a second every 5-10 seconds. So the cause is inderterminable from the information available. Since he wasn't using FSUIPC, apparently, in any case, he never came back with any answers. Hmmm. sorry, then. I can only think that the slightly different memory configuration FS9 will take with FSUIPC installed causes use of some memory which is behaving badly. Can you nail down these stutters to a specific number and interval, or are they random? If random, what sort of average frequency? How long does each stutter last? There are some very quick but regular activities even an unregistered FSUIPC will do in order to have data available to applications requesting it. One of these is reading AI traffic data for the TCAS tables. You can stop this by adding or changing this parameter in the [general] section of the INI file: TrafficScanPerFrame=0 see if that helps, though I must say the default has never been known to cause stutters that I know of. You can also stop it getting weather information from FS by setting WeatherReadInterval=32 The only other regular activities are only enabled in a Registered installation. Pete

Most methods of sending keypresses require the program receiving them to have the keyboard and mouse focus. There are some ways of directing keystrokes to particular programs, though probably not to different windows in the same program. Please check the WideFS documentation. I can help with specific questions if there's something there you don't understand but there's really no point in me reproducing it all here. Additionally there are more flexible facilities for handling windows and sending keystrokes in the 'ext' library added to Lua for FSUIPC and WideClient recently. Regards Pete

The PFC driver does things the most efficient way, bypassing the decoding in FS. The problem is that the add-on aircraft code is probably watching those values in any case, even though it is disconnecting the axis inputs from normal controls. Assigning in FSUIPC to the FS Axis controls is the same as assigning your CH controls in FS. They follow the same tortuous route through FSX's innards. Regards Pete

That would have to be a function of the PMDG code. Only it is determining whether the AT should be on or not. Nothing outside can stop it disengaging. You realise that with a registered version of FSUIPC you can assign the PFC throttles there, instead, disabling them in PFCFSX by assigning to an appropriate User configuration? In FSUIPC assign the throttles to the normal FS controls, AXIS_THROTTLEn_SET, or whatever method you used with the CH controls. Regards Pete

Sorry, I am not aware of any stuttering with FSUIPC. Can you give some references? In that case something you have installed is causing the stutters and it uses FSUIPC and doesn't run, or doesn't run correctly, when FSUIPC isn't available. I don't know what you have wrong, but there are thousands of FSUIPC3 users, with and without registrations, who do not have any such problems. In fact, if FSUIPC is truly not registered it isn't doing anything EXCEPT servicing applications which use it. i think that's where you need to look. For instance the PMDG aircraft you mention are FSUIPC users -- and in fact have a DLL running even when those aircraft are not being used. Look in your FS Modules folder, see what other non-FS DLLs you have running. Regards Pete

FSUIPC doesn't use an offset for that, it is done by transmitting Windows registered messages. I think SB3, which uses FSUIPC, does have offsets for these things, but of course SB4, RW and AVC do not use FSUIPC in any case so offsets are irrelevant to them. The FSUIPC offsets lists include everything FSUIPC supports. Other programs which use FSUIPC use their assigned offsets in any way they like -- if they allow them to be used by others they will have published their own lists or would support them by answering questions. If all you want to do is use offsets to send FSUIPC controls then use offset 3110, as documented, along with the FSUIPC control number (listed in the Advanced User's manual), and the parameter where needed. Regards Pete

This is ALWAYS a problem using TOGGLE controls -- all "toggle" means is "turn it off if it is on or on if it is off". There's no way it can take into account your switch position in FS. You MUST get the screen cockpit in sync with the hardware first, and maybe re-sync if you load a new flight. There is no way around this whatsoever unless you can find distinct ON/OFF controls for what you want to do, or resort instead to using FSUIPC Offsets to switch things on and off. For this you need the Offsets list, from the FSUIPC SDK, and then use the "Offset" controls in the assignments dropdown instead. For example, for Battery Master you'd find the offset is 3102, and it is 1 byte with 1=on, 0=0ff, so you'd assign On to offset byte set with offset x3102 and parameter 1, and Off to offset byte set with offset x3102 and parameter 0. Regards, Pete

If the aircraft being loaded has a name which matches one assigned to that profile, then the profile is loaded automatically. You NEVER manually load profiles, they only ever load according to the aircraft active in FS. That's the whole point of the facility! There is no way to do it manually. So why are you doing this? As I said, there's no way to get the wrong profile, FSUIPC will only use the one assigned to the current aircraft. Regards Pete