Pete Dowson

It is easy to prove. Delete the FSUIPC.KEY file. Now see if those programs run okay. None of them need a user-registered FSUIPC in any case, they are all accredited aircraft. You only need to pay for FSUIPC is you want to use the additional facilities. But you paid for ATR Flight 1, PMDG 737 NG, PSS A320 Phoenix? Or are all those stolen too? You think FSUIPC is an easy program to write and maintain, despite it being a full time job for five years? You think I should give it up and do something else for a living? :cry: Pete

What's a "replied" key please? Do you mean you are illegally using someone else's key? :cry: And you even expected support? Hmm. :x To register FSUIPC (or WideFS) correctly and legally as a full user you need to purchase the key from one of the suppliers. The easiest way is to go to SimMarket. Check http://secure.simmarket.com/product_info.php?products_id=538. Regards, Pete

I think you should be able to include pictures actually in your message, probably by using the "Img" button instead the the "URL" button. But your way does at least keep the message size down, and is better for those who don't want to look at the pictures. This is tremendous. I am very jealous of your practical abilities, for I have none. I can just about wield a soldering iron and build circuits -- provided I have good clear instructions, but when it comes to making anything solid that works or looks good, count me out. I have to stick to programming! :wink: Thanks for showing us, Regards, Pete

Hmm, those are certainly the correct details for the program as notified to me, so the Key should work -- if it is built into the program, as it should be. In order for me to determine whether it is writing the key correctly, could you repeat this test, exactly as above, only before loading FlightTracker go into the FSUIPC options (ALT M F), find the Logging page, and enable IPC read and IPC write logging. Keep the session short again. Remember to turn off the extra logging next time you load FS or it may make rather large files. If the Key is not built into the program then I can only assume either that it is an older version, or that the author intended that user's should manually enter the key. But then the latter would be published with the documentation. Since the Key was issued way back in July 2003 and this is the first such inquiry I've had, I can only assume something is wrong with the specific package you have. However, let me see the fuller log, then we will know and you can be more specific when you request support from the suppliers. Regards, Pete

Sorry, you misunderstood me. I currently use is Visual Studio .NET 2003, but of all the stuff they forced me to pay for, all I use is C and the excellent debugger (the latter being the main reason I moved up from Version 6). The Visual C++ system handles C or C++. It's one of the arcane ritualistic properties, somewhere deep in the menus. If you find your compiler and linker properties and show me them I'll compare them to mine and tell you what's different, if you like. Regards, Pete

FlightTracker was granted an FSUIPC access code in July 2003. As far as I know it uses this to gain automatic access to FSUIPC, with no special action needed by you. Please let me see the FSUIPC log file. Regards, Pete

I only use C. Possibly you need to put some sort of C wrapper around the declarations so that it doesn't mangle C names like I think it does with C++? I'm afraid all those Microsoft C/C+ compiler settings are a rather an obscure black magic art to me. I just do the simplest things, like add the library to the list of libraries it says it wants, and to make sure the LIB file is in my project folder where it can find it. Surprisingly, I've not had this sort of question in all 5 years since I supplied this stuff, so there must be a lot of folks who know what to do, precisely, for C++. I hope one of them can jump in and help. Regards, Pete

Run any one of those which has a problem, close FS, ZIP up the FSUIPC.LOG and FSUIPC.KEY files you will find in the FS modules folder, and send them to me at petedowson@btconnect.com. It sounds very much like a user registration problem. I very much doubt that it is a problem in 3.411, but so far out of several reports no one has sent me the files I need to resolve this. Regards, Pete

Version 3.xxx registrations cover ALL version 3.xxx issues. If it is a legitimate access key you should have no problems. I am concerned by this. Please Zip up a complete FSUIPC.LOG (after FS is closed) together with your FSUIPC.KEY file and send them to petedowson@btconnect.com. Regards, Pete

That's part of FSUIPC's heading data. It is always there. Have you enabled IPC read/write logging? Please show the file, not one line. Oh, that. Just add 'FS2004' to the end of the list and change the array size to 7. As you saw, FS2004 is #7. That's why I asked to see the FSUIPC log with the IPC logging enabled. Hmmit sounds rather like something may be wrong with your registration. What happens if you temporarily remove the FSUIPC.KEY file from the FS modules folder? Let's start againPlease do as I said to start with, i.e. ... enable IPC read/write logging in FSUIPC's logging page, run it, get the error, then close FS down, the Log file (FSUIPC.LOG) produced in the FS Modules folder will tell me what is going on. Regards, Pete

I'd really much rather understand WHAT in the manuals you don't understand. This is the only way they'll get improved so that I don't get asked the same questions over and over. I told you exactly what to do in FSUIPC. Did you manage that? Please clarify exactly what it is you are asking and why things are so obscure in the documentation. :cry: Regards, Pete

The source code shows where it checks these things, so as you are an expert in Delphi you would be in a better position to tell me what is going on. (I don't know Delphi at all). However, if you enable IPC read/write logging in FSUIPC's logging page, run it, get the error, then close FS down, the Log file (FSUIPC.LOG) produced in the FS Modules folder will tell me what is going on. Are you using a user-registered version of FSUIPC? Hmmm. The file "FPCuserIntf.INC contains this: // Supported Sims SIM_ANY = 0; SIM_FS98 = 1; SIM_FS2K = 2; SIM_CFS2 = 3; SIM_CFS1 = 4; SIM_FS2K2 = 6; SIM_FS2K4 = 7; The last one is for FS2004. What makes you think is isn't supported? Are you by any chance using a very old version of the SDK? Regards, Pete

This is WeatherSet.exe? (Not WeatherSet2.exe, which is only for FS2004). Correct? What version of WeatherSet (right clock the EXE and check Properties-Version). What version of FSUIPC? Run it, run WeatherSet, get the error, then close FS and show me the FSUIPC.LOG file (from the FS Modules folder) please. Regards, Pete

Neither FSUIPC nor WideFS send keystrokes or buttons over the connection to Clients. There is a mechanism in WideFS caled "KeySend", which sends an arbirary reference number across, 1-255. All you do it program a key or button in FSUIPC to operate the KeySend command, with a parameter 1-255 to identify it. Then in your selected WideClient.ini file you declare the key Press you want that KeySend number to create. This is covered in the WideFS documentation, and the KeySend is also mentioned in FSUIPC documentation. Please do have a look sometime. WideServer.ini doesn't come into it any more. That method, designed for ISA Epic cards, has not been the best method for several years. Regards, Pete

No, neither. The only thing that can stop it working is the one documented in the FSUIPC User guide: Sounds like you've changed that option or reinstalled video drivers or something, making that Windows option come back on. BTW, version 4 of FSUIPC isn't available for quite a while yet. You mean 3.411. Regards, Pete

Hey, how on Earth did you work that out? That's brilliant! I must give that a try when I get time. Incidentally, the GPSout.INI parameter is "Port" not "Ports". Thank you very much! Looks like I should add this to the GPSout files -- shall I credit you? If so would you rather a different name entered than "FunkyMunky"? :wink: Regards, Pete

Oh, what they used to be called the EFIS display -- there were things for that in FS98 and FS2000. Check the FSUIPC SDK Programmer's Guide, offsets 0E5A through to 0E68. I've no idea whether any of that still applies in FS2002 or FS2004. It looks like no one has ever tried it. If it does then you try setting an on/off control by using the Offset Word Togglebits control (in FSUIPC) with offset x0E5A and parameter 1. Try the FS2004 Forum, not far from here. Or else experiment with some of the assorted Pan and Eyepoint controls available. Sorry -- I haven't an answer. I would have to experiment to find one in any case, same as you. Regards, Pete

Just to note that you should do all the reads and writes you want to do in each "cycle" of your program, whatver, then one Process call. The FSUIPC_Read and Write calls take no time at all and do not invoke FS or FSUIPC, but every FSUIPC_Process call means a process switch into FS and activity in FSUIPC to heed your requests. If you are simply responding to humans pressing buttons and so on, then the single Write/Process sets as you have there will be okay -- with each being instigated manually there is no performance hit to notice. But group them when you do have several things to read/write. Regards, Pete

No, sorry, I have absolutely no idea how to do that. Regards, Pete

Not sure what you mean. Have you got is assigned separately in FS? What are you seeing that indicates it won't "calibrate separately"? Always check things with default aircraft. If you want to assign functions in something like the PMDG or PIC aircraft I think you have to use their keystrokes. They do their own autopilot which is separate from FS's. I don't know what that is. If the CH buttons look like buttons to FS you can assign them in FS, or, for a wider choice of functions and the possibility of keystrokes (eg for PMDG aircraft) you can assign them in FSUIPC. Also, with FSUIPC, you can make assignments for PMDG aircraft specific -- FSUIPC will automatically change according to what aircraft you load up. Regards, Pete

It does? That amazes me, and shows how little I know about VB. I would have thought that: Dim doGear(4) As Long would define an array of 4 longs (i.e. 4 32-bit or 4-byte integers). Does it not? If it does, then Call FSUIPC_Write(&HBE8, 4, VarPtr(doGear(1)), dwResult) would only write the first one, which contains hexadecimal FF -- or does it? To write all 4 parts of the array you'd need a length here of 16, which would then overwrite the actual gear position values (but not for long as I think Fs would quickly replenish those). I am thinking here that what is really happening is that your doGear(1) = &HFF is actually setting "doGear(1) to &HFFFFFFFF. This would be that strange invisible extension which VB seems to do secretly and which keeps cropping up here in the Forum. If you set it as &HFF& to stop it doing that, then I expect you'd only write hex FF to the gear, not enough to operate it. If I am right, then your other declarations: doGear(2) = &H3F doGear(3) = &H0 doGear(4) = &H0 are a waste of time and space. Why not just declare "doGear" as an integer, not an array, and set it to &H3FFF? Or even more in keeping with the documentation, set it to 16383, as defined? On your other question, I think (but I am not 100%) that the WriteS variant was added because of the way VB treats strings -- apparently strings are passed by value in VB not by pointer as in C/C++. The different declaration of the WriteS variant helps sort the VB compiler out. I hope someone who knows more than me about VB will jump in and correct anything stupid I've said here. Regards, Pete

Good! Thanks for confirming! Regards, Pete

I've fixed it in an interim test version of FSUIPC, which I did send to the original reporter (though I've not heard from him since then). Do you want one as well? Otherwise it will be fixed in the next official release, early December I expect. Regards, Pete

No, sorry, it would be impossible to maintain. But pretty much anything which is an external program to FS and interfaces to it through FSUIPC is a potential candidate. Some of these have links on the http://www.schiratti.com/dowson page (right-hand side). Really I think you are going about it the wrong way. Work out what you want to do, then find an application which will do it for you. FSNavigator not only is not an external program (it forms part of FS), it doesn't use FSUIPC at all. As for others, I think there are a few though I can't think of all their names off-hand. The ones that spring to mind are Project Magenta's QuickMap and Ted Wright's "NAV3" (or it may be later now -- I'm a bit out of date with these things). There's also a package called CoursePlanner, which you can use on a network without WideFS -- see http://forums.simflight.com/viewtopic.php?t=28211. I don't know much about it apart from what was said in that thread. Regards Pete

Yes, you would need 2 because you are trying to transfer 32 bits (4 bytes) or data whilst the axes can only transfer 16 bits (2 bytes). 07D5 is the second byte of the 2 bytes used for the 16 bit value in 07D4! They don't "work", they are just addresses, numbers. In Intel processors, memroy is referenced by addresses. Each byte has an address, from 0 up to whatever memory size is used. "Offsets" are merely differences from the start of a block of memory to where the specified data is. 07D4 is hexadecim 7D4 bytes offset from the start of the reserved FSUIPC memory. The hexadecimal number 07D4 is decimal 2004, so there are 2004 bytes lower in that memory. The word "offset" means just that -- "set off, or away from". As documented in the EPICINFO documentation!!! It is listed there as an EpicInfo parameter -- how come you found the FSUIPC_WRITE stuff and by-passed all the easier ones? Sorry, I am trying to advise from memory. I've not used EPIC for years. I think most people now use FSCommunicator or something else, whiich is probably easier to use, than my EPICINFO stuff which was designed mainly to work with the IPC.VXD on Windows 95 with an ISA EPIC Rev D board. As I said, I think the AP ALT VAR thingy uses feet. Certainly not feet min though. I don't really know where you are getting your terms from in any case, but in Microsoft C/C++ the term "WORD" is reserved for a 16 bit unsigned number whereas a "short int" is a 16 bit signed integer. Similarly Microsoft C/C++ uses "DWORD" (for "double word") for 32--bit unsigned and either "long int" or just "int" for 32-bit signed integers. 8-bit bytes are just "char" which may be signed or unsigned depending on compiler options, or "BYTE" which is unsigned The "smallint" may be 16 bit or even 8 bit for all I know. Where are you looking? If it is FSInterrogate then I think the terms there are from Delphi, which I don't know, but there are separate terms for 8-bit, 16-bit and 32-bit unsigned and signed numbers there. They should be reasonably intuitive to work out, otherwise try the documentation. If you need more help with EPIC I would recommend trying the new EPIC forum. I think it is http://www.simengineers.com/yaf/default.aspx. Regards, Pete