Pete Dowson

What's that supposed to mean? I try to help you and you reject the help. Why? Pete

The latest list of offsets (which hardly ever changes in any case) is always installed in your FSUIPC Documents folder when you update FSUIPC. I don't understand the reference to "drives"? The Logging tab in FSUIPC options is not "complicated"! You can select tabs in a dialogue and click on buttons, can't you? Otherwise you wouldn't be able to use any Windows programs really. The log produced may contain some things you won't understand so easily, but the logging of FSX events, or controls, is straight-forward, giving both the number and name of the control invoked. The full list of built-in FSX controls is also provided in your FSUIPC Documents folder, by name and by number. Did you look at the User Contributions subforum threads about the JS41 and what others have done? Pete

The client log you supplied is incomplete. Please always close the program down before getting the log as valuable information is presented at the end. As far as it goes (only one second of operation) there were no errors at all. I don't think it can relate at all to the session you describe. The Server log you supplied shows no connection was made at all, so it evidently isn't the one relating to the Client log, even though judging by the time stamps in each they overlap -- the one second run of WideClient being within the 32 minutes of the Server log time -- but perhaps your PCs have different times set? Either that, or Wideclient was actually connecting (or trying to connect) to something different. Pete

There are no separate "free" and "registered" versions, there is only ONE version of FSUIPC4 (for FSX and P3D) and one of FSUIPC3 (for FS9). The only thing which makes a difference is you registering it! I don't know how you think you are managing to download "different versions". All the links, wherever, point to the same files, hosted here in the Download Links subforum -- and that includes the links on the http://www.schiratti.com/dowson page and on the SimMarket purchase pages. The ZIP format is the standard one supported by Windows and all other zipping and unzipping programs. Many thousands of users have successfully downloaded, unzipped and installed them. Have you never managed to unzip any downloaded files at all? WideFS is never necessary for any other programs, it is just a way of running FSUIPC-using applications on a Networked computer to reduce the load on the FS computer and make use of other PC's screens, keyboards etc. Many programs which need FSUIPC to run do include a version of FSUIPC in their packaging and may automatically install it too. It is up to them. There has never been any restriction on such actions if third parties wish to take advantage of that. The only thing to be wary of then is that such bundled copies may well be out of date -- only the current version is supported. The FSUIPC installer installs it where it needs to go, inside your FSX installation, and does this automatically when you run it. Pete

If it says it is 4.703, then it is 4.703. Check the Install log file which should be in the Modules folder. Paste the contents here if you don't understand it. The most likely thing I think could happen is that your registry says that FSX is installed in a different folder to the one you are loading it from,. Maybe you made a copy at some stage and are using that. FSUIPC's installer expects the Registry entries to point to your installed copies correctly. Pete

BTW, you do realise, don't you, that if any of the actions you wish to control are actually using the normal FS control system, you can find out what it is (so you can assign to it) by using FSUIPC logging. Just enable the Event logging. When you operate the control with the mouse, check the log to see what it reported, if anything. If you (temporarily) run FS in Windowed mode, you can also enable FSUIPC's console log and see the results on screen in real time. While I'm hereagain, let me try to clarify something. Please disillusion yourself of the apparent thought that there are FSUIPC "offsets" for everything any aircraft add-on can throw at your system. FSUIPC is an interface to FS and knows nothing at all about any add-on. If the system you are interested in is simulated internally by FS then there will probably be an offset relating to ts value (but not necessarily its control). Add-ons are pot luck, they do their own thing, and pretty much 0% of them have any interface to FSUIPC or use any of its offsets. Pete

Sorry, I do not have the JS41 and in any case I cannot possibly investigate every add-on aircraft which is published just to see if there are controls provided, keyboard short cuts, mouse macro possibilities or local panel variables (L:Vars) which can do all these things. If the JS41 documentation doesn't help and there are no existing solutions in the User Contributions subforum or in the JS41 support forum, I can only suggest you investigate all these avenues for controls yourself. But bear in mind that quite often the gauge writers for these aircraft do not expect or consider people wishing to use things other than the mouse. [LATER] I searched User Contributions myself and found two threads providing data from the JS41. Why don't you take a look? SDK for what, exactly? Pete

Okay, your choice, but if you know FS so well I don't understand why you do not know how to assign your controls in its assignments dialogues? Once they are assigned there, the calibration in FSUIPC is very easy, just a matter of moving the levers etc and clicking buttons, as instructed in the manual. Most users have found even just this worth the install, before even looking at the very extensive facilities for assigning buttons and switches and so on. But FSUIPC is a toolkit. It has a large number of assorted facilities which may be of use to different users. If you are very happy with FS as it stands and need nothing extra, then really it wasn't worth your purchase. You could have read the documentation before you purchased to see. Did you not think of that? Pete

Don't use ipc.display for fast actions. It's intended for more permanent and updated displays. The process in creating and updating a display is complex and will take time. If you want to measure times use logging -- monitor 0D0C as a U16 in FSUIPC (right-hand-side), "to normal log", then add an ipc.log line to your Lua in place of the display line. Pete

You make assignments in FSX or in FSUIPC. Assignments obviously have to be made before calibration. Calibration acts on the specific FS controls, NOT on the axis itself. Calibration knows nothing about joysticks and doesn't need to. Please refer to the FSX help for using FSX properly with joysticks. I think you are rushing into FSUIPC prematurely. You need to be a bit more familiar with FS itself first. Pete

Actually, the Server never sees any attempt by the Client to connect. There are really only two possible reasons I can think of. Either Port 8002 is already being used by somethnig else on the Server, or, proabably more likely, you have a firewall blocking the connection. Incidentally, your FSUIPC is well out of date and no longer supported. The earliest currently supported version is 4.937. Pete

In the Joystick Calibration section you'll find any control already assigned (no matter where) which is suitable for calibration. You simply follow the numbered steps in the Chapter about calibration. You have at least looked in the FSUIPC User Guide, surely? They way you are asking questions it sounds like you've not even bothered to look at the documentation? Pete

Ah, so you have the time between you operating the switch (an assigned button) and the time offset 0D0C changes, the time from that change till the event is seen in the Lua code, the time to send 'wr' (> = 8 bytes) over a USB line, and the time for that USB device to operate some circuit. So where do you think, in those areas, the biggest delay is arising? Is FS under a great load (what frame rate?). If would probably be at least two frames for the first two parts. The COM call operates by placing the data in an output buffer, and that buffer is then processed by a separate thread which is simply waiting for data to send. In all this there are communications going on between about 4 different threads. so performance of your system, the amount of parallel thread operations (processor type dependent), will all affect the timings. Nevertheless, I cannot imagine it could ever be anywhere near a second. Even half a second seems very unlikely. But unless you measure each of those intervals separately, we wouldn't know where to look. Pete

So you can see why it is apparently taking one second -- or half now? Is it a long complicated plug-in or something? Pete

If its the hardware I'm familiar with, then it isn't as simple as that. The actions which the firmware makes in response to inputs on its connections depends entirely upon the specific firmware chip installed. Every PFC device other than the straight USB-only connected ones has ts own specific firmware chip, but all the controller cards are the same. Any can replace any other, even in a different unit, and the firmware chip dictates which inputs are read and which do what. Then the results are communicated to the driver using a special proprietary protocol which is not made available by PFC except to their own developers, of which i was an honorary one. So, in other words, the inputs you think you might be able to connect to are most likely ignored in any case unless you re-program the firmware. If the hardware is some new type I'm not familiar with, then I have no answer. If it's a standard USB HID device then there might be a way, but their normal USB HID devices still used special firmware and a different proprietary protocol. My PFCFSX driver handles the older serial-port type, My PFCHID driver deals with known examples of the latter type - known to me, that is. I understand they now do a lot more, mostly aimed at X-Plane and with which I not involved at all. Pete

Apart from joystick and button polling (which can be set but defaults to about 50 per second), there's no fixed "polling" unless you programmed it using a timer event, and even that's dependent upon Windows Timer messages. Performance otherwise depends entirely on FS performance, though to prevent slowing down FS's simulation there will be imposed delays between each Lua line of up to one millisecond -- more on occasions if FSX is busy or needs to do more to accomplish the requests being made. All the Lua interpreter does is Yield by using a Sleep of 0 or 1 milliseconds depending on the command just executed -- and, of course, if they involve sending messages to Windows or FS and waiting for a response, the delays will obviously be longer. But most certainly not a second. Even if FS is very busy, and you get the occasional longer delay, the average execution speed will be much much faster. As an example of the sorts of speeds that are achieved, take a look at the Master-Slave lua programs which make one PC running FS slave to another running FS, and with very acceptably smooth results providing one of the PCs (I forget which) is faster than the other. Pete

No, not that I know of. But why do you want to assign your joystick through FSUIPC? The assignments facilities are very extensive and designed for cockpit builders or those who wish to have different controls for different aircraft types? There are many different ways of assigning the same things, and each is better suited to different add-on aircraft or different types of aircraft. In addition, erratic behaviour is almost all a result of dual assignments -- if you do assign in FSUIPC you must disable controllers in FS. If not, both will try to exercise the control and they will fight each other. Finally, good calibration is the secret to good smooth control, not assignments. You can calibrate in FSUIPC no matter where or how you assign -- so first just is FSX assignments but calibrate in FSUIPC. Pete

And, in addition to what Ian says, consider using Profiles instead of "Aircraft Specific". (Profiles are actually the default in all recent versions of FSUIPC -- you actually have to change a parameter to revert to "aircraft specific"). Pete

FSUIPC has no support built in for outputs to any devices. If you mean the GF-WP6 then you can program it by writing a Lua plug-in using the gfd library. Full details are provided in your FSUIPC Documents folder. Pete

Normally you assign a view hat to Pan View in the axis assignments, and leave it at that. If you are assigning to all the views separately, then, yes, it is normal and useful for the return to centre also to return the view to default straight ahead. That's the way I have it. If you want to pan instead you assign it as an axis, not a set of view buttons. But then you have to find the straight ahead view again yourself. Pete

I suspect those, if simulated, will be custom controls as listed in the 737NGX SDK. Did you look? I'm really not sure why you are trying to use Mouse macros when PMDG kindly supplied custom control numbers for almost everything. Pete

Sorry, but all that was over four years ago. I really am not able to spend so much time -- just to understand that earlier post will take me quite a while, and even then I couldn't guarantee anything useful. Why not try what I see it suggests: "an alternative to computing the formula is to fill in you minimum and maximum values in this more complex version of the Lua plug-in:". Pete

That's the problem. There is no Lua function "setbitUW". The spelling is "setbitsUW", as documented! Pete

Hmm. surely you must be able to make a new account? Maybe spell your name a little differently? What objection does it make? I can't imagine the way it can stop new accounts! Normally for problems with SimMarket I think they expect you to post a "Problem Ticket". Pete

Sorry, I'm just here for tech support. I really know nothing about SimMarket itself. If you have a new email, why not just create a new account? I thought you decided your own password in any case? Pete