Pete Dowson

Again, you supply no information at all. Please see my previous reply. Pete

Squawkbox doesn't need a user-registered copy of FSUIPC in any case. I cannot help you without any information. Please try again, then close FS. Find the FSUIPC.LOG file (in the FS Modules folder) and show it to me. Or you can Zip together both the FSUIPC.LOG and FSUIPC.KEY files and send them to me at petedowson@btconnect.com. Regards, Pete

Ah, yesI remember now! Thanks. Pete

In order to do what? Sorry, you have lost me. If FS is running in Windowed mode you just put your Window on top by the Z-order thing, or HWND_TOPMOST or something like that. I really don't know without looking it up. Don't you have a reference? If FS is in full screen mode, you cannot do it from another program as far as I know. Pete

Creat a window? I just use the normal CreateWindow() API. Or am I not understanding your question? What is the problem? Only top level Windows get taskbar entries. if yours is a top level window (i.e. its parent is the desktop) I don't know how you suppress the taskbar entry -- presumably make sure the top level one is invisible, then create a child which is visible? Pete

Oh, right! Apologies if I don't remember. so many faces at these shows I even almost forget who I am! Yes, indeed. I envy you! I seem to spend all my flight time tweaking and testing. Only natural I suppose when I think I know what is going on 'underneath' and think something is not quite right! ;-) Best regards, Pete

If you want to use FSUIPC for reverse on the same single axis as forward thrust, yes, you have to map the single throttle (FS's generic threottle has no reverse capability) to the 4 separate throttles, then do your calibration there, on page 3. If does state this in the documentation. However, I thought there was also a documented way to get reverse on the CH quadrant using the CH control manager -- I don't have such a quadrant but this is what other folks have said. Are, in fact, the throttles on the CH quadrant separate for each engine? Maybe one or more got assigned to the main all-engine throttle and this was overriding the separate ones? Or maybe you had (possibly still have?) something assigned to that main throttle, which would explain why you think you ned to "kill it" in FSUIPC? Please just thoroughly check through the FS Assignments -- Options, Controls, Assignments. Be sure to check this for ALL listed joysticsk (there's a drop down to select them from). It is really sounding like you have dual assignments for throttle which were conflicting. Regards Pete

Good that it wasn't too hard to find, nor anything actually faulty. Thanks for letting me know! Regards, Pete

If the standard Windows calibration plus the documentation from CH and the extra stuff from Bob "Sticky" Church is not yielding satisfactory results then I must say it sounds likely you have a faulty quadrant -- I should contact CH support if I were you, or your supplier. Please do not try to use anything in FSUIPC to do basic calibration. You need properly working and calibrated joysticks to start with. FSUIPC is not a joystick driver and knows nothing at all about them. Regards, Pete

Okay .. please let me know if you do find a specific cause. It may be useful again in future! BTW you shouldn't automatically rule out a hardware cause either. I've had two faulty network cards in the last few years, though in both cases the symptoms were faulty data under load (only eventually proven after copying huge files and comparing the results to find the few bytes in many millions actually missing!). If you aren't using a network port on the motherboard it is worth trying to swap cards. Even if you are using a motherboard port it might be worth trying a PCI card instead. Regards, Pete

A similar problem to what? This is the first message in a new thread so there's nothing to refer to!! :-( You don't need to be familiar with programming! What is that all about? Programming doesn't come into it at all! FSUIPC.LOG is a simple text file in the FS folder. It will identify precisely the program you are using which is not allowed to use FSUIPC (because you haven't paid for it). Just show it to me if you cannot work it out. Anyway, it won't actually affect the "working of FS2002" as you assert, only the working of whatever is trying to use FSUIPC incorrectly or without access permission. Regards Pete

It won't be a regular "application" as such -- look at the Process list. It'll be one of those. Something is doing it. Try killing one process at a time. If you crash the system doing that, just reboot and continue. You'll find it eventually that way! But first, please take a look in both the FSUIPC and WideServer Log files -- you'll find them in the FS Modules folder. Just in case something odd is failing and causing retries or something. With no Client connected, WideServer doesn't even do anything (unless you are using the Beta version as I said before -- that uses mailshots once a second, but it can be turned off). All wideServer does is "offer" a service and waits for Windows to indicate a connection has been made -- i.e. a Wideclient has attempted to connect. There's nothing happening in Wideserver till that occurs, it is simply idling awaiting such a message from Windows. Sorry, I am no Windows or even Network expert. You may find Katy Pluta over in the FS2004 Forum some help if you can't get anywhere killing processes. Regards, Pete

It won't be a regular "application2 as such -- look at the Process list. It'll be one of those. Something is doing it. Try killing one process at a time. If you crash the system doing that, just reboot and continue. You'll find it eventually that way! With no Client connected, WideServer doesn't even do anything (unless you are using the Beta version as I said before -- that uses mailshots once a second, but it can be turned off). All wideServer does is "offer" a service and waits for Windows to indicate a connection has been made -- i.e. a Wideclient has attempted to connect. There's nothing happening in Wideserver till that occurs, it is simply idling awaiting such a message from Windows. Sorry, I am no Windows or even Network expert. You may find Katy Pluta over in the FS2004 Forum some help if you can't get anywhere killing processes. Regards, Pete

Sorry. I don't understand the question. The FSUIPC programmable interface is defined in documentation in the FSUIPC SDK. There is no relationship whatsoever between the hexadecimal "offsets" defined there (which are, these days, primarily just token names) to any "numbers" elsewhere, no matter whatever numbers it is you are referring to. Regards, Pete

You cannot. And there's no need to in any case. It was only used as part of a secure means of identification and now it is embedded forever in your access Key. Regards, Pete

It is true that there's no measurable impact. And in any case there's nothing whatsoever that the currently released WideFS (6.47) does once per second -- the Beta version (released in this Forum only so far) does, by default, issue a short broadcast once per second, so that clients can link automatically. However, that isn't noticeable either and it is suppressible if so. It sounds like something more to do with the way you have your network configured, or else it's an anti-virus or memory checker program, or maybe some other security type action which is occurring. First off, make sure you are assigning fixed IP addresses to every PC, not allowing Windows to seek connections every second or so. That's one cause. Otherwise you'll need to look for other background activities. Regards, Pete

It isn't just a matter of setting integers to zero, it is a matter of setting unused parts of areas you read into to something predictable, zero being a good choice. I don't remember the earlier details (there have been far too many other messages), but it was likely that you were reading a 2 byte value into a 4 byte location and hadn't set the two unused bytes, so you got rubbish. But the same can apply to anything of unequal lengths. You have to do it intelligently! In your code snippet above you say: int dwOffset = 0; int dwSize = 0; int Token = 0; int dwResult = 0; int Result = 0; but (a) I have no idea what you are using some of those for, and (b) there's no point in initialising things to zero if they are all going to be set in any case. For example, the Offset is always a 32-bit value so you will be setting that, and the "dwResult" value is always set as a 32 bit value too. You seem to have misunderstood your original errors and compensated by incorrect changes. Just think about what is going on. If you understood a little more about what you are doing you wouldn't make so many errors. If you read 1 byte into a 32-bit value, only the bottom 8 bits of those 32 will be set. The other 24 bits will retain whatever value they had before. The same goes for any other sizes. Just think, each time, about what you are doing. When programming you must attend to this level of detail! After all that, you should find a thing called a "Debugger" somewhere in your development system. If you compile your code in Debug mode you should be able to trace through it, step by step, examining all these values as you go. You can even set breakpoints which makes it stop at selected points so you can examine things. All this is part of programming and an essential step to getting any new program fully working. Please try it. Regards, Pete

ATIS is not a concern of FSUIPC, it doesn't touch it or affect it. Check you FS options. You should be able to get both the displayed ATIS reports and the spoken ones when you tune a COM radio in correctly as long as you haven't turned off the reception. FSUIPC does nothing unless it is told to by another program, or by options you set yourself. Maybe you have another program now able to operate and therefore switching things off? Regards, Pete

What is ATS and what has it to do with FSUIPC? If you mean FS's inbuilt ATC (Air Traffic Control), that is nothing to do with FSUIPC and won't be influenced by anything in it at all. Regards, Pete

You have errors in the program still then. You need to debug your program further. Pausing makes no difference whatsoever to FSUIPC nor the interface. Please always check all your results with FSInterrogate (that is why it is provided). Also you can use FSUIPC IPC read/write logging to see exactly what you are reading and writing, and even the Monitoring to have values displayed for you on the FS screen. There is really no need to ever have anything wrong! You can fix it all. Regards, Pete

That message has not been in FSUIPC since version 3.39. You most certainly have not got the "latest version" but one at least a year old! Go to http://www.schiratti.com/dowson and get 3.48 or later. Pete

Er"ship it"? It is never "shipped". You have to download it yourself if you have not got it. All they "ship" is the access key, and that comes to you by Email, normally within 24 hours of payment. I think you are misreading something somewhere. Pete

Turns out you are using FSUIPC 3.40 not 3.48. Please check again with a supported version. Regards, Pete

Hmmm. Odd. The key must be wrong, or one of the other details. Zip up your FSUIPC.KEY file and both an FSUIPC.LOG and WideServer LOG from the same attempt -- please be sure to close FS first -- and send the ZIP to me at petedowson@btconnect.com and I'll check. Pete

You need the FSUIPC SDK from http://www.schiratti.com/dowson. All the information is in there. Pete