Pete Dowson

This is nothing to do with FSUIPC. It cannot possibly affect anything to do with any of those messages. Pete

Yes. Only the one 'R'. It is that which defines what is coming, much like K for keypress, C for control, etc. Hmm. Yes. The base format is defined earlier, in about the 3rd para of the "mouse macros" section. It's shown there, clearly, as R<module>:<rect#>,<mouseflag> and then it expands on each of those parts. You'll see that "<module>:" is defined as one optional part -- module number and : together. But I do see what you mean now, that the "R" is being repeated in the definition of the Rectangle itself. Sorry about that -- i'll remove those Rs. They stood there now for several years! Regards Pete

If you are doing this to test Lua plug-in changes, you can change the running Lua program whilst it is actually running, and when WideClient sees the change it will kill the running copy and load and run the amended one. This is a very useful and fast way to test things out. There's a whole lot of initialisation of crucial values being requested and sent. If you've done a full log of the WideClient activities you'll have seen some of that. Whether it takes a few seconds or as much as what you are seeing tends to depend on the workload on the Server end. In my case, with 7 clients and FSX running on an i7 980X overclocked to 4.65GHz, it's about 5 or 6 seconds, though I' ve never timed it exactly. Anyway, if the main reason this is an annoyance is because you keep restarting WideClient, don't. There's no need. It can run all day through any number of Lua changes and any number of FS restarts, as I do here on seven clients. Regards Pete

Sorry, I don't know Delphi at all (nor Pascal for that matter). The difference is obviously in how the two versions of Delphi are compiling or interpreting the code, because obviously the FSUIPC side of the interface is not changing. Doesn't Delphi has any debugging tools so you can find out what is wrong? Regards Pete

You are reading the description incorrectly. The "R" must be the first letter, defining a Rectangle. Then you either get the offset (X...) or the module number and offset (1:X...). You've got two "R"s. In other words, the "R" defines what's coming. The module number and offset go together. You''ve separated them every time with an R. Pete

Gauge names are only relevant to mouse macros, because they point to the code the mouse intercept found and hooked into with the offset listed. If you have more than one module referred to in a macro file they'd have numbers, and the number would be part of the mouse macro encoded for it -- but that's line by line. A multiline macro can contain any mixture, including keypresses, mouse macros, L:vars, FS controls. Regards Pete

You can have WideClient running before FS is even started. In fact it tends to work better that way. On my Clients I have WideClient in the Explorer "startup" folder so it loads when the system starts. Lua programs in the WideClient folder won't start until FS is "ready to fly" unless there's one called "Initial.lua" which will run when WideClient is started -- best not to do any ipc.reads or writes in such a file. No, there's no such thing. I have several Lua programs on clients which read ipc offsets, and have not observed anything similar -- but then they are event driven, so would do things when offsets change. The PCs they run on also have several clients running, so I suppose they's help with the timing of data. Note that there will always be all zeroes in the local WideClient data until WideServer has seen the read request and responded, but thereafter it will be kept updated. Maybe you are only reading once? For client programs, but not Lua, there's a hold-off parameter which stops WideClient returning to them within so many milliseconds when called to read a value for the first time. I think this is as much as 500 mSecs by default, but i'm not sure without looking. Because Lua plug-ins aren't clients they don't go through the same interface and instead simply read the memory direct -- it's a lot fast as you can imagine! Correct. Lua plug-ins are just extensions of the program, and not visible as or counted as 'clients'. Their activities don't count in the application stats, only the overall performance stats there and in the WideServer log file. That's why I always suggest pasting into a message, as you have done. Anyway, the Log shows everything is fine. If your program cannot handle initial zeroes in offsets I think you might want to code the first reads as "read all offsets wanted", "sleep(500)", "read them again". Or just use the offset event and ignore the first call. Let me know. Incidentally, if you still have problems I could do with knowing what version number of WideClient you are using, please. Regards Pete

What have you got "Y" assigned to? Slew mode toggle as default setting? Offsets are certainly not listed by what keypress you might have assigned to them. That would be a bit daft, and in any case most offsets have nothing to do with particular keypress-initiated controls. Assuming you mean "slew mode"? It's easy enough to find: 05DC I think, but please do check the list. Note that you can always determine the FS control being sent by a keypress by using Event logging in FSUIPC. BTW for some reason you posted your question at the end of a thread dealing with something entirely different, in the "Download Links" subforum. It was lucky i spotted it. Please use this main forum for support. Regards Pete

What a roundabout way of doing things. Why not simply assign the macro to the button directly, instead? What's the reason for going via the keyboard? It's very inefficient and adds extra messaging through Windows for no good reason. With a button you can have multiple entries in the [buttons] section of the INI file for any button. The action in the order listed. Or you can put multiple actions into a macro, as documented. As it shows in the Advanced User's guide, any macro can have multiple actions in it. That's the original and main purpose of macros, and, in fact, why they are called macros (as opposed to 'micros' <G>). e.g something like: [Macros] Module="PMDG_737NG_Main.GAU" 1=Combined CMD 1.1=RX32c0*X6a90 1.2=L:apleft_clicked=Tog Then how did you miss the section entitled "Multiple actions in one macro control" in the part about macros, page 39 (ish) in the Advanced User's guide? Regards Pete

Microsoft didn't name those "functions" specifically, they are just reductions in the normal throttle and prop pitch setting below their idle or neutral setting. If you know how to set them on the keyboard or using the mouse on the panel you could see exactly what controls FS is using by enabling the Event logging in FSUIPC, then looking at the log. I think you'll find the reverse (F2) is "throttle decr" and "feather" (Ctrl+F2) is "prop pitch decr". There are separate controls too for each engine, if that's what you need. Regards Pete

Do other client programs work okay? Try FSInterrogate to read the same values -- that's the best test. Or even my TrafficLook or WeatherSet2 programs. Anything which reads FSUIPC offsets. Close down FSUIPC and show me the FSUIPC Log file from the FS Modules folder. Regards Pete

You have a corrupted SimConnect side-by-side library setup. Removing and reinstalling FSX often makes that worse, not better, because the uninstall only does a partial job on SimConnect which prevents the installer doing its job correctly. When you reinstalled, did you install first the base FSX from the CD, then ran it, then SP1, ran it, then SP2 or Acceleration? I think you need to at least run FSX between each stage, unless maybe you are installing the "Gold" version. You could try running just the SimConnect.msi installers. If you have the DeLuxe or Gold versions of FSX you'll find them in the Toolkit (SDK). Otherwise somewhere on the disk. Also, you could try the later FSUIPC4 installer, for 4.638, posted in the Download Links subforum. I've changed the way FSUIPC checks for and connects to SimConnect and that may help. It won't solve problems with other Simconnect users though. Regards Pete

Since you are probably not referring to your more insulting thread on the main forum, I should say here that another user has kindly quoted there the section of the instructions you have apparently quoted out of context -- and read out of context too, it seems! So it is NOT "Create a Desktop Connection using FSUIPC". Those are two separate things, the last two in a list of things! And the line "Creating a Desktop-Link should be done for a fast access to the program itself.." explains that by "desktop connection" he simply means make a shortcut to his program on the desktop so you can start it easily! So, reading things correctly, and quoting them properly, would have saved all that unnecessary aggro, don't you see? Pete

Aha! so it is NOT "Create a Desktop Connection using FSUIPC". Those are two separate things. And the line "Creating a Desktop-Link should be done for a fast access to the program itself.." explains that by "desktop connection" he simply means make a shortcut to his program on the desktop so you can start it easily! Now why didn't the original poster read this correctly? Regards Pete

There isn't a specific "blank" control, but you could assign it to some control that doesn't actually do anything in your aircraft, either because it simply isn't applicable, or because Microsoft never actually implemented any code to support it! For example, one possibility is to assign it to send a keypress of a key not used or assigned anywhere else. You could probably send a "null" (zero) key, but you'd need to assign a real key then change the keycode to 0 in the INI file. For controls which might do nothing, see things like "Decrease concorde nose visor", "Decrease helo gov beep", "Toggle water rudder", etc. There are lots when you look. However, I like the idea of having a "NULL" control you can assign, where nothing happens at all. I'll put that on my "to do" list, probably named "Nothing" as "Null" is a little technical-sounding. Thanks! Regards Pete

Why are you posting here? There's no question in your message, only a good install log! Please don't waste time posting stuff for nothing. If you want help with something you have to say what it is. Pete

I don't think it needs purchasing and registering for use with pmSounds. I cannot support other folks' software. You need to check with PM support, but "pmFileCheck" is a program provided by PM to check things. It's downloadable from their website. If you want me to check whether FSUIPC is installed correctly, close down FS, find the Install log and FSUIPC4 log files from the FSX Modules folder, and post them into a message here. Regards Pete

So, set that parameter I mentioned to 'Yes', try assigning in FSUIPC but to the Axis controls as I suggested, and ensure "NRZ" is selected on the 4 throttles tab. If you hadn't done this already you'd need to recalibrate. Regards Pete

What "FSUIPC bug"? There is no bug that I know of. Why refer to such? First off, why are you assigning in FSUIPC? Is there a good reason? FSUIPC assignment was added to provide more flexibility, changing assignments for different aircraft and so on. Second, if you assign in FSUIPC to the FS axes -- AXIS THROTTLE1 SET and AXIS THROTTLE2 SET, then this is effectively the same, exactly the same, as assigning in FS itself, except you bypass things like the sensitivity and null zone sliders. But this gives you back the option of having different assignments for different aircraft, which you cannot for throttles if you assign in FS. The only possible reason you have to use the FS controls for throttle for this particular aircraft is that it intercepts those controls and processes them. If you assign in FSUIPC "direct to calibration" then they won't be able to see them. Additionally, no matter where you assign them, FS or FSUIPC, if you calibrate them in FSUIPC the controls will normally be converted to the older THROTTLEn SET controls (as these provide a reverse range, whilst the newer AXIS THROTTLE controls don't). Now in the current versions of FSUIPC there is an option to calibrate with the NRZ option ("No Reverse Zone") selected on the calibration tab. That removes the reverse zone but still uses the THROTTLEn_SET controls. What might be needed in your case is for the original AXIS THROTTLEn SET controls to be used. There's an INI file option for that -- check out "UseAxisControlForNRZ" in the Advanced Users manual. You should try setting it to 'Yes'. It goes in the relevant JoystickCalibrations section. Remember also to calibrate with NRZ selected. All this can be aircraft-specific. Regards Pete

That's presumably a restriction imposed by the way the C# interface has been constructed. Multiple connections are possible but the instance number used in generating the memory mapped filename needs to be different for each. However, having more than one connection doesn't directly help do what you want to do, because once WideFS has connected you will get the data back it last saw. You could try referring to offset 333C, but 337E might be more reliable. With that you have to see if it changes over time. If not then either the connection is broken, or FS is closed or crashed. But note that it is only updated when FSUIPC can do so -- long delays in FS disk activities could slow it occasionally. Note that using the same connection in separate threads would necessitate some sort of lockout to prevent one thread corrupting the request data formed by the other. Really you'd be better off having the FSUIPC interface in its own thread, honouring requests flagged from any other threads. If your time critical thread is reading FSUIPC data all the time then just add the additional items there and let your checking thread read the results and apply a timeout for changes. Regards Pete

No it isn't. The install log proves it is 3.96: Regards Pete

It is still the weather -- the last thing FSUIPC does is try reading weather. Then crash. Have you really deleted ALL of the .wx files? If the BIN file is okay and there's no weather loading I can only think it is FSX itself corrupted. As the FSUIPC4 Advanced User's guide says, if you don't need FSUIPC to read or write any weather data you can set WeatherReadFactor=0 in the INI file. But I really do think you need to consider repairing FSX itself. Regards Pete

Of course I am happy with it. Who wouldn't be. It is a full cockpit with dual-linked yokes and pedals, full instrumentation, full forward and aft overheads, with the external scenery on a 10 foot wide screen seen through the windows. Everyone who visits likes it too.It is equipped with dual headsets for intercom and ATC. My flights are always fully occupied, especially flying without a copilot most of the time. My "work" is programming. My hobby would have been flying for real if it hadn't been for my Retinitis Pigmentosa (severe tunnel vision), which stopped me going solo. So now my hobby is flight simming and model railways. I have 2 simulators in my cockpit room -- a dedicated 737NG (actually an -800) and a Piper Arrow III (analogue gauges etc). I fly IFR in the 737 and VFR in the Arrow. They are in the same room but entirely separate, but both are modelled very specifically on particular aircraft. I would not have it any other way -- there's no way to have good realism in a generic setup designed for simple messing about in a multitude of different aircraft! I'm evidently the opposite of yourself. Instead of being a "jack of all trades" I prefer to have the most intimate in-depth knowledge of a few. Why is that sad? Perhaps I should feel the same about you? Regards Pete

Goodness gracious! Where from? It is very much out of date and not supportable! The earliest supported version for FS2004 is 3.98, which is the one available on the download site http://www.schiratti.com/dowson . There's also a much later version in the Download Links subforum here. Regards Pete

Not really. Nothing should be touching it. Regards Pete