Pete Dowson

Is that what the 'bug' is? No one has actually explained it to me yet. In that case it is a possibility! Sorry to have disbelieved you! Well, the airborne aircraft are transferred from the airborne TCAS table to the ground TCAS table pretty soon in any case. Let me check the code: The actual distinction between airborne and ground, for FS2004 only, is currently: If state = 138, "Taking off", then the "on ground" flag is used. If state is one of these, it is on the ground: 128 Initialising 129 Sleeping 130 Filing flight plan 131 Obtaining clearance 132 Pushback (back?) 133 Pushback (turn?) 134 Starting up 135 Preparing to taxi 136 Taxiing out 137 Take off (prep/wait?) 143 Rolling out 145 Taxiing in 146 Shutting down and it is airborne in these states: 139 Departing 140 Enroute 141 In the pattern 142 Landing 144 Going around AHA! I see a bug! There's a typo! The first check above should be: If state = 138, "Taking off", or If state = 142, "Landing" then the "on ground" flag is used. The Landing, like TakeOff2, is a transitional state and I need to determine it by the on ground flag. In the code the second comparison is actually for state = 114 which doesn't even exist! This could have been fixed months ago if only folks had reported the details. Your suggestion is the first which even mentioned to me what the problem actually was. Thanks! I have fixed it in the code here and it will be in the interim test version I will be uploading here in a couple of days. Apologies again, Regards, Pete

Right, but you do need to get it all working properly before FS can use it then. My software certainly doesn't come into it till it is working in FS. I'm afraid I'm really not the person you ask about EPIC any more, especially the USB version. I think it's all to do with the way you define and declare things in your EPL but I never actually figured it out and haven't touched it for years. You'll need to seek help from the EPIC folks. Sorry. Regards, Pete

Why would that cause a problem for FSHotSeat? All that does is move some TakeOff2 and maybe "Landing" state aircraft from one TCAS table into another. The FS "on ground" flag goes through a bit of on/off indecisiveness when aircraft are bouncing about on the runway. Regards, Pete

In that case any button programmed for the PMDG will operate according to that section, not the general section. At least that's how it is designed to work. The general section provides the default action when there's nothing for that button in the aircraft specific section. But all the entries are actions for the one button, 0,0, so, unless I've made a big error someplace, none of your lines 24 to 28 in the general section should work when the PMDG aircraft is loaded. If it is not working like that I will indeed have to look at it and fix it! Well, apart from the fact that it shouldn't anyway (see above), how can you tell? It is exactly the same as line 2 for the PMDG aircraft, look: Okay, thanks. I am deep into something else at present and must get it done. I am trying to make ready an interim release of WideFS, FSUIPC and a new package "GFdisplay" by the end of tomorrow. Then I have a couple of days of family stuff to see to, but I'll be ready to have a proper look at any problems at the weekend, or shortly thereafter. In the interim version of FSUIPC which I'll be uploading here (check announcements) there will be extra logging for button programming. I've had to add it to help with GFdisplay programming. Maybe this will help resolve your problems too, or identify the bugs more exactly. Well, the only thing I can think of it to have that button also programmed to Repeat with an Offset Byte Increment control, adding 1 to a free offset in FSUIPC (66C0-66FF are available for general user application). You'd have an offset test condition for the byte to get to a certain value, then do something different. if the repeat rate is reasonably predictable that should do the trick. In other words something like: 100=B66FF&C0=0 R1,1,Cxxxx,0 ; Your main initial control repeated till 66FF >= hex 40 101=R1,1,Cx110066FF,x00400001 ;Increment 66FF on each repeat till hex 40 102=B66FF&C0 R1,1,Cyyyy,0 ; Your different control after n seconds 103=U1,1,Cx010066FF,x00000000 ; Reset count to zero on button release You'd have to adjust this for timing. Incrementing Byte 66FF by 1 on every repeat till it gets to 64 (hex 40) will only give 5 seconds if the repeat rate is somewhere close to 12/sec. Unfortunately this won't work with the current FSUIPC because I found a bug in the offset condition testing. Strange no one reported it. It is fixed in the version I'll release here soon. Regards, Pete

I never saw it. According to the records here, the message you sent earlier was the first and only one from you in the whole set of Simflight forums! Maybe, if you had your private key and email showing in the graphics it was deleted quickly by the forum administration. It is strictly against all the conditions to publish these details for others to use. If you send me an email attaching the notification you had from SimMarket I will check the Key here. Send to petedowson@btconnect.com. I should warn you that in the 18 months this system has been operating, virtually all cases of keys being rejected have turned out to be because of incorrect entry of the details. I notice that you say: but you don't mention the name and Email details -- they too must be absolutely exactly the same as in the notification email. Did you cut and paste those too? All I can do is check that the details in the original email are self-consistent. The rest is up to you. Regards, Pete

Hmmm. that's strange. Is this when the PMDG aircraft in question is loaded, or another? I think, logically, if the current aircraft is the PMDG 737-700 then, since all of the above actions are for button 0,0, then none of the entries 24-28 should work. They should be completely ignored in favour of that button's programming for the active aircraft. On the other hand, if the current aircraft is not PMDG 737-700, none of the section so headed is even loaded by FSUIPC, so that should have no effect on the general part at all. Can you clarify please? Also the U stuff. It certainly should be. If there's a problem there, it's a bug, and I'll need to fix it. But first I need that clarification. Then I need to boil it down to the simplest reproducible case. I don't provide those, PM does. All FSUIPC does it toggle the bits PM tells me about. What exactly takes 3 seconds? Just incrementing/decrementing by 1? There's a problem there somewhere if so. It's really a question for the PM team I suspect. I must admit I am rather disappointed at the speed of reaction of the PM MCP to most of the offset controls it supports. It seems to have got slower and slower as more things have been added. I think the main concentration these days is supporting hardware MCPs directly connected, like the Aerosoft, CPFlight and PFC MCPs (all connecting by COM port). It's fine then. Maybe you can change its cycle time to make it look more often (see the MCP.INI file). Are you running the PM MCP on the same PC as FS? I've always found that's best. The MCP is the hub. As I say, all FSUIPC does it toggle or set a bit (it varies form control to control) in an offset. the rest is up to PM. For PM use, of those, your best bet is CPflight I think, but ask on the PM forum. Go-Flight at present don't support PM directly (it can be done via FSUIPC and a new program I'm working on now). Aerosoft don't make their MCP any more. The PFC one is really super but probably over the top (too expensive) unless you are very serious or very rich. Many PM users seems to be using the CPflight stuff. Regards, Pete

Neither EPICINFO nor FSUIPC normally have anything to do with EPIC (or any other) axis inputs. Axis inputs go direct from EPIC through Windows to FS. You need to check first whether Windows recognises them as correct axes (in Game Controllers), then make sure they are correctly assigned in FS (Options-Controls-Assignments). Make sure that the sensitivities in FS are at maximum and the null zones at minimum or close. Don't try calibrating in FSUIPC until they work in FS. Incidentally, having an aileron trim axis is an odd selection if you are only connecting five axes. Shouldn't that be elevator trim, which you do need all the time? You'd only need to change the aileron trim in cases of aircraft damage or asymmetric thrust. Regards, Pete

Sorry, I'm lost. I see nothing else from a "wild ol' dog". What question was it and when did you ask? Is there a thread about it somewhere here? This seems to be the only message you've ever posted, anywhere in SimFlight forums. :? Regards, Pete

Yes. In the FSUIPC.ZIP (get it from http://www.schiratti.com/dowson if you were supplied with only a bare FSUIPC.DLL module) you will find a User Guide, readable in both Word and Acrobat versions. There's a complete section on each of the option pages in FSUIPC, including Visibility. Regards, Pete

Of course AV400 is not actually an NMEA protocol. :wink: Okay, thanks for the update! Regards, Pete

This is all stuff I've virtually forgotten now. but the EPIC95 package with the VXD is still available at http://www.schiratti.com/dowson, where it has always been, and provides not only the VXD but also the registry files to get it all properly entered into the registry. AND documentation! It simply sounds like you've not installed the VXD correctly with the registry additions needed. Go get the ZIP package and check the documentation. After that, I'm sorry but you'll need to contact the EPIC makers, R & R (Ralph Robinson). regards, Pete

I think the registry points to GFconfig. The GFdev.dlll file is in the same folder as GFconfig. Regards, Pete

Not easily. Unless the GoFlight installer made the Registry point to the X-plane folder that older one won't be used. Or overwrite it with the newer one so it doesn't matter? Regards, Pete

I see you have these buttons only enabled for the aircraft "PMDG 737-700". Can you please re-check with a default aircraft instead? You are using FSUIPC 3.45, yes? If not please install that. Then go to the FSUIPC Logging options page. Switch on the Event logging. Test the button again. Switch off the event logging. Look in the log, see if there's a "View Forward" control listed. If the log is short enough, show a bit here (if you are using PMDG it will NOT be short!!). That is also Joystick 0? Or did you pull the first one out? There's nothing really to go wrong with the programming of button release, so I suspect something is interfering with the control instead. Regards, Pete

Further to my last reply, I've looked into this. It is not possible to program a button to send the Print Screen keystroke using the FSUIPC options screen, but you can do it by manually editing the FSUIPC.INI file. The reason is that Windows takes the keypress before FSUIPC can see it, so it can never fill in the box on the Buttons screen. Edit the FSUIPC.INI file and program it there. To make it easy, program your button to make, say, a "space" key press, then close FS and edit FSUIPC.INI. In the [buttons] section look for the line with K32,8 at the end. That will be the sapce. Replace the 32 with 44, the keycode for PrintScreen. This gives you a "normal" print screen -- the whole screen. I've also tried it with ALT (for the current window), K44,24 and this works too, but unfortunately the ALT also brings up the normal FS menu. Other keys which won't be easily displayed by FSUIPC but which may be usable by direct editing include: 19 Pause 20 Caps Lock 27 Escape 144 Num Lock 145 Scroll Lock Hope this helps, Regards, Pete

Yes, that's the problem, which is why it can't be used to program an FS or FSUIPC function. Oh, I see! You actually WANT it to do a Print Screen. Sorry. I thought you were asking whether the key could be used for other things. My misunderstanding. Its list only includes those usable in FS, that's why. I'm not sure if I could make an exception for Button programming (as opposed to Key and Hot Key programming) -- but I'll have a look. If it is easy I'll slip it into the interim test version I am planning to upload here later this week. Watch the announcements. Regards, Pete

Well, the only bottleneck should be the processor on which FS is running. If the "data rate" you are reading is the one displayed in the PM PFD program's graphics display, then, yes, that could depend on the processor on that PC AND on the graphics card there too. But that won't slow down the rest, and it certainly should not slow down the WideFS operations, even on that PC. Your best bet for the PM MCP is still to run it on the same PC as FS. Even more reason to have the PM MCP there. This is with the PM MCP on a Client PC too? There's something odd there then. Are you sure the GoFlight driver (GFdev.dll) is up to date? There's no such symptoms here with any of the GF modules on any system. Check the GF website for a more recent driver package. Regards, Pete

I don't think so -- doesn't Windows see it anyway? Try it and see. Regards, Pete

Well, I don't really know why you persist in misunderstanding (are my messages really so obscure? :( ), but of course you can view it in such a restricted way if you like. You seem to be missing some of the things I mentioned. For example you won't find many of the FS controls listed by FSUIPC actually available in the FS assignments -- as I said there a hundreds there not in FS's list. Of course some don't work and none are obviously documented. FSUIPC gets the list automatically from the FS CONTROLS.DLL which not only includes all those you can assign in FS assignments but also all those that Gauge writers can use in their programming. You did actually use one (Panel Toggle) which is in FSUIPC's list but not in FS's, didn't you? Additionally there are no facilities in FS assignments to, for example, make key assignments different for different aircraft. And of course there are quite a few non-FS controls added by FSUIPC which are actually executed by FSUIPC. You can peruse the FSUIPC user documentation to see those. Regards, Pete

No, not real flying. I did learn to fly for real years back never got a license -- got stopped by my failing eyesight (hereditary retinitis pigmentosa, gradually killing all my rods, or is it cones? Anyway, the peripheral & night vision goes). That's why I do simulation. I'll have a look. Thanks. Regards, Pete

Ah, thanks for the offer -- but I got one straight-away at my usual GPS suppliers! :wink: Does the "Fly" demo come with any maps? Looks like you have to buy a subscription for maps on top? Difficult to tell what sort of European coverage they have from that web site. Regards, Pete

Great! I'm in the UK. I'll see if I can find a source here. Of course, not having the 'a' version, I haven't got any of those, only the road maps (MapSource / City Select). Well, good luck! Let us know when you get anything out of them! Regards, Pete

I have an iQue 3600 (not the 'a' though). It's got a USB sync cable. How do you configure it to send/receive serially as a COM port? I assume its maps and so on are for aviation, and that it comes with some other menu items to set it for NMEA input? Oh, I see. I thought you said you "have the iQue communicating as well."? What was that communicating as/through/to, then? Well, since the socket on the iQue doesn't really have the usual D-type pins 1-9 or 1-25 to "crossover, and since it would be pointless of them to make a cable which connected Receive on the iQue to Receive on the PC, and Transmit on the iQue to Transmit on the PC, it jolly well must be, really. :wink: The only reason I am careful to tell folks to get a null modem or crossover cable is that there are lots of serial cables designed to connect PCs to other devices, and devices which aren't "originators" of signals (DCEs) usually have their serial ports wired as terminals (DTEs), so cables aren't crossed-over. PC to PC links need crossing over because they are both DCEs. (At least I *think* I have these acronyms right -- it's been a long time! :wink: ). Also, many cables which may look right could be designed to be extension cables, and they won't be crossovers either. But a cable with a PC type serial plug at one end and some proprietary thing on the other, as the iQue cable must be, doesn't really have terms like "crossover" applicable to it. Not that I've found. That's why I was asking you -- I assumed it must be something special in the "a" version. The options on the satellite reception screen on mine are only "New location, New Elevation, Preferences, and About". Preferences only contains "WAAS enabled" and "Battery Saver". Maybe yours has more? If Garmin says you can do it, maybe they can tell us how? Regards Pete

Only a few hundred! :wink: (Including the Panel Toggle one, I think!). Also FSUIPC can assign GoFlight buttons, and make both Key and Button programming specific to particular aircraft. And a few other facilities I think, like more key combinations with Tab, Win and Menu used as shifts. :) Regards, Pete

Not arrived yet. Can you re-check? Pete