Pete Dowson

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

Oh, sorry, didn't mean it like thatit's just that what was happening sounded so wrong. :-( Oh, goodthat's all right then. Phew! :-) :-) Thanks! Pete

What do you mean "as usual"? If you've not paid for WideFS it is not legal for you to use it. Please ZIP up the last FSUIPC.LOG and FSUIPC.KEY files so that I may investigate this. something is not right. Regards, Pete

That's not legitimate -- one of the recent releases was a Beta b mistake. It will expire one day soon in any case then nothing will work. Check the wideServer Log. it probably says you need to register WideFS. Yes, you certainly must! It's the only honest thing to do in any case if you want to use it! Regards, Pete

Not corruption. You were using version 3.48 which is too old for a 2006 user registration, as was clearly notified to you in the email with the Keys. There's absolutely no need to delete anything at all. If you do you lose all your settings. All you need to do is replace the FSUIPC.DLL with the latest version (3.65 at present). Regards, Pete

In that case it is most certainly a problem with your Key. That IS the FSUIPC.LOG file. What do you mean, you can't find it??? Version 3.48!!! No wonder -- if your registration was purchased in 2006 you need 3.53 or later! Current is 3.65! The log proves it is a Key or Version problem. Please ALWAYS use the latest version! Regards, Pete

Sorry I don't support old versions -- 3.53 is now over 6 months old. Current is 3.65. Please update. Pete

With FS2004 most of the old FS98 methods of doing things with weather don't work too well in any case. The weather is cleared initially because you cannot set "global"weather (which is all FS98 had) whilst the world is populated with localised weather. After the weather is cleared for you (which only happens the first time you try to use the old FS98 weather interface) then of course you need to set suitable clouds -- you cannot have any rain or snow without a cloud layer. Even then I have doubts. In FS2004 the weather becomes "localised" after a while, and then you cannot use the global weather settings unless you clear the weather again. Horrible. If you are really interested in dealing with FS2004 weather please check the New Weather Interface, which is designed for FS2004. Regards, Pete

This is probably one for the PMDG support folks. I don't know their aircraft. However, there are tow things I can think of: 1. Perhaps there's no power? The 737-600 has a glass cockpit system and needs electric power to show anything. Have you checked battery etc? The PMDG aircraft are quite sophisticated and usually it isn't a matter of load-and-fly. 2. If you do think it possibly has anything to do with FSUIPC (like, did this aircraft work differently BEFORE you registered FSUIPC?) then please load up FS again, load the aircraft, see the problem, close FS, the show me the FSUIPC.LOG file which you'll find in the FS Modules folder. Regards, Pete