Pete Dowson

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

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

For spoilers it is easy enough to assign an axis in FS's own Options-Controls-Assignments dialogue. Scroll down the Joystick axis assignments and you will see it. FS2002 does not provide such a method for Trims and Flaps. You have to "cheat" by assigning a different axis, one that FS does recognise but which you are not otherwise using. You can do this in the FS assigments too, but then you need to determine the NUMBER of that FS axis control -- there are some suitable ones listed in the FSUIPC Advanced Users Guide, but for a complete list you can download the FS controls documents from the Schiratti site. Then, armed with the numbers so assigned, you have to edit a couple of parameters in the FSUIPC.INI file, in order to tell FSUIPC which axis controls to intercept and divert to trim and flaps. All this is actually explained in the Advanced Users Guide. It isn't part of the normal user interface as it is an unusual thing to find enough spare axes for these things except on cockpit-builders systems, and these are "advanced users", at least in my book! Pete

For spoilers it is easy enough to assign an axis in FS's own Options-Controls-Assignments dialogue. Scroll down the Joystick axis assignments and you will see it. FS2002 does not provide such a method for Trims and Flaps. You have to "cheat" by assigning a different axis, one that FS does recognise but which you are not otherwise using. You can do this in the FS assigments too, but then you need to determine the NUMBER of that FS axis control -- there are some suitable ones listed in the FSUIPC Advanced Users Guide, but for a complete list you can download the FS controls documents from the Schiratti site. Then, armed with the numbers so assigned, you have to edit a couple of parameters in the FSUIPC.INI file, in order to tell FSUIPC which axis controls to intercept and divert to trim and flaps. All this is actually explained in the Advanced Users Guide. It isn't part of the normal user interface as it is an unusual thing to find enough spare axes for these things except on cockpit-builders systems, and these are "advanced users", at least in my book! Pete

Both WideServer and WideClient automatically produce log files, called amazingly "WideServer.log" and "WideClient.log" respectively. They are in the same folder as the INI files you provided. They are mentioned in the documentation and always contain the full story. Pete

Both WideServer and WideClient automatically produce log files, called amazingly "WideServer.log" and "WideClient.log" respectively. They are in the same folder as the INI files you provided. They are mentioned in the documentation and always contain the full story. Pete

these are only the INI files. I also asked for the LOG files. It is the LOG files that tell what is going on! Pete