Pete Dowson

A difference in email address between FSUIPC3 + WideFS6 and FSUIPC4 + WideFS7 won't stop you registering -- the keys for FSUIPC4 and WideFS7 must have the same name and email, as must FSUIPC3 and WideFS6, but those details are only kept in the KEY file which is stored in the Modules folder for the specific version of FS. So, something else is going on which is not evident from your explanation. Perhaps you should send all the details to me at petedowson@btconnect.com (please be sure to ZIP any attachments), and explain what you do and what you see. Regards Pete

I don't know what this has to do with FSUIPC, but all versions of FS have swtched to outside view to show the crash. Then the last loaded Flight (or last Saved Flight) is reloaded so the view swityches to whatever that flight had. As always, FSUIPC provides such axis assignments if you need them. You have to purchase it though. Pete

Sorry, I've no idea what it is or how it would be referred to in MSFS. Is this something to do with that mysterious "helicopter beep"? Is it a simple on/off switch, or some sort of axis/dial? For things simulated in FS, references to specific things actually in FS would help. If it isn't simulated then you would just have to have a dummy switch. If the "Helo Governor Beep" adjustment is what you want, then the controls INCREASE HELO GOV BEEP and INCREASE HELO GOV BEEP should work, I would have thought? Searching the List of FS2004 Controls also reveals these, which may or may not be relevant: ROTOR GOV SWITCH SET ROTOR GOV SWITCH TOGGLE Regards Pete

Yes, I understood that. It is just that you were referring to specific entries within such a range so in order to cross-check I have to read through them. search through them to find out what you are talking about. A specific data reference needs a specific offset value, please. It probably works in FS2004, it's just that I haven't had time to test it and update the document. I tend to rely on feedback. Why not try it? You don't need to write a program for that, simple use FSInterrogate. Where are you referring? Originally there were some like that (all those in the second table), as they were mapped-through areas of FS memory which folks found by experimentation and consequently labelled them for me. I provided the information but could not guarantee to do the same in every version. Gradually many of those moved from that second table to the first -- the first table are all supported as far as possible in all relevant FS versions. If they don't work and folks report that I undertake to fix it. I don't undertake such for the second table, in general. Examples? I would be very very grateful if you could try to be more specific. I cannot work on generalities. Sorry. Regards Pete

No. The single byte switches in 3102 and 3103 were implemented in FSUIPC by operating the relevant FS controls (i.e. just like using FS control assignments). The 2xxx ones are mainly derived from originally unsupported mappings directly into FS2000 or 2002, direct into FS's memory. There was a whole batch labelled "not necessarily supported ..." (in fact there's still some there, in the separate table at the nd. Unfortunately (for me) quite a few folks used them directly so I had to move them into the supported table. So now I have to make them work in each subsequent release in any case. No difference. 3101, alternator switch, is listed. What else are you talking about? If you have any question about offsets it is best to actually say what the offsets are, not use "XXX" as I cannot check that. FSX offset status is provided in a separate document available in the FSX downloads. Regards Pete

TCP is a connected protocol. The process of creating a socket and getting data across involves, for the Server (with parameters omitted for now): WSAStartup(..., ...); to initialise WinSock SOCKET s = socket(..., ..., ...); to get a socket assigned a series of setsockopts according to needs bind(..., ..., ...); to associate an address with the socket listen(..., ...); wait for a connection WSAAsyncSelect(..., ..., ..., ...); to send message to window when a connection attempt is made The action on the Client is different, but equally complex. In both cases either a separate thread has to be used or a lot of trouble is taken over getting everything to operate asynchronously and thus not ruining performance. I've left out all the errors checks and clean up actions they need. And even UDP involves most of those steps. I think you just miss out the "listen" bit. Now, tell me, how do you see that as equating to your "All that needs to be done is open a Winsock socket connection to the specified port of a specified IP address."? Let me see your code (in C please), without using any fancy libraries not available or not wanted inside the FS process. I am on holiday from late tomorrow (Thursday) until Monday 25th June. Maybe you'll have some easy short source code by then? Honestly, nothing I've seen in networks is as simple as you are making it sound, so I'd really like to see this. Regards Pete

I still don't really understand. What protocol does TelNet use? All my Network programming has been done by using th WinSock interface, which is completely different (no similarity whatsoever) with what I do to drive a serial port. I just can't imagine how one can be mapped onto the other. Is it connectionless like UDP? If not who does the connection and who does the listening? Maybe I don't know enough about Networks. All the stuff I did in WideFS was copied direct from MS examples. See, that's where I'm lost. What does "redirect it to TCP" mean? TCP is a protocol. Yes, its datagrams can contain data, but there are connections to be made. The making of the connection is asymmetric -- WideServer and WideClient for instance are different, even though they indulge in two-way data exchanges. There is a "mailshot" facility in Windows XP and later, which I use for the server to broadcast its availability to any who may listen. I suppose that could broadcast GPS data, but will anything be listening for specific broadcasts. They have to know what to expect. I'm not averse to adding facilities if they will be genuinely useful, it is just that I don't understand what I'd have to do in this case. Do you have any examples or specifications? Regards Pete

I doubt it, unless such names can take the place of device names or filenames in standard I/O operations. What would be receiving the data at the other end? I don't know of any specification for NMEA data to operate over Networks. If you set the port to WideFS it is already sent over the Network, but of course the receiving program has to operate the WideFS protocol. I really cannot imagine what the application for anything like you are suggesting could be. Perhaps you could elaborate? What Network protocol are you thinking of anyway? Regards Pete

No, the FSUIPC.FSI file is maintained by me as well. It's just that it is not the full documentatin, no where near. Just enough words to get by -- the reference always must be the Programmer's Guide. There's no way all that stuff is ever going to get entered into the FSI file, at least not by me. Of course you can add your own notes. FSInterrogator wasn't originally going to come with any of that data, just a partial file as an example. It was expected that its users would build up the datas themselves as they got to know different parts. It is all completely user accessible. Really I cannot think of any reliable way of getting the details of the plan other than reading the Plan file itself. Unfortunately I don't know how to get the plan filename in FS9 or before -- it is already provided in FSX (offset 0130). If the plan is loaded as part of a Flight you can of course read the FLT file and get the plan filename from there. Regards Pete

Sorry, apart from the fact that is a members-only forum, I've not really got time to delve into problems of other products. I am desperately trying to tidy stuff up here for version 4.12 before I leave for a holiday very early on Friday morning. By all means, feed back into that thread my comments if there are others also losing the base version SimConnect by following some, presumably incorrect, instructions. Well, it is a long way around and may, if one of those installations is still doing the wrong thing, still end up with you in the same boat. Try the repair first (insert the DVD 1 and select repair). Regards Pete

Okay, the problem is that the base SimConnect version, the one which came with FSX on the original DVDs, is not installed, or at least it isn't installed correctly. The section of the Install log above should read like this: Checking compatibility with installed SimConnect: ... Okay, Probe Manifest matches installed SimConnect 60905 (Original) Found later build SimConnect 61242 (SP1 May07) The original SimConnect ALWAYS needs to be present as it is that which loads FSUIPC4. I don't know how you managed to lose the original installation, but the only way to move forward is to repair it. Please refer to the FSX Help announcement above for re-installing SimConnect. Note that you shouldn't have to repair the SP1 update as well because that Simconnect update is installed okay. FSUIPC4 will use it, it's just that it won't be loaded because only the original version, which must always be present, will do that. Could you tell me what you actually did to lose the original SimConnect installation? It shouldn't be possible. I hope the LevelD install doesn't do such a nasty thing! I may have to add more warning messages for this to my Installer! :-( Regards Pete

Did they say why? It sounds like their install messes up the DLL.XML or SimConnect.XML files. Naughty! Is the an Install log there? If so, please paste it here. Is there an FSUIPC4 log there? Ditto. I can't help without any information I'm afraid. Pete

No idea. I'm afraid I'd need more details. Are these keyboard shortcuts direct to the add-on aircraft's panel? Are you using FSUIPC or what? Possibly these subsystems are handled by the add-on aircraft code and you are instead trying to use the built-in FS facilities which don't apply? If you are using standard FS controls, test them on default aircraft first. If they work on the defaults but not on an add-on aircraft it is because that add-on does its own thing. Does the aircraft come with any documentation on how to deal with these subsystems? If it only supports mouse clicking for some of these things when I'm afraid the only way is to use something like Luciano Napolitano's "Key2Mouse" program. But many add-ons do allow keypress assignments (certainly PSS and PMDG aircraft in any case). Have you checked? Regards Pete

Sorry, you must have made an error then as you clearly said And I understood this okay: You are mixing up a typo correction with a total misunderstanding for some reason. Okay. Sorry then. Evidently the chap who decoded all that got it wrong. I'll delete it, or at least comment it as suspicious .... ... ah, hang on. It is already so marked in my copy of the list. It says "This appears to have been optimistic. I can’t find the destination ID" Isn't that in your copy? Regards Pete

Okay, I'm letting you know now. Yes, it is a bug in FSX and it will be fixed in the next FSX update -- the one due late this year with the DX10 support. Regards Pete

Not sure why there's any difference in full screen mode. ALT is not a good key to use as it tends to enter Menu mode -- are you sure that isn't what is happening? Why do you need to use ALT in any case, and what have you programmed that short cut to do? Regards Pete

Departure airport you mean? Sorry, then. I have no idea. maybe it only gets filled in when it is "current" (i.e. you are dealing with approaches)? FSUIPC only provides a straight mapping through to the memory area inside FS containing that stuff, as found and identified by another user. I guess he must have seen it there in some circumstance? Regards Pete

I've never really used any of those offsets, they were documented after being supplied by another user. However, I think you need a flight plan for most of those to work, else it can't know much about where you are going. Is this after filing a flight plan? Pete

Does this work even if you don't file a flight plan? Pete

Didn't you use that powerful facility called "search" at all? That's all I had to do! For FS2004 and before I would have thought the values in offsets 83xx were sufficient. Just searching on "view" should have found those for you quite quickly. The same offsets are listed in the FSX offsets status but as not available (yet). They are one of the facilities missing in SimConnect still, hopefully for rectification in some future update. Of course the FSX view system is all changed, being very much based on "cameras" which can be user-defined. How we can map this to the old offsets remains to be seen. Currently SimConnect provides ways of setting cameras, but no ways to read their details. Regards Pete

The programming routines can be identical if you read the data into your own structures, as I said. You don't have to read the data in offsets en bloc. The list of Reads can place them values where you like. If you care to bypass the FSUIPC_Read and FSUIPC_Write procedures you can even simply pre-define the read and write data structures for copying directly into the memory-mapped file area. I use this technique in several of my programs. The FSUIPC_ series of calls are only wrappers to make things easier. The sources are all provided, so you have the ultimate flexibility in how you do things. I cannot move stuff around for you without breaking all the other programs which have been reading this stuff for that last 7+ years. You must surely see that? Regards Pete

If only folks would read them! ;-) Pete

More luck than judgement I suspect, as different parts were discovered at different times. Mostly the NAV1 items date back to FS98 or even before, whereas some of the NAV2 facilities came later. Just read them all and rearrange them to suit your code, if you wish. Well, I cannot change the offsets after they've mostly been that way for about 7 years -- it would break a lot of programs. Obviously, after you've read the data you can sort it however you like. In fact it isn't actually that hard to write the list of FSUIPC_Reads to read them into your structures in the exact order you want, irrespective of actual offset values. Just think of the offsets as "names" or "tags" rather than numerical positions. Regards Pete

Thank you! Just one little correction. The AV400 protocol isn't actually "NMEA". Maybe that GPS range doesn't accept NMEA inputs, except possibly for waypoint or routing data --- not many Garmins seem to. I hope you don't mind if I add your notes to the little bit of GPSout documentation that exists? Regards Pete

Two points already. 1. 04FA is not a byte but a word (2 -bytes, or 16 bits). 2. Why are you messing about in the INI file when you can do all this in the FSUIPC options much easier? Did you not refer to the section all about this in the User Guide? It tells you all about specifying LIMITS there, which you have ignored altogether in yuor attempts. Because the lower limit is zero, as you've set by omitting it. Because the upper limit is zero, as you've set by omitting it. Please delete all the stuff you've added manually, then load up FS and go to the FSUIPC Options. Select the Buttons (or Keys) tab, and follow the instructions in the USER manual, not the Advanced Users manual. Use the WORD operations, as appropriate to the value you are addressing, and either unsigned or signed depending upon whether you want to allow decrementing/incrementing between DH and MDA values. I'm sure I referred you to the correct documentation earlier? :-( Regards Pete