Pete Dowson

Sounds like an ATI card problem -- there seems to have been a number of flicker problems with ATI cards. Is that what you are using? Try the latest drivers, or check it in maximised Windowed mode. Regards, Pete

Is AFCAD2 released now? As it is freeware I can make an access key for it, but I need details first. No one has asked before. I need the EXE name, and details from the Version Information (right click on the EXE and select Properties-Version). I need the "Product Name" and the "Company Name". These things must be exact. Then I can publish a Key in the Sticky thread above. Regards, Pete

The smoothest you can get it is by going to Options-Settings-Display-Weather and setting all top three sliders to maximum. Most certainly never use anything but 3D clouds. Regards, Pete

Hi Jonathan -- I was going to say "Yes! I have one other report!" when I saw it was the same one -- yours! :) Did you try setting "SyncInit=No" as I suggested? If that fixes it, then it is something to do with the automatic restart introduced in version 1.70. Unfortunately, since you skipped from 1.61 to 1.70, missing the main change, in 1.63, I've no other way of isolating it at present. If "syncinit=no" works, then leave it that way for now and I'll investigate it when I get back. Regards, Pete

Yes. See the FSUIPC SDK, Programmers Guide, offsets 088C etc etc. Regards, Pete

Sorry, no. I've really no idea how to find other aircraft data in CFS1. In fact the fact that FSUIPC partially works in CFS1 (and CFS2 for that matter) is more luck than judgement. Sorry. Regards, Pete

Sorry, but FSUIPC doesn't have any influence on any of that. As far as I know the only dependence on FSUIPC was for the accelerated adjustments on one of the gauges, but Pete McLeland can tell you more. Regards, Pete

Have a scan through the FS2004 Forum, not far from here. In general the main ways seem to be (a) reducing sliders and (b) getting a faster processor and more memory. But I'm sure there are manay more specific hints folks have come up with. Regards, Pete

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