Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I see you have sent me an email, so I will reply there. Regards, Pete
  2. Thanks! I don't get time to browse Forums. The latest versions posted by SimMarket (where I got my copy) in still 1.2.1. Pete
  3. There are no such messages possible from any of my software. They are produced by Visual Basic library code, and I not only have never used VB but I know nothing about it. Florian may be puzzled but I'm afraid it is only he that can debug his own programs. There's no way I can help here I'm afraid. If Florian needs help understanding something he's doing with FSUIPC then of course I can help, but this is just about as far from anything I know about or FSUIPC does as it is possible to get! Even the "English" error message is gibberish to me. Forms? Modes? I think these are VB terms relating to the window displays. Incidentally, I am using SA_WXR and loading it by RunReady all the time, so it is most likely to be down to something in your specific installation. Ah. I'm using 1.1.2 I think. I wasn't aware of an update. Thanks, [LATER] I found 1.2.1 ready for download in my SimMarket account. Where did you find 1.2.2? There seems to be no updated documentation though. I was hoping Florian had added automatic OFP and GCS "ON", as he already added the option to have it automatically switch on. I use it with Project Magenta and have no buttons accessing SA_WXR so I just want it to run in the background with no attention needed. Pete
  4. Ah, good! Thanks for letting me know. Pete
  5. The message that tells you that only exists in versions of FS older than 3.40 -- from over a year ago. You may have downloaded 3.50 but it seems you've not copied the FSUIPC.DLL file from the ZIP into your FS Modules folder. There's really nothing to "stuff up", installation is just a matter of putting one file into one folder. Regards, Pete
  6. PFC.DLL only supports the PFC protocol. Elite have their own proprietary protocol (secret to them). There's no way PFC.DLL will handle it. You could check with PFC to see if the hardware can be switched, but I don't think you will be in luck. Regards, Pete
  7. Easy, though you won't find it called PSUIPC. You simply delete FSUIPC.DLL from the FS Modules folder. That's it. If it isn't there it cannot be loaded by FS. If it cannot be loaded it can't run. It really is as simply as that. FSUIPC is very simple like that, it uses no fancy installer, it doesn'ty make any fdolders or icons nor loads of entries in your registry. It simply runs from FS Modules folder when it is loaded by FS, and that's it. What backup? FSUIPC never makes any backup. Pete
  8. No. If you have the menu hidden by default, it doesn't even actually exist until it is called up again. Programs that add stuff have to watch for menu calls and re-insert their items each and every time. FSUIPC and my other programs do this, as does FSNav, but it sounds like SB3 isn't reacting to the same Windows events. Please report this to the SB3 support folks. Regards, Pete
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.