Pete Dowson

So what stops them containing calls to the main Windows API DLLs? What stops them doing standard memory allocations and using memory pointers, the lack of which appears to be the reason behind the "token" stuff in the .NET FSUIPC implementations? Everything I've read points to a lot of "protection" imposed on these prograns by the 'framework' layer that smells exactly like interpretation to me. Evidently I've not understood what I've read about them, but I also don't understand how they can be so restrictively "managed" with something very like what I call interpretation. Regards, Pete

Sometimes folks get this sort of behaviour over in the PM support web/newsgroup. Did you check there? I'm not sure what the causes can be -- maybe something has a memory leak (do you notice an increase in disk activity?), or the network drivers for your network card, or maybe your hub or switch, is having problems. Or the video card/processor is simply not up to the job at the frame rate you are trying to drive it all at. Are there any errors being reported at all in the WideServer or WideClient logs? That's really always the first place to look. The other thing to check is the video drivers, especialy if it is only occurring on clients which are heavily display based -- the PM PFD.EXE program being a prime example. If it isn't happening with the CDU or MCP software, for instance, then this would tend to indicate something to do with the display system. If there are no errors reported in the Logs, then the delays, if any, will be occurring in the lower levels of Windows network drivers -- maybe running out of buffers on a system where the processor is overloaded and not allowing the main application (PFD) to keep up with the traffic. WideClient won't be queuing anything -- if an update comes in before the previous one is requested, the previous one will simply be overwritten, so it never knowingly supplies anything out of date. What I think can happen, though, is that the PFD software and the video drivers it is using are taking so much time out of the processor that Wideclient isn't actually able to read the incoming frames fast enough. There are two things to investigate, apart from checking the logscompare the FS frame rate with the frame rate achieved on the PFD software. Try limiting the FS frame rate to something which can be matched by the client PC. And see if the video card and driver is causing any problems, hold ups -- ask in the PM group about this sort of thing. There are some known problem cards I believe. Another thing you could improve is to replace the 5-port hub by a switch. Switches used to be more expensive, but they are as cheap as hubs these days and much more efficient. BTW have you tried the latest interim version of WideFS? We're up to version 6.615 now. The UDP protocol, now supported, can be significantly faster than either SPX or TCP, but it is less reliable. you have to try it and see -- check the logs afterwards. Regards Pete

I hope someone who knows VB.Net will chime in and help, as i don't know it at all and some things about it seem positively weird. I guess most of the weirdness (for me) stems from it being a "managed" (interpreted) language rather than a true fully compiled one. Well, apart from "token" which is a puzzle to me and only seems to appear in the managed language versions, the others were certainly explained in my original notes for C programmers. I'm sorry if none of it came through in those voluntary contributions. Anyway: dwOffset is the offset as listed (in hexadecimal) in the main document with the long tables of variables. I think in VB you need to be careful of those greater than 7FFF since VB seems to assume 8000 and more are negative, and fills the rest with ones, making FFFF8000 etc. To stop that I think you have to postpend another $. dwSize is simply the size of data (the number of bytes) you want to read or write. The FSUIPC interface can read or write as much as you like, up to the buffer size limitations, but usually, if you are reading into a single variable rather than an array or structure you would set this to the byte size of the variable you are using, such as 4 for a 32-bit integer. The only other parameters defined in the FSUIPC interface are a pointer to where to place the result (your variable) -- or, for a write, where to get the value to write -- and a place to put an error number (result) should anything go wrong. You don't need to look at the result unless the function returns FALSE, to indicate a failure. Not sure that Forums can have sub-forums like that, but there have been plenty of threads with examples, at least in VB. Some in VB.NET too, I'm sure. Sorry, but scanning or searching may be the only way to find them. Limiting your search to this Forum with VB.Net as a keyword should turn up something. The latter two sound okay, but I'm not sure what is going wrong, if anything, with the data. I'm afraid someone who knows VB.Net would have to help there, unless your compilation system comes with a debugger, in which case you should be able to trace it through. After all, all the source code is provided and is part of your program. FSUIPC (the bit I know) only gets involved in one SendMessageTimeout call within the Process routine. Are you using FSInterrogate as your reference rather than the documentation, where it does tell you the units? FS stores many angular values in 16 or 32 bit integers, making maximum use of the capacity of those bits. So, since the range of angles is only 360 degrees, the most accuracy is achieved by making the whole range of values possible in 32 bits represent those 360 degrees. Thus 360 degrees would be represented by the maximum number possible, plus 1. The maximum number in 16 bits is 65536, the maximum in 32 bits is 65536*65536. Thus you can see how the formula is derived for converting the value you read into a proper angle in degrees. For accuracy and ease, you should copy the value you read into a floating point variable (I assume VB.net WILL do the conversion as other languages do?), and only then multiply by 360 and divide by 65536*65536 (or just by 4294967296, which is the same thing but harder to remember ;-) ). Regards Pete

Well, it's possible, but I wouldn't like to say that without looking at the logs first. It may be something easier. Regards, Pete

If it wasn't you'd probably get an error message. But you can check in the FSUIPC Log to see if it says it registered okay -- things like that are logged there. Regards, Pete

Okay. Good. The current Interim Version is 3.615, available above, so you may like to upgrade once again! ;-) Regards, Pete

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