Pete Dowson

The author did apply for a Key and was issued one back in August 2004. When this occurs, I always assume that they are following the FSUIPC SDK documentation and building the key into their product. The list of freeware keys in this Forum is only for those programs no longer maintained or supported and therefore which didn't get the keys built in. Since there have been no other such questions in the 21 months since the key was issued I can only assume either that the DLL is rarely used or that the key is, indeed, programmed in correctly. Haven't you even tried it? Regards, Pete

Why the indirection? You'll be using shared memory with FSUIPC to read its data. It seems to be a waste having a program merely to pass data from one shared area to another. The interface to FSUIPC involves memory shared via the memory file system in Windows, the same as is used for most of the inter-process data passing in that environment. If the other program has an FSUIPC interface, then as I just said, it should be reading the data from FSUIPC in the first place. It would be wasteful to have a third program intervening. What is providing the HUD and this Icon? If it is a gauge in FS, then you'd be better off doing most of this stuff in the gauge itself. I'm not sure how you'll get an existing FS gauge to respond to your inputs unless it is by changing something in FS which it is already reading. Not knowing what data it is you wish to read and/or change I cannot really advise any further. I suggest you download the FSUIPC SDK from http://www.schiratti.com/dowson, and scan through the programmer's guide documentation you'll find therein. Regards, Pete

Where are the wideServer and WideClient log files? That's where the answers are most likely to be found. Sounds like you have a Network problem. No, please don't play with any of those configuration parameters, unless we find out they are needed. The values have been optimised over many hard hours of testing over several years, and suit all systems I've yet come across. I don't think yours will be any different. There's no way to know what is happening without looking at whatever the programs are telling us, and that is in the Log files. Regards, Pete

If you select the turbo quadrant in PFC.dLL, the throttles there are already set to do that. There are 8 throttles, if you look at the list (a picture in the Doc). Four "ThrottleN" and four "ThrottleRN" (where N goes from 1 to 4). The "R" variety include an idle notch calibration and a reverse zone. If you are assigning a User Config you would need to find those in the drop-down lists, but simply assigning the appropriate turbo quad will give you the correct ones in any case. Haven't you just gone and tried? I thought that would be the first thing you'd do when I said just to enable the turbo quad. Pete

If you mean you SAW the AI aircraft touchdown, yet it still remained in the Airborne list, that's how it was for a while before I fixed it in 3.47. With it working like with the way HotSeat was then, you either wouldn't get the HotSeat sounds, or they'd be late. For them to be EARLY, the Landing aircraft must have moved to the Ground list with the aircraft still floating 50 feet over the tarmac. If the aircraft moved to the Ground list correctly, just about on touchdown (maybe slightly before for a small aircraft, owing to the 50 feet check), then it sounds like the HotSeat author is now looking at the Airborne list instead of the Ground list -- possibly trying to compensate for the short period of incorrect classification (about two years ago). There is obviously no way to resolve this without FSHotSeat involvement. I really don't know what they've done. I also don't understand why you originally said that ALL versions of FSUIPC after 3.40 had the sounds LATE, but now you say EARLY? The change to the current system, which is the best one all round, was in 3.47 about 15 months ago. BTW just to crosscheck that it was all operating exactly the way intended I've just been watching aircraft landing at O'Hare (I chose somewhere nice and busy! ). The "Landing" state on the Airborne list starts on finals -- and not short finals either, but 10-16 nm or so out. But watching both lists at the same time, with a closeup on the runway, I can see them shift from the Airborne to the Ground list just about perfectly, when the dust kicks up from the touchdown. I hope you get the answers from the author. Regards, Pete

The PFC.DLL cannot detect what quadrant you have connected -- there is no hardware mechanism for that. They are merely mechanically attached, not electrically. If the turbo quadrant assignments are to your liking, just enable that quadrant so that it gets selected, then calibrate it as usual. Alternatively, you can use one of the User-defined quadrant pages and define the levers to do whatever you want, calibrating each lever again there. I did most of my development and testing only with a six lever (4-jet) quadrant, just because all levers were then always available. Regards, Pete

I don't think so, they were undecided about how to play it. I think it possible they only sell it to hardware makers like Aerosoft Oz and GoFlight, maybe. But ask in the PMDG forum. Pete

That's both one -- a linear response, which is the default, is a "straight S curve". Didn't you get any documentation with the PDF.DLL? If not then it wasn't my ZIP you received (the current user release is over at http://www.schiratti.com/dowson along with all my other FS software. You might need to download that first in order to get the documentation you appear to have missed). It sounds like you've not even calibrated the controls yet -- that should be your first step. The instructions are all in the document. There's even pictures, including one of the "S curve" facility, which is actually entitled Sensitivity changes: "Response Curves". I know most folks don't bother to read instructions until all else fails, but it really would work out quicker than extended exchanges on a Support Forum. ;-) Don't forget to check the aircraft model you are using too. Regards, Pete

Well, it isn't that easy. The problem is that the "short name" option was a later add-on, so I couldn't default it in case it messed existing users up -- there are lots of cases where the short name would match others. I did think of using "*" for "anything else after this", but there's actualy nothing stopping that, or any other character, being used in the aircraft title. Regards, Pete

You didn't show me the main INI file parameters -- did you set "ShortAircraftNameOk=Yes"? This is needed to make that work on all parts -- Keys, Buttons, Calibrations and Axes. Regards, Pete

If you have the response set to linear, then the sensitivity is exactly as it needs to be to reach to maximum deflection at either end. If you want less sensitivity near the centre you need to select one of the "S" shaped response curves. This will make it even more sensitive at the extremes to compensate for a flatter response near the centre. It is still necessary to be able to reach the extremes -- if they are "too extreme" then it is the aircraft model which is the problem. You can adjust control surface efficiency in the Aircraft CFG files. Yes, but FS's sensitivity slider is just a divider -- it reduces both the range of movement you can achieve and the resolution of the control input. Even with such a device I would say that you could get much better results setting sensitivity to maximum and calibrating in FSUIPC with an S-shaped slope applied. BTW nothing in what you say seems to relate to your subject heading "jumping wildly". Where does that come from? If the response is jittery up and down, and fluctuating wrongly, then you either have a faulty connection or a bad pot, or possibly or poor power supply. You probably should talk to PFC. Please also try the interim release version of PFC.DLL (1.998) available in this Forum (see top), as it does fix an error in the X axis which may cause jitter in certain circumstance. Regards, Pete

Okay, now that you explained this on the 'phone, here's what you can do. There are 64 bytes of free offset space reserved for users. Currently I use them in the programming examples in GFdisplay only. They are from 66C0 to 66FF inclusive. You need to program a button (one which isn't real, so you don't lose a real one) to set a WORD (16-bit or 2-byte) offset to the value 1. You'll need to edit the INI file for this as you don't have the button to program on-line. I'll choose button 0 on joystick 16, just as an example, and offset 66C0. In the [buttons] section add: InitialButton=16,0 1=P16,0,Cx020066C0,x0001 If you already have buttons programmed, just make the 1= line the next sequential number available instead of 1. What this does is make FSUIPC simulate the pressing and releasing of button 16,0 when it starts. The Control "x020066C0" says "Offset Word Set" and the parameter x0001 sets that offset to 0001. This gives you a 1 in byte offset 66C0, and a 0 in byte offset 66C1. I hope this is clear. Incidentally, if there are other things you need doing initially, just add more program lines for button 16,0. They will be done in the order of the line numbers (the 1= bit). Regards, Pete

Sorry, I am lost here. What would "fixed digits" be in FSUIPC offset terms, and why would you need any offsets at all to display anything, let alone something fixed? Regards, Pete

Yes, but in which list -- airborne or ground? If you saw it after touchdown still you must presumably have been looking at the ground list? The whole trouble is that the "Landing" state starts when the aircraft is on finals, and only changes to "rolling out" for a short time some time after ground contact. In fact with the poll rate of many programs the 'rolling out' is often not seen. What happened a couple of years (nearly) ago was that I was classifying it on ground or not based on the "on ground" flag, separate from the state flag. However, that turned out to be dodgy because of bouncing, and so on, and it was apparently too late for programs like hotSeat or HotSFX or whatever it was back then. So, for the last year or more (since 3.47 in fact), I've classified the AI as "on ground" if their state is obviously one on ground (sleeping, pushback, taxi etc), or rolling out. "Airborne" likewise (departing, enroute, in pattern). That leaves two dubious ones: "Take off 2" and "Landing": here, since 3.47, I classify them "airborne" if they are at least 50 feet off the ground (measured to their datum, so cockpit probably), otherwise ground. There are other programs, like Radar Contact and AIsmooth, which depend on this stuff, so I needed to try to get it reasonable. Really, unless we understand how FSHotSFX or whatever is making its decisions there's nothing we can do. I would be reluctant to change it again when it was confirmed as fixed over a year ago and is in common use the way it is now. As far as I can tell from watching programs which use this information, I think the methods I use now are fine. Did you report this to the author or his support system at all? I don't know how you'll get it resolved else. One thing you can do for more "responsiveness" (but possibly reduce your FS frame rates a little) is increase the Traffic poll rate in FSUIPC -- the default is only 10% of AI aircraft per frame. If increasing that to 100% removes the delay then the problems you are seeing may just be polling delays. Ideally FSHotXXX should allow you to configure the delay (positive or negative) to handle individual systems performances. The parameter to change in FSUIPC's INI file is TrafficScanPerFrame. Regards Pete

No. There is no limit as far as WideServer is concerned. I regularly connect 8 or more clients. I'd need to see your WideServer, WideClient Logs and INI files before I can even make any guesses as to what may be occurring. There is no measurable affect on FS frame rate for installing FSUIPC alone. It actually does nothing by itself. Do you have something else running at all? And what was your previous version (the one with "22")? I do hope you haven't renamed any versions and left them in the modules folder, or placed any in the main FS folder? Ahyou run PFC too? Please try removing your FSUIPC.KEY file from the FS modules folder, first of all. Then check your modules folder thoroughly -- it sounds very much as if you have something duplicated there, probably re-named. Also check you have none of these DLLs in the main FS folder. Since a "complete re-installation" merely consists of copying the same DLLs into the same place, I am not at all surprised. No, for PFC not to get the correct version of FSUIPC is very very strange. It doesn't even have to "connect" to it like external programs, it gets it directly, in memory. This implies something very corrupt and actually taking place of the correct memory. Please check the things I mentioned, then come back. Regards, Pete

In that case it is one of the axes not supported by the standard Windows joystick API, only DirectInput (DX). Sorry, FSUIPC does not use DirectX at all. I only mentioned "null zone" to remind you to set it far left. It doesn't have to "operate". The main relevant part is the Sensitivity slider, which sounds as if it is full left -- which is zero sensitivity. Just set it full right. It looks like you skipped over the most important part of my reply. Check the sensitivity, as I already said. Regards, Pete

You are really full of ****, you know? You say FS is simple -- so, tell me, how does it work? Do you know? I've spent many years with all sorts of versions of FS and I only know how small parts work. You complain about my technical documentation on the one hand, and want me to tell people how my software does what it does on the other? Get a grip! If you want to start delving into how my things work, start with the FSUIPC SDK, freely downloadable. Once you understand that, ask questions about how each bit does what it does, and I'll tell you. But I'm not about to launch into a many thousand page manual about how I manage to make things work the way I do. Oh, and I do recommend TCP/IP on XP systems -- the two are compared in the documentation. In the latest interim version I also support UDP, which is definitely faster but less reliable. Check your facts please before posting. You seem to put finger to keyboard without any prior thought far too often. Pete

Okay. I've checked, and, yes, writing to 2834 does "stick" -- all that happens is that FS counts down by an amount which is determined by the electrical load (unless FSUIPC stops it via the "magic battery" facility),or, if it is set to a value below full charge, when the generators are running it increments it until it gets to full charge. So, I've added the following new FSUIPC offset controls: 0x7000zzzz Offset Float32 Set/1000 0x7400zzzz Offset Float64 Set/1000 0x7800zzzz Offset Float32 Inc/1000 0x7C00zzzz Offset Float64 Inc/1000 In each case the parameter is divided by 1000, so giving three decimal places in the final value written or incremented. Decrements are via negative increments. I attach interim test version 3.609 of FSUIPC for you to try, to see if it meets your needs. Regards, Pete FSUIPC3609.zip

Actually I have nothing to do with it apart from supplying the ZIPs for upload, as I, in fact, do for around 50 other sites. Enrico is the only one who actually gathers all my stuff onto one page, which is very nice of him, and this is the reason I refer folks there in many places. He does in fact imply this on the page, thus: However, this is a minor point. We should forget it and not argue about it, that's silly. There you are again! What a frustrating person you are. Please read things a little more carefully and don't add your own words. No where, in anything to do with WideFS, does it say or imply the need to have FSUIPC registered. To use WideFS you only need to register it, but that is done IN FSUIPC as WideFS has no user interface at all of its own. No one has ever made the mistakes you are making, so it seems you are almost deliberating setting out to be awkward. I don't find this interesting or amusing, and I am not going to be drawn into any more silly and unproductive conversations with you if you persist. No, that is another total untruth. FS Navigator has never used FSUIPC and doesn't need it at all. The rest of your message, another overlong and unnecessary diatribe, is not worth answering. You have your views and you obviously like to expound upon them at length. In total here you are fast approaching the length of some of my documents which you despise with so much venom. Good bye. I am simply not allowing myself to be tempted by any more of your nonsense. Pete

FSUIPC doesn't recognise it where? In the Axis assignment facility (FSUIPC 3.60), or only in the Joystick Calibrations? If it is the former, then it seems like it isn't one of the standard 6 axes supported by the Windows joystick API (X Y Z R U V). What puzzles me about what you say, though, is what you mean by FS displaying it but not making use of it -- how can it "display it" if you cannot assign it? Or do you mean you assign it okay, but it doesn't operate the thing you've assigned it to? If the latter then all that means, probably, that FS has got the sensitivity set to zero -- go to the Sensitivity slider and move it full right. Whilst you are there, move the null zone full left. If that makes FS work with it, then it should also make FSUIPC's calibration section see it. Regards, Pete

Oh, right. Sorry, I misunderstood. And I assume you aren't using software with flexible user programming like the pmSystems from Project Magenta? I am reasonable sure that it just counts the voltage down as juice is used up before the generators are on, so you might get away with just writing a value once, but some experimentation would be needed. Used in conjunction with FSUIPC's "magic battery" option (to extend the life) maybe you'd only need to be able to write something small to it. Trouble is it is 64 bit floating point, so with current FSUIPC facilties the only value you can easily write is zero, but you'd need to write two 32-bit zero words to do that. Best actually for me to add new FSUIPC offset controls, to write 32-bit and 64-bit floating point values calculated from, say, a normal 32-bit value representing the amount needed times, say, 1000. I would probably add these to the list in the Advanced User's document: 0x7000zzzz Offset Float32 Set 0x7400zzzz Offset Float64 Set I'll check first that offset 2834 does operate as I thought. If you think you could use this I could supply a test version of FSUIPC for you. What do you think? Another alternative is, of course, to simply use FS's master battery switch, and invent your own which only operates the FS one when the APU is running correctly. You could achieve such simple logic using FSUIPC's conditional button facilities. Regards Pete

Okay. Please give the attached version 3.608 a good going over. I've been testing here and it seems okay so far. I'll continue over the weekend too. Basically this is now what happens: 1. FSUIPC only loads the default Axes or the ones specific to the current aircraft (allowing for the shortened name option if that is set and used). The decision is based not on the presence of an [Axes ...] header, but on there actually being valid assignments in that section. In other words, you can't have an aircraft-specific section with no assignments -- it will be ignored. 2. Everything in the on-line editing works identically for the general and aircraft specific assignments. 3. When running with the general assignments (i.e. for an aircraft not provided with a valid section), selecting "aircraft specific" will bring up a message box asking if you want to use all the general assignments for this aircraft. Here you can cancel (go back to general) , or select Yes to work with the general ones, changing them as needed, or select No to start with a blank sheet. In either Yes or No case you may be asked if you want to save any changes in the general axis assignments you may have made so far (else they will be lost). If you select "No", to start from scratch, but then don't assign anything, FSUIPC will revert to the general assignments for this aircraft (it will reload them automatically when you Ok). 4. The converse is a little different. If you enter the dialogue whilst running an aircraft with existing specific assignments, then try to de-select "aircraft specific", you will be asked if you want to delete all the specific assignments. No or Cancel will retain the status quo, otherwise the general assignments will again prevail for this aircraft. This actually represents a new facility -- before this it was only possible to lose aircraft-specificness by deleting every such assignment via the dialogue, or by deleting the section in the INI file. Note that FSUIPC does not (cannot) delete the [Axes....] heading in the INI file, but it will be emptied, making it ineffective. I hope this is all clear! Have fun, and let me know how you get on. Best regards, Pete FSUIPC3608.zip

This is only because it is controlled by something in the Aircraft.CFG file, and gets overridden all the time. You don't really want to do it that way, I assure you. I'm not sure what aircraft you are looking at, but most of the airliners I know of won't power the buses for the instruments unless the battery is on in any case. The APU just provides more power and keeps the battery charged up. No, but you can control the battery voltage by writing to offset 2834. That's the better way. You can drain the battery and charge it. More realistic, no? ;-) Regards, Pete

Where else do I contact you, according to your website, you only accept conversations in this place, that was not my design, but yours. I was not suggesting you contact me on this subject! The questions you want resolving, about assorted ways of confiuring FS and the many display options there are have been and are still often discussed elsewhere. Here I support my programs. You really haven't got to that stage yet -- you still need suggestions about ways of doing what you want to do. I don't write or support applications, only tools for applications, and you may not need anything outside of FS to do what you want in any case! No. A way of discarding the second PC. You don't even need a triple head if you only want the two screens you mention. Almost any modern video card supports two monitors out of the box. Join the club. I'm 63 this year and at this rate won't see 64. :-( No you are not! You are a customer by accident or mistake. And I am very sorry about that. You should find out how to do what you want first, not how to use tools which may or may not be anything whatsoever to do with it. In fact, there is really nothing my programs will do to solve your problem. You need to look at FS itself, which has many capabilities already, then, if you desire, look at external gauge programs. They may or may not use my software as tools -- there are some which do and others which don't. Either way, the instructions which come with the applications are the most important part, not my instructions which are mainly for reference in any case, at least after the first page or two. BTW I see you are in Cheshire. Far from Stoke-on-Trent? If you were to become a bit friendlier, so i wouldn't be frightened of you as I am now, then possibly you could visit? I have some interesting stuff here, accumulated over the years (I've been programming things with FS since FS4 days, more intensively when my eyesight problems stopped me getting a pilot's license). Pete

You did not ask "HOW", you just launched into an insufferable barrage which I found quite insulting and not in any way inducing one to answer kindly. If you browse some of the threads here you will find I answer questions as helpfully as I can. You apparently came here to rant and rave, not really to seek any guidance. If you look back on your messages perhaps you may see that -- imagine you or your projects are the object of your own outbursts. I have worked full time on these programs now since FS98 days, and not earned one penny until I nearly went broke in the year FS2004 was released. I have never wanted to "sell" just develop and support, but circumstances forced the issue. FS9 is nothing remotely like a "simple program" I assure you. And it was never designed to do what you want of it. Maybe the next version will. Perhaps you came into this at the wrong time. Almost everything outside of FS's base capabilities has been produced by third parties and for the most part with no help from Microsoft. When I look around at what has been achieved with what Microsoft provides I am constantly amazed, yet you come along and deride it all as "simple" and wonder why everything for it is not too. Anyway, to answer your question, if all you want to do is have views on one screen and instruments on the other, just make sure your main PC has a video card which supports two monitors, then discard the second PC, attach its monitor to the first, and simply undock the panel parts and move them over to that monitor. You need nothing of mine nor any other add-ons, and it'll all run just as fast, better, in fact, than with two PCs. I don't have a Web site. If you mean Enrico Schiratti's page where he provides my software, that is a service he provides, for downloads. It in no way tries to explain what any of the packages do. The problem is that you are starting from the wrong end. You need to decide what applications you want to run, and then see what they need to support them. My programs are background, they are tools for other programs and do little useful on their own. There you go again! :-(. That is most certainly completely untrue! Where on Earth are you getting this stuff? You do NOT need to purchase FSUIPC to use WideFS! You only need to install it. Purchase gives loads of other benefits, which you don't even have to read about (it would presumably only confuse you). It isn't in that BOXED note -- the ordering of things in the documentation is deliberate, besed on the misunderstandings which have occurred over the years. WideFS is now in its 10th year and a lot of learning and experience has gone into the way those important parts are presented. You appear to choose to quote things out of context to distort this. Exactly, because folks, not unlike you it seems, constantly assumed it would run FS internals or do the job WidevieW does. From experience I judged it best to get all of the warnings right up front, because 90% of folks never read much further, even if they read that far. Most folks just install, try things, THEN think of reading the manual. This is even worse if they've paid and find out they can't do what they thought. Believe me, the order is correct and for very good reasons. If you don't like it, don't use it, but please don't come here with these attitudes. I can help if you ask for help, but I'm not going to take unjustifiable criticism apparently spoken out of ignorance. Please do come back if you decide to be more friendly in your attitudes. I cannot deal with you otherwise. Sorry. Pete