Pete Dowson

And are they in the same workgroup, as instructed in the "configuring your network" section of the User Guide? If the Network is okay and both PCs are in the same workgroup you shouldn't have to make any changes whatsoever. I don't know what you mean by "and so forth", but you only need to set the Server name or IP address and the Protocol if you insist on keeping your PCs in different workgroups. Sorry, nor do I, and I don't know what that means. No, they explain nothing about what is happening on your system because they are simply the parameters defaulted and used by WideFS in any case, so I know them well (I did write them after all). The files which tell us what is happening are the Log files, one of which is always produced by both parts. So show me those instead. Incidentally, although you said "We went over the .ini files to set the IP adresses and so-forth" in fact there is no sign at all of any such parameters being set in the copy of the INI you showed! Seems you were editing something completely different and not related to WideFS? Regards Pete

You don't need an FSUIPC command. Those are the idle/cut off switches, operating the fuel valves for the engines. They are controlled by FS controls "MixtureN Lean" (cutoff) and "MixtureN Rich" (idle) where N is the engine number (or omit for generic all-engine controls -- the same ones assigned by default to the Ctrl+Shift+F1 and Ctrl+Shift+F4 keys I think). Pete

They only disappear if the mouse trap cannot be set. Maybe you forgot to update your FSX installation? It does say this in the first two lines of the Mouse Macro chapter in the FSUIPC4 User Guide: NOTE: These facilities need FSX with at least the SP1 update incorporated. Macro files should work with the original version of FSX, but the easy user macro creation facilities will not be available. Regards Pete

You are sure about what? Sorry, I don't understand. As for suggestions: If you want to implement hardware solutions for a complete cockpit simulation, including the overhead, you need to either use external cockpit simulation software, such as Project Magenta, Sim-Avionics or FlightDeck Software, or choose an aircraft add-on which provides a development kit which allows such an interface, like Level D aircraft. The simulation of subsystems actually built into FS itself is quite rudimentary by comparison, and sadly many of the more sophisticated add-on aircraft do not provide any way to hook into their internal workings. for Wilco aircraft you can ask them if there is any solution, as I suggested already. Regards Pete

There are no built-in FSUIPC offsets for non-FS functions, and not even for all those FS simulates. FS doesn't in fact simulate much of the overhead action at all. Add-on aircraft often do, but they all do it their own way. Wilco may be using FSUIPC for some of their stuff, I don''t know, but you may find out more on their support site. Regards Pete

Ah, sorry, I missed it! The log shows everything is working perfectly, all of the correct keystrokes and messages EXCEPT that there are no WM_KEYDOWN messages arriving from Windows for the Control or Shift keys whilst you hold the Button down. Something about that button being held down is clobbering something in Windows, or possibly there's a joystick driver or another program stealing those messages before FS (or really FSUIPC) sees them. I've no idea, but it certainly cannot be anything either FSUIPC or IYP is doing. And FSUIPC doesn't get a chance if the messages don't arrive. Let's try some experiments. 1. Leave the microphone switch deactivated so you don't have to use it to make things happen. But use it in any case. What happens? 2. Still with the option off, see what happens if you simply hold a different button down, one not related to this but programmed to do something else. 3. Same as 2. but using a button not programmed to do anything at all. 4. Same as 2 and 3 but using a button on a different joystick, if you have one. 5. Instead of programming the one button which you hold down, could you possible find another? Program one to switch the mike on, and the other to turn it off, so you don't have to hold it down? See if that makes a difference. If you have no other button let's reprogram that one to toggle on and off with alternate presses. Maybe with answers to those questions we'll have a better idea of what is going on. At present it looks very strange. The KEYUPs are definitely arriving, but something is swallowing the KEYDOWNs. Could you list any other add-ons or programs you have running at the same time, please? I'm getting suspicious it's another utility doing this. Regards Pete

Oh, right. I use "PTT" as the term for my on-yoke mike switch. I'd want to use the same no matter who I was talking to. Maybe it's a good job I don't (currently) fly on-line! No, it me who doesn't understand. Okay. And you've used that in the session where you lost the use of the Shift key? It's not so much likely that anything is blocking anything, only that the "KEYUP" message in Windows is being lost, so the Control and/or Shift keys look like they are still pressed down. A keypress like "Ctrl+Shift+1" involves 6 separate messages which have to be processed through Windows then through the FS Window procedure: WM_KEYDOWN for Shift WM_KEYDOWN for Control WM_KEYDOWN for '1' then a short delay WM_KEYUP for '1' WM_KEYUP for Control WM_KEYUP for Shift This why i hate keypress dependent programs. Radar Contact registers its key-press requirements with FSUIPC, and thereafter FSUIPC looks out for them. IYP sends keypresses by invoking a keypress control in FSUIPC which makes is send that sequence to FS's Windows Procedure. FSUIPC intercepts the keypresses in the Windows procedure, sees they are for RC, and flags the event for RC to pick up. All of that should work fine, though it could conceivably get messed up by other programs sending keypresses, or the real keyboard being used, right in the middle of the sequence. That is very unlikely, though, as it is all over is milliseconds. The IYP control to activate the microphone input to IYP is completely separate from that and involves no keyboard messages whatsoever. This is why I don't understand how it could possibly have any bearing. The log I asked for should show the sequence of KEYDOWN and JKEYUP messages. If it is large, ZIP it and send it to petedowson@btconnect.com . Regards Pete

I'm even more confused now. By "PTT" I mean "push to talk" -- a button to enable your microphone, so you can talk to IYP. Whay's the difference between that and a microphone switch? Ok. Er, yes I know. But you said all of your IYP commands to RC use only Ctrl+, not Shift+Ctrl+ Since nothing is sending the Shift key I can't see how it can get locked. Regards Pete

Easy with a Lua plug-in. You use the event.offset facility to call a function whenever that offset changes, which checks the new value and sends the keypress when appropriate. Regards Pete

I use them all regularly. They make a very good combination. They cannot be at all related, unless you are using a conflicting keypress for your IYP mike switch. Are you assigning the mike switching button to the special IYP PTT controls in FSUIPC? If so, then there's no keypress involvement whatsoever, so no possibility of any interaction. I use the standard Ctrl+Shift+But then I always have, ever since I started using RC many years ago. I was not aware IYP even had an "alternate" mode. It surely cannot work then? I have to have the facility Active for the PTT controls to work, I'm sure. I do, in any case, and this was under Robert's original instructions. That's okay. I assume you don't have it repeating? In that case there can be absolutely no interaction between it and any keystrokes used by any program. There's no use of keys, keystrokes, keyboard, nothing, with those IYP controls assigned from a button. Without holding the PTT button down? That's not right! Erwhy? You said you had a button for this. Why aren't you using it? And if the mike switch was off before this, how is IYP relating your "turn right" instruction as you just stated? Something is very mixed up here! Well, I'm confused by your sequence in any case. Well, I've no idea what IYP is doing on "enable" and "disable" microphone switch. I assume this is the same as the checkmark you don't have in the Options? I have that checkmark always set and never use "enable" or "disable" microphone switch. Maybe you could try eliminating its use too? If IYP is genuinely sending the correct keypress then nothing to do with microphone button actions is going to interfere. This is the problem I have. "Steams"" meaning what exactly? And how does "shift" come into it when you don't use it? Hmm. It is certainly sounding like IYP is doing some extra unwanted keyboard actions when this "enable microphone switch" command is used. There's no other possible explanation -- it should simply be responding to Windows broadcast messages, totally unrelated to the keyboard. That is certainly how the FSUIPC YP control work, and it is certainly fine using the Option checkmark, no use of the "enable" "disable" command. Are you sure those aren't intended for use with on-line ATC programs or IYP's user intercomms facilities? You need to do some logging in FSUIPC to show what is happening. But first download the very latest FSUIPC update (4.616) so we are both on the same version (see Updates announcement). Then enable Button/Keys logging. Reproduce the problem you just mentioned (Ctrl and Shift locked) and show me the log. Also, perhaps you'd try to explain how Shift comes into it when you've nothing using it? Note: it is a busy weekend with the World Cup, which I am absorbed in, so it may be Monday before I can look at it. Pete

The SDK is free. I hope no one has charged you for it! Regards, Pete

The FS coordinates are not "8 bit doubles" or even "8 byte doubles", but 64-bit fixed point integers. Doubles are floating point, something completely different from "fixed point"! The formulae are given in the Offset tables which are included in the documentation in the FSUIPC SDK. I'm rather surprised that you are attempting to interface to FSUIPC without reference to the SDK. It certainly does support 64-bit doubles -- they are the only "doubles" any 32-bit language supports on Intel type processors. However, it is not doubles you need. Please do refer to the documentation. You need 64-bit integers, defined by __int64 in Microsoft C/C++, and probably something along those lines in Microsoft VB. You need a reference guide for VB to determine the correct declaration. I have seen folks refer to something called "currency", but that seems rather obtuse to me. It might just be "Long", but that is a 32-bit integer in 32-bit C/C++ compilers. Some references talk about "long long" but that's probably an ANSI or ISO C/C++ type. Regards Pete

So, in the calibration you have "no reverse zone" checked, and the calibration done accordingly, right? If you've calibrated without a reverse zone I don't know of any way of using the lever to get reverse, unless you are operating that button you speak of. Sorry, I've no idea how you manage to get reverse with only forward thrust calibrated. I think you need to seek support from the aircraft makers. It sounds like they have some odd arrangements. Have you checked it with the FS default turboprop aircraft at all (like the King Air)? Also, be sure you are using the latest updates for FSUIPC -- please see the Updates announcement above. There were some changes for some aircraft, though your problem does not ring a bell. Regards Pete

Well, all this is explained, probably in a different way, in the FSUIPC docs somewhere, but here goes ... The FSUIPC interface is derived from an original design by Adan Szofran, for FSW95 originally and updated for FS98, which simply provided access to a module in FS called "Globals.dll", in which most of the variables which FS cared about were stored and activated from. In that interface the "offset" was a genuine offset (i.e address difference) from the start of the Data in the GLOBALS.DLL. The fact that the data moved about from release to release (i.e. from FSW95 to FS98) was irrelevant to the interface as it was then -- it was up to the implementer of applications to work out what was what. Folks simply had to modify their programs for each FS update. When Adam gave up (he was recruited into Microsoft) I was faced with an FS2000 with another different FS Globals arrangement and, worse, some things moved out of GLOBALS and into other FS modules. This prevented many of my applications (ones I'd paid for, for example), so I wrote my own replacement for Adam's work. His were called FS5IPC and FS6IPC (for FS5 and FS6), I called mine FSUIPC, with "U" being for "Universal" as I intended it to work with FS98 programs, which I had, in FS2000 -- and any future FS. As FS was developed, "GLOBALS.DLL" became a thing of the past. All of the values previously at "known offsets" in "known modules" in FS became buried in private data in black box (they call it "encapsulated") modules -- the results of "Object Oriented Programming", the new rage! Worse, many values were only computed on demand. In the end, FSUIPC3 (for FS9 and before) retains compatibility between FS98, CFS1, FS2000, CFS2, FS2002 and FS2004 simply because it has tables which tell it where or how to get each item of data relating to each "offset" entry in its long list. FSUIPC4 (for FSX and ESP) does it the same way, but it populates almost all the data in only one way -- by asking SimConnect for it. SimConnect was really a result of my long-term negotiation with Microsoft's FS team for a decently consistent way of interfacing to FS. It had potential but sadly was never really finished before Microsoft clobbered everything. Regards Pete

You need locations for all the data in any case. How small are you trying to make your program? If you want to read 1000 bytes worth of data you need 1000 bytes. The number of different variables isn't relevant in any case. They are never going to squeeze 200 variables into 6 bytes! Even if they are only one byte each that is 200 bytes. How much memory does your PC have? What is your obsession with memory usage? My example above assumed you were more concerned about ease of programming, and there's nothing much easier than simply declaring an area equal in size to the offset space, i.e. 65536 bytes, and locating your copies of the variables you need at the same offsets as they would be if FSUIPC's offset memory were genuinely as it is pictured to be. Regards Pete

You can use any sort of buffer you like, but it is not a good idea to read data you don't want. As far as the FSUIPC interface is concerned all data is just bytes, so you can still build up your read requests with the correct offsets and the correct sizes (in bytes), asnd have them read into your character-based buffer at your own computed offset, or even the FSUIPC offset. e.g Reading 5 bytes at 0x8954 (a fictitious examples): char my_big_buffer[65536]; ... FSUIPC_Read(0x8954, 5, &my_big_buffer[0x8954]); ... more reads ... FSUIPC_Process. .. Then you know you have the 5 bytes at 8954 in your buffer, but you don't need to read all 65536 offsets to get it! Yes you certainly can, and in fact it is by far the best way! There is no reason why the offset (0x8954) and size (5) in my example can't be from parameters. Just loop reading the parameters, doing the reads. Then one Process. Pete

ALL of it? You shouldn't do that. You shjould only ask for what you need. Some of that stuff needs calls into different parts of FS to obtain and you shouldn't be asking for that to be done for data you don't need. You never have to make multiple Process calls, only multiple FSUIPC_Read or Write calls, which only build up your list of data requirements. The Process call just sends the request to FSUIPC -- one Process call for ALL of your requests, once per cycle. There's little cost in the Read and Write calls as these only add your request to a shopping list. Regards Pete

From what program? Has this anything to do with any of my programs? I've no "MSG#14" in any of my programs. I can only support my own programs. If FSC is Flight Sim Commander and you are using WideFS then show me the WideClient and WideServer log files. But make sure your Network is working first, and also make sure your FSUIPC and WideFS are up to date. Oh, and please find the Caps Lock key on your keyboard (on the left probably) and press it so you can use lower case too. It makes messages more readable and less like shouting. Pete

I simply Googled "Windows System Error 1326" and got this: which indicates that you don't have access to that file from the PC you are running WideClient on. In any case, I don't think trying to run a program on your PC "PORTABLE" which is located on another PC in your Network is going to be muchgood. To start with it is going to be awfully slow, with the PORTABLE PC trying to access the BUREAU disc all the time whilst SuperTrafficBoard is running. You should really NEVER try running programs across a Network. Most simply won't work that way in any case. Either install SuperTrafficboard on PORTABLE and run it there, properly, or use facilities on BUREAU to run it there. In general you should always install programs on the PC where you want them to run. Any other way is always likey to be doomed to failure, irrespective of passwords and permissions. This is not a "WideFS Problem" as your thread title misleadingly states. Regards Pete

Okay. Let's see: First, it appears that "AICarriers.exe" is loaded by the EXE.XML file, which FSUIPC installation certainly doesn't touch. Looking at that file it looks fine, providing that your AICarriers.exe program is in the folder it refers to, i.e: C:\Program Files\AICarriers\aicarriers.exe Before that is loaded, however, you also have another EXE loading: 3wirex.exe from the FSX main folder. Is that correct? I don't know what it is, but do you? Is that working okay? If those paths are correct then I don't see any reason for your AICarriers program not to load. Have you checked if it is running? Switch FSX to Windowed mode (ALT + ENTER) and check the Windows task bar. Is it (and "3wirex") listed in the programs currently running? Maybe it has an error and there is a message box awaiting your answer? Often that happens but it gets hidden when running FS in full screen mode. The DLL.XML shows FSRecorder loading from here: C:\Program Files\FS Recorder for FSX\FSRecorder_FSX.dll Is that running okay? And FSUIPC4 loading from the FSX Modules folder. Is that okay? Really, I can see nothing amiss. Try my suggestions to check whether it is running or not and/or whether it has failed with a report. If it is running maybe you could try to terminate it (use Windows Task Manager if it appears hung). Try starting it manually, by double clicking on its EXE. If it then works then it might be falling afoul of the security check bug in SimConnect, one which was very serious in the original FSX release but was mostly worked-around in SP1 and more so in SP2 (if your FSX installation is not fully updated to SP2 or Acceleration levels then I would urge you to apply these updates). Unfortunately Microsoft never managed to fix it fully before the FS team was disbanded. The only further possibility is that it is running afoul of some other, unknown, SimConnect bug. I am unlikely to be able to assist there, but if you would like to get a SimConnect log (see the FSX Help announcement at the top of this Forum for instructions) then I'm sure it would be of use to the AIcarriers support folks. I can also look to see if there is anything obvious, but since I've no idea about even what AICarriers is let alone what it does I am not really in the best position to solve its problems. If you do enable SimConnect logging, keep the session very short -- only long enough to prove a problem exists, and do ZIP up the log as it will be huge. If you want me to look at it say so here and I'll tell you where to send it if you find difficulty attaching it (as some folks do for some reason I've never fathomed). Regards Pete

What logs? I don't think logs are relevant. What is VRS Superbug? Why is that relevant? If AICarriers is not loading and it is normally loaded by SimConnect via entries in the DLL.XML or EXE.XML files, then maybe those are corrupt. But I don't know either VRS Superbug nor AICarriers. Really you need support from whatever company makes the program you have which does not work. I can help you find out if there is a corrupted XML file (post it here), but I know nothing about those other programs and cannot help with them specifically. The only place a Log might come in useful here is if you do not know how to find the DLL.XML and EXE.XML files -- they are in the same folder as your FSX.CFG file, if you know where that is. If not you can show me the FSUIPC installer log which will be in your FSX Modules folder. That helps, but only because it tells us where the FSX.CFG is, and therefore the DLL.XML or EXE.XML files. Regards Pete

Sorry, I think you have become mixed up? Surely your qualified tech did not insert the title into your message here? My point was only that you entitled this thread with a passing comment from the log which was only pointing out that WideServer could not support IPC/SPX because it isn't installed. If you are not intending to use IPX/SPX, that does not matter. This is why I asked why you used it as your title? Okay, now you left WideServer running for over two minutes and no connection seen. And this time you ran long enough for WideClient to report an error. It appears that your Server is not seeing the client and the client cannot get through to the Server. Assuming it is getting the IP address correctly (192.168.1.100 looks normal), there is either no true network connection to the Server or, probably more likely, you have a firewall stopping it -- either stopping WideClient sending out to the Server, or the Server stopping incoming connections. There's really nothing else I can tell from here. You need to allow your two PCs to talk freely, or at least make exceptions for FS and WideClient. Regards Pete

Send me an email please. petedowson@btconnect.com. Pete

You have a CFS2 installation at: C:\Program Files\Microsoft Games\Combat Flight Simulator 2 and that is correctly detailed in your registry. You have no registered installation of FS9. If you believe you do have an FS9 installation, try using the program I pointed you to to fix your Registry. It seems you must have either moved your FS9 installation or rolled back Windows without reinstalling it. FSUIPC is correctly installed for your CFS2 program. Regards Pete

You've changed something then. Why is your heading "Address family not supported by protocol family"? You aren't using the IPX protocol are you? In current Microsoft operating systems that protocol is optional. You'd need to explicitly install it if you wanted to use it. The Server and Client logs show everything is normal, though you are using an out of date WideClient. There are no errors, but you only ran the Server for 10 seconds and didn't terminate FS before showing the log, so there's innformation missing, and you only ran WideClient for 20 seconds before terminating it. Possibly they weren't actually running at the same time, or long enough to establish themselves? 10 seconds for FS seems woefully short to do anything and terminating the Client after just 20 seconds seems to show a slight lack of patience? Please update to a supported version of the Client. And there's no errors indicated, yet. Pete