Pete Dowson

The gauge in the Grand Caravan is most definitely the culprit. Compare the very same altitude there with the one in the standard Bendix-type radio stack (the Altitude display is the value above the VS display in the autopilot at the bottom of the stack). It is evidently not converting metres to feet correctly -- probably rounding down instead of rounding to the nearest. :( I'll look at increasing the value in metres just a tad, see if that helps. I really can't say why it changed -- possibly it is related to the re-compilation of the PFC DLL with version 7 of the MSVC compiler -- I was using version 6 until recently. Certainly that part of the source code hasn't been changed. Whatever I do, the main priority is to keep the main A/P and MCP displays correct, which they certainly are still. MS evidently have different conversion code in the Grand Caravan selector gauge. Regards, Pete

No problem for me, but you might get a wider and more relevant audience in the general FS2004 Forum, or maybe the cockpit builder's Forum (they won't ALL be building their own pedals! :) ). I think there's a hardware discussion forum over on AVSIM which may get results. Regards, Pete

Actually, assuming you are using a recent version of FSUIPC, it should be extremely hard -- FSUIPC traps all errors and logs them, then continues. If you mean crashing FS, then yes that is extremely easy -- writing to some sensitive parts of FS can cause chaos. All FSUIPC_Write calls do is add data to the data area, FSUIPC is not involved at all. The only time FSUIPC is involved is in the FSUIPC_Process call, where a SendMessageTimeout is used. Unless you have the timeout in that set too short, the FSUIPC_Process call won't return until the data it transferred has been dealt with in any case. There are many programs which do Writes, Processes and Writes with no problems, so if you think you can reproduce a problem IN FSUIPC I'd like more details please. It sounds more like a problem being generated in your program. If you call FSUIPC in an extremely tight loop then naturally both your program AND FS/FSUIPC will be completely tied up and may appear hung. Really? Where? What language are you writing all this stuff in? Maybe here's a problem in the specific SDK code you are selecting. In the 4+ years of FSUIPC, using the exact same interface all this time, exactly the same as FS6IPC and FS5IPC before it (going back to FS95), I don't recall anyone with the sort of problems you are describing, unless it was an error in the program they are writing. Please supply more details so I can get to the bottom of this. It is easy to crash FS's weather system by supplying bad data. Just providing cloud types that aren't supported will do that. In the FS98 and AWI interfaces I do check and correct the inputs provided, but in the case of the New Weather Interface I don't check anything -- FSUIPC is a direct conduit into the Weather DLL. I omitted the checking after discussion with the main Weather program authors. We thought more flexibility for possible experimentation would lead to better things, but that carries the risks of crashing FS as you have found. Regards, Pete

I don't have a web page. This is my only outlet :) . If you mean Enrico Schiratti's page containing all my programs, I think the list there is simply a list of those programs folks asked to be listed there. Unfortunately, the log file you sent me tells me nothing because (a) You didn't turn on the IPC write logging as I asked, so there's nothing there showing what FSC is doing, and (b) It shows a program called "FSC70" being run on the FS PC -- but you said the problems were when you ran it on the Client. Are you sure you are not running it on both and it is getting into some sort of conflict with itself? Further, I see you are using version 3.125 of FSUIPC, which is three versions and several weeks out of date. Please get the latest (3.135) before trying again with suitable logging options selected. I simply cannot support anything but the latest versions, otherwise I waste too much time eliminating changes that may have affected things in the interim. Incidentally version 3.14 is scheduled for release this weekend. I post details of current supported releases in the announcements at the top of this forum. Regards, Pete

It crashes FS? There should be no way at all that is possible. Please give me more details. I take it I have to wait for a new timestamp when using NW_SET_PENDING too. Yes. The "SET_PENDING" is a SET command. The reason you have to wait for confirmation is that the data you supplied, that which describes the weather, must remain intact until it is sent to and accepted by FS. If you don't wait for the confirmation and change anything (like the command) then the wrong things will happen. I'm wondering, now, whether trying to ACTIVATE without first SETting anything upsets FS. If you leave the entire SET_PENDING part out does it crash? It says "WAIT TILL THE TIMESTAMP HAS CHANGED". So you compare it with itself, to see when it changes. You simply read it at the same time (i.e. in the same PROCESS) as the SET, then, after the process, loop (with small sleeps, or use a Windows TIMER so you can do other things) reading it again until it returns a different value, showing that the update has been accomplished. (For safety put a limit on how long you wait, to avoid hangs in case things go wrong). Yes, I've been using that system for years in various things, and this is the first question on it. But no question is stupid, it would be more stupid not to ask! :lol: Regards, Pete

Well, of course. Sorry, I thought when you mentioned the support in FSUIPC for AVC/RW PTT you were using the specific control I added for this, which uses no keystrokes at all, it sends the PTT commands direct to the program using Registered Messages. In general that works a lot better than the keyboard method, and works with versions of Roger Wilco that don't pick up the hot key correctly unless it comes from a real keyboard. Regards, Pete

Sounds like something odd is happening in the GoFlight driver. All FSUIPC does is read the value coming in on the axis and set the flaps accordingly, nothing more. Try calibrating again. Ah, well -- that does indicate something wrong with the calibration. Cannot GoFlight sort this out for you? I thought they had later driver versions to calbrate analogue axes better? No, it cannot. FSUIPC is only trapping the final input to FS before the value is sent to the simulation engine. It is far far away from the joystick and calibration interface, it is merely dealing with FS control values. If you have trouble calibrating you really do need to seek help from GoFlight. Regards, Pete

Why use those, when there are simpler Mixture controls in the normal engine areas, 0890 for Engine 1, and so on? To use the ones you mention you need to supply double floating point values, whereas 16-bit integers suffice for the original (FS98 compatible) areas supported by FSUIPC for all FS versions. Sorry, I don't understand this part. Where do es Magenta come in? I don't know EpicMapper. Have they got a support site? Regards, Pete

I have no idea what FS Commander is, sorry, but evidently it is writing to something pretty critical in FS. You'll need to enable FSUIPC IPC write logging so that this can be determined. ZIP up the log and attach it here, or send it to petedowson@btconnect.com. What happens if you run the program on the FS PC? Should be the same, as WideFS is only a networked copy of the same FSUIPC interface. WideFS is only a vehicle for transferring his read and write requests to FSUIPC. FSUIPC does not stop programs trampling all over anything in FS. Is his program specifically compatible with FS2004? Sounds like he has an error someplace. But I cannot tell without seeing what it is doing. Pete

WideFS doesn't care at all what addresses you are using. But WideClient needs to know the name of your server. You edit the WideClient.ini file on the client to do this. No one asked to see the DLL. But the INI files -- WideClient.ini on the Client and WideServer.ini on the Server -- are the parameter files controlling what WideFS does. They are text files and you need to look at them and certainly you have to edit the Client one in order to tell WideClient the name of the Server. This is explained in the WideFS documentation. As well as those two text files, there will also be a WideServer.log file with the WideServer files, and a WideClient.log file with the WideClient files. These log files are also ordinary text files, and are produced when you run the programs to tell you what is going on. Look at those too. If you want help here simply cut and paste the text from those files into your messages. It is easier than attaching them and more suitable for small amounts of text (as certainly the INI files, at least, will be). The INI file must be in the same folder (Modules) as the DLL, not separated. Regards, Pete

Yesin FS2004 you can dynamically change the payload, even different payloads in different locations if you like, so you can upset the balance quite easily. :) Hmmm.. sounds like you have a good project there for a unique helo simulation. As far as I'm concerned, helo flying is too difficult already without messing around with even more realism! :wink: Good luck! Regards, Pete

No change on my part, not in the several years of my PFC driver's existence. Sounds more like the specific panel you are using. Altitudes internally are all in metres and some gauges don't round correctly. Either that, or perhaps you re-programmed the knob on the PFC avionics, perhaps? I've just checked here and the values shown on, for example, the default 737 MCP are always multiples of 100. I've also looked at the code where I operate the increment and that is not only the same as it has been for at least 20 months, it takes great care to correct any reading it gets from FS which isn't a multiple of 100. Regards, Pete

Not just ATC, also the AI traffic system. As far as I remember, when this has been discussed with Microsoft, attempting to give correct ATC and handle AI Traffic in combination with injecting aircraft from the MP interface and sending data out through it was simply too big and complex a job to sort out for one release. Rather than create situations which were not handled correctly (MP aircraft in ATC space as well as MP aircraft / AI Traffic interactions) and so facing many possible complaints, MS probably though that merely providing a clean MP environment would be better both for users and for them. Regards, Pete

Well, not mapped by FSUIPC, no. Don't forget nearly 80% of locations FSUIPC presents these days are actively obtained by my code specifically for you to read/write. In many cases this involves procedure calls or long chains of pointers. The offset mechanism for this interface is mostly just an illusion, created to maintain the interface originally started in FS95 days. In order to find anything new, like possible some location somewhere which is "building up ice", someone (not me at present, too busy) would have to disassemble FS and trace backwards from the point where the Pitot tube blocks to find the calculations used to determine this. I don't even know how it is simulated. For all I know if might simply be a random number generator, weighted on the severity of the icing and how deep in the cloud layer you are flying. I do know that it doesn't have to be a cloud graphic you are flying through, only that you are in the layer (between base and tops) defined for the icing cloud. Really the usefulness of FSInterrogate for finding things is almost at an end. It can only search through memory areas I am mapping or am populating, and it isn't likely that I'll map or populate data I am not aware of being of any use. It's a bit of a chicken and egg situation, if you see what I mean. As more and more of FS is re-written using C++ object-oriented methods, more and more data is being encapsulated in private parts of objects and getting hold of it is getting more and more difficult. Maybe. But finding those values is a very difficult job. Sorry, I don't understand what you are suggesting. You start off trying to understand FS's logic for determining (one of) the effects of icing, and then suggest that FSUIPC duplicates FS, or attempts to. Why? What's the point of FSUIPC doing it? You are simulating icing effects on the pitot tube? Is this because you think the FS mechanism for this doesn't work? I'm rather confused now. And what about the effect of the build up of wind ice on performance, expecially lift? Maybe that would be a good addition, as I don't think FS does that. Regards, Pete

Well, that wasn't so much me, but the AVC programmers using the same system (a Registered message) as Roger Wilco, which I supported for many years. The key assigned in AVC is irrelevant to FSUIPC because it sends the controls to AVC directly, not via the keyboard. If you use a button for PTT there is no keyboard key involved. Well, you won't like RC then, as it needs many more than 3 for all the different requests and replies you may need to give. The FS ATC also uses more than just the one to open its window. There's really no equivalent of "Push To Talk" in either case. Since neither RC nor FS ATC uses "PTT", and AVC only uses PTT, I can't see that there is anything in common at all. Sorry, I'm not sure what you are hoping to achieve. With on-line flying you have real humans listening to you and interpreting your requests. With FS ATC and RC you don't, so you use different keys. You can of course try using MS GameVoice or the recent Voice Buddy, to convert voiced commands to keypresses -- maybe the PTT comes into action then? FSUIPC looks at the key before FS does so multiplayer or otherwise is irrelevant. If you want a button to both send the FS ATC window keypress as well as sending PTT to AVC you can do that, you can have a number of things all happening when you press the button. But to do this you have to edit the FSUIPC.INI file. Full details are provided in the Advanced Users Guide for FSUIPC. Regards, Pete

Sorry, I'm not aware of one. If you find anything, let me know. Regards, Pete

I don't have a website, but you probably mean Enrico Schiratti's site, as he does present all my software. Other sites only provide some of it. I think you'll find, if you read it again, that they undertake to send the key(s) to you within 24 hours. Generally it is faster, but it depends on the time of day. Humans are involved and they do eat and sleep. :wink: If you applied by email the response is to the same email address. The home address is normally for verification of credit card, if that's how you paid. Only allowing one hour before getting so het up is a little extreme, isn't it? Many sites providing keys for downloaded programs only undertake to do so within two days or more. SimMarket are very efficient and usually it is only a few hours. If you don't hear within 24 hours, as stated on the site, report the problem via http://www.simmarket.com's Customer Services. Regards, Pete

Icing is a weather property, part of the cloud data. If the responsible cloud layer isn't one of the lower two layers which are available in the old FS98 weather areas, then it would only find differences in the New Weather Interface areas up in the Cxxx offset range (FS2004 only). The Advanced Weather Interface for FS2000 and FS2002 would also reveal the data, but that interface is a request-response interface and cannot be searched in that way. Use WeatherSet (WeatherSet2 in FS2004) to check the cloud layers. Regards, Pete

It looks like the aircraft you are loading (B727-2ANG 2004\b727) has a Gauge installed which accesses FSUIPC and has two things wrong with it: 1. It is accessing FSUIPC using the EXTERNAL applications interface, which is why it looks like it is FS2004 which is accessing FSUIPC (the external interface check identifies the PROCESS, which is FS of course). This access method is wrong and always has been wrong. It is inefficient, it can cause problems with other, more legitimate, gauges and modules attempting to access FSUIPC. I provided a special internal module user library and interface over four years ago. 2. It is not an accredited program, so it hasn't got a key. Moreover, because of its incorrect access method it cannot be granted a key, even if it is FreeWare. There's no way it can be recognised correctly. The only way you can use it as it stands would be to register FSUIPC yourself. This wouldn't avoid the possibility that its access method won't clash with other add-ins, but it would allow it to work correctly, assuming it is really FS2004-compatible, which looks a little unlikely to be honest. Oh, there is one other course of action if you prefer. It may only be one gauge in the aircraft which is responsible. If you found it (in the PANEL.CFG file) and stopped it loading, then the rest would probably run okay. As the first access it is making is to the Central Fuel Tank (0B78) I suspect it will be either a fuel gauge or some re-filling or warning system. Regards, Pete

Whatever you can remember, really. I use Clear weather = Ctrl+Shft+W Standard Baro = Ctrl+Shft+B (B on its own is FS's QNH) Sim Rate 1x = Ctrl+Shift+X (X for X1) If you want something a little easier to press you could use TAB+W, Tab+B and TAB+X respectively. Regards, Pete

Registering FSUIPC is unrelated to Registering WideFS -- the use separate registration keys. And for FSUIPC 3 you need WideFS 6, previous versions won't run, there are too many changes. WideFS 6 needs registering or it cannot be used. Well one of them, the one containing WideServer.DLL and FSUIPC.DLL, needs to be running FS, of course, as those modules are FS modules and have to be installed in FS. All the other WideFS client PCs simply run WideClient.EXE instead of FS, plus your application programs. Correct. Regards, Pete

Not that I've seen. The closest I can get is what I mentioned. Apparently you must have that first download to get it going. Oh, sorry. I misunderstood -- I thought FS automatically updated your weather every so often, something like 15 minutes, if you selected the option. I know you have to start it off. Well, I don't know the reason you couldn't have it defaulting, or saved with a FLT file, but I do remember it was discussed. Sorry. :lol: Ah well. If I knew how to do it I'd certainly add it in some place, but it isn't really an area I know much about. Most of my work on the weather has been to try to support the external weather programs, which I think have a better chance (in the longer term) of developing into something more worthwhile. With FS facilities it's often a two year wait instead! :wink: Regards, Pete

I don't remember any of this and had to look it up myself, but that line looked wrong anyway. The format according to the documentation is: N = Bn:c, W, S I think the "B" there needs to go in so ESOUND knows you are referring to Buttons. Other letters are M (modules) and V (variables). Otherwise it's a token name. Regards, Pete

No. I have no idea how to do that.. doesn't FS do that optionally already if you enable it? This is for what? To save two clicks each time you load FS you mean? I don't know of any way of making FS default to going on-line without some user intervention. Sorry. The weather functions in FSUIPC are almost all related to the interface FSUIPC provides for EXTERNAL programs. I have no way of interfering much with FS's own stuff. FSUIPC's prime purpose is to provide an interface for external programs. It doesn't actually try to replace FS's own provided functions. I wouldn't even know how to do most of them. Sorry. Regards, Pete

The button numbers 0-511 are derived assuming 32 buttons on each of 16 joysticks (the Windopws Joystick API limits), in order. So "1,9" = 1 x 32 + 9 = 41. Try 41. If I re-wrote Esound (and my EPIC stuff) now I'd use the J,B format, but all that software is many years old and uses the original pre-Windows EPIC button notation. Regards, Pete