Pete Dowson

Ouch! Why did you do that? You just needed to REPAIR FSX, using the original DVD! :-( Regards Pete

They are folders. Each contains a file. Yes, you should have three -- the base RTM version (60905) is missing, as reported by the FSUIPC4 installer. Just run FSX repair off the original DVD -- I think it's an option when you insert it. An alternative, which may be more reliable, exists if you have the Deluxe edition and have installed the SDK from it. In Core Utilities you should find a SimConnect.msi which will install Simconnect properly -- if you've also installed the updates to the SDK for SP1, Acc/SP2 the original one will be in a subfolder someplace. Regards Pete

Well, not quite. I know ASX needs SimConnect SP1, but most need the base version RTM. FSUIPC4 and the latest TrackIR actually use the latest SimConnect they can find -- RTM, SP1 or Acc/SP2. The problem for FSUIPC in your installation is that, since FSUIPC4 has to be loaded INTO FSX, as a module of it, it has to rely on SimConnect to get it there. The side-by-side library mechanism implemented in Windows only allows ONE version of a needed DLL to be explicit in any one DLL or program. FSUIPC4 has to have an explicit relationship, visible to Windows, with just one of the three SimConnects it can use. There's the rub. The only SimConnect version I should be able to rely on as ALWAYS being there, always installed, is the RTM version, as that comes with the DVDs and is installed first. SP1, ACC and SP2 are all optional. So, FSUIPC4 declares in its file that it needs RTM SimConnect simply so it can get itself loaded. Once it is loaded it actually connects to the latest one installed, instead. I cannot make the Installer patch the binary of the DLL according to the installed SimConnects, because so doing would wreck the Code Signature, and that would stop it loading for sure. Regards Pete

Is this FSUIP3 or FSUIPC4? It should be perfectly smooth in FSUIPC4 (well, as smooth as FSX is) since it is obtained at the FS frame rate. In FSUIPC3 it is obtained by a call to PANELS.DLL (much as a Gauge would), but because all such calls are an overhead, this is one of a large number which are performed every few FS frames -- 4 I think, in this case. Would that explain your problem? I have gradually been "promoting" assorted offsets to faster updating, on request. For today's PCs it won't be such a noticeable performance overhead, though I'm not willing to do a wholsale update on them. This is the first request for this one, but I will promote it to every frame with the next increment (probably 3.809 on Monday or Tuesday -- look out for it in the "Other Downloads" announcement above). I don't calculate it, I read FS's own result. I used to compute it, long long ago (version 2.??), but it never exactly equated to FS's computation. I did find out what values they were using once, but I've long forgotten, sorry.. Regards Pete

Right. So you are all sorted in this regard? Erthis is confusing. You say you have added these using the "internal FS commands" (I assume you mean Mixture Lean and Mixture Rich controls?), so what else could FSUIPC do for you? Why? I'm evidently missing something here. Please explain. Regards Pete

Really? Is that with ActiveSkyX on the same PC as FSX? You've somehow destroyed the RTM installation of SimConnect. You should be able to repair that following the notes I provide in the "FSX Help" announcement. Don't change any SimConnect file. Just follow the instructions. So are a lot of folks I think. Microsoft really made a mess of the installation/uninstallation process for FSX. It is all related to the "side by side" library facilities in WinXP and Vista, which seem to have been rather insufficiently throught out. vista is worse than XP in this as it is almost impossible to get rid of a bad side-by-side installation so getting it replaced is a nightmare. Uninstalling and re-installing FSX is usually the cause of more problems that it ever solves. Regards Pete

There are several flags, one "ready to fly" (3364 = 0), one "in menu" (3365 bit 0) and another "in dialogue" (3365 bit 1) . Their setting and clearing hasn't been changed in all the time they've existed. This is not the same as the ability for an application to actually connect to FSUIPC -- it can do the latter soon after FS starts -- though in very early versions of FSUIPC there was an imposed delay (the parameter for that is still there -- it is called "initdelay" I think). However, the purpose of that was merely to change the order in which different intercepting add-on DLLs subclassed the FS window, and in recent software that's never been needed. It certainly wouldn't stop connection during the FS opening dialogue, if you have FS stopping there. Anyway I've just double-checked, and the "ready to fly" indication is most certainly not given (3364 changing to 0) until FS is genuinely "ready to fly" -- the "in dialogue" flag (3365 bit 1) is, however, cleared after you click the "fly" button and FS starts its loading progress bar. That's as it is supposed to be. Hmm. I've been an AS user for many years and I've NEVER had to restart it to make it update to the current position correctly. I'm afraid you need to get back to HiFi Simulations about that. Incidentally, I'm checking with the current version (3.80x). I'm afraid I can't check any old unsupported versions, though, as I say, this is not an area where there's ever been any change. Regards Pete

There's absolutely nothing you can do in FSUIPC which would result in such a mess. Sorry, you most certainly have got something completely unrelated going on there. To force FSUIPC back to default settings simply delete the FSUIPC.INI file from the Modules folder. Everything you ever set is saved there. The only other part which you will have made is the KEY file, but that only holds your Registration details. Pete

Hmm. Strange. What does "one ad" mean -- is this "one add-on"? FSUIPC4 uses directInput, just like FSX, but it associates the joystick with a normal Windows joystick number (0 - 15). You said buttons on the same unit were recognised. What joystick number? If they see it with a joystick number, so should FSUIPC, so it is a puzzle. Sorry, I don't know what that means.. both enabled and disabled with FSX? What about FSUIPC4? What does "Spoilers have to move with a button" mean? What have you changed to stop it working, please? Is this a new PC, a new Windows installation, or something? I've not changed FSUIPC, so it is something in your system I think. Well, it certainly creates a lot more questions, doesn't it? Regards Pete

Where doesn't it react? You haven't answered any of my questions! I cannot help without knowing more. Have you tested your axes in FSX itself, first? Never try to use FSUIPC before getting basic things working. You need to read my replies properly, please. I cannot help with the information you provide. Regards Pete

Do you mean FSUIPC's "Axis Assignments", or only the Calibrations facilities? If assignments, FSUIPC4 uses the same method for reading joystick axes as FSX. Does FSX see them okay? If calibrations, make sure you don't have the sensitivities in FSX turned right down. The slider for sensitivity should be all the way up (to the right), for null zone it should be all the way down (to the left). Regards Pete

Well one answer is in the documentation supplied with FSUIPC. Yes, you can assign more than one axis directly to the same FSUIPC "direct" function. But there's only one place you can calibrate, so you need to make sure the two are not completely unlike each other, and you may need to calibrate with a bigger "dead" zone at each extreme and a larger centre part too, where that applies. Note that by doing it this way the last change in either axis will move the control, so if either axis suffers from jitter, you will likely get very variable results. The only way around this, using this method, is to make sure the currently unused axis is "parked" in one of the dead zones -- i.e. centre or min or max, hence the need for possibly more generous zones for these. The way which is generally recommended, but which means either assigning axes in FS, or at least not direct to FSUIPC calibration, is described in the section called "Multiple joysticks" in the Advanced User's document. This is a bit better in that the most extreme value of the multiple inputs is the one which "wins", rather than the last one which changed (or jittered). Regards Pete

Okay. Strange that it didn't affect many folks, all this time! Regards Pete

No problem, just concerned as to how the confusion arose. Glad it is clear now, and little threads like this no doubt help others. Regards Pete

The WideServer code is built into FSUIPC4, rather than being a separate DLL, that is all. There's no other difference. It just makes it more efficient. I would have done this with WideFS6 and FSUIPC3 if ever I had to rewrite either -- WideServer actually preceded FSUIPC development by about 2 years and the need / opportunity to rewrite everything didn't arise until FSX. You still need to pay for and register WideFS7 so that you can enter your Key and enable it. It is no different to the previous version in that respect. If you recall, you entered the WideFS6 registration into FSUIPC3. No it doesn't. You purchase FSUIPC4 and WideFS7. You enter both keys, and both are enabled. WideClient stays the same, that's all -- you don't have to change your Client PCs. There are lots of folks using both FSX and FS9, so it would make it really messy having to keep interchanging WideClients according to which FS you were running, don't you think? Especially when there's absolutely no need! I'm not aware of anyone else coming here so confused as you. How did this arise? These products have been available in this form now for over 18 months. Maybe you should review the documentation which comes with them and explains things, or even look at the Announcements in this Forum? Try, for instance, the "FSUIPC4 and WIDEFS7 AVAILABILITY" section in the Announcement entitled FSUIPC4 and WideFS7 ready for FSX: IMPORTANT NOTES! Regards Pete

Nor most of the 737 overhead, I would think? Or has GoFlight provided special drivers for the PMDG 737? I know there was a special SDK on sale for hardware developers -- expensive I think. Not till I release this new mouse macro stuff, no. None of it? Maybe they didn't go for the 747 SDK, or one was never produced? Regards Pete

I just programmed the GF module via the software that comes with it. It works for using it together with PMDG 737 I'm even more confused now. You are using software for the PMDG 737 which comes with the GoFlight unit, right. So where does Key2Mouse come in, and why did you have any problem in the first place? Why post the message here? What, exactly are you thinking of mapping via FSUIPC? Something is being omitted in all this, and it is puzzling me. Sorry. Yes, but I am not specifically talking about mapping actual keys or buttons for every function, only adding FSUIPC controls which can be so mapped by whomsoever desires. This is what the file for the 737 I have produced enables. Regards Pete

So, are these via Key2mouse? For the FS9 737NG overhead I do have my new mouse macros working very well now, and they work whether or not the overhead is visible. But i cannot release it yet. Since i am still not clear what you've done, I don't know what "doesn't work". Can you explain? Do you mean Key2Mouse doesn't work? Is this the FS9 747? If so, yes, the mouse macro facilities I am working on should enable you to add a full set of dedicated controls for the 747 too. I've not found any yet no amenable, but I've not tried so many yet. I am not very familiar with the 747 so I am not the best person to build a file with decent control names. Maybe when I have the facility ready and documented you could build the file and I would host it for other PMDG users? I've not yet tested anything on the FSX PMDG 747that's for tomorrow! Regards Pete

Most of the EFIS panel controls are purely panel functions and only usable with the mouse. I have long complained to MS about the number of default panel facilities with no keyboard or button configurability, let alone any way to them via "offsets". I've always maintained that anything switchable by mouse ought also to have a way of driving it directly via FS controls or events, and feedback via token values, but still both default and add-on panels feature some such switching. The EFIS panel functions which can be assigned (with names to match) are: Increase decision height Decrease decision height Barometric std pressure Kohlsman inc (i.e altimeter pressure setting inc) Kohlsman dec (i.e altimeter pressure setting dec) I'm afraid the others are only mousable, and I have no solution for them. You could use Lucian Napolitano's Key2Mouse program, to assign keypresses to make the mouse move and click, then program those keypresses to joystick buttons in FSUIPC's "Keys" tab. I don't know any other way. Even the "mouse macro" facilities I've added and am still developing won't work on those. Regards Pete

It's easy enough to find in the drop-down -- I don't know how you missed it: "Autocoord toggle". There's also separate "on", "off" and "set" versions. Pete

Two questions in one, there. First, yes, with the GFDev.dll driver correctly installed, or added to the Modules folder, FSUIPC will recognise buttons and dials on recognised GoFlight units. There's no special "tab" or options menu for GoFlight, if that's what you are expecting -- the buttons and dials will simply be recognised and assigned a joystick/button number in the normal Buttos and Keys tabs in the Options. This is described in the User Guide, which is worth perusing. You will see that the dials on GoFlight units are normally seen as 4 buttons, fast ad slow in each direction. Second, FSUIPC cannot operate functions it doesn't know about, at least not directly. It knows about all those built into FS, and many built into Project Magenta. Whether other add-ons can be so programmed depends on them. If those functions are assignable to keystrokes, then you can first make sure the keystrokes work from the keyboard. When you are happy they work fine, program them to your GoFlight units via the "Keys" tab in FSUIPC options. If you are talking about the 737NG overhead (the PMDG aircraft I tend to use), then I think none of the overhead gauges are programmable for keyboard and you have to resort to using the Mouse. There are two ways around this, one of which is available now and reliable -- using Luciano Napolitano's "Key2Mouse" program to allow you to assign keystrokes to mouse positioning and clicking operations -- and one of which ("mouse macros") I've been working on only this last week, and has reached trials stage in the current interim versions of FSUIPC (3.806 and 4.266, in the Downloads announcements above). Interestingly enough, apart from the "APchart" application, already supported through the supplied mouse macro file in those downloads, the FS9 PMDG 737NG overhead is my current main test vehicle for the more advanced mouse functions. I do have a working macro file for a specific version of the PMDG 737NG. The risks are that some of the mouse actions need code offsets which MUST match exactly the code you have installed, else they will almost certainly crash FS to the desktop. Unfortunately, as yet, I've found no way around this risk. That said, however, if they work (i.e. if the macro file corresponds correctly with the installation of the add-on you do have), then they seem to work well, and reliably. At present I have the initial version of this macro file under review in PMDG, to make sure I am not violating any copyrights. I don't think I am, but except for private tests I cannot at present release the files publicly. I am also still looking for ways to eliminate or at least reduce the risks of crashing FS when using mismatched macros. Regards Pete

I've done this in version 4.266, now downloadable via the FSX Downloads announcement above. Regards Pete

Okay. Thanks for letting me know. Good luck! Pete

Did you find time yet for this? I've been trying to make Brakes cause a problem here now for quite a while, with no success. I assigned them and calibrated them exactly like you. I also went all the way through the code lookng for anything odd which might make brakes different from any other assigned axes -- there isn't. So I'm still at a loss. One more thing in review. When I analysed these entries in your log: 39.95232 [ 1, 2383]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-16383, GroupID=1, Flags=16 < 39.95234 [1] Event: Group=2 EventID=66387 Data=-16383 > 39.95235 [ 1, 2384]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 39.95237 [1] Event: Group=2 EventID=66388 Data=-16383 These are two events setting Left (66387) and right (66388) brakes, respectively. no error, perfectly good. They re-occur regularly without problem. However, much later (3 mins 42 secs): > 222.61162 [ 1, 11209]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 222.61164 [1] Event: Group=2 EventID=66388 Data=-16383 > 222.61165 [ 1, 11209] < 222.61166 [1] >>>>> EXCEPTION=2, SendID=11209, Index=0 <<<<< Unrecognized Data Received. [ 1, 11209] I assumed that all these lines were referring to the one exchange, number 11209. But they can't have been. The "Event" which is logged IS the result of the "TransmitClientEvent", so it is okay. It looks like SimConnect.DLL then transmitted a bad block to FSX, which bears the same sequence number (11209) but has no valid type (this is the "> 222.61165 [ 1, 11209]" line, without expansion as FSX doesn't recognise it. The exception for "unrecognized data" is referring to this second, incorrect block from SimConnect.DLL. Something, and I've no idea what, is causing a problem between SimConnect itself and FSX. Why this should only occur when you have brakes assigned directly in FSUIPC4 I've no idea either, but I've now also noticed something very different in your SimConnect log to mine. There are many many Brake operations, i.e. > 1244.78564 [ 1, 56858]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-16383, GroupID=1, Flags=16 > 1244.78567 [ 1, 56859]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 These are occurring regularly even though the values being sent are the same every time. This shouldn't be happening -- FSUIPC4 ignores successive identical values, it only sends new ones when they change (although, for brakes, it always sends the pair even if only one changes). I'm thinking this is jitter on the axes, somehow being detected BEFORE I calibrate to the range needed. I'll have a look at that -- maybe I should also eliminate equal final post-calibration values. However, since most of the values are -16383, i.e. brakes off, I would like you, please, to set a proper null zone when calibrating your brakes in FSUIPC4. In other words, go back to the configuration which was crashing, but recalibrate so that you press the brakes a little, to get them off the stops, before clicking the minimum set button. The FSUIPC instructions for calibration does advise always to set a null zone to avoid jitter problems. Incidentally, one of your other axes (the Rudder, in fact) is also jittering, this one quite badly: > 1244.73518 [ 1, 56852]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=266, GroupID=1, Flags=16 > 1244.73526 [ 1, 56853]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=399, GroupID=1, Flags=16 The value seems to be 399 correctly, but that 266 value is recurring every few seconds. Is this your feet jittering on the rudder? If not, maybe you should consider trying a different USB port for it? Meanwhile, I'll look to see about reducing the number of identical successive transmissions to SimConnect. Regards Pete

Tell me more. Does Ctrl+Alt+4 work on the keyboard? Alt is a very difficult Key to use, because you have always to be sure to press it first -- if you do not it invokes the Menu instead. I suspect that FSUIPC issues the Alt first even if you pressed them the other way. FSUIPC has a fixed order for all the shifts -- it deliberate does Alt first just so that Menus can be invoked. Best to always avoid Alt if possible (I think I say that in the documentation someplace). Is that an ALT combination, too? When you say "nothing", does it Log nothing in the FSUIPC4 log when you enable the Button and Key logging facilities, to check? (See the Logging tab in the FSUIPC options). Please do use the facilities to check your actions. There's a lot there to help you. If you don't understand the logs, show them to me. Also show me the [buttons] section of the FSUIPC4.INI file so I can see your programming of the buttons. If the keypresses don't work on the keyboard, it is either PMDG or your assignments in PMDG. If they work, then if would either be the ALT key problem, or you. I'd need more information to be more specific. Regards Pete