Pete Dowson

Nice. Do you overclock that? I have my i7-975 overclockeed to 4.5GHz, but it is water-cooled! ;-). I've only got 6 Gb memory on mine, but as it isn't running much more than FSX that's more than enough. And it is very fast DDR3 2000 MHz memory. I am of course also running Win7 64-bit. Is it using a serial COM link? My PFC 737NG simulator is linked via an ordinary COM link. I bought a BrainBoxes PCI serial port card to connect it -- BrainBox has had 64-bit Win7 drivers out for over a year now. Otherwise, if you are using a USB-Serial port adapter you need very recently released drivers from the appropriate website. FTDI do most of the chipsets used in those things and their drivers work okay now, but they didn't a year ago when I first changed to Win7 64. It really is not worth going back to 32-bit. Just get the correct 64-bit drivers and go back to Win7 64. It really won't be anything to do with any software of mine. There's absolutely no difference in FSUIPC or WideFS on 32- or 64-bit systems. The files you show confirm everything is working fine. Regards Pete

Yes, of course. FSUIPC offers the same facility for normal joystick and all GoFlight buttons, knobs and switches. Assignment in FS is to a control. Most easily accessed controls in FS are pre-assigned to keypresses, by default. Yes, of course. But what I don't understand is why you don't just assign the buttons or switches in FSUIPC's "Buttons & Switches" tab directly, instead of going through the rigmarole of having GF send keypresses and then FS or FSUIPC converting them into FS controls. No, because in the FS simulation such a selection would do nothing. It isn't really simulating ignition as such, so continuous ignition (CONT) or in-flight restarting (FLT) would be the same as normal starting. you might as well assign "CONT" and "FLT" to the same starter as "GRND". Unless I've made a mistake in my support for the MESM you should be able to assign any of its switches to any controls in FSUIPC's lists, or to any keypress (but there is no built-in FS simulation of jet ignition coil selection). I've not been able to test FSUIPC with the MESM, and no one has so far volunteered any information on whether my support works. I'm just a bit confused by your wanting to use GF's keypresses instead of programming the switches directly in FSUIPC. Is this because you've tried and it doesn't work, or is it something else? Regards Pete

I added support for that a while ago in FSUIPC, but as far as I know it's never been tested. I haven't seen one. Really? doesn't GF software support it out of the box? Surely they don't expect every purchaser to buy FSUIPC as well? If you have a registered install of FSUIPC, have you tried simply programming directly? I'd be interested in any feedback. Which aircraft? Those aren't really implemented very fully in FS itself. Strange. I don't understand that. if they are keypresses in GF software, what would you re-do them in FSUIPC? The magneto switch you refer to is the Cessna prop starter switch. FS does not simulate separate jet ignition circuits. And for its jet starter it only has start and off (equivalent to ground and off for the 737). If you are using the default FS aircraft you can ignore the ignition switch. What you do with the other depends on which version of FS you are using. The FSX jet starter is a little different (due to an FSX bug I think). Regards Pete

Can we please PLEASE get this clarified? When you reported this too me days ago and I asked for a log, you showed me a log of a successful FSUIPC flight session lasting over three hours and terminating aafter 10:30 in the evening. Your message was timed in the morning. When did you do the restore? Before you went to bed, or after you got up? I still cannot understand the sequence. Please could you review this thread and make sense for me of all this? I'm desperately trying to help you, but you seem to answer one question per day and it isn't easy figuring it all out. Right. Those aren't logs, but control files for the loading of your FSX add-ons. You have all these add-ons loading at the same time as FSUIPC: HeliTraffic2009 Object Placement Tool Panels ang Gauges (Simpropace) Level-D Simulations FS Recorder FS Recorder Module FSUIPC4 Note that you are loading TWO FSRecorders, not one. That could be a problem in itself. One is C:\Program Files (x86)\FS Recorder for FSX\FSRecorder_FSX.dll the other is C:\Program Files (x86)\FS Recorder for FSX\RecorderFSX.dll I doubt both of them exist, but check and delete the section which isn't relevant (or simply don't reinsert it). Also you are loading, as an EXE AICarriers One of these is conflicting, probably because of the Trust bug in FSX. The first test to do is to rename both DLL.XML and EXE.XML to something else (eq DLL.XMX and EXE.XMX), then re-run the FSUIPC4 installer. That will create a DLL.XML with only FSUIPC4 being loaded. Run FSX and check it is okay. Then add the other stuff one at a time, checking each time. One easy way to do this is to insert the sections from the renamed files one at a time. Insert then before the final line, the one saying For HeliTraffic, insert this: HeliTraffic2009 False False C:\Program Files (x86)\Heli Traffic 2009 Demo\HeliTraffic2009.dll For Object Placement (if you use this -- it's part of the FSX SDK, for developers), insert: Object Placement Tool False False C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\Mission Creation Kit\object_placement.dll and similarly the "Panels & Gauges" too from the SDK: Panels and Gauges False False C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\SimObject Creation kit\Panels and gauges\Simpropace.dll and the Level-D support: Level-D Simulations False False Modules\LVLD.dll The FS Recorder (change the name for the other one. Only choose one): FS Recorder False False C:\Program Files (x86)\FS Recorder for FSX\FSRecorder_FSX.dll When you've sorted the DLL.XML out and tested, just rename the EXE.XML back to what it should be to re-enable the AICarriers application, if you want that. Regards Pete

It isn't really an FSUIPC function. The things Windows calls "Buttons" are merely things it detects as pressed or not pressed. The electrics involved are simply a connection made by the button. Since windows can detect a button being pressed or released (because the "pressed" indication comes on or off), whether the button is held pressed by a finger or by the spring or latch in a switch is not only irrelevant, but unknown to it. A true momentary switch which only gives a quick on-off pulse is rare in this area, especially if the software or hardware is polling, because the short-loved pulse may be missed altogether. Not only that, but it is less useful than an ordinary press-to-make button because you cannot use it to indicate things to be done whilst it is held pressed, like repeating an incremental action. Rotaries tend to produce pulses, and turning those too fast will create many short pulses many of which would be missed. Pete

Of course. When assigning, FSUIPC will only see them when they go from "off" to "on", but you can program both the on (= press) and off (= release) action just the same as for push buttons. Same for rotaries that send "on off on off" pulses. Pete

:o The calibration facilities, which include mention of the sync options, are a small fraction of all that. The contents page will tell you which page to go to. Pete

I repeat. The physical alignment is up to you, it is not a software function. If you mean "can I hold them all in one hand and move them together", I don't know, as it depends on how wide they are and how big your hand is, doesn't it? If you mean can you get the same values from them at different points, then, yes, you can sync at a number of points along the travel, however many you need. Please browse through the FSUIPC documentation which is free to read and you'll see what facilities there are. Pete

Calibration is a software process. It's not related to the size, height or shape of the levers. It's just a matter of saying "this readable position means X, that readable position means Y". Pete

FSUIPC3 supports 6 axes on up to 16 joysticks, so that's 96 all together. This is a limitation of the Windows "joy" API. FSUIPC4 was written to use DirectInput, which supports 8 axes on each joystick. Should be okay. Each joystick controller will presumably have its own connection to the PC and look like a separate device. You could have 16 such boards with 6 analogue axes on each, as well as a 360 degree POV and 32 buttons each. Regards Pete

Thanks for the info -- I'll certainly check it out! Pete

Which is just as it tells you in the first few lines of the document supplied with the program. I really can't understand why you should criticise that. I can't think of a better place to tell folks what they get and where to find it than at the beginning of the only document actually included in the ZIP. I am certainly not in favour of plastering everything onto people's desktops which are subject to enough nonsense and clutter as it is. I've lost count of the number of times I've had to delete the Adobe Reader icon off my desktops which unnecessarily appears every time they think it necessary I receive another update. Regard Pete

That'll be because you are running an old, unsupported version. Please keep up to date. If you aren't sure why, please review the Announcements at the top of this Forum which I assume you must have somehow missed? Regards Pete

Why do you arm the spoiler on the ground? Seems to me quite dangerous. As you accelerate for takeoff the bouncing on the gear switches could surely activate the spoilers in any case, with disastrous consequences? The mouse macro facility doesn't know anything about screen regions. It simply traps the place in the Gauge code which is called when you operate the mouse click, and sets things so it can call that code directly. No, because I've no way of using the coordinates in any case. As I say I am calling the resulting code directly, I am not emulating a mouse click. Additionally it does spoil the whole point of the mouse macro system which is entirely independent of the screen -- you don't even need the relevant part to be visible. What you want to do is already very capably done by "Key2Mouse" by Luciano Napolitano. You program your button or switch to send the keystroke to move the mouse and click the button. Regards Pete

Not my call, you;d need to ask the vendor, but I guess it was an introductory offer, really, for folks who'd bought version 3 AFTER FSX was released, possibly not realising there was a new version of FS now available.. I thought it was only for 6 months -- is it still running? That surprises me! Pete

Not really. There's no way I can generalise a check from that. Thanks anyway. I think you just have to stick to the unchecked method (i.e. ????) for such cases -- but take care to re-generate the macro if you ever update that aircraft. (You'd need to re-generate them all in any case then, but the others wouldn't crash FS, but only log the error and not work). Regards Pete

Right. But before I go into that, can you please tell me whether you really still have a problem or not, because the run-time log your showed was for a successful 3-hour flight session with FSUIPC running well, as I explained. You first post, mentioning the problem, was at 11:48 in the morning of the 14th (not sure if that's your time or mine), and FSUIPC was loading fine at 10:30 pm the previous evening (though again I don't know if these times refer to the same zone as I don't know where you are). So, what did you change, what did you add, between those two times? As I said, checking that will undoubtedly be the quickest way to a solution for you. Else the process of elimination could take days (or weeks at this rate, with you only acting on one question or request per day!). If you do, indeed, still have a problem, have you yet tried re-running the FSUIPC installer as I requested? If not, please please do that first and re-test! Else we're both just wasting time. Now to the log. This shows your DLL.XML and possibly your EXE.XML files are in this folder: C:\Users\Home\AppData\Roaming\Microsoft\FSX Please find those two files there (DLL.XML for certain, EXE.XML possibly, depending on what you've installed). You can either load them into a text editor (e.g. NotePad -- not WordPad), then cut and paste them into a message here, as you did with the logs. We'll go from there. It will still be easier and more likely to succeed with less hassle if you could remember what you did in those few hours, apart from sleep that is! ;-) Regards Pete

That's an old version, no longer supported. You need 4.60 or later if you want support. FSUIPC is not assigning anything. The name it uses is the name specified in the Aircraft.CFG file. If you have multiple liveries in the CFG file then naturally they'll have different names and whether there are numbers or not is up to whoever compiled the CFG file. For sanity you should really set "ShortAircraftNameOK=Substring" and use a portion of the name which is common, or change over to using Profiles which are much easier. Regards Pete

I managed to load it into FS9 and take a look, but that particular routine is a mess. Rather convoluted. Either the table entry pointing to it is constructed dynamically, so the entry actually changes (in which case there's no solution), or it is some result of the relocations or de-compression. To try to help I've added a facility to make FSUIPC bypass the check and execute the code in any case. I won't publish this generally because it is rather dangerous (possibilities of executing wrong code at random, but more likely a crash). I've added a trap for normal exceptions so it may save anything so drastic (it would log an exception, the same as it now logs the mismatch). Download this replacement FSUIPC.DLL and put it into your FS Modules folder: http://fsuipc.simflight.com/beta/FSUIPC3985.zip Then To make it take this course, edit the macro file. Find the part reading X188bf0*X8b12,31 and change it to X188bf0*????,31. The 4 ?'s tell FSUIPC to bypass that check. Let me know if this helps. I think it has a 50:50 chance. Regards Pete

Unfortunately it looks like it is compressed and/or enoded in some way, so I can't get into in using my normal tools. I'll have to try to assign it as a Gauge in an aircraft so it'll get loaded into FS and de-compressed/decoded first. I cannot promise that I will succeed in finding any solution. Unfortunately this is also the way with many default FS gauges -- it isn't only add-ons which have such problems. Designers don't always think about the needs of those wishing to improve simulation realism with hardware. You might see if the switch settings are stored in Local gauge variables (L:vars), because, if they are, then writing to those, via a normal macro or a Lua plug-in, may just do the trick. There are some "sticky" threads at the top of this Forum about all this, mostly contributed by 'guenseli'. Check the one entitled "Tutorial: how to get LUA Vars or commands out of FS ". There's also one about the MD11X (the FSX version) which might be partially relevant. If I get anywhere with the GAU file I'll add to this thread, but it might take a while. And even if I find a solution it might not result in an updated FSUIPC version for a while as I'm in the midst of other stuff at present. Regards Pete

I don't know -- FSUIPC only logs what it sees being passed through the FS controls system. If those were the parameters created by using the mouse on the switch then the same values sent by other means should have had the same effect. Regards Pete

There is no way FSUIPC can introduce any "flutter". If you really mean erratic behaviour then that is almost always due to dual assignment. If you assign in FSUIPC you must NOT also assign the same axes in FS. Sounds like you need to figure out what you changed. Try using FSUIPC's axis logging, That might show you what is going on. If you run FSX in a Window you can enable the FSUIPC console log so you can see things in real time, on screen. If things are "fluttering" without you touching anything then it'll be hardware or drivers. If you get two conflicting outputs every time you move anything it will be dual assignments. Pete

This is only because the process requesting data does it by sending a message. That goes into Windows' message queue, and FSUIPC gets to it in turn. There's certainly nothing really clever in that. Sorry, I can't really advise on so little information. If you are processing requests via one channel you need a way of queuing things. I leave that problem to Windows. Regards Pete

Ah, yes. Sorry, my mistake. Ahthen somehow the Gauge is different each time it is loaded. There's a safety check -- it compares the two bytes at the given offset with those in the macro to make sure the version of the gauge hasn't changed since you made the macro. This check prevents my code jumping into a gauge at some random place and causing havoc, crashes and other nasty events. 145767 Macro: mouse action="PMDG_MD11.GAU":X188bf0*X8b12,31 In this case the two bytes at offset 188bf0 were not equal to 8b12. But the other two were okay: 145767 Macro: mouse action="PMDG_MD11.GAU":X188c10*X8b90,31 145767 Macro: mouse action="PMDG_MD11.GAU":X188c30*X8b90,31 which is rather strange. I can only think that the code at 188bf0 has an instruction which contains a full, not relative, address starting in the 2nd byte, and the Gauge is loading in a different part of virtual memory. I've not seen this happen before at all, and I'm not sure how it can be dealt with. Perhaps you could ZIP that gauge (PMDG_MD11/GAU) and send it to me as an attachment. Send to petedowson@btconnect.com. I'll see what the code looks like and try to work out an alternative cross-check which i can include. Otherwise I'm afraid that might be a function which isn't really susceptible to this treatment. There's only one FSUIPC.INI file, it's the one next to FSUIPC in the FS Modules folder. It contains all of your FSUIPC settings. What other INI file is there which is at all likely to do that? I don't think there could be any ambiguity! But it doesn't matter now. Regards Pete

And what is the version number of that "latest version", please? I always need version numbers! I've lost count of the number of times falks have said "latest" when they mean the latest they've seen, not the actual current version. Sorry, I've no idea. Did you test the macros when you made them? Without any specific information, like the INI file (which is where all your settings are saved), I cannot really comment. You could of course use the FSUIPC Logging to see what is happening -- use Button logging. But do please double check the FSUIPC version number first. It should be 4.60 or later. Regards Pete