Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. No it is not right. You do not have to delete anything. Best, in fact, to keep back-up copies of all INI files so you never lose your settings! FSUIPC makes any minor changes itself if they are needed (deleting old parameters now not applicable and adding new ones), and WideFS settings haven't needed changes for ages. Also, if you've registered FSUIPC or WideFS or any applications manually, then save a copy of your FSUIPC.KEY file too. All you need to do for any new version is copy in the DLL. It will overwrite the previous one. That's it, done and dusted! If you get inot any problems and suspect any settings, by all means remove the INI file and try again, in case a parameter is responsible (unlikely), but keep a copy. Regards, Pete
  2. By the way, the registration access system is not a problem with older versions of FSUIPC (pre version 3) -- they'll just ignore it (well, they will write to offset 8001 and you can probably read it back too! But the area isn't used for anything else). So you don't need two versions or need to remove code to test. Regards, Pete
  3. No, the details in your Version Information are wrong. These are the details you sent to me: > Program name: BOTA.EXE > Company: The Battle of the Airlines Trophy > Produkt name: BOTA You missed a "The " in the Company name! Computers are stupid. They do exactly what you tell them, not what you really want them to do! :) Regards, Pete
  4. Seems that Visual Basic keeps too many odd things it does secret or just undocumented, since many VB programmers seem to have this problem. What the VB compiler seems to do is take your &H8001 and expands it into &HFFFF8001 -- i.e. it sign extends it. This is not a valid offset for FSUIPC, though the top 16 bits are used for control flags for special purposes, mostly to do with the Advanced Weather Interface. So FSUIPC masks the flags it currently understands and this gives it the F8001, which is of course illegal too. I've been told the the (stupid?) VB compiler even does the same if you explicitly give it as: &H00008001 which I think is really really bad! :? I've been informed that you can stop the sign extension by post-pending another &, i.e. &H8001& Alternatively decimal works too, for some reason (&H8001 = 32769). I just wish there was some logical consistency in VB and at least that such weird interpretations were well documented in the VB programming books. :( Regards, Pete
  5. The only way this message can arise is when WideClient does not see the ServerName parameter. In all other server name errors it will actually try to access the Network. Here it is not even doing that. Though you show an INI file with the server name included, I think the only explanation is that either the WideClient.ini file is not in the same folder as the WideClient.exe you are running, or somehow you have got the INI file mis-named. It must be "wideclient.ini" and it must be in the same folder as the "wideclient.exe" which you are running. Regards, Pete
  6. The Taxi Wind facility, as it's called, is still in current versions of FSUIPC. It applies to FS2000 and FS2002. I've not found any way to apply it to FS2004, that's all. There's quite a lot of stuff about it within the forum here -- look for Taxi Winds. I did follow through some hopeful avenues in FS2004 but they didn't work, and I've not found any others. I think the problem is nowhere near as bad in FS2004 as in FS2002 or earlier, and in fact seems pretty realistic. I suspect taildraggers are really pretty difficult to handle in a crosswind in any case. I'm sorry, but all I can suggest to clearing the weather or selecting weather with manageable winds until you can learn to control the yaw. Certainly I would have though rudder pedals to be an absolute must in such conditions. Regards, Pete
  7. Actually, the "run ready" facility doesn't work that well in FS2004. I have quite a lot of difficulty from inside FSUIPC knowing when it is safe to access aircraft paramters in SIM1.DLL simply because there's nothing clearly obvious to tell me when a previous flight is deleted nor when a new one is completely loaded and initialised. And it isn't only Flights, simply loading or reloading an aircraft is the same problem. All the data structures are deleted then re-built for the new aircraft in both cases. And different structures are built for each aircraft type -- prop, jet, turbo, helo, glider. It's a nightmare in fact. In FSUIPC I take some precautions to simple avoid trying to access areas which are not valid at any time, but it isn't foolproof. I use pointers in other, more general structures, and before accessing those I check for validiiy by APIs like "IsBadReadPtr". If I do ever find a foolproof way, I can certainly provide some sort of indication. It could be useful for my other modules. But it might help for me to actually understand why an application (rather than FSUIPC) would need to know. Can you explain? Regards, Pete
  8. I think it would be easy enough to do this, but it has not been requested at all before. I only added what was specifically requested there. I can add it to the list of things to do in the next version, if you wish. Regards, Pete
  9. I think Elite do their own thing, probably writing direct into FS. I know nothing about them and they've never contacted me. I think your only recourse is to contact their suport. Regards. Pete
  10. Delete your FSUIPC.INI file then -- if FSUIPC is assigning buttons for you it is because you have told it to at some time. It does not touch joystick buttons at all of its own volition, those are all user facilities. If you dete the INI file it will delete all such erroneous assignments you made before. Regards, Pete
  11. A 64-bit (8-byte) floating point number, also called a "double" in C/C++. There's no easy way you can generate those directly in EPL, and there's no 8-byte data transfer facility in any case. You can do it through EPICINFO which has facilities for dealing with these things, but I don't know FSCOMM. Maybe you could ask the author? Regards, Pete
  12. It should work, but there was a bug in some versions of FSUIPC where the button repeat action didn't work. Make sure you are using the latest version (3.11). Regards, Pete
  13. You need to send both emails you got from SimMarket and also tell me which one you have used or want to use. Send to petedowson@btconnect.com. Regards, Pete
  14. The problem is two-fold: 1) Depending on what you do in "doSomethingwithData", your program is not relinquishing the processor and this will affect performance. Certainly, the call to FSUIPC_Process will cause a process switch, but doing this possibly very fast is actually only wasting much processor time switching unnecessarily. 2) The loading on FSUIPC, processing the end-to-end requests, is a loading on FS itself, which isn't a good thing. Since the most if not all of the data you are using cannot possibly change faster than the FS frame rate, most of those calls be will just an overhead and doing nothing useful. The solution depends on what else the program is doing. If it is actually doing NOTHING except when it gets new data, and you don't mind it being rather unresponsive to user interventions, then simply try inserting a "Sleep" in the loop, say for 15 or 20 or more milliseconds -- experiment and use the biggest value which works well. Alternatively, trigger this section of code on a windows timer call -- either by WM_TIMER messages or using the TimerProc facility in SetTimer. Using the loop in a separate thread with a Sleep would also work, but is probably an unnecessary complication. Certainly do not have it in a thread with no Sleep, that could be worse (especially, as I found out recently, on Pentium 4 HyperThreading processors). Regards, Pete
  15. Since AFCAD is freeware I have made a freeware key for it to access FSUIPC. Please see the Free Key list which is a Sticky message up above. Regards, Pete
  16. Sorry, but FSUIPC has no relation to anything graphical whatsoever. In fact by itself it isn't even doing anything., unless you've set some options. There's something else going on there. I'm not sure how you can go about determining exactly what it is, but start by removing all add-ons and re-installing one at a time. Regards, Pete
  17. Check the "module users" part of the FSUIPC SDK. Whatver you do, do NOT use the normal external interface. It is fat and inefficient for use withing the same process. The module users method is a simply message passing system with you maintaining the data area. Regards, Pete
  18. That's odd. I don't know of anything that would change that. What was the previous version of FSUIPC you were using? Regards, Pete
  19. Sorry, I don't know any way to do that "on-the-fly", only through the menu. Regards, Pete
  20. As documented, it is available as freeware for its true original purpose -- as a successor to FS6IPC for interfacing external programs to FS. I have merely put a price on the additional facilities. I am afraid that, if the default FS and Windows facilities for joystick calbration are not sufficient for your needs, then there are only two alternatives: either write a driver for them to interface to FSUIPC (for freeware I provide a free key), or purchase a user key for FSUIPC so you have access to all the optional features. Regards, Pete
  21. Sorry, I know zero about FF and it isn't an area I want to get tangled up in. You'll need to report it to Microsoft. It won't be anything to do with FSUIPC at all. Regards, Pete
  22. Ugh, really? I'll have a look this weekend. Sorry. Regards, Pete
  23. I don't understand. GPSout is intended to make FS effectively look like a GPS to an external map program, normally running on another PC. Sending GPS outpput data to another GPS sounds rather odd. I have a Garmin GPS and the only input it can take is feed from an external GPS receiver/amplifier, for more accurate or sensitive operation. The format for that is not NMEA. If your GPS can read NMEA output from another GPS, then presumably there's some appropriate mode for this. I think you'd need to determine this from its handbook. Regards, Pete
  24. Sounds like an ATI card problem -- there seems to have been a number of flicker problems with ATI cards. Is that what you are using? Try the latest drivers, or check it in maximised Windowed mode. Regards, Pete
  25. Is AFCAD2 released now? As it is freeware I can make an access key for it, but I need details first. No one has asked before. I need the EXE name, and details from the Version Information (right click on the EXE and select Properties-Version). I need the "Product Name" and the "Company Name". These things must be exact. Then I can publish a Key in the Sticky thread above. 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.