Pete Dowson

Ah, I didn't spot that either! Two errors in one entry! That's good going! :D Er .. I'm in a bit of a mess with this thread. The originator messed up the proper flow by posting "URGENT I NEED HELP 2" with an identical message to the last one in his "URGENT I NEED HELP". By the time I spotted this there was another reply, so I tried to add the new thread to the tail of the old, but I simply cannot fathom this weird Forum software, so I now end up with two threads with the same title! Beats me. :? Regards, Pete

It needs the name only, the part before the .exe bit, so you enter Squawkbox, not Squawkbox.exe. It does actually say "(before the .exe part)" on the screen. In the FS modules folder, along with FSUIPC.DLL, FSUIPC.INI and FSUIPC.KEY. Regards, Pete

Show me the FSUIPC.LOG file. Tell me what you did to register Squawkbox. I really don't know anything about on-line flying or what you need, but I can check if you have done the right things for FSUIPC. There is a lot more to it than FSUIPC, however. Regards, Pete P.S. After tomorrow (Wednesday) I am away for 8 days -- back on the 24th October. So if you are not fixed up soon I hope others will be able to help you.

Ah, I'm glad it is documented! I did wonder. It seems quite bad having a language where even a value explicitly declared as &H00008000 is converted to &HFFFF8000 with no warnings, nothing. How did this slip into Microsoft's design I wonder? No need to apologise. I suppose there ought to be a warning in the VB part of the FSUIPC SDK, but the individual parts aren't really mine, and not knowing anything about VB I am reluctant to interfere with what is already written. Regards, Pete

I don't know why the Visual Basic programming books are so awful, because everyone asks the same question. It seems Visual Basic sign extends any hexadecial value, so your "C40C" becomes "FFFFC40C". FSUIPC uses the top 16 bits as flags for assorted operations to do with WideFS and the AWI. It masks out the bits that it likes and this results in your 8F. According to other VB programmers (and, I would hope, the VB programming books?) you have to post-pend another & to stop sign extension: &HC40C& I would have thought that specifying it as &H0000C40C would be specific enough, but no, the stupid compiler thinks it knows better and changes it to &HFFFFC40C, apparently without even mentioning it to you! I have lost count how many times I've had to repeat this stuff, there must be many mentions already in this Forum. Regards, Pete

I think that address is in a library routine. If your Win2000 update replaced more recent library DLLs installed by FS with earlier ones, which is possible, you may need to uninstall and re-install FS. All that means is that FSUIPC is not able to run far enough to open the log file. They change every time. I wouldn't worry about that. The only information which might be of use is a proper DrWatson log. If you check towards the end of the FSUIPC User guide, there's a section "If FS crashes ...". If you can follow that and Zip up the results I'll have a look. The bad news is that Win2K Dr.Watsons aren't enormously helpful, and, further, I am away after tomorrow until October 24th, so it will be a while before I can get to it. I do have a Win2000 installation here, but I'm not sure what it's update level is. It was the latest at the time but whether that was SP3 or SP4 I really don't know off-hand. Is SP4 recent? Regards, Pete

If you've not paid for and registered FSUIPC, you need to register Squawkbox with FSUIPC. There's a Freeware key for it listed in one of the Sticky messages above. Regards, Pete

I'm afraid you need to explain rather more. The FS2004 ATC does not use FSUIPC, so it is not involved at all. Are you using Squawkbox or something similar for on-line flying? If so, have you registered it with FSUIPC (assuming you've not registered your FSUIPC)? There's a free key for this listed in the Freeware Keys list above. I think also Squawkbox for FS2004 needs another program to convert the new FS2004 Multiplayer Interface to the FS2002 protocol that SB understands. Regards, Pete

Are you sure FS itself is not stuttering at the same time? The PFD may simply be reflecting what FS is doing. I notice that, especially with clouds, FS2004 will stutter more noticeably on turns, for instance. Also I get noticeable stutters near the ground which I think are associated with autogen objects appearing. This is on a 3.2GHz Pentium, but I do have everything turned up to maximum so I cannot complain! :wink: I wonder if the two parts of PM are competing for WideClient's attention and sometimes getting into conflict? You might want to try setting "UseTimer=on" in the PFD.INI, or possible setting it "Off" if you already have it on. Also I think there's some cycle time setting you can adjust in the MCP.INI file -- try different values there to see if there's any improvement. Ah, if you have a separate PC for the CDU I certainly think the MCP would be better there than with the PFD. I don't think there will be much in those which you should need to or want to change. Defaults for everything should be fine (it took me months of experimenting to get them that way, so if you start playing it could take you months too! :) ). But there are some things you can do in the PM INI files. Probably these are best discussed in the PM group where there are more knowledgeable folks on this subject than I. Certainly, though, experimentation is the key. I'm sure you can find a happy arrangement. Regards, Pete

That would certainly be possible -- maybe it ought to auto-unlock on a large input value change too? I can add it to my list of things to look at, at the end of the month probably. I'll think about the smoothing problem too, but it isn't an area I really want to spend a lot more time on when I would rather plan a more thorough assignment utility, as I mentioned. BTW there is already a smoothing action for PFC axes (all except toe brakes), active in PFC.DLL at present. It ignores reversals in direction if they occur within 150 mSecs. It needs three input values with the last two showing an up-down or a down-up and both within 150 mSecs. This should stop normal pot ambiguities, a fast wobble around one value. Are yours occurring at a lower frequency and getting past this check? The facility I am talking about is described in the documentation as added in Version 1.27: "Automatic axis smoothing has been added, to prevent much higher frequency jitter which can (presumably?) be caused by poorly smoothed power supplies." I think this is why I do not see jitter on my axes, or at least have to work hard to find it. Regards, Pete

Since the standard presure of 29.92" is equivalent to 1013.2 mb (or hPA), 1" Hg = 1013.2/29.92 mb. There are 25.4 mm in one inch, so 1mm = 1013.2 / (29.92 * 25.4) or 1.333214 mb. If you are writing to FS through FSUIPC you provide 1/16ths of a mb, so multiply your mm by 1.33124 * 16, or 21.33. Regards, Pete

No problem. Good flying now! Regards, Pete

Ah, so it is an AIR file or CFG file problem, with how the aircraft flight model is defined? Have you searched the web to see if any one has made better models? Sounds like there needs to be a little more damping on the yaw axis sensitivity. I think that would be better than attempting to smooth the inputs, as the latter increases the latency and makes it more difficult to fly, like poor frame rates. I'll add both to my listwhat does the "prop sync switch" actually do on the aircraft at present? BTW I am away from this Thursday till 24th October, so I won't be able to look at doing this till towards the end of the month. Regards, Pete

Why would using default drivers give "movement spikes"? I don't think the one follows from the other. You can use the FSUIPC calibration for any of the supported inputs which are assigned through FS. But they don't smooth jittery inputs. They operate not on the joystick values, but on the internal control values which result. The main purpose of the facilities is to provide precise maxima and minima, and well-defined "dead" zones, so that full range and stable centres can be achieved. Anyway, it won't do any harm to try them and see. You can reset the FSUIPC actions on the axes if you don't like the results by simply pressing the reset button provided for each. Regards, Pete

You shouldn't be getting a lot of such "wobbles". That's usually indicative of a poor power supply. I'm no hardware expert, however, so I think you should seek advice from PFC. I have to hunt for positions on my PFC throttles where there can be such wobbles (presumably then due to dirt or temperature or humidity problems, I don't know). The value of '3' seems to be the resolution of the pots used by PFC -- the maximum range of 0-127 (rarely achieved) therefore actually only has about 40 discrete positions and I assume that anything part way between then is "ambiguous" and may therefore be liable to this "wobble", though as I say I find them difficult to find. But I did get a much more powerful (and smoothed) power supply than the one originally suggested. With only 40 positions, any smoothing I might apply betwen adjacent readings (i.e. 3 apart) would have the bad side effect of effectively reducing the available positions to only 20, not enough at all. Either that, or making them slow to respond. I've had on my list, for a long time, features for assigning programmable axis inputs for FS, with definable response curves, slopes and detentes. But this is a rather big project if I am going to be able to achieve it with a decent understandable user interface. Finding time for such things is my main problem. Regards, Pete

It occurred to me that what you might mean by "thrust vectoring" is actually asymmetric thrust -- i.e. one engine providing more than the other? I tend to think of "thust vectoring" in terms of things like the Harrier jump jets. If you are getting asymmetric thrust with the levers set the same, you could try re-calibrating them to be a bit closer. However, you will never get two pots giving exactly the same readings all the way along, even if the ends are exactly right. So always check the readsouts for N1/N2, or EPR, or RPM, or whatever your particular aircraft measures engine performance by. There is also a Hot Key you can program (in a Registered FSUIPC) which enables a throttle sync function. This actually copies the throttle 1 input to all engines, so you are then bound to get identical performance from each, all other things being equal. If you use this just remember to toggle it off when you want to use asymmetric thrust to aid in ground steering! Regards, Pete

FSUIPC doesn't provide any such facility, but you can easily switch those off in FS9 -- try the Options-Settings-General menu entry, uncheck "Show cockpit tooltips". Regards, Pete

Download them again from http://www.schiratti.com/dowson. Naturally if you completely re-install FS and deleted the original you will lose everything you installed into it in the first place. Next time you want to do such an extreme thing, use the FS uninstall but do not delete anything it doesn't, then install again to the same place. That way all the additions will be retained. FSUIPC and WideFS are always available from the Schiratti site in any case, and 3.04 is pretty old now. Go get 3.11. I hope you saved your FSUIPC.KEY file some place safe, else you'll need to re-enter your registration details too. Regards, Pete

Sorry, no. I don't even understand the term "thrust vectoring". It sounds like you need to talk to someone who knows something about the specific aircraft model you are flying. There is no difference in PFC throttle inputs between aircraft. It's just straight forward throttle axis position converted to throttle control value. Same with all aircraft. Watch the throttle lever positions on the FS panel graphic. Regards, Pete

Why did you delete your FSUIPC.KEY file? When you upgrade from one version 3 to another you only need to pop in the new DLL. No re-registration is needed unless you delete the KEY. All you need to do now is re-enter all the details EXACTLY as originally suplied, same name, same email, same Key. Everything must be exact, character for character. Pete

Version 3.11 does this fine. Pete

I doubt if playing with that will ficx the problem. Maybe reomving or changing other modules will. The "initdelay" value simply controls how long after being loaded FSUIPC subclasses the main FS window so it can receive messages from client programs. In earlier releases this defaulted to 3 seconds, but with experiments here, on my system, I found that reducing it to 0 helped. But it only helped when I also did the same in AdvDisplay, PFC.DLL and removed Lago's ViMaCore2004.dll. Any on of those would give me the same symptoms. I think there is some timing problem, probably in DirectX9, which is affected by small changes in the order or timing in which certain calls are made. These will be all from FS itself, as none of the modules I mentioned has anything to do with graphics or DirectX. You can read a lot more about all this in other threads. I think we are all hoping MS will some time release an update for DirectX which wil fix it -- judging by results from saearching the Web it isn't confined to FS but affects a lot of DX9-based graphics games. Well, it is really up to Peter to explain that. I didn't want to do it and I do not support it, and I certainly don't appreciate it being published openly. It simply tells programs that they are running on FS2002 instead of FS2004. This will wreck the facilities in some (e.g. FSMeteo), but apparently it is needed for one of the gauges in Peter's panel which checks for FS2002 else won't work. It would be better to fix the gauge, as it is evidently checking needlessly for FS2002. Regards, Pete

I don't know Delphi -- is "single" a 16-bit unsigned integer, because if it isn't there's your first mistake? The heading at 07CC is! Then, if you divide a 16 bit value by 65536 you are bound to get a fraction and you can't hold fractions in a 16-bit integer. Try copying the value into a floating point variable before you do the conversion. If a Delphi "single" is a 32-bit "float" then you cannot read the 16-bit integer directly into that and expect it to make any sense. Floating point formats are completely different. Regards, Pete

I think the only way to tackle that would be to try to detect the window being created (probably by some message intercept) and change the size on-the-fly. However, whilst I can probably do this for any window (the "stop resizing and moving" facility is related), positively identifying the correct window may be a problem. I'll add it to my list for looking at, but it will be a couple of weeks yet - I am away from next Thursday for a week and have quite a few things to do before then. Regards, Pete

All that does is tell WideClient not to simply return to the application with whatever data it has in memory (zero) if the offsets are ones which have not yet been read from the Server. It actually makes WideClient loop, not returning for that amount of time (1000 = 1 second, the default is 500 I think) unless the data arrives. It really only affects the application initially -- with something like PM, all the components are asking for the same things over and over. Once the Server has provided them to the Client once the WaitForNewData won't apply any more -- unless you close and restart the WideClient, or unless you are getting the links reset (which would be logged at both ends as a new connection). So I really don't think you'd notice any differences unless you were having lots of resets, which is bad bad bad anyway, Regards, Pete