Pete Dowson

So? I have a water-cooled i7-980X 4.65GHz 6Gb triple port RAM at 2000MHz, an overclocked water-cooled GeForce GTX 480 and FSX. What is the relevance? The actual processing time for any request in FSUIPC very rarely takes even as much a 1 mSec, on any system, There really isn't much it has to do. Everything else is Windows and other processes and threads. Okay. Go ahead. You might also want to consider Lua. There's already an example of a Lua plug-in for recording parameters to a CSV file. It's provided in the Lua package installed with FSUIPC. The plug-in method has the advantage of running in-process and therefore not suffering any process switching nor memory mapped file overheads. Pete

Depends entirely on your system. I assume you are running an external EXE program? Each time you make a request there's a message posted to FS, a process switch, and eventually the message gets to FSUIPC which then responds. Some things are faster than others in FS itself, depending what has to be done to get the information. Once FSUIPC has provided the data and thinks it has returned the data, there's another process switch. The time when your program sees it depends on when Windows gives your process any processor time again. Process switching itself can take milliseconds sometimes -- use Task Manager to see how many processes are running at any one time. The main overhead is in message queuing and process switching. The data quantity is almost irrelevant. You always want to do all the reads and writes in one batch, one "FSUIPC_Process" call. It should be easy to match a reasonable frame rate in FS -- certainly the 25 fps your 40 mSec cycle should be easily achievable, assuming the FS frame rate is around 25 fps too. But of course everything also depends on the loading on your PC -- FSX is very different to FS9, in particular. Regards Pete

You can do it -- one of two ways in fact: 1. Editing button assignments in the INI file, making multiple assignments for those keystrokes, each conditional on an offset value which you would also, on the same button press, increment cyclcically using the "Offset Byte Cyclic Inc" control. You can use the free user offset x66C0 for that. Details of parameter formats for all these things are in the FSUIPC Advanced User's document. or 2. Have a little Lua plug-in script invoked by the button which sends the keystroke depending on a Global Lua value which is incremented also. The Lua facilities are documented in the separate Lua packaging installed with the rest of the FSUIPC documentation. Personally I prefer the latter as it is cleaner and should be easier to formulate and understand. Regards Pete

I edited your reply as you included all your answers in a "Quote" from me! This made it impossible for me to quote you in response! So, if they are not motor controlled, where are you seeing the levers advance, as you said " wow the levers did move ...". I am now even more confused because without motor control i don't see how the positive feedback can arise. 088A is the "direct" way. 089A is the same unless disconnected. Perhaps you mean to use FS axis controls instead? That's actually less direct of course. But normally a motor driven throttle will move according to the A/P-set throttle value (read from 088C) and that movement affects the potentiometer output which is fed back into FS via either 089A (which is disconnected when the A/T is engaged) or via the Axis controls (also disconnected). If your throttle doesn't have the motor control, then how would that happen? Ah, not actually "calibration, merely mapping the range appropriate to the control. Yes, the internal FS values for forward thrust are 0 to 16k. Negative values are reverse thrust. The THORTTLEn_SET controls are the same -- 0 to 16k for forward thrust. The AXIS_THROTTLEn_SET controls don't provide reverse and operate forward thrust from -16K to +16K. So you need to add 16K and divide by 2 (or divide by 2 and add 8k). Okay, I'll take a look. Thanks. Yes. I think it intercepts the AXIS_THROTTLE controls and reinterprets them for the Airbus Fly-by-Wire Thrust modes. I suspect most Airbus simulations do something similar. However, you have the solution now? You need not invoke 089A. Note that the solution would actually be more efficient as a Lua plug-in on the FS PC. Regards Pete

Well, this is a strange coincidence! Within a week of each other two users have exactly the same problem! See http://forum.simflig...pearing-macros/ Of the Macro files you list, these two cannot be the same. One must have a space before the '.'. It is that which creates the problem, due to the way in which Windows handles INI and CFG files. Seneca.MCRO SENECA.MCRO That reaults in a complete full and rather useless Macro file index in the INI: [MacroFiles] 1=737 OHD 2=767 3=APchart 4=Seneca 5=Seneca 6=Seneca 7=Seneca 8=Seneca 9=Seneca 10=Seneca 11=Seneca 12=Seneca 13=Seneca 14=Seneca 15=Seneca 16=Seneca 17=Seneca 18=Seneca 19=Seneca 20=Seneca 21=Seneca 22=Seneca 23=Seneca 24=Seneca 25=Seneca 26=Seneca 27=Seneca 28=Seneca 29=Seneca 30=Seneca 31=Seneca 32=Seneca 33=Seneca 34=Seneca 35=Seneca 36=Seneca 37=Seneca 38=Seneca 39=Seneca 40=Seneca 41=Seneca 42=Seneca 43=Seneca 44=Seneca 45=Seneca 46=Seneca 47=Seneca 48=Seneca 49=Seneca 50=Seneca 51=Seneca 52=Seneca 53=Seneca 54=Seneca 55=Seneca 56=Seneca 57=Seneca 58=Seneca 59=Seneca 60=Seneca 61=Seneca 62=Seneca 63=Seneca 64=Seneca 65=Seneca 66=Seneca 67=Seneca 68=Seneca 69=Seneca 70=Seneca 71=Seneca 72=Seneca 73=Seneca 74=Seneca 75=Seneca 76=Seneca 77=Seneca 78=Seneca 79=Seneca 80=Seneca 81=Seneca 82=Seneca 83=Seneca 84=Seneca 85=Seneca 86=Seneca 87=Seneca 88=Seneca 89=Seneca 90=Seneca 91=Seneca 92=Seneca 93=Seneca 94=Seneca 95=Seneca 96=Seneca 97=Seneca 98=Seneca 99=Seneca 100=Seneca 101=Seneca 102=Seneca 103=Seneca 104=Seneca 105=Seneca 106=Seneca 107=Seneca 108=Seneca 109=Seneca 110=Seneca 111=Seneca 112=Seneca 113=Seneca 114=Seneca 115=Seneca 116=Seneca 117=Seneca 118=Seneca 119=Seneca 120=Seneca 121=Seneca 122=Seneca 123=Seneca 124=Seneca 125=Seneca 126=Seneca 127=Seneca Of all those you only actually use 1 and 4, so I suggest you replace the entire [MacroFiles] section with: [MacroFiles] 1=737 OHD 2=767 3=APchart 4=Seneca and let the others get reallocated as and when. Then go and get FSUIPC 3.989y from the Download Links subforum, in which this problem has been fixed. Note that the Seneca macro file with the space will be ignored. If that's the one you want, delete the other and remove the space in the filename. Regards Pete

Okay, that should be fine. Okay. So, things to check: What .mcro files are there in the FS Modules folder? Please find the FSUIPC.INI file and paste it into a message here, so I can check that corresponds. Also, just in case, you could try the latest FSUIPC version, 3.989y, from the Download Links subforum. That's the one I'd be testing with. Regards Pete

It's a special INI file line (no space!) which you have to add yourself. It isn't in the Options dialogue! I couldn't possibly put all these odd special "fix someone else's faults" options in there! As documented in the FSUIPC Advanced User's manual, it is one of those you have to add yourself. Or, better, go complain to Saitek and get them to fix their hardware. With their attitude I'm surprised I actually bothered to try to help them with any sort of workaround in the first place! Pete

I'm not sure what you mean by "still have those changing views" (have you told me about them before?), but if you mean the well-known spurious button presses sent by the Saitek yoke with the old buggy firmware, then, if you can't get the device fixed by Saitek, I think the only answer is to use the EliminateTransients=Yes option in the FSUIPC [buttons] section. That was why it was implemented. But of course that will only work if you program the buttons in FSUIPC. Regards Pete

Oh, I see. (But I usually press Shift+Delete, which bypasses the recycle bin! ;-) ). Not necessarily. Is that value from the Log file? Try it anyway -- see how far up the axis movement that really is . And don't forget that the first 20-30% of the lever is normally speedbrakes off and Armed zones in any case. The actual speedbrake deployment is about 27% to 67% (flight detente), 100% only as landing spoilers. One other way you could do it at present is by directing the Spoiler axis to a Lua plug-in script which checked for sudden short changes and discarded them, forwarding the others on via the spoiler control. For transient button presses I did add a facility for the [buttons] section called "EliminateTransients" which discarded button presses of less than one poll width (about 25 mSecs by default). I'm not sure it's a good idea for axes though -- I'd first like to see the log showing the problem on your system first, to see how to tackle such a facility. Finally, the "filter" option in the FSUIPC calibration might remove it too. Have you tried that? Regards Pete

And what is its number? Saying "latest" doesn't help at all I'm afraid. I ALWAYS need the number. Some folks have said "latest" and been using a two year old version, the "latest" they'd bothered to find. The actual latest at present is 3.989y. Sorry, there's something missing in this part. Until what, and what indication, and what did you confirm? Sorry, none of this part is making sense to me. What little sense I can derive seems to be saying that something you installed overwrote your "latest" copy of FSUIPC with a really old one which doesn't even support macros. Maybe you could check -- check the actual VERSION NUMBER of the FSUIPC. It is shown in the Log file, it is shown on the first FSUIPC options tab, it is shown in the Properties of the FSUIPC.DLL file. Let me know please. Regards Pete

GUIDs weren't always added. I found I needed more precise identification because some folks have several identical devices with the same name. Yes, for letters you choose for yourself. If you simply changed the Auto option then FSUIPC would have have assigned A, B, C. Hopefully R Y T are more meaningful to you. You should be fine with whatever letters you want. The Auto option was only for those not wanting to be bothered. Without Auto if you add a new device you'll need to assign letters again yourself. With auto it's just plug-and-go but you then have to put up with FSUIPC's choice of letters. Regards Pete

This is always a video driver problem, and almost invariably only affects full screen mode. You either need to find better video drivers for your card, or switch to Windowed mode before going into the menu. The dialogue produced for FSUIPC is an absolutely standard Windows dialogue box, and FSUIPC code isn't actaully involved until after the display is drawn. Regards Pete

It would help if you stated the version number of FSUIPC, so I could determine whether the options you can try are included. I think you should first update to the very latest, just in case (4.664 is in the Download Links subforum). Anyway, what is happening is that SimConnect has stopped responding. Something is killing it. Possibly something earlier in the FSUIPC log might show more about what it might be, but otherwise it might need a SimConnect log instead. What seems likely is that you have other programs or add-ons using Simconnect and one of those is clobbering it. Perhaps you can list all of the SimConnect-using add-ons you are running so we can proceed with an elimination. The only thing you can really do in FSUIPC is change the timeout FSUIPC imposes on the time it will allow between getting data from SimConnect. However, although it might be worth trying it just to see, the extended time would mean a poorer service FSUIPC is able to offer to its client programs (i.e. out of data data, or good data less often). But I suspect it won't help in any case because the log shows that the connection won't even re-make -- SimConnect is not even responding to the reconnection attempts. Anyway, the parameter is SimConnectStallTime=1 That '1' is 1 second. You can make FSUIPC more lenient to SimConnect performance by increasing it. Try 2, 5, 10. I'm not saying these will fix things, but if they change the results it tells us something about what is going on. Oh, if you are NOT using FSX with SP2 or Acceleration, then you need to update. The older versions of Simconnect were much more prone to this sort of thing. Regards Pete

But how can you show that? The folder listing would list the new one created by FSUIPC if you'd deleted it then run FS. Odd that the throttle affects the spoiler. What sort of bad value does it generate on the spoiler? Maybe you can simply calibrate those values as part of the dead "spoilers down" zone. If you are not sure what values it produces, just Log axis events in the FSUIPC logging tab and check the log after it happens. Regards Pete

Well, it sounds like your firmware is even older than anything I know. You'd really need to find out why it goes wrong from PFC. Regards Pete

On the FSX PC it is installed when you install FSX. You weill have to create a SimConnect.xml file -- there should be one shown in the ASE manual or possibly supplied in one of the ASE folders. For the client you have to have the Deluxe or Gold edition of FSX, and the SimConnect.msi file for installing it is available on the DVD. Then you have to create a SimConnect.cfg file for that end. All this should be explained in the ASE manual. I shouldn't really be supporting SimConnect as in effect it is actually a "competitor" to FSUIPC! I'm sure you can ask questions about all this over in the Active Sky support forum. Regards Pete

Have you tried reading the relevant parts of the ASE documentation. I'm sure they tell you how to set it up for networks. It only uses FSUIPC (and therefore WideFS) for use with FS9, not FSX. No, you will have to set up SimConnect for Network use. You'll need to refer to ASE documentation. I don't know if it needs any fsx files sharing, I wouldn't have thought so. I'm sorry, but I cannot support other folks products as well as my own. They keep me busy enough! Regards Pete

Did you explain here, in this Forum? If so you should maintain continuity by adding to your original thread rather than starting a new one. No, ASE does not use either FSUIPC or WideFS when used with FSX. I don't think you are reading the correct part of their documentation. ASE only uses FSUIPC and WideFS for FS9. There's no "WideFS" to install, as such. You Register it when installing FSUIPC4 on the FSX PC. On the Client PCs you merely run WideClient. Regards Pete

As I pointed out, updates are provided in the Download Links subforum here. I don't actaully have a website. Enrico Schiratti maintains a web page with my last official documented releases -- that would be 4.60a -- but updates are provided here, where I have access. That's where you'll find 4.664 and lots of other goodies. When that problem occurred, which wasn't often, yes, that was the work-around. But it shouldn't happen in any case in the recent updates. Let me know if it does. I don't think many companies target their productions to use FSUIPC. Why should they? That doesn't make them a "mickey mouse" company. For FSX I don't think any aircraft specifically uses FSUIPC -- FSUIPC is for compatibility. most use SimConnect these days if they need to do anything outside of the normal FS-supported aircraft interface. Thje mouse macro facility in FSUIPC is a "hack" -- it works by doing actual code jumps into specific places in the aircraft code. It in no way relies on anyone writing the aircraft to be so "hacked", but it does rely on a now almost defunct way of writing gauges -- the C/C++ Gauge library of FS8 and FS9, which is also supported in FSX but is almost supplanted by construction of gauges using XML. Even Microsoft did not use their own SDK for writing the default FS gauges -- almost nothing in any of the default FS9 or FSX aircraft is susceptible to this technique. Regards Pete

No, I don't know Synergy. I use VNC, which provides the screens of other PCs on the Network as Windows on the one you are using, plus of course the mouse and keyboard use. No. WideClient only picks up keypresses if 1. it has the keyboard focus --unlikely unless you click first on its Window, assuming you have it visible, AND 2. you set the [user] parameter SendKeyPresses=Yes (this defaults to No when omitted). The only Hot Key facility offered by WideClient is the one called ButtonKeys, which picks up defined keypresses even when WideClient doesn't have the keyboard focus, and uses them to toggle defined Virtual buttons for assignment in FSUIPC. But you have to add the details for each and every one of those for it to work. Regards Pete

You are trying to use an axis control from a Client PC, not on the FS PC? Er, sorry. Now I am really confused. Where is this USB connection< then? Surely not on the WideClient PC? How does it get its value into FS? These levers, are they motor controlled by any chance? If so, the software used with them might be READING the value from 088C, moving the lever according, which is then giving you a new position which you are feeding back -- result positive feedback, completely unwanted. Writes to 089A are either ignored (except for a copy placed at 3330) if the thorttles are currently disconnected for AutoThrottle control, or result in a write to 088C, so I'm not at all surprised. 089A is realy simply a disconnectable 088C intended for autothrottle motor control applications where the feed through has to stop when A/T is engaged. Sorry, you'll need to explain what you mean there. Since copying to 089A shouldn't do anything, isn't this the same as doing "copy the read value from 0x88C “calibrated” to 0x3114 addressing KEY_AXIS_THROTTLE1_SET via 0x3110", which would certainly make more sense. What exactly do you mean by "calibrated" in this context? Sorry, what do you mean? I wish I knew a bit more about this weird throttle device of yours. Did you build it yourself? Why is it so unorthodox? Regards Pete

In that case please read the chapter in the User Guide entitled Keeping track of multiple control devices and all would become clear. Alternatively you could have simply searched for "Joynames" in the document. Regards Pete

Sounds like an old bug where the window was simply not being cleared. You should be able to simply click anywhere else it will go away. This was fixed some time ago. It didn't happen on many systems, being very timing and video driver dependent. Good, because it should never create any folders. It would create a file by that sort of name, but only when you've finished adding macros. Initially there are none to be written. By the "latest" do you really mean 4.664? You should really always state version numbers, please. Folks have said "latest" and been using very old versions -- the "latest" they happen to have seen. Please do visit the Download Links subforum when you are in any doubt. I expect that aircraft is not written in C/C++ using the standard Microsoft gauge library. Only those have the internal structures which allow this type of mouse hooking. Many new aircraft for FSX are written using XML, like the default ones. Such aircraft are not susceptible to the mouse macro system. They may be using Local Variables though (L:Vars) and quite often those can be programmed. The "End Macro" option must stay available until you press it to end the macro creation phase. That's what it is for! It is then that the macro file is wrtten. Please do read a little more of the documentation. [LATER] I just checked in the User Contributions sub-forum, where these is a thread listing non-compatible aircraft for mouse macros, and this appears in that list, at the head: - 757 Captain (Captain Sim): For FS2004/FSX Regards Pete

If you calibrate multiple throttles through FSUIPC they get translated into the older THROTTLEn_SET events, which provide the reverse zone too (0 = idle). The newer AXIS_ ones don't. If you must have the AXIS_ events instead you have to set the NRZ (no reverse zone) checkboxes and also set an option in the INI file, as described in the documentation. See this item in the FSUIPC History document for versions released in January last year: Regards Pete

No idea. Server broadcasts depend on a working network, both PCs being in the same workgroup, both operating systems supporting broadcasting (at least XP SP1 or later), nothing blocking or using ports 9002 and 8002, and, of course, FS up and running, ready to fly, on the server. Regards Pete