Pete Dowson

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

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

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

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

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

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

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

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

I don't know of one. If anyone does, please let me know too! Pete

I don't know of one. If anyone does, please let me know too! Pete

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

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

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

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

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

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

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

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

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

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

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

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

If by "hex.address" you mean access values in FSUIPC, then I'm afraid you are out of luck. When programmers make panels like those they do their own thing, within their own code, and do not usually export it in any way accessible to FSUIPC. The only definite exception I know about is Project Magenta. The 767PIC version 1.3 does allow access through a DLL I think, but I don't know if they make it available. Certainly I've never seen any official documentation for it. For others I think you can really only resort to programming mouse clicks -- something like Luciano Napolitano's "Key2Mouse" program could be used to convert keystrokes to mouse clicks. Regards, Pete

If by "hex.address" you mean access values in FSUIPC, then I'm afraid you are out of luck. When programmers make panels like those they do their own thing, within their own code, and do not usually export it in any way accessible to FSUIPC. The only definite exception I know about is Project Magenta. The 767PIC version 1.3 does allow access through a DLL I think, but I don't know if they make it available. Certainly I've never seen any official documentation for it. For others I think you can really only resort to programming mouse clicks -- something like Luciano Napolitano's "Key2Mouse" program could be used to convert keystrokes to mouse clicks. Regards, Pete

Sorry, but there is really no way possible to use different parts of an FS panel on different PCs without an installation of FS on each one. Each part of an FS panel uses so much code inside FS that it is completely dependent upon it. WideFS can only link EXTERNAL programs to FS over the LAN. If your client PC is powerful enough for FS then you can try linking multiple copies of FS together, but this involves WidevieW (by Luciano Napolitano) not WideFS. Even then, from what I've heard, the panel parts aren't actually driven correctly on clients, so you'd need to run the panel on the server and use the Client for views. All in all you'd be much better off using multiple monitors on an single PC. You can undock panel parts and simply drag them onto the other monitor. Regards, Pete