Pete Dowson

Did you try it? You would get better acuracy and make the code a lot simpler if you converted to floating point THEN did the calculation, thus: hdg = value; hdg = (hdg * 360.0) / (65536.0 * 65536.0); or this, which is really the same, as the compiler will convert 'value' before it does any computation: hdg = (value * 360.0) / (65536.0 * 65536.0); BTW Because "value" is signed, this will give you a signed heading, i.e +179 to -180, rather than the usual 0 to 359. You may want to make "value" an "unsigned int" (a Windows DWORD in fact) instead. Regards, Pete

Sorry, I don't know. I don't use SB myself and I don't keep up with it at all. I was merely informed by the author that it would be in the "next update". That was about 11 weeks ago. I have no idea if any such update has been released since then: you will have to check whichever website it is obtained from. Obviously, the message facility I'm using won't have been tested either, so I would like feedback as and when it is supported in SB3. Regards, Pete

ALL the files?? For FSUIPC the only file you need to move is the module itself, FSUIPC.DLL. As the documentation clearly says, all the others are optional. What is confusing about the instructions please? I cannot do anything about improving them on such a general complaint. :-( They've been improved in the last six years but the current format has stood the test of recent times and very very few people get confused. I'm sorry if they are not in any language you know, though. To access the program, load FS and find the Modules menu entry, therein selecting "FSUIPC" (or just press ALT then M then F). It does tell you in the documentation you know. There are even pictures in the documentation. Did you look? As described, with a link, in various places, including: (a) the documentation (b) the websitte from where you downloaded it © in the oddly named Announcement above entitled "Paying for FSUIPC, the why and how". Pete

Why are there two WideCliient logs and no WideServer log? There are always two ends to a connection. Looks like you are running a LOT more than pmSystems -- you have pmSounds, the PM MCP and the new FSInterrogate there too! This error occurred after 50 minutes from the FS connection being started not, as you say, "a short time". After that you closed down and started again (but not WideClient), but you seem to be then getting errors from one of the programs: Those "READSTATEDATA" errors indicate bad requests actually being received from one of the programs -- one of MCP, PMSOUNDS and PMSYSTEMS. Sorry, I can't tell which one. I suggest you report this to PM support -- that isn't a Network problem, it is data corruption in one of the programs. In the other log there was this: Again you are running FSInterrogate. However, the data error is exactly the same, and is consistent. If it is pmSystems which is hanging or gpoing odd, then it may be that which is responsible. Why not try it on its own, to prove it? Regards, Pete

If you reinstalled Windows or put FS on a different PC you have to re-enter the details in the original way. If you can't find them, you can open the KEY file in Notepad or any editor, and cut and paste them into the dialogue. Just copying the KEY file only works for reinstalling FS on the same PC or moving it about. Regards, Pete

Seems that the answer is clearly stated in the error message -- you need to provide a pointer to a character or an array of characters and you are not, you are providing a constant. Really you should be able to read that yourself. Yes, send the correct sequence of messages to FS's Window, of course. Look up "PostMessage", "WM_KEYDOWN", "WM_KEYUP", "WM_CHAR", and "SendInput". Please see if you can find some books on Windows programming. They will be more appropriate than trying to learn here. I am trying to support my programs and develop them too, as well as maybe fly just now and then if possible. I hope you understand that I really cannot carry on an elementary Windows programming course here -- I really am not a good teacher, I have insufficient patience and understanding of learner's needs. I'm very sorry. Regards, Pete

I just search the Window title for "98", "2000" or "2002", else it's 2004. I think I will make it more foolproof in future though by reading the main EXE module's Version information. ;-) Pete

There are FS controls to do that -- the one normally assigned to Shift+P, for start/stop, optionally followed by keyboard keys 1 or 2 to select direction. From a module or gauge just send appropriate Key Events. Pete

Er, no! Key2Mouse is a program by Luciano Napolitano which converts keystrokes into mouse movements and clicks. It is used to click on gauges which don't recognise keystrokes. It sounds like the very opposite of what you are thinking! Regards, Pete

If the OUT value matches the IN value then either FSUIPC hasn't been set to calibrate that axis (the bitton above still reads "SET"?), or you have pressed it (to say "Reset", but haven't done the calibration. If you really do WANT an input value of 10000 to provide an output value of 0 then 10000 must either below the Minimum value Set (for a single throttle on page 1), or between the two Idle values (for the multiple throttles on page 3). Then FSUIPC will certainly change it! It sounds as if you are simply not using FSUIPC as described. Regards, Pete

It isn't FSUIPC "forgetting" a key assignment then. As you say, the assignment is still there. And there's been no changes in 3.50 in this area. Maybe TeamSpeak is not picking up the key press? I notice you've programmed the button to be "held" -- this may cause Windows to generate repeats -- it would normally generate repeat keypresses after a delay if a key is held down. Perhaps that is the problem? I don't know how Teamspeak works with these things -- this is why, for Roger Wilco, AVC and SB3 we changed to a direct command, sent straight to the program. It is a pity Teamspeak didn't offer similar facilities. You may be better off checking the option not to hold the key, and simply pressing it once to talk, then again when you've finished. Another problem of course may be that TeamSpeak it cannot see keystrokes sent to FS. Incidentally, one way of proving whether FSUIPC is in error or not is simply to assign the keypress (Del == Numpad Decimal to FS) to some easily recognisable function in FS's own keyboard assignments, and then see if your button operates that correctly. This is certainly how I test these functions -- I don't have all the applications to test with, and certainly not TeamSpeak (sorry, I don't fly on-line, yet. Maybe when I have more time to actually fly! ). Regards, Pete

Yes, of course. There are two ways, one easy but user-dependent, the other harder. The easy way is to use the virtual buttons facility in FSUIPC. You get your program to change bits in the 3340-3363 range of offsets (288 "buttons"). These can be detected in the Bttons page in FSUIPC options, and there can be programmed to send keystrokes or FS controls, as usual. The disadvantage of this way is only apparent if you plan to release your work to others, as they then need to have a user-registered FSUIPC and would ned to program these buttons. If they had anything else using the same virtual buttons they'd have difficulties. The other way is to program via the offsets 3200-320B. This actually does send the Windows messages for KEYDOWN and KEYUP. But you have to remember that you need the whole sequence. For a combination of, for instance, Shift+Ctrl+A you'd need to send three KEYDOWN's and then the three KEYUPs. This way is more flexible, but really FSUIPC is not doing much for you -- the reason the facility is there is for WideFS, so keystrokes can be sent to FS from client PCs. If you are running in the same PC (and for Gauges, even in the same Process!) it may be just as easy for you to send these messages by PostMessage direct to the FS window (class "FS98MAIN"). However, you may not get exactly the same result unless you do it using the Windows "SendInput" API as FSUIPC does -- messages like WM_CHAR may not be generated correctly otherwise. Regards, Pete

No, not at all. You are not reading it as it is written. During autobraking, operating manual brakes should stop the autobrakes. This is what this facility is for -- so you can disarm automatically by pressing your brake pedals. I cannot actually tell when autobrakes are in use. All I can tell is when manual braking is used, and this is the indication you get. I do think this is actually what it says, if you read it again: BTW, I don't know what aircraft you are modelling, but in my 737NG book there is nothing stating that the Autobrake Disarm Light should flash in the circumstances you describe. It lights as follows: 1. Momenrtarily during self-test when RTO selected on the ground. 2. A malfunction exists 3. The system is disarmed BY manual braking during RTO or landing 4. The system is disarmed by moving the speed brake lever from up to down during RTO or landing 5. A/Bs have been selected off because of pressure over 1000 psi 6. Landing was made with RTO selected -- no braking occurs! In other words, the light is a result of something, not an instruction for you to disarm it -- that happens automatically then you get 3 or in other error conditions. Apart from the test case (1), the light means autobraking is already off or inoperative!. Regards, Pete

There's no change in any of the weather setting facilities. Version 3.50 is the same as the module which has been on Beta release and used by over 800 people over the last few months. The only way to prove what was happening is to enable Weather Logging (in the Logging page in FSUIPC) and see what was being set and implemented. Every time there's a new release (and I do mean every time) there are always all sorts of reports of things changing which haven't been touched, and even things not anything to do with FSUIPC. One person even emailed me and said the new version made his sound go quiet in his headphones! :shock: :shock: If you have any real information (logs) which shows any anomalies, I'll be glad to check things for you, but I have been using what became 3.50 for many weeks now with ActiveSky V and Radar Contact and there has been no discrepancy with the weather at all here. Sorry. Regards, Pete

In a 16 bit value there is no such thing as a value as big as 40000-50000. you are interpreting these incorrectly. They are negative. The range of signed values possible in 16 bits is -32768 to +32767. You are treating a signed 16-bit number as if it were unsigned (its range is then 0 to 65535). It is all in the interpretation. I think you fundamentally misunderstand numbers in computers. This is really something you need to learn something about if you are to be a programmer. For now just subtract 65536 if the number is greater than 32767. But please go and do some reading. Regards, Pete

It's actually "FSUIPC" so you may be looking for the wrong files! Anyway, the most likely thing that is happening is that when you close FS it only appears to close, but it is still running with no windows showing. To check this, do CTRL_ALT_DEL and select the Process list -- see if FS9.EXE is still listed. If so, select it and End it (there's a button below to end processes). Then see if FS loads without that problem. If this is what is happening then it means something you have installed in FS is not terminating properly. I seem to remember an earlier version of ActiveCamera could do this -- it was fixed though. Whatever, make sure you have the latest version of any add-ons you have installed. Regards, Pete

Is pmSounds still a freeware item? The key should work for the version it was generated for -- if it doesn't then maybe a new one can be made. Have you asked PM support? It is really their province. If you want me to investigate please try again, close FS, then show me the FSUIPC.LOG file (from the FS Modules folder). Regards, Pete

You always need to calibrate well first in Windows' Game Controllers. FSUIPC is only providing the "finishing touches". Also, check that you have FS's settings correct first, too. The Sensitivities slider should be up full (hard right) and the null zone slider full left. I don't think there's ever any ideal settings which you can copy from one controller to another. The whole reason there's any calibration in the first place is because of all the variations from one unit to another. That said, you should find it helps with airliner control to use of of the slopes with a flattened centre -- gives you more control where you need it. The flattened centre slopes are those with positive numbers in FSUIPC 3.50 (numbers weren't shown before). Regards, Pete

Hmmmnot sure I understand. But if it asymmetric inputs which are the concern, there is a switchable FSUIPC option to equalise them all. It's the "throttle sync" hot key, in the Hot Keys page. You can program a key press there, and if you have one, a button to send in in the Buttons page. The "IN" value is what FSUIPC is seeing coming from the control. How your control is producing maximum reverse at full forward I don't know. Have you got some other drivers doing this? If this is only with the specific aircraft, try checking the option at the bottom of the 4 throttles page, to stop FSUIPC processing the old THROTTLEn_SET controls. Maybe they are being used by the aircraft's thrust management asystem. I know you need that for the Feelthere ERJ 145. Certainly not the -4096, but even calibrating it for the highest positive you get won't help if you push the stick into the -4096 zone. There's no way FSUIPC can distinguish that from a negative number, because it is one! If your quadrant does this even for standard default aircraft, then I would say it was faulty --- it means there's a bad contact or a short at one end of the travel. In that case get it replaced. Regards, Pete

Not true, apart from the new facility to make them aircraft specific. None of the columns have been changed since about version 2. The headings are different in each page depending on the axes concerned. The separate throttles page (page 3) has always been as you say. You follow the instructions, step by step. This is no different from any version over the last four or five years. What is the problem? Regards, Pete

WideFS 5.40 is too old and not supported. There's no "free" WideFS. Regards, Pete

With Squawkbox 3 it is all taken care of in that program. With Squawkbox 2 you need AIBridge by Jose Oliveira. There's a link on the http://www.schiratti.com/dowson page. That's all I know I'm afraid. There's no other magic, it just works as far as I know. Regards. Pete

Neither FSUIPC nor WideFS know anything about either IVAP or cpFlight equipment. I'm sorry, but I have absolutely no idea how they communicate and know nothing about them whatsoever. If cpFlight blame FSUIPC/WideFS let them show that to me. I think you need them to provide more information to each other -- maybe cpFlight can talk to IVAP or vice versa? I really cannot support other folks' software or hardware, especially stuff I have not got and know nothing at all about. Neither have ever supplied me any information about any of this. Pete Dowson

As I said before, the Log shows the SB3 modules connecting to FSUIPC okay. The KEY file you sent shows you are using an illegally generated FSUIPC access key. Where did you get it? You are not listed as a registered user and you are breaking the law by using this counterfeit key. Unless you have an excellent explanation I will be reporting this This will no doubt be the entire reason for your troubles. I cannot tell any more because the Log you show here, and the one you sent by email, is not complete. I asked you to run FS, get the problem, then CLOSE FS before getting the Log. I cannot do anything with an incomplete log. You need to close FS first. Pete