Pete Dowson

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

FSUIPC features button programming which allows such combinations to be sent to FS when you press a button, yes. If FS is not in its menu system at the time it should work -- FSUIPC isn't able to send keypresses to real Windows-type menus or dialogues. Try the keyboard. When FS in in flight mode does Shift+Ctrl+F10 do what you want from the keyboard? If so, then it should do the same from a button programmed in FSUIPC. But, sorry, I cannot guarantee that as I don't know the software you are talking about. Regards, Pete

Sounds like the Airbus fly-by-wire. FSUIPC made provisions a long time ago to allow all controls, throttles included, to be disconnected yet have the values available to a panel. This facility is used by a number of the more complex add-ons. Evidently the "Feelthere" folks (who I'd never heard of before, BTW) felt they didn't want to have to use FSUIPC. Still it would be nice of them to at least define what they are doing so some sort of compatibility can be achieved. I suspect that a lot of other throttle control systems, such as those from PFC and Elite, will not work properly with this aircraft either. Okay. I don't need to know any secrets, just how Throttles 3 and 4 come into this. You've already shown that you can use the older Throttle controls with Reverse. So it really sounds as if it's the Throttle 3 and 4 values "interfering" with those on Throttles 1 and 2 when the latter are on a totally different scale (0-16k instead of -16k-+16k). Regards, Pete

Depending wherabouts in the world you are needing this, there are some rather more accurate terrain meshes available for FS. Whether that helps or not I don't know. Regards, Pete

Aha! You have get the jet reverser option enabled (on joysticks Page 7), and you have it operating even when you need a mixture control. Either press "Reset" on the reverser calibration, or check the option just below "Reverser for jets only". If you want to use the Reverser axis whilst still also using the mixture control you'll have to change the reverser control allocation to another axis in the INI file. Regards, Pete

Ah, you have two separate throttles. So you aren't mapping from one throttle. The ERJ-145 has two engines, yet in your earlier post you said "in fact they are utilizing all four throttle assignments but getting instructions for lever position through the first two throttle lever inputs." Are they actually simulating this aircraft somehow with 4 engines, 2 invisible? Please use FSUIPC's monitor (right-hand side Logging page) and check how many engines it says it has (offset 0AEC, type U16). Hmmm indeed! You have me completely puzzled. There are two sets of individual throttle controls: AXIs_THROTTLEn_SET and THROTTLEn_SET. The former are the more recent and it is those which FS will be assigning. They have no reverse section -- the values run from -16384 for idle to +16384 for full thrust. This is in common with pretty much all the modern axis controls in FS. The older ones, THROTTLEn_SET, offer a reverse range -- anything below zero (down to the max reverse thrust which varies, but is typically -4096 -- FSUIPC calibrates to this nominally but varies it in practice according to the aircraft). Idle is 0 and full thrust is +16383. Using these older values is the only way to get the reverse thrust on an axis input. So when you calibrate on FSUIPC's page which allows reverse, it converts the new controls to the old ones. Maybe the way the aircraft is using the Throttle 3 and 4 values is assuming the range is one way (-16384 to +16384) when it's actually the other, or vice versa. I really can't imagine what it is doing with the extra throttles, but if it is trying to re-combine disparate values somehow I could imagine it would get in quite a mess. Really, some information on exactly what they are doing would be extremely useful. At least it might show whether there is an easy solution or not. I'm afraid there's no facility for that. For a 4 engined aircraft, with two throttles you'd want to be able to get differential thrust -- 1 and 2 on 1 and 3 and 4 on 2. There's realy no call for 1+3 and 2+4 (a very weird combination in any case -- outer and inner would be more likely (1->1+4 and 2->2+3), but even then ... One experiment you could try is temporarily giving up your two prop controls (say) and allocating all 4 throttles. I'm really not sure where all this is likely to take us. I really think you might be better making some approach to the authors to try to get some information. What's a FADEC system, by the way? Regards, Pete

None of what you say is unknown to me, but nor is it at all relevant as far as I can see. I have no idea why you need to change any code at all -- how did you think FS got the ground altitude? In FS there's only the ground elevation given by FS. It isn't using a GPS in real time to get this, it gets it from the scenery files which contain whatever data the person who made it put into it, possibly after modification by things like AFCAD altered runway elevations if you just happen to be over an airfield. How the elevations were originally measured or computed is not really relevant to the calculation involved, which as I say is a simple subtraction. In FS if the ground elevation says -15 then it is -15 -- the mesh it uses for the ground tells it so, and the rendering will place it so. What it actually is in that spot in the real world is really nothing to do with it. This is a simulated world. There is some likely small discrepancy with the aircraft altitude though. I'm not exactly sure where it is measured to -- some datum in the specific model you are flying I think. It won't be your eye level or the lowest point of the extended gear. Regards, Pete

Okay, thanks. Pete

No, as it says is subtracts the ground altitude from the aircraft altitude. It takes the aircraft altitude (the one that states aircraft altitude, in the place where you'll also see latitude, longitude, pitch,bank, heading -- it's one of the 6 coordinates) and subtracts the ground altitude. Sorry if this sounds obscure. I really didn't think it could be a lot clearer? :wink: Pete

I'm running about two weeks late on that at present. Sorry. I'll try and get a Beta out within the next week or two. Pete

Strange. I wonder why. I've been told this once before, but no one could explain what was going on. I understood it was with the main throttle calibration in FSUIPC, but are you saying it's from the separate individual throttle calibrations? Are you, by any chance, mapping a single throttle to the four separate ones? Ah, so they are mapping the thottles too? Sounds like two overlaying attempts at mapping values -- leading to disaster, certainly. And what would you propose being the solution? First of all I'd need to understand precisely what the problem was -- i.e. exactly what was happening. Without the aircraft (which I am not willing to purchase as I don't want to fly it) this is difficult. And even if I did, from what you say there doesn't appear to really be an easy solution. Certainly there's no solution to double mapping -- either one or the other needs to map inputs to outputs, not both. If you expalin how many real axes you are actually using and how you are setting the throttles up in FSUIPC then maybe I could make other suggestions about things you could try. I find it a little odd, and not a little annoying, that the makers of this aircraft not only say it's nothing to do with them and refuse to help, but no one from whatever group it is responsible for it has ever approached me about it or asked if I might like to resolve it. I'm sure with some detailed information from them, and possible even an aircraft to test with, a solution could have been found. As it is, with suppliers like that, it does not endear one to working very hard at any sort of solution. That said, I'll try to help if you have more information, but I really don't know how far I can go. Odd also that this is only the second time it has been mentioned here. The first was two months ago and I got no reply when I asked for more details. It doesn't appear to be a popular need at all. Regards, Pete

Well, there are about 6 or 7 different such programs in the SDK. I only did the one in the C package, and that does have a key and auto-registers itself, as shown by this part of the source code, also provided: // Now to auto-Register with FSUIPC, to save the user of an Unregistered FSUIPC // having to Register UIPCHello for us: static char chOurKey[] = "IKB3BI67TCHE"; // As obtained from Pete Dowson if (FSUIPC_Write(0x8001, 12, chOurKey, &dwResult)) FSUIPC_Process(&dwResult); // Process the request(s) Perhaps you were running one of the others? You can easily modify them to suit, the source is provided. I can only really support the C part of it. Keys are not solely related to program names, as you will see if you read the Access registration document, also in the SDK. Also, peruse the freeware keys list above. Regards, Pete