Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    168

Everything posted by Pete Dowson

  1. I just spent a little time looking through the stuff I've got on Autopilot values. Although the autopilot obviously keeps track of whether IAS or Mach is selected for Speed mode when the Auto Throttle is engaged, I don't think it knows or cares what the A/P gauge itself is displaying. It looks very much like the selection of IAS or Mach for display is purely a local thing to the Gauge code. FSUIPC cannot get local gauge data. Regards, Pete
  2. FSUIPC itself does nothing unless you have selected options or are running a program, and certainly it doesn't have anything to do with graphics at all. Possibly you have the random cirrus additional cloud layer enabled and something has replaced your nice wispy cirrus clouds with some horrible dark graphic? The other possibility is that you have enabled the "Virtual Sky" option by mistake? That only works properly in conjunction with the correct installation of the application program which provides the graphics. Did you check the weather dialogue in FS to see what conditions were set when this occurred? I might help to know. Just select "minimum weather defaults" on the first page of FSUIPC's options. If that stops it then you have either got a video card driver problem which is rendering clouds badly, or have virtual sky enabled, or have somehow replaced your nice cirrus clouds with something horrible. You can check the cirrus clouds by adding some yourself, of course -- go to FS's weather dialogues and have a play. Always check the options you have set in FSUIPC whenever you suspect anything. It saves a lot of hassle. I hate having all those options, but they've all been put there at the requests of users, all of them. :-( Pete
  3. You would have to ask Jeppesen to add such a feature. FliteMap has a facility to read position data from GPSs. GPSs connect via the COM port. This is what GPSout is emulating. Do you know any GPS devices which have an Ethernet port? If so then perhaps you can persuade Jeppesen to support them in a new version of FliteMap. If you do this, let me know (and which GPS has Ethernet) and I will consider adding Ethernet support to GPSout. I'd need to know how the NMEA 0183 specification has been extended to support this medium too. WideFS is nothing to do with it as it is merely an extension of the FSUIPC interface to Network computers. FliteMap is not an FSUIPC application and I don't think you could possibly persuade Jeppesen to make it one! Pete
  4. You would have to ask Jeppesen to add such a feature. FliteMap has a facility to read position data from GPSs. GPSs connect via the COM port. This is what GPSout is emulating. Do you know any GPS devices which have an Ethernet port? If so then perhaps you can persuade Jeppesen to support them in a new version of FliteMap. If you do this, let me know (and which GPS has Ethernet) and I will consider adding Ethernet support to GPSout. I'd need to know how the NMEA 0183 specification has been extended to support this medium too. WideFS is nothing to do with it as it is merely an extension of the FSUIPC interface to Network computers. FliteMap is not an FSUIPC application and I don't think you could possibly persuade Jeppesen to make it one! Pete
  5. What does, what positions? If you mean the increment shown in FSUIPC's Flaps section, then what you are reading is the increment -- the difference between each flap position. It is fixed for a fixed number of flap detentes. It only changes if you change to an aircraft with a different number! Sorry, you've lost me now. Where can you put 3 numbers as parameters? Where are you looking? The FS flaps control takes a SINGLE (1) number between 0 and 16383. 0 means "no flaps", 16383 means "full flaps". The other positions are spread equally between those two extremes. So for example if there were only 3 positios (0, half and full, say) the parameter values for those would be 0, 8191 and 16383, the increment being 8191. Just extend this for the number of positions you want. Pete
  6. What does, what positions? If you mean the increment shown in FSUIPC's Flaps section, then what you are reading is the increment -- the difference between each flap position. It is fixed for a fixed number of flap detentes. It only changes if you change to an aircraft with a different number! Sorry, you've lost me now. Where can you put 3 numbers as parameters? Where are you looking? The FS flaps control takes a SINGLE (1) number between 0 and 16383. 0 means "no flaps", 16383 means "full flaps". The other positions are spread equally between those two extremes. So for example if there were only 3 positios (0, half and full, say) the parameter values for those would be 0, 8191 and 16383, the increment being 8191. Just extend this for the number of positions you want. Pete
  7. FSUIPC can only list the controls provided by FS. In fact the list you see is extracted at run time from FS's "Controls.dll" -- the names are from there too. FSUIPC just adds things for PM and KeySend. In that case you have to use an axis input (Flaps Set is one such and suitable). See the Joystick section, and how to assign a Flaps control in the Advanced users guide. "FLAPS_SET" is not assignable in the FS CFG (at least not without patching CONTROLS.DLL as explained in my FS2002 controls document) so FSUIPC allows mapping from any assignable axis control. If you have no spare axis, only a set of buttons, then you could try assigning the Buttons to the Flaps Set axis, and setting the Parameter there to the correct values to ensure correct flap selection -- in the Flaps section of the Joystick page you will see the increment needed for your aircraft when it is loaded. If it says "2047" for instance you would set flap parameters 0, 2047, 4094, and so on, or something like that. You'll need to experiment to see if you can make this work, I've never tried it myself. Keep us informed. Regards, Pete
  8. FSUIPC can only list the controls provided by FS. In fact the list you see is extracted at run time from FS's "Controls.dll" -- the names are from there too. FSUIPC just adds things for PM and KeySend. In that case you have to use an axis input (Flaps Set is one such and suitable). See the Joystick section, and how to assign a Flaps control in the Advanced users guide. "FLAPS_SET" is not assignable in the FS CFG (at least not without patching CONTROLS.DLL as explained in my FS2002 controls document) so FSUIPC allows mapping from any assignable axis control. If you have no spare axis, only a set of buttons, then you could try assigning the Buttons to the Flaps Set axis, and setting the Parameter there to the correct values to ensure correct flap selection -- in the Flaps section of the Joystick page you will see the increment needed for your aircraft when it is loaded. If it says "2047" for instance you would set flap parameters 0, 2047, 4094, and so on, or something like that. You'll need to experiment to see if you can make this work, I've never tried it myself. Keep us informed. Regards, Pete
  9. Okay, thanks for that. If you do get any more information on the problem and want me to look at it (e.g. a DrWatson dump, as described in the FSUIPC User Guide under "If FS crashes ...") then Zip the data up and send it. Maybe an FSUIPC log too, plus a description of how you made it crash and a list of other add-ons being used. Please make sure you are using latest versions first, of course. Generally, however, now that most folks are using XP rather than WinMe or Win98 I'm not finding the DrWatson dumps at all useful. They seem to be completely obscure and unhelpful compared to those produced under Win98. [if there's any reader who knows how to interpret XP DrWatson's perhaps he would get in touch with me, please?]. Regards, Pete
  10. Okay, thanks for that. If you do get any more information on the problem and want me to look at it (e.g. a DrWatson dump, as described in the FSUIPC User Guide under "If FS crashes ...") then Zip the data up and send it. Maybe an FSUIPC log too, plus a description of how you made it crash and a list of other add-ons being used. Please make sure you are using latest versions first, of course. Generally, however, now that most folks are using XP rather than WinMe or Win98 I'm not finding the DrWatson dumps at all useful. They seem to be completely obscure and unhelpful compared to those produced under Win98. [if there's any reader who knows how to interpret XP DrWatson's perhaps he would get in touch with me, please?]. Regards, Pete
  11. There are no known conditions where FSUIPC, operating on its own, will crash FS. But FSUIPC is merely an interface program, allowing access into FS from external applications, and some numbers of aircraft panels too. Anyone can write programs which crash FS through misuse of this interface -- just writing silly values to some FS locations will do this. That said, there are currently no outstanding bugs causing FS crashes with any known products, or at least none at all that have been notified to me. Not only that, but for at least the last year all instances of crashes in FS have ultimately turned out to be due to other things -- buggy video drivers, faulty gauges, mis-installed panels, overheating video cards, and assorted interactions with other programs like virus checkers, to name a few. It seems that FSUIPC is thought to be the cause of all the FS ills in the world, and it really gets quite depressing. Sorry, but I think you need to look elsewhere. Pete
  12. There are no known conditions where FSUIPC, operating on its own, will crash FS. But FSUIPC is merely an interface program, allowing access into FS from external applications, and some numbers of aircraft panels too. Anyone can write programs which crash FS through misuse of this interface -- just writing silly values to some FS locations will do this. That said, there are currently no outstanding bugs causing FS crashes with any known products, or at least none at all that have been notified to me. Not only that, but for at least the last year all instances of crashes in FS have ultimately turned out to be due to other things -- buggy video drivers, faulty gauges, mis-installed panels, overheating video cards, and assorted interactions with other programs like virus checkers, to name a few. It seems that FSUIPC is thought to be the cause of all the FS ills in the world, and it really gets quite depressing. Sorry, but I think you need to look elsewhere. Pete
  13. I don't know of one. If anyone does, please let me know too! Pete
  14. I don't know of one. If anyone does, please let me know too! Pete
  15. All VB programmers seem to have great problems with strings. It seems this is a big flaw in the language. I don't know VB so I hope someone else will jump in tyo help, but as a last resort have you considered treating the string as a 24 byte array instead? Can VB handle arrays? Then each ASCII character will occupy one element each in that array. Doesn't VB come with a debugger? If so you should surely be able to trace through your code and find your error -- the usual problem I'm told is trying to pass strings "by value" instead of by pointer. I note you have this: Dim dwString as string How does the VB compiler know to reserve 24 bytes for this string? Don't you have to tell it someplace? If you read 24 bytes into a space where it only allows for one, you will most certainly get errors. Pete
  16. All VB programmers seem to have great problems with strings. It seems this is a big flaw in the language. I don't know VB so I hope someone else will jump in tyo help, but as a last resort have you considered treating the string as a 24 byte array instead? Can VB handle arrays? Then each ASCII character will occupy one element each in that array. Doesn't VB come with a debugger? If so you should surely be able to trace through your code and find your error -- the usual problem I'm told is trying to pass strings "by value" instead of by pointer. I note you have this: Dim dwString as string How does the VB compiler know to reserve 24 bytes for this string? Don't you have to tell it someplace? If you read 24 bytes into a space where it only allows for one, you will most certainly get errors. Pete
  17. FSUIPC does not output anything. It provides an interface for programs to read and write values. The same interface is duplicated on Networked PCs via WideFS. Full details and tools for using this iterface in C/C++, Delphi, Visual Basic or even Assembly Code are included in the FSUIPC SDK ("Software Development Kit"). Pete
  18. FSUIPC does not output anything. It provides an interface for programs to read and write values. The same interface is duplicated on Networked PCs via WideFS. Full details and tools for using this iterface in C/C++, Delphi, Visual Basic or even Assembly Code are included in the FSUIPC SDK ("Software Development Kit"). Pete
  19. Look at this: BYTE FsuipcMem; and this: FsuipcOK=FSUIPC_Open2(SIM_ANY, &dwResult, &FsuipcMem, 64); You have declared FsuipcMem as a single byte (8 bits only!), yet told FSUIPC in the Open2 call that there are 64 bytes there! You will be getting parts of the program overwritten! Your FsuipcMem should be decalred thus: BYTE FsuipcMem[64]; if it is to be 64 bytes long. The C compiler couldn't possibly guess that you want 64 bytes. You have to tell it! Pete
  20. Look at this: BYTE FsuipcMem; and this: FsuipcOK=FSUIPC_Open2(SIM_ANY, &dwResult, &FsuipcMem, 64); You have declared FsuipcMem as a single byte (8 bits only!), yet told FSUIPC in the Open2 call that there are 64 bytes there! You will be getting parts of the program overwritten! Your FsuipcMem should be decalred thus: BYTE FsuipcMem[64]; if it is to be 64 bytes long. The C compiler couldn't possibly guess that you want 64 bytes. You have to tell it! Pete
  21. The fix for batteries draining too quickly has been in quite a few releases now -- see the History document. Originally it was a fiddle which could also be invoked in the AIRCRAFT.CFG file ("electric_always_available"), but I changed that because that stopped electrical systems from being failed at all. The current way it does it is by allowing you to slow down the rate of change -- a parameter in the FSUIPC Technical Options page does this. This change was made in version 2.85, over a year ago now, as you will see in the History document. There's been no further change since then. What "new" version? There's been no new version for a good while now. It is frozen at 2.975 whilst I get on with work for FS9. You really must be more clear about what your "old" version is and what your "new" version is, those terms mean absolutely nothing to me. You need to refer to specific version numbers please. You say you are familiar with "read me" files, but there are none for FSUIPC, only several documents. I suggest you start by checking the Technical options section in the User Guide, then maybe peruse the History document to see all the changes between your "old" version (perhaps pre-2.85?) and the current one (2.975, released mid March this year). Pete
  22. The fix for batteries draining too quickly has been in quite a few releases now -- see the History document. Originally it was a fiddle which could also be invoked in the AIRCRAFT.CFG file ("electric_always_available"), but I changed that because that stopped electrical systems from being failed at all. The current way it does it is by allowing you to slow down the rate of change -- a parameter in the FSUIPC Technical Options page does this. This change was made in version 2.85, over a year ago now, as you will see in the History document. There's been no further change since then. What "new" version? There's been no new version for a good while now. It is frozen at 2.975 whilst I get on with work for FS9. You really must be more clear about what your "old" version is and what your "new" version is, those terms mean absolutely nothing to me. You need to refer to specific version numbers please. You say you are familiar with "read me" files, but there are none for FSUIPC, only several documents. I suggest you start by checking the Technical options section in the User Guide, then maybe peruse the History document to see all the changes between your "old" version (perhaps pre-2.85?) and the current one (2.975, released mid March this year). Pete
  23. That's odd. I only downloaded and installed the regular package. Within the subfolder "Docs" is one called EPICIO.DOC. That's all there is, and I think it is all you need. I've attached it in case somehow it didn't get installed in your package. No. VXD's only run on Win98/Me, not on any NT-based system, and the USB EPIC is most definitely best used on Win2000 or XP (I could not get it to work properly at all on Win98). Apart from that, USB drivers are totally alien to me, another world completely, and one I never want to get involved with! Ralph's solution to USB was to have a Windows Driver (the .SYS file you install) and a DLL at the user level to talk to it. A different approach completely to my VXD. Pete
  24. That's odd. I only downloaded and installed the regular package. Within the subfolder "Docs" is one called EPICIO.DOC. That's all there is, and I think it is all you need. I've attached it in case somehow it didn't get installed in your package. No. VXD's only run on Win98/Me, not on any NT-based system, and the USB EPIC is most definitely best used on Win2000 or XP (I could not get it to work properly at all on Win98). Apart from that, USB drivers are totally alien to me, another world completely, and one I never want to get involved with! Ralph's solution to USB was to have a Windows Driver (the .SYS file you install) and a DLL at the user level to talk to it. A different approach completely to my VXD. Pete EPICIO.zip
  25. You need to write to Ralph Robinson of R&R, who makes the EPIC. I really cannot undertake to support their products. In fact I don't really use an EPIC these days, though I can still answer some questions about my own software. You talk to USB EPIC via the EPICIO.DLL supplied. The interface to this is defined in documentation also supplied by R&R. I'm surprised you've not got it amongst the "latest EPIC software" you say you have. Have you looked through it all? 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.