Pete Dowson

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

Yes, you'd need to set those around you. I don't think FS has any way of recording weather for anything by the at the weather stations. Everything in between is interpolated. At some of the larger airports, in areas where there are several airports close to, and all are WX stations, you can get the weather varying over the one airport, due to interpolation. This can be a little odd when downloaded weather features weather for near stations with different reporting times! For READING weather, you can use either. If it's a lat/lon between stations it will be interpolated. For WRITING weather, the ICAO is needed -- not only that, it must be one listed in FS's list (which does change from time to time -- current one is the WxStationList.BIN in the same folder as your FS9.CFG file. Don't worry about the ".BIN" filetype. It's just a compact list of 4 characters per station, just the ICAOs). The positions and names are given in files in the weather folder in the main FS folder. It won't do any harm writing to invalid ICAOs. They just won't work. Depending where you get your METARs from, they won't necessarily correspond to FS's (from Jeppesen) in any case. The main weather programs do try to set stations which aren't listed and come to no harm. If you want to be sure, or even want a data base of positions and names, check out the files in the FS weather folder. note that locations (lat/lon/alt) are in 32-bit "floats" in those. Regards, Pete

You can do, but it's really more efficient just to write each part. Obviously the fields which are adjacent would be more efficient together, and this would apply really to anything less than 16 bytes or so apart (the overhead for a new block). But you can do it all in one process. The only thing to be sure of is to write the command (at offset C800) LAST, as it is that which triggers FSUIPC into action. I've just re-read that, and I've had to make a correction. Sorry. I was pretty busy and confused then I think. I shall have to write some extra documentation for the NWI, because even I had to refer to my code to make sure of some of these things. Here's the low-down on signatures and what triggers what. This is sort of a draft expansion for the current flimsy documentation, so please have a good read and let me know if it makes things clear: ======================== SIGNATURES and Reading Weather The signature fields are only really used when READING weather, in the CCxx offsets. This is to prevent one application reading one thing and another reading another before the first has picked up his data. Since, for reading, the signatures are so important, it is they which trigger the actual operation in FSUIPC of asking FS for the weather at XXXX ICAO or the particular Lat/Lon. When reading weather it is also important to wait for the TimeStamp to change to indicate that it has been read. This can give rise to some interesting situations if your program runs on a WideFS client PC. I have recently devised a scheme which I think makes things foolproof (and this applies to other read facilities in FSUIPC which use signatures and timestamps): At the start of the program, sleect or generate a pseudo-random number as a starting signature. Then, for each read: 1. INCREMENT your signature 2. Put together the FSUIPC block of requests and issue the Process call. The order would be: (a) read the timestamp CC04 (to be checked AFTER) (b) write ICAO to CC08, or Lat & Lon to CC10 & CC18 with all spaces to CC08 © write signature to CC04 (must be last to trigger the read) (d) read CC24 (e) FSUIPC_Process 3. If CC04 was read as non-zero, retry from step 1 (this is effectively a normal CC04 wait, in case something else was reading already). 4 Else, wait for CC24 to change (i.e. read CC24/process till CC24 reads differently). Now this is good for reading a single weather station, such as for giving ATIS reports or ATC instructions. If you want to read a whole bunch or stations or positions, for instance in order to build a weather map, then this will be too slow. Because you are incrementing the signature each time, the next request won't be accepted till the previous one has timed out -- about 8 seconds in the current FSUIPC. So, when reading a whole bunch of weather stations or positions, after the first time for the batch, you need to skip step 1 (i.e. leave the signature the same) and bypass the check in step 3. This is ONLY for that batch, mind. Next batch, first time through, you do the whole thing. COMMANDS and Writing Weather When writing weather to a WX station, via offsets C8xx, all you have to do is write all the assorted weather data you want to set, but be sure to write the Command value, at offset C800, last. It is writing that which triggers FSUIPC into actually doing anything. Prior to that, anything written to the rest is simply ignored. To avoid other programs interfering with what you want to write, it is best, however, to write it all in one call to FSUIPC_Process. In other words, you can have as many separate FSUIPC_Writes to set the various weather aspects (those you don't want to change could be copied direct from the Read area, of course). At then end of the sequence of Writes, you have one to write the command, then the Process call. The normal rules about efficiency apply to these writes. It is more efficient to have less numbers of separate writes, so writing larger areas, but only if this doesn't involve writing masses which you don't need. Writing all 1024 bytes is easier program-wise, but less efficient as far as the data transfer goes. But bear in mind that each separate write or read carries an overhead of about 16 bytes, and of course a little extra processing time in FSUIPC. After each weather write you do need to wait for the TimeStamp at C824 to change before writing the next, otherwise the data you then write may supersede the previous one. FSUIPC can only write one station at a time using the interface it has to FS's weather engine. ======================= I'm afraid that, although after clearing all the weather, setting GLOBal weather does take effect, the weather at each WX station gradually becomes localised. Once it is using its own local weather, no amount of simply writing GLOBal weather again will change it -- such writes will only succeed for stations not yet "localised" (i.e. usually those well out of range of the aircraft). I'm afraid, using only GLOBal weather, you would have to periodically "clear all weather" as well, to enable any changes. This would be okay if you could do it without it having any real effect until you then set the new global weather, but I'm afraid the effects are noticeable and not nice. What it comes down to, really, is that for decent weather control in FS2004 you have to set local weather -- i.e. weather at local weather stations. Yes. You simply specify the number of layers and provide the values for each. There's no automatic layer generation if that's what you mean. They are items in an ordered array, lowest to highest. Regards, Pete

I haven't heard any results from you on this, good or bad. If this is not yet resolved, I would like a couple more simple tests done, if possible, please. First, with the current FSUIPC, before running AS2004 at all, clear all weather in FS itself. i.e. go to the Weather folder and select "Weather Themes" and "Clear skies". Does it still crash? (This has probably been tried before, but I mention it just in case). Second, please install the attached FSUIPC 3.461. Then try AS2004. Let me see the Log. In this version not only do I trap errors but I try to identify which routine the error was in via flags, which will be logged too (as "Diag="). From this I may just be able to tell which FS routine is responsible. Of course, whether I can then actually do anything about it is another matter. The FS routines to clear and visualise weather are very complex and call lots of other routines, mostly indirectly via C++ type virtual procedure tables. Really horrible stuff to follow. Also, however, if a crash does occur before weather setting or weather clearing, the crash logging routine now clears down the FSUIPC flags telling it that there is a weather operation pending. Therefore it now may not actually loop, but carry on even without clearing the weather. I suspect this will make it crash somewhere later, and it isn't a solution at all, just a way of trying to get nearer an explanation. Thanks & Regards, Pete FSUIPC3461test.zip

There's nothing FSUIPC will do with any axis input UNLESS you have told it do. Simply go to the mixture part of FSUIPC's joystick options and press the button marked "Reset". Also make sure there are no "Map to ..." check boxes checked. Take a look at the page with the four separate mixture axes too -- maybe your real axis is assigned to one of those instead. If you want FSUIPC to revert to its default treatment of axes -- i.e. none at all -- then you can do so easily and completely by editing the FSUIPC.INI file before loading FSUIPC and deleting its [JoystickCalibration] section altogether. Finally, the current version of FSUIPC (6.45) includes facilities to log axis inputs (see the Logging options page). You could try that, briefly, to see the sorts of axis values which are arriving. They will be labelled too, so you can see if they are the generic all-engine values or the separate ones. They'll go to the Log and make a large file quite quickly, so only enable it for a short time, operate the mixture axis, then disable it and look at the FSUIPC.LOG file. Regards, Pete

There's no button to press. If WideClient is connected, that's it. All you do now on the client PC is run whatever program it was you purchased WideFS in order to run. If you want you can even edit the WideClient.INI file to get it to load the programs for you, all as described in the WideFS documentation. Regards, Pete

Hmm. I'm still not sure that there's nothing for me to be concerned about (oops, a double negative!), in particular the odd looping on the module check which seemed to be indicated in your Ivap logging. Are you saying that you now think you understand what was wrong, or are you, sort of, just starting afresh? If there's nothing for me to sort out, that's great, but if there might be I'd rather do so whilst there's a way of sorting it than have it come back to bite me later! :wink: And, yes, I think I will put just a few seconds of "grace" on Gauge access after I see aircraft reloads, just in case the odd gauge hang-over you demonstrated happens in real life! :) Regards, Pete

Well, Project Magenta (PM) has its own set of offsets which you can drive directly. I think that would be more efficient. The "virtual buttons" facility at offset 3340 is really for the more general purpose application of buttons to be programmed in FSUIPC. For the PM offsets you need to refer to the list avaialble on the Project Magenta site, http://www.projectmagenta.com/resources/docs.html. Regards, Pete

What "doesn't work" on the PC that does not have FS on it? What FSUIPC application are you trying to run? WideClient does not do anything much on its own, it os only an interface for other programs. Pete