Pete Dowson

Okay. Neither FSUIPC nor WideFS are involved in making other players aircraft visible in FS. With FS2004 and before I think SquawkBox and other such programs use the FS Multiplayer interface. With FSX it is done through SimConnect. Either way it sounds as if you have not got a proper connection for those interfaces between your SquawkBox PC and your FS PC. I'm sure the SB folks will be able to assist. Regards Pete

Answers to most things are in the documentation supplied, rather than on Forums. It is quite extensive. Didn't you "search" that first? After all, that's why it is provided. Forums aren't documentation, they are for problem resolution. Assign the button to a KeySend control (in the drop down). With any so far unused parameter 1-255. Then in the [user] section of the WideClient.INI, add a KeySend line to define your keypress and, if the program is being loaded by WideClient (best), the Run or RunReady details. Please do refer to the WideFS documentation supplied. It is all there, and it shouldn't have to be repeated verbatim here. If there's something you don't fully understand, by all means come back and ask a specific question, but please don't just ask how generally to do something which is documented. Regards Pete

I found a bit of time to make the small changes needed and test them, so please download FSUIPC 4.281 from this link: http://fsuipc.simflight.com/beta/FSUIPC4281.zip Offsets 07F4 and 07FA should now work fine, reading and writing. Regards Pete

Sorry, I think you are under some sort of misunderstanding. WideFS has nothing whatsoever to do with aircraft visibility, whether AI or multiplayer. I'm really not sure what you are doing -- whose other airplanes are you expecting to see, and where are others seeing you? All WideFs does it extend the FSUIPC interface to Networked PCs. There would be no copies of FS running on the client PCs. Regards Pete

I don't know what is meant by "temporal button press", not where to set half a second but I suspect this may be referring to the "Eliminate Transients" facility, for buttons programmed via FSUIPC. It is documented in the Buttons section of the FSUIPC User Guide, as follows: The parameter has to go into the [buttons] section of the FSUIPC.INI file. Later versions of the Saitek yoke fixed this problem I believe. Regards Pete

Okay, I've checked into this. I can make offsets 07F4 and 07FA work, for both reading and writing. The writing of 7f4 to turn the N1 hold on/off will have to use the FS control, internally, and that's only a toggle, but it will check the last read value first. The N1 hold value can only be set directly in whole numbers, 0 to 100% or more, even though you'd normally have values at least ot 1 decimal place, so I'll make the 07FA value readout more accurately, with 16384 = 100% as it already does in the Engine read-outs. Unfortunately, the only way to set the value directly is via the FS control, so writing to 07FA will actually write the nearest whole % number. All this is easy enough for me to do and it will be in the next incremental release, on my return from holiday in three weeks. Regards Pete

Okay. Well, 07F4 isn't implemented at present in FSUIPC4 in any case, as it didn't work in FS9 or before. I can add it, assuming that the Sim Var for "RPM HOLD" works and equates to "N1 hold". Should it? 07FA should actually read the A/P RPM Hold value -- it is definitely reading this from FSX -- but I have no idea what units these would be in -- what units do the AP_N1_REFcontrols use, please? In other areas the N1% value is from 0 to 16384, with 16384 being 100%, but maybe these are different? If the data file for FSInterrogate has 07F8 down for RPM value then it is an error. I'll check it and change it. If these do equate to the AP RPM hold and AP RPM values then they should certainly be readable, and the latter should be in 07FA already. If they don't work I'm afraid there's no way. I'll check them. Regards Pete

Good. That might be the one to go with then. I think I went a bit overboard with the change in the first. [LATER] I've made one other change -- to weight it more in favour of the Networking, i.e. against the applications, for the first 5 seconds or so of connection. In other words, for the first 5 seconds after a successful connection, it operates more like 6.75x, then changes to what you found works well. This is to avoid bottleneck problems when several hungry programs are started using "RunReady", all competing to get lots of initial data. So, the version on release in the Announcements above is now 6.763. Pete

No, it is quite often used that waybecause ... ... the most normal usage would be speakers on the FS PC and headphones on the RC PC -- much more realistic, you see? ;-) I've used RC with WideFS throughout its entire existence. With my present cockpit the FS speakers are forward and rear, whilst RC talks to me via speakers in the overhead (OR via headsets (optional)). The headsets are equipped with microphones, and I have experimented with voice recognition programs converting spoken commands into to RC menu selections, though really the set up was intended for on-line flying (which I've never got around to. Anyway, that didn't last long. The voice recognition wasn't as good as I'd hoped, and anyway I felt really daft talking to a PC! ;-) Okay, thanks. Regards Pete

They weren't available (or at least apparently not working) in FS9 or before, and since FSUIPC is primarily about compatibility with previous releases rather than support for brand newly-programmed applications they didn't get automatically supported for FSX. I have been adding stuff by request -- it is just that no one requested these before. You are looking at the wrong document. According to the FSUIPC4 Offsets Status document the A/P RPM hold variable is possibly readable at 07FA (FSUIPC4 does read it into that location), but there's no way to set it through those offsets, and that is documented too. In the pre-FSX "FSUIPC for Programmers" document the relevant offsets (07F4 and 07FA) are just marked with queries, and as far as I am aware never worked. However, FSX does have these Controls for N1 hold: AP_N1_HOLD AP_N1_REF_SET So if these do equate to the Variable names "RPM HOLD" and "RPM HOLD VAR"" (do you confirm that?), then I could add support for both reading and writing these via offsets 07F2 and 07FA. Could you verify first that they work? You can assign them to keys or buttons (the "SET" one needs a parameter of course). You could also use the controls via offset 3110. There are also controls AP_N1_REF_INC and AP_N1_REF_DEC. Unfortunately, you just missed an opportunity for these to be added -- if you had asked me before the weekend I could have added support into the just-released version 4.28. I'm not too tied up to do it until I return from holiday -- in the week commencing 19th May But surely the standard 737 MCP doesn't have an adjustable N1 facility. The "N1" (THR) button is normally programmed to do the same as TO/GA, as both use the relevant N1 value set via the CDU. That's certainly how Project Magenta has always treated it. Let me know and I'll add stuff to my list. Regards Pete

Well, it shouldn't really be noticeably slower, or at least that it matters at all -- it's getting almost as much time as before. Do you have any other programs running on the same PC? Any other WideClient applications? No. it isn't one timing value but a set of interacting values. It isn't something I want to be user adjustable as it is easy to make a mess. There is one parameter which would change things, though i'm not sure by how much: NetworkTiming=5,1 Applications get more time the lower these are, but then the Networking gets less. These values have been arrived at over years, so you don't realy want to mess much. You could try: NetworkTiming=5,0 but if you do, please change it back for any other tests you do for me, else I'll be working on false premises. What amazes me is that the original system has been working well for about 10 years now, and through all versions of Radar Contact -- with, in particular, a huge amount of use with RCV4 -- and suddenly out of the blue there are two users complaining about response and CPU utilisation. Nothing has changed, so it is very puzzling. With such an untroubled history I don't really want to make any significant changes in WideClient, just maybe teensy tweaks which will hopefully not affect most users at all. Here's another little tweak, back towards what you liked, but not too much: http://fsuipc.simflight.com/beta/WideClient6762.zip Try it without changing that NetworkTiming parameter, please. Pete

Maybe the window title changes. The problem with checking for window titles, however, is that they can be not only translated for different languages (a problem possibly overcome by reading the correct string from the Language DLL), but I think additional views and Windows can now be added via the camera system, so it is difficult to predict. If you do discover a programmable way of finding out this mode, let me know and I'll try to use it to update the offset. But it must be a way which works on any user's system. Regards Pete

Sorry, I don't know. There's no provisions for this in SimConnect at all. Maybe Microsoft didn't realise it would be needed. Write to tell_fs@microsoft.com with your needs and reasons, so that they at least might have it listed for some future update. If anyone does find out how to detect this mode I'll try to use it to update offset 0628 in an update to FSUIPC. Regards Pete

I've had a response from one tester of 6.760 who said that, unlike previous versions, it "locked up" on his system. In fact the Log showed it failing to stay connected. I'm a little worried that I may have changed the timings too far the other way now, giving the applications to much time making the networking suffer. So, I have a "compromise" version, with the timings half way between those two extremes. This is: http://fsuipc.simflight.com/beta/WideClient6761.zip Do you think you might try this and let me know how you get on with it, please? I'll send this privately too, to make sure you see it. Hope you don't mind. Regards Pete

Good, glad you like it. I've found a little bug when it is used on existing Macro files, so please do replace your version of FSUIPC when I release proper User versions, this week (versions 4.28 and 3.81). Oh, and thanks for the positive feedback, it doesn't happen very often! ;-) Regards Pete

ErI didn't supply an INI file, so that is yours! User parameters are supplied bythe User! That is why it is so named. You create a User section using a line which says [user]. Why did you delete your previous INI file? WideClient NEVER deletes it! Pete

Sorry, though everyone always blames FSUIPC, there is absolutely no way this can have anything to do with it. You need to go to PMDG support. Pete

More likely FS2Crew. Maybe some or all of the key combinations you chose were already allocated to it? Maybe which module got the keypresses first depended on load order. Good. Happy flying then! Pete

No, I hope not. It will be the new current Wideclient once I've verified that I've not messed anything up! Please try it for everything. Pete

You have to explicitly Disable the Pipe, as I showed back in one of the messages here. I showed specific SimConnect.xml examples for you to make it easy. I've never seen a log with so many SimConnect servers simultaneously enabled: one for remote use ("global" actually means "remote"), and FOUR (4) all for Local use? Why? I think you should check your SimConnect.xml file and get it simplified down. I would be surprised if you are not overloading things.

It is only soaking up idle time. Please read the thread. Check this thread again, please. Pete

Okay. Please try this version and let me know how you get on: http://fsuipc.simflight.com/beta/WideClient6760.zip Regards Pete

Okay. I see what is happening, but it may not explain all the difficulties you are getting. That really depends on lots of things. I think one of the problems is that you haven't got enough client applications using WideClient on that PC and a safeguard I built in to stop one program monopolising it is coming into play. There's a mechanism in WideClient which is explicitly designed to stop one Client program hogging the whole PC. It kicks in when it gets lots of requests very close together. RC is doing this -- it is sending lots of requests very quickly, without much of a gap between. So, every few of these requests WideClient refuses to return control to it immediately, and instead loops in a message checking mode for about 25 mSecs. During this time it is asking Windows for messages and processing any it has, but also offering to relinquish control to other processes all the time -- via a "Sleep(0)" call. Sleep(0) offers control to any other waiting process, but gets it back immediately if no one else wants it. It is this mechanism which eats up "idle time" and makes it look as if WideClient is demanding 100% of the processor. In fact, any other process should run easily -- EXCEPT Radar Contact which is held up because it is awaiting the response to its last call to WideClient. I am making a revised version of WideClient for you to try which has these values changed -- reducing the time RC is held off and increasing the Sleep value so that WideClient doesn't look like it is hogging things. I'll post a link to the updated version for you to try soon ... Regards Pete

Oh dear. You cut off the first few lines. I was really really hoping to see confirmation there of the version of FSUIPC4 you were actually using, at last. :-( Anyway, that log is not of a session in which the FSUIPC menu entry didn't appear, look: Anyway, I'm sorry I cannot help with your PMDG problems. Best to visit their Support forum for those. Maybe it is something simple, like somehow you have got their parameter file marked as "read only" so your assignments don't get saved? Pete

Ah .. you mean the Add-Ons menu doesn't appear? Or it does but FSUIPC is not listed in that menu? This is indicating a possibly Simconnect problem. Please, when it happens, close FSX, then save the FSUIPC4.LOG file, if there is one, and show it to me. Ah, now we are getting somewhere. Some real information for the first time! Let's examine this: Your items (1) and (2) imply that although FSUIPC does have the assignment, i.e. it is reloading it, that assignment isn't doing what it did before in your PMDG aircraft. Right? Your (4) actualy seems to confirm that it is PMDG which isn't remembering the key assignment. You say "PMDG doesnt seeeven the keys, if I press ctrl shf 8 on the keyboard.". So, how is this "Ctr Shft 8" assigned in the PMDG aircraft? Are you sure you don't actually have to go into a PMDG menu and explicitly tell it to save your assignments? If not, are you by any chance using Vista and have FSX installed in its default location, in Program Files? If so I suspect that the problem is that anything PMDG wants to write back to its folders is being stopped -- Vista write-protects all folders in Program Files against normal applications. To verify the latter you could try running FSX "as administator" (that is right click, select Run AsAdministrator". This would allow it, and PMDG software, to write to the folders. Okay. See if any of the above helps. There is an alternative now, which might work for you. If you download FSUIPC version 4.272 from the FSX Downloads announcement above, you will find an added facility for "Mouse Macros". There is documentation inside, and it isn't too hard. You can add new controls to FSUIPC based on mouse clicks on the panels (only add-on panels, in general). Then you can assign those to buttons. Try it and let me know. Pete