Pete Dowson

The FSHotSeat author has not contacted me, and I have absolutely no details about such a problem. I am afraid that it will never be "fixed" if no one seeks a solution. Going back to an old unsupported release really solves nothing. I'd really rather you check the KEY file first please. The suggestion I made to you was merely to ascertain whether it was due to a bad user key, but. I'm sorry, I omitted to ask whether you are FSUIPC user registered first. If you are not, then my earlier post is completely irrelevant so shouldn't be repeated in any case. If you do have a bad key (that is a stolen or counterfeit FSUIPC user key) then most things using FSUIPC won't work in any case. What happened after 3.40 is that the user key checking was tightened. So far there's been no case at all of any good non-time limited keys falling foul of the checks, but about forty cases of counterfeit keys discovered and one good but time-limited key. If you do go back to the FSHotKey support site then the best thing to do would be to have the FSHotSeat person responsible for this suggestion contact me directly, and discuss what is happening so a solution can possibly be found. Maybe FSHotSeat is writing to an undocumented part of the FSUIPC offsets, the function of which I am not aware of, and that area has been re-mapped elsewhere. If this is the case I'm sure it can be located and rectified quite quickly. It has been several months since version 3.40 was superseded (five months at least, in fact), with as many intermediate releases. To let a problem go for so long with no one botthering to try to get it fixed doesn't really bode well. Why not see if it can be dealt with, even if belatedly? Thanks & Regards, Pete

Ah, yes, I think you are right. In FS2004 at least it isn't what you need -- best to assign View Forward instead. It does what I wanted view Reset to do in any case. I'm afraid FS doesn't provide any conditionals for use with its assignments. Whatever clever things you do in FSUIPC won't stop FS interpreting buttons and POVs the way it has them assigned. Sorry. Regards, Pete

I was in the process of replying to a PM (Private Message) from an FSUIPC user who was complaining about the Brakes problem in version 3.45, when the system inexplicably came back with "user doesn't exist" and both his and my messages disappeared! The message was comparing 3.44 with 3.45 and mentioned two problems -- one about the brakes not working (known and reported here a while back) and one concerning thrust reverse, for which I needed more details. Can the person who posted it please re-post here (preferably with more details about the reverse problem) so I can deal with it properly? There was nothing private about the "Private Message" in any case. :wink: Please, all readers, never post technical queries or bug reports privately. There's limited capacity there, both for numbers of posts and for attachments, no threading and so no history. Worse, only the poster and postee sees the message, so answers help no one else and may be a long time coming when I'm on holiday. Thanks, Pete

Oh, right. Sorry, I would never have understood that from what he said. Thanks! But if you are Creating a Flight initially in any case the date and time are presented to you so it is easy enough to change there and then. Thanks. I've not heard of that one. I do use FSRealTime, which allows you to set an offset to your system time -- I'll look at Time Keeper. Regards, Pete

I'm not sure what you mean, but if you need to contact me privately you can do so initially via the Private Message (PM) function here. Regards, Pete

FSUIPC does not touch sound or have anything whatsoever to do with it. If you have a problem with >3.40 which isn't present in 3.40 then the most likely cause is an incorrect user Key. Try removing the FSUIPC.KEY file from the FS Modules folder. If that fixes it, then I need to see the KEY file -- do NOT show it here, ZIP it and send it to me at petedowson@btconnect.com.

Oh, but I would so love to find time to fly other than my standard test flights. I need to be able to notice every little difference, so on the few occasions I do manage to fly it is usually the same routes. I'm very sorry, but I still don't understand. I thought you were referring to the Zulu time on the weather being different from your local time, which of course it will be except in the Zulu time zone. Surely if you are creating your own flight you can set the time and date how you wish it to be? I don't think this is dependent upon time zones. When I go to the "Create a Flight" dialogue I see, in box 4 ("Selected time and season") the current date and time. This is obtained by FS from my PC system. For example, I am just looking now and it says "12/02/2005 02:06". Now, I did not enter that. This is FS's setting because I have the option set (Settings - General) to use System Time. Perhaps you haven't set this? There are some problems with crossing time zones, which is why I recommended FSRealTime to you. Have you looked for it? Maybe it will answer your needs (which I plainly still do not understand)? Regards Pete

There are 6 files in the WideFS ZIP with names beginning "Wide": WideFS.pdf WideFS.doc -- the documentation in two different formats WideClient.exe WideServer.dll -- the programs themselves WideClient.ini WideServer.ini -- the configuration settings for the two programs. Please look again. In the case of WideServer.ini it really doesn't matter a great deal in any case, because WideServer will generate one automatically when FS is run, and all the default settings it makes should be fine. It is a little more important to start off with one for WideClient because you have to edit it to tell the Client the name of the Server. Regards, Pete

Why are you assigning them as Keystrokes? Best to use the FS controls for view selection. Why do you have them repeating? There's no point in repeating fixed view selections. Best to program them for the controls, on "Press", with release assigned to view reset. That's because that scrolling is "panning", not view selection. By default FS uses the Hat for panning. The only advantage of using FSUIPC is to get view selection instead, which best suits 2D cockpits. I think they will pan if you set "pan_in_cockpit-mode=1" somewhere in the FS9.CFG, but I'm not sure about that and don't really see the point. If you like panning you are best using FS's Hat system. Regards, Pete

Living and mostly flying where I do, in the UK, local and Zulu time are the same, usually, so I don't notice any problem, if there is one at all. Weather METARs are timed in Zulu time in any case, not local time -- is that the "problem" you see? I'm really not sure I understand. You can fix the latter by reloading the AI traffic. In FSUIPC I've provided an additional control to toggle AI traffic off and on -- if you do that, when it is reloaded it will obey the current weather. As for the first part of this 'problem', sorry, I've not experienced that, but then I tend not to use the "create flight" dialog. A matter of long-term habit, I suppose, over many versions of FS. I prefer it to load straight into a flight. If I want to download weather I do so then via the Menus, but mostly I use ActiveSky or FSMeteo in any case. Sorry if I'm not being much help. Maybe this is a better discussion for the FS2004 Forum? Regards, Pete

The key programming is saved in the file called "FSUIPC.INI" in the FS modules folder. All FSUIPC options and selections are saved there. Are you using the latest version (3.45) of FSUIPC? If not, please upgrade first. Then, if it still happens, show me the [Keys] section of your FSUIPC.INI file. Maybe that is in a mess from some problem earlier? Regards, Pete

Are you running the PM MCP on a Client PC? Without knowing more about your configuration it is difficult to know where the delays might be occurring. Generally, with a fast enough FS PC it should be easily possible to maintain data frame rates over WideFS to every client in the 20's. What are you experiencing? (The performance figures are provided at the end of all the WideServer and WideClient log files when you close everything down). With, say, a data frame rate for a client of 20, the MCP should be able to see 10 changes per second (it needs two-way exchanges). This is probably slower than you may be used to, and that may be the problem. You'd get more predictable results by turning the knobs more slowly. Personally, I always run the PM MCP on the FS PC in any case. This is far better for autopilot control, and, with the MCP being more or less the "hub" for so much of PM's data flows, reduces a lot of the exchanges from needing to be two-way over the Network to one-way, or even avoiding the Network altogether for the GF devices are on the FS PC. I have a new version of WideFS almost ready for pre-release testing by those interested. It tightens things up quite a bit by using its own timing system -- all previous versions relied upon the windows Timer message scheme, which I've recently found to be rather unreliably wonky! I hope to post this here early next week -- it may be well worth your while trying it when it appears. There will also be an update to FSUIPC and the Beta release of my "GFdisplay" program, hopefully sometime next week too. With the latter I am including examples for GF unit programming (both displays and switches), with the MCP featured for use with FS A/P or PM. I am hard at work on the documentation, which it badly needs as, I'm afraid, it is horribly complicated looking. Regards, Pete

Are their two questions there? I'm not sure what you are asking in either case. For time control in FS I use FSRealTime bu 3D Softworks. However, I recently found that this can cause some problems in FS2004 because the way it changes time doesn't get recognised properly in the AI traffic routines and so on -- I've fixed this by changing FSUIPC and that will be in the next release. As for "not initially using the current weather when choosing ...", I'm afraid I don't understand that part. Can you elaborate? Regards, Pete

The default assignment in FS for Shift+Z is the "Coordinates/Frame Rate Cycle" command. It is listed and assigned, unless you've de-assigned it for some reason? It's the control called "Readouts flight" in the controls lists and in FSUIPC's dropdowns. Why not assign it in FS? The FSUIPC list actually uses the "official" FS names for these, as seen in the FS9.CFG file, and as listed in my "list of FSxxxx controls" documents -- the FS2004 one is included in the recent FSUIPC ZIP packages. It gets these names automatically from the FS "CONTROLS.DLL", which is also where FS gets the names from when writing the FS9.CFG file. Looks like the "official" control name is "Panel hud toggle". Regards, Pete

How odd. FSUIPC itself isn't doing anything when you do that, it is all down to standard Windows library routines, managing what's called "property sheets". Hmm. Never heard of such problems. I have four different FS9 installations on different machines, some with very many add-ons, and the installation of FS9.1 never needed any of them to be re-installed clean. The only problem I had was on one PC (with virtually no add-ons I hasten to add) where the 9.1 installation itself took a long long time to complete (over an hour I seem to recall). But complete it did and it's been fine since. Well, I don't know what is going on there. The differences between FS9.0 and FS9.1 are relatively minor as far as FSUIPC is concerned. They are all fairly technical changes, nothing really to do with the user interface or the way FSUIPC operates. Hmmm. I wonder if you have some other process running in the background on your system which, for some reason, it having more effect with 9.1 than 9.0. In your shoes I would be carefully examining what is running on the system and try a process of elimination. As well as those things that put an icon in the bottom right corner when they are running, check the Process list (Ctrl-Alt-Del, select Processes tab). You can even try deleting them there -- if you delete anything serious you may crash the system, mind, so be careful. However, a re-boot should recover things. As a way of working out what's doing what it's crude but sometimes effective. No, nothing much has really changed in 9.1. Just some bugs fixed. Regards, Pete

Well done. I must say I didn't understand a word of the explanation though. I think I'm really still embedded in the world of DOS and only recently got to terms with Win98. Most of the stuff in the current Microsoft spectrum just bewilders me. Regards Pete

The Ctrl+E keypress is only assigned that way in FS's Options-Controls-Assignments. It can be assigned to any keypress - or button - in FS. If your button is assigned to Ctrl+E in FSUIPC and Ctrl+E is still correctly assigned in FS's assignments, then it will work. It certainly does here. Are you using FSUIPC 3.45? If not, download and install that. Then, in the Logging page you can select "Event logging". With this you can actually see the controls being sent to FS -- the ENGINE_AUTO_START control is sent no matter how the Ctrl+E arrives. If this isn't occurring it sounds like something else is also happening when you press that button. Perhaps you have it already assigned in FS itself to do something else, and that is interfering with the auto-start? Well, I think that certainly indicates that you have forgotten to de-assign the same button from other actions in FS. Assigning it directly to the FS control is much more efficient in any case than assigning it to a keypress which is in turn assigned (in FS) to the control. In fact, for all FS controls already assignable in the FS Options-Controls-Assignments dialogue you do not need to use FSUIPC at all -- why not simply assign it in FS? If you do that, FS will automatically deassign it from whatever else it is doing there. You seem to be making a very complicated job of it? Regards, Pete

Great! Neither the exact solution one might wish for, but at least workable. Thanks! Thanks. It will be relaxing by being different -- leaping on and off steam trains in northern India. I shall return quite fit but exhausted (physically though, instead of mentally! :wink: ). Good flying now! :) Best regards, Pete

Okay. Thank you very much. These things gnaw at me, you know. I enjoy techincal interchanges and get rather confused when emotive words start appearing. Okay, thanks. That will be interesting. Regards, Pete

Well, from your private posts it seems that your FeelThere contact finds me 'rude', not only to him/them, but also to you. Do you feel that way? I've reviewed our chat here and I really don't understand how they get such an impression. Anyway, such an emotive injection into technical exchanges is not terribly conducive to a solution I'm afraid. From all the evidence so far I really doubt that there is a solution in any case. There's likely no way I can affect the forward throttle range they are using without hacking into their code, and I'm not going to do that. The two different FS controls are, well, different. But you still haven't answered what seems to be quite an important question: how have they provided the reverser control for their aircraft? Because of the effectively forced use of the newer axis controls, it looks like the implementation doesn't allow any axis control of reverse at all. Is is supposed to be all by buttons/mouse/keyboard? If so, then I think you would need to stick to that, and calibrate your two throttle axes only in FS. One other thing. If you could give up one of the other axes you could see if the Reverser axis facility (page 7 in the Joysticks part of FSUIPC) will work. Worth a try? Regards, Pete

Hmmm. It was certainly never meant to affect that at all. The fix control acceleration option ONLY does anything if it sees two successive controls for DIFFERENT things, indicating the one thing is interfering in (causing)the correct acceleration of another. I can't see any way it should ever have affected legitimate (Microsoft intended) acceleration in such simple basic cases. I would have counted that as a bug if I had known, and sought to fix it. I've now tried it here with FSUIPC 3.44 and 3.45 and I cannot see any difference. The trim button actions accelerate after a while whether using buttons, mice or keyboard, all in exactly the same way here -- with and without the "fix acceleration" option set -- and in all three cases it also matches what FS does with FSUIPC removed altogether. Mind you, I do not have any of those advanced panels which flood FS with repetitive controls. Are you only noticing this difference with those? What about with default aircraft & panels? I've looked through the code and see no way the fix control accelerations option should have ever interfered with any legitimate acceleration, except by accident when these panels do their sending-lots-of-controls tricks. There's a later interim version of FS attached to one of the recent threads here. Let me seeyes, the one entitled re: writing active weather to fsuipc from active sky. Try that. I have made further changes in this area. I can't see how they can affect things, but then I don't see why the difference between 3.44 and 3.45 changes what shouldn't have been happening in the first place (if you see what I mean :wink: ). Anyway, try it and let me know. Regards, Pete

What language is that written in? Are you using any of the sources, libraries or wrappers in the SDK? I'm afraid the only one I know about is the C language one. Hmmm. I've never seen that error come up before. All it means is that this call to Windows returned zero (which indicates an error): hMap = OpenFileMapping(FILE_MAP_WRITE, FALSE, chId); The only reason that I know of that this may fail is that the filename is not one of an existing memory file. The "FILE_MAP_WRITE" access requested requires an existing file, and provides read and write access to it. The "chId" here is a pointer to a zero-terminated ASCIIZ string which must have been pre-registered in Windows and identified with an Atom ID. It is the Atom ID passed by the SendMessageTimeout in your program which is used in FSUIPC to retrieve the string from Windows. This method of passing the memory-mapped filename is used because it is not possible to supply strings themselves between separate processes, and pointers to them are meaningless because they refer to different virtual memories. If you are using one of the packages in the SDK exactly as supplied, with no modifications of your own, then possibly there's a bug in the one you are using. But no one has mentioned anything and there have been no changes to any of them for some time now. The first thing to do is to check you are using the correct package and actually identify the language you are using. Possibly the original author may then be able to help, or someone else using the same language. Failing that you would need to use the Debugger associated with the language you are using in order to track down the problem up to the SendMessageTimeout (or equivalent) call. All the sources are provided, so this should be possible. Regards, Pete

That's exactly what the FSUIPC control "Traffic Density Set" is for! The percentage is provided as a parameter. Note, however, that if you set a higher value than the current one you will get the "traffic loading" progress bar. Oh, you want to program it? Best to use offset 3110 and send the FSUIPC Traffic Density Control. Recent releases of FSUIPC support FSUIPC controls via this offset as well as FS controls. See the Advanced User's guide for control numbers. Regards, Pete

Well, it seems their program is using the -16k to +16k scale for forward thrust no matter whether the control is AXIS_THROTTLEn_SET or THROTTLEn_SET. They either didn't realise there was any difference, or, more likely, just assumed no one would ever be using the old FS98 controls these days -- even though they are the only ones providing reverser axes. The raises the main question. How do THEY provide reverser control for their aircraft? It looks like they really don't allow any axis control of reverse at all. Is that supposed to be all by buttons? The problems are, I think, going to be insurmountable without help from them, maybe even a modification by them. I'm not sure whether I can "fiddle" things at all. I would certainly need a copy of the aircraft, and I really don't want one. Oddly, I see absolutely no controls going to FS for Engines 3 and 4 at all, so when you say: I'm a little bemused about where those are. Did you check that FSUIPC offset for me in Monitoring? It would be useful to know how many engines FS thinks this aircraft has. Regards, Pete

No, it was an essential part of the facilities provided for the Reverser control and was added at the same time. This goes back a few years. It wouldn't have changed just by upgrading FSUIPC.DLL. Perhaps you deleted your FSUIPC.INI file then didn't quite restore all your settings to the way you had them before? The Reverser is not enabled by default. When upgrading FSUIPC versions, just replace the DLL. Nowadays you don't need to delete the INI file unless things get in a mess and you want to start again. I try very hard to maintain compatibility with parameters. Regards, Pete