Pete Dowson

With only the one program connected via WideFS from another PC? To start with, with a WideFS connection you should be limiting your frame rates in FS to the update rate your Network can cope with. Depending on your FS PC, 64 fps may not be a good rate for coordinating Network programs. It isn't anything to do with how many variables you read or how often, because all those are maintained by WideClient in your client PCs. Once you ask for an offset, any offset, then WideServer knows that PC is interested in it and will thereafter continually send it whenever it changes. It sends nothing when it doesn't change. At the most, WideServer will attempt to match the FS frame rates -- some variables change at frame rates, some more often, some less often, but WideFS tries to regulate that. You can probably get higher network frame rates using UDP or IPX protocols than TCP. I use UDP on my 8 PC cockpit system for just this reason, and can sustain a good frame rates on FS and throughout the Network. UDP is checkless -- if anything is wrong on the network, UDP give lose data or get it worng. If you get problems you would need to fix them or use TCP. But choose a sensible frame rate limit in FS. Also, do check the logs. Frame rate slowdowns are often due to things going wrong -- retries, reconnections, etc. Look in the FSUIPC, WideServer and WideClient log files, see if there's anything not looking right. Or, are you testing your program on the FS PC, not via WideFS? If so, it sounds like you are being extremely inefficient in the way you are reading them. There are programs around which read many hundreds of variables at frame rates (20 times per second or more) without noticeably impacting FS performance -- those used to drive external gauges, for example, in the assorted hardware cockpits around. You shouldn't even be able to measure it, especially not for a mere 40 variables. That's next to nothing. Try some testing with the supplied FSInterrogate program. You CAN use that to slow FS down -- for instance selecting every listed offset, all many thousands of them, and reading them at its top rate. But for all normal selections you cannot measure the impact -- not providing FS has the focus, of course. If the focus is on FSInterrogate then FS gets less processor time by virtue of the user focus, not because of any FSUIPC servicing. What does that mean? What function calls? That's the exact opposite of what you should do. Do all the "FSUIPC_Read" calls. Those don't interface to FSUIPC at all, they simply build your request in memory. THEN do one FSUIPC_Process call. Only that actually does anything with FS/FSUIPC. Every Process call you do means a Process change. Only do one per cycle, and most certainly not one per variable -- that would be a very big mistake! And do not sit in a tight loop trying to read with no delay in between -- you won't give anything else a chance to do anything. You should be doing all this once per cycle, only, and your cycles should ideally be driven by something like Timer calls from Windows. Something like a 50 mSec timer (giving 20 cycles per second). You could use "Sleep(50)" instead, but then your program's thread cannot do anything either, and you possibly have other Windows messages to service. Regards Pete

Really? That's weird. I'll take a look at that. Can you tell me the specific version number of FSUIPC please -- especially whether FSUIPC3 or FSUIPC4 so I can test the same one! (I ALWAYS need to be told the version number, always always, please) So it doesn't alter that one too? No. That would be daft. Line numbers are not at all relevant. Assignments made in the aircraft specific section override assignments made in the general section, is all. Pete

As per the previous two replies, I confirm that the answers are no, no and no. WideFS links PCs not running FS to one that is, and enables external programs written to the FSUIPC interface to be run on such networked PCs. If you want synchronised copies of FS, you want WidevieW, by Luciano Napolitano. But even then I don't think that does multiple cockpit copies. It is more aimed as multiple external views, for really wide views all around you. Regards Pete

Two points: a) if the FSUIPC entry is not getting into the Menu bar, yet a log is being produced, there is something really really seriously wrong with your FS installation which cannot have anything whatsoever to do with whether FSUIPC is registered or not. I respectfully suggest you re-examine this point. b) The log absolutely shows that the Key is not liked by reason of it referring to an impossible purchase date, in relation to your system date. There is no other possible explanation. [LATER] I've just found your order -- your Keys are dated 23rd July 2009, which, from here in the UK, is now yesterday. I see you are in New Zealand, which should make you way ahead of my time, so there should be no problem with the dates -- but please do re-check your system date. I'm now even more sure that must be the problem. Regards Pete

Yes. Actually it changed in 4.50. My own Certificate expires next month (August), and none of the issuing authorities will now grant certificates to individuals, only companies. I am not going to form a company at this stage just to get a renewal of my certificate, so simFlight, my publishers (owners of these Forums and of SimMarket), kindly stepped in and got me one in their name. This one is good till 2012. The User Guide was changed to reflect this when 4.50 was released, so if you had referred to the section headed "Nextrunning FSX. But read this first:" (page 9) you would have seen this change confirmed. Pete

It isn't on any "maze of sites" (?), but in the User Guide, supplied in the ZIP with the downloaded program. Installing FSUIPC is actually very simple. You simply copy the module itself (FSUIPC.DLL) into the FS Modules folder. That's it, that's all you do. It is documented that way too! How are you determining that FSUIPC is not loading? If it is in the Modules folder it cannot fail to load -- FS loads all DLLs placed in that folder. Is there a Modules menu (last item, probably, on the Menu bar)? If so, does it include FSUIPC? If not, then FSUIPC.DLL is most certainly not in the Modules folder -- or else you have more than one installation of FS and you are placing it the wrong one! That is a different matter. That does not mean FSUIPC is not running. It only means that it isn't servicing applications correctly. If this occurs when registered by not without registration it can only mean one of two things: 1. Your key is actually invalid, being generated by a pirate key generator, or, probably more likely 2. The system date set on your PC precedes the date of purchase of your key, so making the key look invalid. Well, the Log itself proves that what you were saying about FSUIPC not launching is patently not true. It is launching and running fine. But the key is certainly invalid. Check your system date and put it right. If it was already right then the key is malformed. Raise a problem ticket with SimMarket -- but let me know too, please, as their system is reliably automated employing some software I did for this. Regards, Pete

No. It cannot be that easy, obviously, because the moving map program is expecting you to connect your GPS device to a serial port, isn't it? I don't know of any normal commercial mapping programs which have FSUIPC/WideFS interfaces built-in. Please read the small amount of documentation for the GPSout facility. It isn't too much to read. It does tell you that (a) you need to tell GPSout to connect to WideFS, and (b) you need to configure WideClient, in the client PC, to send out the GPS data on a COM port at a speed acceptable to your map program. Then, so that the Map program can receive this data, you need another COM port to read it back on. One way of doing this is by using two real COM ports and a "null modem" cable. That's how you'd do it if you were actually connecting your PCs by COM ports. However, there are "virtual serial port" programs which save you the trouble -- these programs can generate a pair of coupled serial ports in software, enough to fool Windows. You need to look at those -- I always used the freeware MixW one, but that won't work on Vista nor on 64-bit systems. The other is by Eterlogic, free for 32-bit and reasonably priced for 64-bit. The settings required for selection of NMEA Sentences, and serial COM speed, will be determined by your map program. I can't help there, you'll need to check its documentation. Or experiment. Regards Pete

No idea, sorry. Is this MCP the one supported by the version of GFDev.DLL you are using? FSUIPC supports one called GFMCP and one called GFMCPPRO. You shouldn't put non-FS DLLs in the Modules folder, because they can crash FS -- it tries to run every DLL there. The GoFlight install should install it in the same place as your "GFconfig.exe" program -- FSUIPC uses the Registry path for that install to find it. Alternatively, Windows will probably find it if it is in the main FS folder, or in the Windows\System32 folder (I think). No confusion should occur. Obviously FSUIPC hasn't been able to load GFDev.DLL at all. Maybe the current GoFlight installer doesn't install GFDev.dll with GFconfig.dll like it used to? That would be rather annoying and increase my support load unnecessarily. if this is the case, perhaps you'd be kind enough to complain about that on the GoFlight forum, or to their support. With the WideFS client connection it is easier, because GFDev.dll can simply go into the same folder as WideClient.exe. But you can't do that with FSUIPC.DLL because of the way FS module loading works. Regards Pete

GoFlight software uses modules which run inside FS. It isn't anything to do with FSUIPC or WideFS. It needs to be installed on the FS PC. The Goflight button and knob programming facilities in FSUIPC and WideFS do not use Goflight software other than the GFDev.DLL which, if not installed by your attempted install of the full Goflight suite, can be obtained from the "Updates ..." Announcement at the top of this forum and installed into the same folder as Wideclient, on the client PC. Provided WideClient can access GFDev.DLL, it will transmit GF button operations to FSUIPC, where they can be assigned withing FSUIPC's Button tab. If you want to use GoFlight assignments and facilities you have to have your GF modules attached to the FS PC, or possibly use their own GFremote package -- though i don't think that developed very far. The normal GoFlight software doesn't use FSUIPC or WideFS. Regards Pete

Actually the important thing is that they are all run at the same privilege level -- either all "as administrator" or none of them "as administrator". Vista and Win7 prevent data exchange via DDE or memory sharing between programs of different privilege levels, and that effectively puts a wall between FSUIPC/FS and external add-ons. Whether an Add-On for FSX runs okay without the administrator privilege level might also depend upon the way FSX was installed -- if left to install in its default folder in "Program Files", then one of the problems which can arise is that all Program Files folders are protected against writing (except the Modules folder, when created by FSUIPC4's installer). This problem does not arise if FSX is installed elsewhere. Regards Pete

The name and address or email are used to identify you, uniquely. Registration for two different people is not allowed. This is actually documented. You'll need to get one of the Keys changed -- raise a Problem Ticket on your SimMarket account. They should be able to sort you out. Regards Pete

No, sorry. I am seeking to do less as I get older, not more! ;-) If you visit the Mycockpit X-Plane forums you'll find that there's an X-Plane plug-in being developed called "XPUIPC". Check this thread: http://www.mycockpit.org/forums/showthread.php?t=14896 Regards Pete

Sorry, I don't know this product. Is it a hardware throttle system? Does it need FSUIPC, or look like a normal throttle to FS? FDC crashes? Because you are using a throttle? That makes no sense. What overlap is there between them? Not without knowing why FDC crashes! If a program crashes, the only people who can say why are the people who wrote the program, or at least those who have the code to debug such a crash. I would love to help, but the FDC folks must first identify why their program crashes. Evidently it isn't checking something correctly, something which is manifestly a possibility! Regards Pete

Yes, of course. Offset 3122 is BIT-oriented. There's always one of bits 6 and 7 enabled, as, whilst the radio stack is on, there's always at least one COM device receiving and transmitting. Bit 5 is set to receive on both -- the transmission is still only enabled on 1. So, of the three top bits, 7-5 the combinations are 100 TX & RX on COM1 010 TX & RX on COM2 101 TX on COM1, RX on both 011 TX on COM2, RX on both. Your "critical" values of 96, 128 and 160 are using those patterns: 64 = 0100 0000 96 = 0110 0000 128 = 1000 0000 160 = 1010 0000 You always need to check the FSUIPC log (or your Lua log if you've enabled Lua logging). In this case it will show that you have a syntax error. The UB in the event.offset() call is a string, it needs to be "UB". Also, the name of the function being called is a string too. So that last line of your program needs to be: event.offset("3122", "UB", "findCom") Incidentally, your program at least found a weakness in my code. With no "" around your "findCom" parameter, FSUIPC crashes FS. It gets a null string pointer and doesn't check it! I'll fix that in the next update. BTW you have programmed it for no change in 66C0 if the value is >= 191? (not that it should ever be, logically, but you never know with FS! ;-) I don't know. I would need to know what control you were trying to use that needs a parameter. For switches there are very few! I tried to send the parameter by just putting it at the end of the control, e.g. 655552 for 65555, parameter 2, but that doesn't work. Of course sending a different number won't work -- the number won't be one FS recognises, or it will do something entirely different! Regards Pete

Really the technique for taxiing an airliner is to increase the throttle till it starts moving, then IMMEDIATELY reduce it to almost idle. You should be able to taxi with almost no throttle once it is actually moving, just increasing it again for corners when the tyre friction will slow it down a lot. You don't really need help for setting slopes -- there are even pictures in the User Guide, and the slope can be seen graphically in the FSUIPC calibration tab -- simply press the slope button after calibration and move the slider down or up depending where you want the flatter response (flat = slow response, steep = fast response). By default (slope 0) it is linear, as you will see. Pete

No, they would have quite different meanings when, for example, testing the lights offset (0D0C) in which there are 10 bits used for different lights. i haven't had time to look into this. If I can reproduce it, I'll fix it. Meanwhile, please be patient. i have a few urgent things to clear up first. Thanks Pete

Thanks. I didn't actually want the whole file, only the joystickCalibration and Axes sections. These two lines at least prove you've pressed the correct "Set" button for left and right brake axis calibration: However, in your Axes section there is nothing assigned to any brake axes, and most certainly not to FSUIPC direct calibration for brakes! Instead you seem to be trying to assign the brake KEY events in FS (Brake Left and Brake Right) to a zero-sized portion of your brake axis movement, using the right-hand side of the Axis assignments. 65720 and 65721 are the FS key controls, same as pressing F11 and F12 on the keyboard. They are NOT axes, although for compatibility with FS98 - FS2002, FSUIPC can be made to treat them as such. But you've made these key presses operate just as key presses, and only when your brake axes pass through a zero value (that's what "B,0,0" means -- Both directions, range 0 to 0)! In other words you appear to be messing about with a completely different facility altogether. Please just use the LEFT HAND SIDE of the Axis Assignments, and assign the brakes to the brakes there! That's what the assignments dropdowns are for! After all, you seem to have managed to use them okay to assign other axes there okay, as these lines show: They set direct assignment for aileron, elevator, two throttles and a rudder. So why are you treating toe brakes so wildly differently? I'm not at all interested in the version of FS! Only of FSUIPC! I ALWAYS need to know the version of FSUIPC! It is shown in FSUIPC's properties, or on screen in the main "About" tab, or in the Log file! It isn't hard to find! Pete

Are you by any chance running either, but not both, of FSX and FSXPAND in elevated priority mode (i.e. "as administrator"). If so, they cannot talk to each other because of privilege protection. Can you please show me the complete FSUIPC4.LOG file from the FSX modules folder? Make sure FSX is not running first, please. Pete

It sounds as if your assignment settings are wrong. You should not touch anything else on that Tab if you don't fully understand it. Please show me the [Axis] and [JoystickCalibration] sections of your FSUIPC INI file so i can see what you have done. I also need to know the specific version number of FSUIPC (I always need this information). It might also help if you enable Axis event logging in the Logging tab of FSUIPC, and showed me the resulting log after you try these things. Regards Pete

You need first to actually ASSIGN them, not just view them! If you have actually assigned them, how have you assigned them? Direct to FSUIPC or to the FS controls? (What do the words in the one of 4 possible assignment edit fields you used actually say?) After assigning them, and you move on to the Joystick tab, you have to press the "Set" button, top left in the relevant calibration areas, so that it turns to "Reset", else they are not intercepted for calibration. Merely assigning them does not calibrate them, and if assigned "direct" lack of calibration means no action. Please do refer to the step-by-step guidance for calibration in FSUIPC provided in the FSUIPC User documerntation. Pete

Oh, "garden gnomes". We don't have any! ;-) Pete

No idea what a "Heinzelmännchen" is, but I'll try and reproduce this phenomenon when I get the chance. Not many (if any?) folks use the offset conditions on keypresses. Most all of the fancy stuff is done with buttons. I don't think I allow for any comments in the [Keys...] sections in any case. All that fancy stuff was only really ever done for [buttons ...]. Pete

Yes, this is the exact symptom of what I said. your two computers are not in the same workgroup, as they have to be for Broadcasts to work. You really need to change the XP workgroup name to be the same as the Vista one, or vice versa. Look in the "My Computer" properties where you can set both your computer name and the workgroup name. If you don't do this you can instead tell Wideclient about the Server -- use the ServerName and Protocol parameters exactly as described in the documentation. Pete

You sound like a person who just emailed me with coincidentally the exact same question! :-( As I said there, you may need to post your WideServer and Wideclient log files. however, it certainly sounds like you are using different Workgroup names -- Vista and XP have different default workgroups. You either need to make both names the same, or tell WideClient the ServerName and Protocol (parameters in the INI file) so it can find it. There is documentation about this. Pete

The SimMarket order page I am of course referring to is the web page on SimMarket where you can order and pay for FSUIPC3, or alternatively an FSUIPC3 + WideFS6 package. Then you will get FSUIPC3 key(s). You cannot use FSUIPC3 with an FSUIPC4 key. They are different programs entirely. Pete