Pete Dowson

I don't know if the two are derived differently, but i wouldn't have thought so. I just provide what I can get from FS. Sorry, again, I don't know. I'd have to test it to see. If the GPS values imitate real GPS's the update rate might be a lot lower. No, there isn't that i know of. Regards Pete

Okay, I will! Thank you! Pete

WideClient needs no key -- WideFS is registered on the FSX PC. You can have as many clients as you like. Why would clients need keys if they cannot talk to an unregistered server? When you read the manuals, did you do what they suggested? It doesn't seem so, unfortunately ... I don't want pictures. I need you to tell me what you have done. Do your computers see each other? Are they in the same workgroup, as suggested in the manual? If not, and you don't want them to be, have you edited the client INI file to provide the Server details -- the name and protocol, or the IP address and protocol? [LATER] Looking at the files you included, I see that WideClient is waiting for the Server to tell it who it is, where it is: 1188 Trying to locate server: Need details from Server Broadcast 1188 Failed to connect: waiting to try again Yet the Server is broadcasting: 16099 Broadcasting service every 1000 mSecs You appear to have not yet bothered to enter the ServerName and Protocol parameters into the Wideclient.INI, as suggested in the Manual. It actually looks like they cannot connect automatically because the two PCs are in different workgroups, so you did not bother to change those to be the same either? That's the first thing to do if you want a good working network. Unfortunately Win7/Vista and XP use different default workgrop names. I always change all mine to "PETES". Which manuals did you actually read? You seem to have missed the main section on configuring your network. Please do check again. Regards Pete

FSUIPC's virtual buttons are simply separate bits in nine 32-bit words within its program-accessible offsets, relating to 9 virtual joysticks 64-72. There's nothing special about bits 7 or 15 -- they are intermediate bits in the first 32 bit word. However if this SPAD program is using BYTES instead then those bits are the top bits of the first two bytes. Maybe they are using signed bytes, so those bits are sign bits, and they are losing them en route. When you say "etc" do you mean 64,23 64,31 65,7 etc? If so then some such error seems likely. I think you need to talk to SPAD support. Regards Pete

But that is absolutely nothing to do with FSUIPC or any software of mine. Probably you need to run its installer "as administrator" to give it privileges to access your Program Files folders, which are all protected by Windows from writing! Aren't there instructions with it? Pete

I'm not sure what you mean by "the buttons won't work" (they will be doing whatever they are programmed to do), but the notice of multiple entries simply means that you've been editing the INI file to program multiple actions on the one button or switch, and so it cannot be edited in the dialogue. To stop things becoming too complicated on screen for the 99% majority of users and uses, it is only capable of assigning one action on press and one on release. But FSUIPC does support a whole sequence of actions, even with conditional tests, on any button or switch. This more complex use can only be done by editing the INI file, in accordance with the details in the FSUIPC Advanced User's Guide. If you are using joystick lettering, and so have a joystick "C", then button 24 on it will be C,24. The lines in the [buttons] section handling it will contain 'C,24'. probably after a P (Press), R (Repeat) or U (Up, or release). If it is in a conditional it will also have a C in front of the P or whatever. But just search for C,24. Buttons programmed for a specific aircraft or Profile will override any general programming (in the main [buttons] section), but if you delete them the general assignments will then prevail. Also, after deleting or editing the INI file, if you are doing this with FS still running, you need to go into the Buttons tab of FSUIPC options and clieck the Reload button there, so it loads the changes. Otherwise the ones it loaded previously will still be operational, and will later overwrite your INI changes. You mean as a sequence? Yes, you can, in the INI file. You'd need to refer to the format for the Button entries in the INI file, and the values for the keypresses. For 3 keystrokes it is 3 lines in the INI. They are obeyed in the order of the line numbers (the numbers before the =). Yes, for most things. Check that the joystick number or lettering works the same -- FSUIPC3 uses a different Windows method for joysticks and some axes may have different letters. X and Y are always the same though. And some of the options in the [General] section may be different or not apply, so afterwards just check through your settings in the varuious Option tabs. Regards Pete

If it supports local networking, yes. If not, if you cannot network it, then no. So check that. WideFS just needs standard networking capabilities. Any recent version of Windows will do from XP onwards. Old versions of WideClient work on Windows 98 and even Windows 95 too, but I don't think the latest ones will. Regards Pete

That's really weird. i cannot imagine what they've done to get such an outcome! I assume you've tried different Baud Rates, and with VSPE set to emulate baud rate and not. -- the only option is provides when creating a new pair? Regards Pete

I'm not surprised. What did you expect? John Nicol notified me late Friday that 1.2 was available for download, and I've been trying to download it ever since. Despite my broadband connection being certainly capable of at least 512 KBytes/sec, the maximum I get from their site is 120! I've got part 1, part 2 has almost finished (the downloads from there keep stopping and overnight, when I am not at hand to resume them, they just sit doing nothing). I am trying to get part 3 at present. I don't know when i'll get it installed -- hopefully in the next few days -- but after that there could be anything from one to two week's work involved in hacking into the code and making the relevant changes. It isnt easy. I have to re-find all the hooks i found before. With FS updates I used to have several months, but unlike with the Microsoft simulators I am not on any "Beta" team with L-M so I don't get anything before you do. I have go a lot on these next two weeks or so, then I'm on holiday. It may well be November before I have a revised FSUIPC. That's probably pessimistic, but possibly not totally unrealistic. Regards Pete

If I can understand the reason (I always like to know there's a good reason), I'm willing to consider some amendment which will do something like you ask, possibly just for "event.control" (I don't think it is very easy with most event types, but with that it should be -- I can check). Maybe on the lines of event.control(control, "proc", CANCEL), or your event.controlCancel(control, "proc") I need the "proc" name because that's how they are indexed for access. There may actually be other "proc"s receiving the same control, which would not want cancelling. Regards Pete

The function will (normally) only be handling one type of event. No. Just make the full function a non-event called function, and have several simple functions like function controlX(val, param) func(val,param) end function controlY(val, param) func(val,param) end etc. The internal structures controlling event detection are not really very amenable to doing it a different way. If you simply want to ignore certain controls just do so in your main event function. If this isn't viable for you, can you explain why you need this alternative method of doing things? I always like to fully understand reasons for things. Maybe I could then look at another way.. Regards Pete

As expected -- I tried your INI here, as I said. Sorry, evidently I was not clear. When I said "I may need to insert additional logging around the area in question and ask you to run tests. would that be okay?" I meant I would have to alter the code to get more information. There is no logging between where it logs "Clear All Weather requested: external weather discarded" and a little later "Advanced Weather Interface Enabled". All it is doing is establishing the assorted weather offsets. It has reached the first of those two messages but not the second. I will have to start burrowing into the ancient code in that intervening area, code which hasn't changed in years, to find out what part of your system is being called when FS hangs. This means working out salient places to log an extra message so I can see where it gets to. This will take some time and probably several iterations. This is why I asked if it was okay with you to proceed down such a path. I need to be sure it isn't actually a true FSUIPC problem. If it turns out to be an unexpected quirk in FS9 which has never been discovered before I will hasve to work around it. If neither then at least I might be able to pinpoint which part of your FS9 installation is corrupted. .The default Station List is in the FS Weather folder, but a new updated one is only created when you download weather from the Microsoft/Jeppesen site -- i.e. the FS real weather facility. It keeps an updated station list because Jeppesen remove or add stations from time to time. So, what is your answer to the above? I don't know when I'll get time to do the work involved in this, but I would email you the test versions plus instructions if you agreed, as and when I can work them out. I'd need your email address. If you don't want it broadcast here, write to me at petedowson@btconnect.com so I can reply privately. Thanks & Regards Pete

Hmm Strange. I can't see anything odd in the INI file -- in fact it is much less complex than my default one. just in case, though, could you please, just as a test, remove it (save it or rename it) before running FS9 just to see if default settings make any difference? But it is still a problem for me, nevertheless. And its a bit intractable at present. It is stopping in a place where nothing has been changed for many releases, and I've no other reports. I need to narrow it down somehow. This 3.998 was supposed to be the last "Beta" before a full user release with updated documentation, next month maybe. I can't do that if even only one person has such a problem! I may need to insert additional logging around the area in question and ask you to run tests. would that be okay? Oh, one other thing. Do you have any FSUIPC-using applications installed which might be trying to use FSUIPC as soon as it is is loaded and ready? If so, or you're not sure, perhaps you could enable ipc Read and Write logging and do the test with 3.998 again, please? Either add LogWrites=Yes and LogReads=Yes to the [General] section of the INI, or set the options with 3.997 and then change over. [LATER] I just tried using your INI on my XP SP3 system with 3.998 and it was finem as shown here: ********* FSUIPC, Version 3.998 by Pete Dowson ********* Running on Windows Version 5.1 Build 2600 Service Pack 3 Verifying Certificate for "D:\FS9\MODULES\FSUIPC.dll" now ... SUCCESS! Signature verifies okay! Running inside FS2004 (FS9.1 CONTROLS.DLL, FS9.1 WEATHER.DLL) User Name="##########" User Addr="##########" FSUIPC Key is provided WideFS Key is provided Module base=61000000 WeatherReadInterval=4 LogOptions=00000001 DebugStatus=255 7500 System time = 25/09/2011 00:07:23 7672 \\FSXBEAST\D\FS9\ 7938 System time = 25/09/2011 00:07:23, FS2004 time = 12:00:00 (00:00Z) 12422 \\FSXBEAST\My Documents\Flight Simulator Files\737 at EGCC.flt 12485 AIRCRAFT\b737_400\Boeing737-400.air 22250 Aircraft="Boeing 737-400" 24297 ERROR: Can't change message filter: functions not available 28469 \\FSXBEAST\My Documents\Flight Simulator Files\UI generated flight.flt 28875 Clear All Weather requested: external weather discarded 29407 Advanced Weather Interface Enabled 37610 Traffic File #13 = "scenery\world\scenery\traffic030528" 45266 WeatherOptions set, now 4000370F (timer=0) 49032 System time = 25/09/2011 00:08:04, FS2004 time = 00:07:45 (23:07Z) 49032 *** FSUIPC log file being closed Memory managed: 8 Allocs, 341 Freed ********* FSUIPC Log file closed *********** I'm now very concerned over what on Earth could be different on your system to cause such a problem? This may take a while to determine. I would suggest redownloading the DLL in case of corruption, except that if it were corrupted it would most certainly fail its signature test.. Regards Pete

Most folks with a Saitek throttle quadrant prefer to use use the throttle switch, the one which operates automatically when you pull the lever back. That can be assigned, in the Buttons section, to "THROTTLE DECR" with repeat enabled. If you want to give up part of the axis range for more precise reverse control then, with only one lever for multiple engines, you have to set the "Map to 4 throttles" option in the main Throttle calibration section, then go to the 4 throttles tab and calibrate Throttle 1 there with a reverse zone set as you wish. This is all explained at length in the User Guide. I can't really reproduce it all here. If you have any specific questions, ask them by all means, but please read the documentation first because that's much fuller an explanation than I'm likely to attempt here. Regards Pete

How do you "assign reverse thrust"? There are reversers and revers zones on normal throttles. And there's absolutely no way anything to do with throttles can affect flaps -- you probably have an assortment of mis-assignments. Your settings are all in the INI file, not in the DLL. The DLL is just code! If you want to delete your mistakes and start again, simply delete the INI file before running FS. Without any specific settings FSUIPC doesn't touch any of the controls whatsoever. You need to be more specific about where you are assigning things and what you are actually assigning. If you are assigning in FSUIPC you MUST remove assignments for the same axes in FS itself. You can of course assign in FS instead. There is no "centre" for the normal generic throttle. the "centre" settings for throttles (to allow a reverse zone -- not what you are doing, a reverser) only apply to the separate throttle controls for each engine. If you want to use those justmake sure you don't set the "No Reverse Zone" option for the 4 throttles. As the documentation explains, if you want a reverse zone on a single all-engine throttle you have to map the generic throttle to the other 4 then calibrate in the 4 throttles page. If you haven't assigned anything to flaps in FSUIPC, then FSUIPC can't have anything to do with your Flap problem. You need to see what you've done in FS. None of that is at all relevant. The relevant data is how you are assigning in FS, how you are assigning in FSUIPC, and what you are actually doing there. I recommend you delete the FSUIPC4.INI file, then read the FSUIPC User Guide a little more, and try again. If you don't understand something, please ask specific questions. Please don't plough into things headlong until you know what you are doing. Regards Pete

Hmm. Strange. The changes between 3.997b and 3.998 are pretty much only concerned with axis filtering and additions to the VRInsight capabilities. And the "fixed" one was just a change from indicating version 9.98 to applications to the correct 3.998. No changes really which would affect things during initialisation, and certainly not before the stage indicated by the next message which should appear: 78547 Advanced Weather Interface Enabled which was never reached in your 3.998 install. This suggests that either the WXStationList.bin (in the same folder as your FS9.CFG file), or the WX file being loaded initially, is corrupted. These binary files will be processed in FS when FSUIPC tries to initialise its weather offsets, with completion indicated by the above message. FS appears to process these binary files blindly, assuming they are correct, without any validity checks. Bad values can wreak havoc and cause corruption in other areas of FS memory, resulting possibly in crashes or hangs or even nothing obvious at all. Just the small change in memory arrangement between 3.997b and 3.998 could make all the difference with unpredictable corruption such as this. If renaming or removing the WxStationList.BIN and WX files (in your FLTs folder(s)) doesn't help, please show me your entire FSUIPC.INI file, in case there's some setting there which I need to test here. Regards Pete

I really can't see how they can tell the difference between a program generated series of inputs on a serial port and a real GPS, unless they are actually testing to see if it is a real COM port. You could eliminate that by using a real COM port and a serial cable link, like in the days before we used virtual serial port programs. Could be a bug I suppose, but it would be a very strange one if it selected out only software generated data! Do keep us informed, please. Regards Pete

The facility is okay here with 3.998. I'm sure 3.991 is okay too. you have a basic C error. You define msg as a pointer to a string, and then, when calling FSUIPC_Write you take the address of that pointer (&msg). So the parameter being passed is a pointer to a pointer, not to a string. You can use msg as it is as the pointer to the string, because that's what it is, or use &msg[0] to point to its first character. Also it is very inefficient to use a separate Process for each read or write. Your code would be better as: char *msg="This is a test\0"; short int ctrl=0; FSUIPC_Write(0x3380, strlen(msg)+1, msg, &dwResult); FSUIPC_Write(0x32FA, 2, &ctrl, &dwResult); FSUIPC_Process(&dwResult); Not sure why you are using "if" on the Process call when you aren't doing anything if it fails. You are writing a single line, so also check that you don't have the option to suppress single line messages set on FSUIPC's "About" option page. Pete

There's only the one, giving a count of the number of failed cylinders, and it isn't writeable. I don't know where these apply -- presumably only to the Red Bull racing aircraft scenarios? No, sorry. It has to fit into a table which is used for all assignments. 16 characters gives an enormous number of possibilities. Computers in DOS days had a limit of 8 characters on filenames and that period lasted many years without anyone running out! ;-) I thought the 16 character limit had been mentioned in the documentation. Sorry if it hasn't, I'll correct that. Pete

Please show me the WideServer log and one instance of the Client log with this problem. Please close both FS and WideClient down first. You can paste the logs into a message here. It isn't relevant to WideFS, but it does indicate something wrong with how FSX has been installed. The installation path is obtained from the Registry entries made by the FSX installer and should be correct or you could be in for other problems. You didn't "roll back" to a previous Windows restore point after installing FSX, did you? And you did actually install FSX rather than make a copy of the C installation in the E drive? (You CAN do such copying, but only after installing properly first). I know of no possible reasons other than firewall or incorrect settings. How are the Clients knowing the IP address is 192.168.1.101? Have you given them the explicit IP address and protocol? And are you sure that is correct? Generally it is much better to just make sure all the PCs are in the same WorkGroup (which they won't be by default), and leave the connection to occur automatically -- i.e. no Procol or Server parameters in the Client.INI files. Regards Pete

The FSUIPC SDK offsets lists provide all that FSUIPC can create. Folks who've implemented more extensive failures have done so by manipulating those values in the simulation which can be manipulated in order to generate the correct symptoms. These are the ones supported by Simconnect: TOGGLE_VACUUM_FAILURE TOGGLE_ELECTRICAL_FAILURE TOGGLE_PITOT_BLOCKAGE TOGGLE_STATIC_PORT_BLOCKAGE TOGGLE_HYDRAULIC_FAILURE TOGGLE_TOTAL_BRAKE_FAILURE TOGGLE_LEFT_BRAKE_FAILURE TOGGLE_RIGHT_BRAKE_FAILURE TOGGLE_ENGINE1_FAILURE TOGGLE_ENGINE2_FAILURE TOGGLE_ENGINE3_FAILURE TOGGLE_ENGINE4_FAILURE Where these match offset usage in previous releases of FS I've mapped to them, otherwise you can of course use them as FS controls, or via offset 3110. There are some SimConnect variables which deal with failures and which are mapped to offsets: RECIP ENG TURBOCHARGER FAILED:index ==> Offsets 36B8 etc PARTIAL PANEL ADF PARTIAL PANEL AIRSPEED PARTIAL PANEL ALTIMETER PARTIAL PANEL ATTITUDE PARTIAL PANEL COMM PARTIAL PANEL COMPASS PARTIAL PANEL ELECTRICAL PARTIAL PANEL AVIONICS PARTIAL PANEL ENGINE PARTIAL PANEL FUEL INDICATOR PARTIAL PANEL HEADING PARTIAL PANEL VERTICAL VELOCITY PARTIAL PANEL TRANSPONDER PARTIAL PANEL NAV PARTIAL PANEL PITOT PARTIAL PANEL TURN COORDINATOR PARTIAL PANEL VACUUM All of the PARTIAL PANEL ones are not system failures only gauge failures, or blanked gauges. Virtually all of these are mapped to FSUIPC offsets 0B64 to 0B73 inclusive, for compatibility. The ones that aren't are, I think, read-only in any case. There's nothing more accessible programmatically. Regards Pete

The log showing the FS controls will give you both the name and the number of the control. The event.control function allows you to specify a Lua function to be called whenever the control occurs, and you identify it by its number. Please do look up the event library in the FSUIPC Lua library documentation. Pete

No, the log is not locked. You can switch Event logging on via offset 3400 in recent FSUIPC4 versions -- please see the release notes in the Updated Modules thread of Download Links subforum. Are you wanting to monitor ALL controls, or only specific ones? If it is a limited list you can use the Lua "event.control" function. Regards Pete

I am using Jeppesen FliteMap version 9.5.2.1 build 15211, and that works perfectly well. There seems to be many ways of getting to accept a variety of data. I normally run it at 19200 and use Generic with almost any of the NMEA selections, or "Aviation ABC" with GPSout set to "AV400". I think most of the Garmin NMEA selections work too. I've used it with the interval set to 500 mSecs and 1000. I prefer the faster updates and it copes well. I really can't see that Jeppesen would have changed anything to wreck all of these. and especially not in a rather minor increment such as 9.5.2 to 9.5.5. It would also wreck their use with real GPS devices of those types as well. It must surely be down to some settings you haven't got quite right. BTW there is no way I can detect changes made to what a program will accept as INPUT. Of course i can diagnose OUTPUT problems, by looking at the output. But there's no way apart from trial and error to discover anything about input. Regards Pete

Hmm. There's no difference that I know of which would affect AS. Can you please try it again, then make sure FS is closed, and show me the FSUIPC.LOG file from the FS modules folder. You can paste it into a message here. [LATER] Please try downloading 3.998 again. I found a little typo which makes applications see the original 3.998 as version 9.980, which may confuse them. Sorry about that. Regards Pete