Pete Dowson

No, no one has ever asked for such a thing. Both the Hot Key and the bit in 310A are just requests to FSUIPC to copy throttle 1 to the other throttles, ignoring their own inputs. Being a simulation thing, not a real aircraft one, I didn't think anyone would have a gauge or indicator for it! Can you explain more about this need, please? Regards, Pete

OkayI'd obviously forgotten a *lot* about EPICINFO. It is indeed quite possible for me to run it and test it (well all except the talking-to-EPIC bits) with no EPIC attached. I'd forgetten entirely -- in fact I remembered later that I'd even recommended this once for non-EPIC users as a way of tracing the behaviour of the assorted Gauge variables. Anyway, it makes everythnig MUCH easier, and it definitely means I can see a future for it, or an equivalent facility possibly built into FSUIPC, for FSX and beyond. I'll just need someone around like your good self to test it on real EPICs for me! . Tracing through the code for the Scaling option you are using I can see why the 32768 bit is being added. The -ve number flag isn't cleared by the scaling code even though, post scaling, the result must always be positive. As far as I can see this error has ALWAYS been there, it is an integral part of the way it was coded way back when. I don't know what you did originally to get around this nor why you remember it differently -- what HAS happened in between, for you? Anyway, I've fixed it (one line) and I am attaching 4.23 -- the first update for nearly 3 years as far as I can tell! Please confirm it's okay for you now. Oh, one minor thing. I think the correct SCALE lines you want should be: PLANE_PITCH_DEGREES=Scale 360,-179,181 PLANE_BANK_DEGREES=Scale 360,-179,181 The RANGE you want is 360 (0-359), and the upper limit of the input is 181 (this is exclusive, as documented, making the max acceptable 180). Regards, Pete EpicInfo4230.zip

I've had a look at the code for this inside EPICINFO, and in fact FSUIPC is not involved at all! Those two variables, like nearly all of those listed for PHs, are obtained directly from the FS PANELS.DLL using the same interface as used by Gauges in FS panels. The only thing I can think of it that you are comparing some results from a much older version of EPICINFO. I do have some changes marked as being done in EPICINFO version 3.893, which affects the conversion of the floating point values I get from FS for these variables (all angles): PLANE_BANK_DEGREES PLANE_PITCH_DEGREES ATTITUDE_INDICATOR_BANK_DEGREES ATTITUDE_INDICATOR_PITCH_DEGREES but currently I don't see how these could affect the scaling. The change seems to have been to normalise the integer result to a value between 0 and 360. I'm not sure how EPICINFO then arrives at what you see. I really am so busy at present, and this would take quite a bit of ancient code analysis for me to figure out, especially without my old EPIC ISA boards usable (I've no PCs with ISA slots these days). I do have a USB EPIC here someplace, but I really never got into programming that so that would take even longer. On second thoughts, maybe I can run EPICINFO with the logging and so on and no EPIC card? I don't remember. I'll check that out when I get a chance. My problem still is making enough time to embark on something like this. I need a space of 2 or 3 days to suddenly appear. Very difficult at present. Is it really possible that you only recently upgraded to EPICINFO 4.22? Regards, Pete

GPSout needs a COM port number or name. I've really no idea how USB serial ports look, thouh there is one example someone gave me which I put into the TXT file documentation (did you look?) -- some thing like Port=\\\WCEUSBSH001 though I suppose this might be different for different devices or serial/USB drivers. The other thing is that, for most PDAs, as soon as you plug them nito the PC they get taken over by the automatic synchronisation software you or Windows installed to handle them. Somehow you would have to stop all that running too, to free up the port for others to use. I don't know how to do that. I never ever managed to get my PDA linked up, so you are not alone. Regards, Pete

1. FSUIPC 3.0 is far too old for me to support (3 years now). The current version is 3.65. Please review the announcements at the top of this Forum. 2. I very much doubt that any FS2002 dated program will have correct access to FSUIPC 3 in any case -- does it say in its documentation that it works with FS2004? If so, then they presumably have an access key for it. If not, then you have no option other than to buy a user registration for FSUIPC 3.xxx, or maybe to try to find a very old copy of FSUIPC (I think 2.975 was the last one for FS2002, nearly 4 years ago). 3. Your proper recourse for support for any third party application program is to the suppliers and/or makers of that progam. I'm afraid I couldn't possibly even consider supporting all of the thousands of add-ons out there that may or may not use FSUIPC, let alone those from years ago. Sorry. Regards, Pete

It most certainly sounds like it, yes. If you want me to check, try again, be sure to close FS after the error, then Zip up the FSUIPC.LOG and FSUIPC.KEY files from your FS Modules folder and send to me at petedowson@btconnect.com. Regards, Pete

No, because FSUIPC is not hardware dependent -- it deals with FS controls, not with hardware controls. Also there is no way I could possibly become familiar with all the hardware which could be connected to FS -- in this case, for example, I have no CH devices and I've never heard of that Vmax device you mention. Check the FSUIPC user guide. There is a step by step guide to calibrating FS joystick controls in FSUIPC, including both the generic single throttle (which, like the FS ones, has no reverse range), and the multiple separate throttles which, in FSUIPC, are made to have reverse by introducing an idle "centre" -- the "centre" which should be calibrated around your idle detente. It also expalins how you can map the one to the others should you be unfortunate enough to have only one throttle lever (which i would assume you are not). Regards, Pete

I'm afraid you've come to the wrong place. WidevieW is by Luciano Napolitano and is presumably supported on his own site. Please check the documentation for it, I'm sure it tells you where to go. Regards, Pete

Sorry, I think they must've meant someplace else, like the cockpit builders forum, somewhere near the top of the simflight forums list. I wouldn't know where to start -- this is mostly about software here. Pete

The methods used to provide the inter-process communication, between your program and FS, require access to assorted bits of the Windows API. Your program may not actually need to have a Window (or if it does it can be an invisible one) -- maybe it can be a "console program" -- but it certainly needs to be loaded by windows and have access to Windows APIs. Including the Windows header will allow that. But by all means, try just defining DWORD before calling up my header. Regards, Pete

Yes. The error refers to Line 37. Did you look at line 37? It is this: The data type "DWORD" is a Windows data type. This won't have been defined -- you have not even included the Windows header -- since, to access FSUIPC, you must compile a Windows program, this is essential. You could of course define DWORD yourself (it's an "unsigned long" in a 32-bit system), but you will probably fall foul of other things later if you do not include any Windows definitions. Please see if you can find a book on Windows programming -- for C the one by Petzold is good, almost essential. Once you can write a Windows program I'm sure FSUIPC interfacing will come much easier to you. Regards, Pete

Hmmmvery clever! Thanks. you are most welcome. Regards, Pete

No, it's okay. I'll sort it when i understand it. I am thinking of incorporating everything into FSUIPC for FSX and beyond (WideServer and GPSout are already absorbed), or at least making the other DLL's mere satellites (depenfing on size). I'll be looking at what I might be able to do for EPICinfo in due course. it is just in testing I will have some difficulties now. Pete

Ah, maybe that should have been reviewed with each release of FS. Sorry. Not having used EPIC stuff since FS2000 makes this quite difficult for me. I am pretty sure I wouldn't have used the term "original" for something derived. I would really need to compare the results from FS2002 and FS2004 to offer an sort of comment on this. Sorry. Have you removed FS2002 already? Regards Pete

Good news, thanks! Pete

Assign them and test them on a default aircraft. If they work there, you have succeeded. If they then don't on a third party aircraft it is likely that they have replaced FS's A/P with their own and not bothered to support the same controls. I'm afraid in that case you will have to check their documentation to see if they have any alternatives other than the mouse, such as keyboard shortcuts. Regards, Pete

Maybe we could have been more productive here if you'd pointed out where your concern lay initially? ;-) Anyway, I'm not sure how you work out that you are getting negative numbers. The original values in the log extracts you showed were all positive, look: Let's take ine if these and work out what the scaling should theoretically be doing according to the documentation: "orig val=211.348", and your SCALE is "361,-179,180" 211 is over the max of 180, so set it to 179 (max-1). Then (361 * (179 - -179))/ 359 = 360 or pretty close Actually, this applies to ALL of those values over 179, so they should ALL have been returned the same, as 360. That's presumably a bug in EPICINFO (and presumably a very long standing one), but I'm certain it isn't what you are asking to be fixed here -- after all, why would you want all values 180-359 set to 360?. Somehow you seem to be asking for a value, returned by FS, which is in the range 0-359 already to be scaled to a range of 0-360not sure why. Maybe FS2002 returned the vaues -179 to +180, not 0-359? You seem to forget that I haven't changed EPICINFO between version 4.22 which you say was okay, and version 4.22 which you say is not? So why point at EpicInfo? I think you need to do the same logging again with FS2002 and compare them. Meanwhile, for FS2004, try scaling 0-359 to 0-359 (or, in other words, don't bother with the scaling?) Regards, Pete

FSUIPC does work to a certain extent with CFS1, and a bit more with CFS2, but I'm afraid I can't tell you whether enough will work for your needs -- you'll need to try it. If you mean CFS3 then I don't know anything which works with that -- it was a complete departure from FS. Pete

Yes. Use FSUIPC logging, PLEASE? I cannot debug your program step by step. I don't even know VB and you've shown none this time in any case. You need to do your own debugging. It is part of the joy of programming. There are enough tools around surely. Apart from the Logging, there's FSInterrogate where you can look at every byte, and surely VB must have a debugger? Offhand I have no idea what "F096" should be in any case. The TCAS tables contain an array of structures. Treat them like that. Regards, Pete

I can see two things wrong, easily, and I don't know VB at all! First you say you want to read F068, yet you specify F000! Second, I'm pretty sure that VB expands &HF000 to make a 32-bit value FFFFF000, which is certainly not what you want. I seem to remember someone saying you needed to postpend another & to stop it doing that, so try &HF068&. Ouchthat's too much VB for me. I wouldn't know if your TCAS datatype matched my C structure at all. However you can check: Please use the FSUIPC logging facilities to see the results of your endeavours. I'm sure you'll be able to figure it out from that -- use the IPC Read and Write logging options and the FSUIPC Log file will show you what your code results in across the interface. Well, the documentation does explicitly say that you cannot read back what you write there, doesn't it. ;-). Also, don't forget that the target is eraed if you don't keep replenishing in within 8 seconds -- use a 2 or 3 second time at most to be safe. Regards, Pete

Well, if I can remember enough I can. I can't test anything here though. Since EPICNFO is the same both times, and certainly FSUIPC's pitch and bank must be the same for FS2002 and FS2004 else things like the PM AI display would have gone wrong, I can't see where any of the changes could have affected anything ... I had to read the docs to work out what that was supposed to do! Why 0 AND 360? Shouldn't you only have one or the other? Shouldn't your 361 be 360? Let's see: Original value = 0, which is 179 bigger than your minimum. According to the docs: val you get = (Range * normalised value) / (max - min) Your range is 361, your normalised value is 179, your (max-min) is 359, so 361 * 179 / 359 = 179 to nearest integer. Which is what you got. Taking one more, for 'proof': 361 * (176.824 - (-179)) / 359 = 357.806, or 357 as an integer. All the others work out correctly as well. As far as I can see this is all exactly and perfectly as it should be according to what you've set. Your values are all 0-360. What precisely is the problem? Regards, Pete

No, I wan't saying that! Naturally I'd assumed that you had actually tried using FS, otherwise why even think of FSUIPC? If you've not actually used your controls with FS yet, do that, assign the axes, test them out, don't use FSUIPC at all. Then if it all works and you are happy, why use FSUIPC? I'm sorry, I misunderstood entirely your original question it seems. Regards, Pete

Yes, and FSUIPC is totally independent of hardware in all the items you mention simply because its "joystick Calibrations" are NOT dealing with joysticks as such, but with the controls you assigned in FS for those joystick functions. The calibrations and modifications are done AFTER FS has read and done its thing with the joysticks. This is another reason why there's no hardware documentation -- it really has nothing to do with hardware! The "Axis Assignment" facilities (on the "Axes" tab) recently added to FSUIPC are a different kettle of fish, but you need none of that to do what you want. Pete

Well, you may be lucky and find someone here who can help, but it is really outside of the scope of this Forum, and something I know nothing about. But here are some initial references: For the aircraft "container" details (Aircraft.CFG, and folder structure) you should download the Microsoft Aircraft Container SDK (I think it is called that). For panels there's a Panels SDK I think. Both from Microsoft's FS website. But for actually constructing the visible model and the textures, and making a flyable AIR file for its performance, I am really at a loss. Possibly there are other Fora which will help you with this? Regards, Pete

I don't get such problems, but then I have a very fast system with a fast graphics card. You need to adjust the cloud draw distance (actually letting them draw when they are further may even help, oddly), the cloud density, and, above all, 3D clouds only -- those ugly 2D clouds are drawn suddenly ("popping up") in a ring around the aircraft and cause awful stutter. Just play with the settings in FS till you get smooth results. Don't look at the frame rate, just fly and see if it feels smooth, that's all that matters. Well, I would absolutely *hate* that, but the only thing I can think of is to set the cloud draw distance as low as possible. You won't get any clouds on the horizon at all then (unless you are on the ground, so the horizon is too near! ). Blimey! I've *never* ever experienced anything like a 20 fps drop (this would make my frame rate less than 10 in most places, negative in some)! What on Earth have you got your frame rate limiter set to? Use something sensible like 25 or 30 fps as the limit and let FS use the rest of the time, when it has any, getting its graphics and textures sorted. Also, go get some of the more compact cloud bit maps. I don't remember the names, but they do help a lot. No one I know of. You might want to post on the FS2004 Forum, or enlist the services of that competent company who sort out FS performance, especially graphics, with you. FSGS is it? Ah yes, near here: Regards, Pete