Pete Dowson

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

No, there's no such facility in FSUIPC at present. In fact it has never been asked for, at least not a direct switch-over like that. Well, I assume some of that is to do with Airbus automation / fly-by-wire. It certainly isn't realistic for all that to happen on one button push in any of the aircraft I know, but then I know little about Airbuses I'm afraid. What direction does the throttle operate in to control reverse thrust? Surely not push forward for increased reversed thrust? That seems rather non-intuitive. The FSUIPC provisions allow for the IDLE to be set a chosen distance up the axis, so that when the throttle lever is pulled all the way back it provides full reverse. Exactly. It is certainly possibly to provide controls to re-assign axis uses, or simply to change the range of axes, as you seem to want. However, to provide general programing facilities like that with an easy-to-use interface is not a small job. For some time now I have had on my list a project for a separate module, or even program, to not only allow dynamic reprogramming, but also for having variable response curves and keystoke emission at different axis values (for Airbus throttle detente type operation. However, that's a big project to undertake and there's been too much other work to attend to. I'm not really sure of the true usefulness of just having the throttle being a foward axis or reverse axis, expecially not with the confusion of reversal of direction, but I can consider it. On the whole I would rather leave it and do things more comprehensively, later, when I get the time. Yes, that is important. You need a reliable non-jittery area for idle. Best to glue a small piece of rubber (say) onto the axis slot as a sort of "detente", just offering a little resistance so you can "feel" the throttle into idle from either forward or reverse settings. Regards, Pete

Sounds like either you need to thoroughly calibrate them in Windows' Game Controllers, or there is some fault in them or the connection. Oh, right. That's odd then, because both FS2002 and 2004 have the same joystick input routines. The main change was between FS2000 and 2002. You only purchase version 3. All the updates 3.xxx are inlcuded, you don't need to pay for each one. And 3.04 isn't supported, it's too old. I only support the current versions. Why not use the latest on both? Check the History document for all the changes and improvments you are missing otherwise. No, not unless you are using FSUIPC to calibrate, in which can you may be doing this better in one than the other. Just try copying your FSUIPC.INI from the good installation to the other. Make both of them 3.135 whilst you are at it. There are no values relating to joysticks in the Technical tab -- you mean the Joysticks tab? Simply press the "Reset" buttons on each axis entry, so they change to "Set", then FSUIPC won't be interfering at all in any of your joystick inputs. Regards, Pete

I only generated the key based on the information given to me at that time. In fact a Product Name or Product Description field is needed, so I don't know how the currently uploaded version (2.0) was ever used with the Key I published, even though this dates back several months already. I know Jose is near publishing a revised version which is (also?) compatible with FS2004 -- version 2.0 isn't, as far as I know. If this is not suitable or imminent all I could do, with Jose's permission, is patch the Properties in his version 2.0 to make it acceptable to FSUIPC. I can do this during the week, but perhaps meanwhile you could post this to him and see what he says? Thanks, Pete

Not that I know of. The best data I found, actually available in memory for FSUIPC to locate, is the GPS data now mapped in the 6000-61FF offset area. You can read the details of the previous and next waypoint, and the number of them, but I've not found the complete list nor the filename. There may be some other stuff in that area -- I've only documented what I recognised. Regards, Pete

Okay. The only reason there's not been a key for it is that no one has asked before. since all the information I needed was in the Log extract you supplied, I have managed to make a key without further to do: Application="Airport" Product="Airport for Windows" Company="Tom Hiscox (thiscox@msn.com), Pascal Meziat (pascal@simflight.com) " key=E590 W3BL YV9L I'll add this to the main list at the top of this thread. Regards, Pete

Sorry, what is "Airport"? Is it freeware? Pete

Right at the beginning of the FS2004 Beta phase, or even a bit before, if I remember correctly, MS did ask if I could produce a specification of what I needed, so they could produce a proper interface module. I was a bit taken aback, but quite pleased. So I responded with the Programmer's Guide I'd produced -- "look, these are all the things folks use at present. that's a start. But there will be more ...". They said, "... but we need an inclusive list". I said that there's no way it can be "inclusive" because there's always something else, some new application or need. I can't predict what that may be. You just have to look at the changes in the Programmer's Guide from version to version to see that -- when compared with what was available in FS98 it is astonishing what's been added. Not only that, they said that even if we agreed on some specification of the data needed, it would be AFTER release date before they could even start to look at it, and after the revised SDKs they normally produce as well, most likely. So, at that rate, maybe we'd be lookng at something soon, maybe by Summer or Autumn this year. I reckon that even if we'd agreed something, it would have had to be cancelled. The pressure on the MS team for ongoing developments is quite heavy, it's a small team, the SDKs are voluntary (not committed), and they will certainly have started working on FS2006 (?) by now -- it's Alpha testing will be starting in not so many months. The best bet for something more successful would have been if they could have put me on a sort of "trusted outsider" status (with an NDA of course) and let me see the header files and internal interface details. Some of the team thought that would have been a good idea, but management would never has stood for it. Then, when I found I had to go semi-commercial (reluctantly forced by changed circumstances), that was most definitely not an option for them and presumably will never be again. Regards, Pete

Disassembly (I use IDA Pro and PE Explorer) and Debugging (Soft-Ice mainly, MSVC Debugger and WinDebug for some things). In other words what used to be called "hacking", though that term has now come to mean, more usually, breaking into Internet or other on-line resources. I don't do the latter at all. :) It's hard work and takes a loooonnnngggg time! Thousands of hours goes into finding stuff in each release -- and it gets harder now they use C++ and COM a lot, the assembly code that produces is awfully convoluted. :roll: Not that easy. Much of the stuff I need isn't exported at all, even by the old FS5-type linkages which have always been the mainstay. I have to find not only the routines but also the correct "this" pointers to stuff into their "this" register (sometimes ECX, sometimes not!). Same with data -- in C++ there's not such a big distinction between data and code, it's all wrapped up tight in the protective black boxes they call "objects" these days. Ugh. :x I am at heart and by history an Assembler level programmer. C is about as far away from the nuts and bolts as I like to get. The sort of code produced in the name of Object Orientation is totally alien to me and makes me shudder! :( Regards, Pete

Not quite. In the UK the requirement is that all IFR flights in controlled (class A-E) airspace must file a flight plan. In uncontrolled airspace (F/G) a flight plan is not required Sorry, I was referring to FS. Pete