ronzie

Took out the EPIC line leaving the pollinterval in. It still works OK.

Yes, there are a number of USB devices via a USB 2 powered hub and all are USB 1.1 transport. These are all C&H products without their Control Manager since on my system that was not too swift: 568 COMBAT STICK (no room on my desk for a yoke) PRO THROTTLE RUDDER PEDS I'll run a test without the EPIC line but leave the timing parameter under the BUTTONS section. If you like send me your suggested version that diables the button polling in the menu. However, would that if it is the problem affect the initial startup menu as well since FS always loads a default flight in the background (verified by your log)? The problem only occurs on a flight exit. You have my e-mail address and an attachment of that size is not a problem. Are we UP late tonight? You are five hours ahead . We'll let why I'm on 98SE still go for now. I will say that 2000 refused to get through the hardware detect on my genuine Intel everything! 98SE does seem to have better timing loops and is mandatory (over 98) on over 1 Gb cpus for network related dlls to load (as documented by Intel).

Little Deja Vu, Pete? See this May 18th thread: http://forums.simflight.com/viewtopic.phlight=fs9 for details: Same symptoms. ESC worked to exit in the blank menu screen, any other key crashed. The good news is that your posted {buttons} entries for this user also RESOLVED my problem on a quick test with a loaded parked aircraft, RC 3.1, and AS2004 all running. Got a clearance from RC, had AS weather refreshed, shut down RC, quit the flight, and the menu text came back and I was able to make further selections!!! Without this user's details, the only similarity I see is that both of us did not have a {buttons} section in the .ini if I am reading the thread here correctly. If the original poster would kindly jump to that thread (way back about 18 MAY when 3.22 was introduced), maybe he can compare system specs to get some commonality clues. The problem has carried into 3.30 and is now resolved. (I also let 3.30 build its own .ini file but that did not cure the problem. Does the buttons section only get created when something is assigned in that tab?) Perhaps the buttons section and some default entries are required regardless of EPIC output being applicable or not. Some PLEASANT news for your recovery period. I also wonder whether these statements might be required for the extreme possibility that some of your polling services might be looping or going out of bounds due to no default parameters and might be causing stuttering (as suggested on some other forums). Probably not applicable but just a thought. The old "C Programmer's Rule". Never leave any variable uninitialized. If it is zero'd by the compiler, the routine may be out of bounds as I probably am right now for suggesting this . Glad to hear your health is doing well with all this eye mess. Hope you enjoyed the Expo with Ray.

If the Apollo MX20 is a Reality-XP product, they will use their own interface to FS. If FSUIPC provides more activity from various applications, then that of course from the apps themselves can further load down the CPU. The more demanding the environment (such as FS9 with its 3D cloud modeling and local weather writes) or the demand of aircraft model detail and function, plus any additional demands placed on the system by weather add-ons such as AS2004 and its use of more weather writes (local), the more taxing on the CPU and the closer you are to the performance limitations of your particular system. What Pete is saying (if I am correct) that for the most part, the activity of FSUIPC itself is very efficient in monitoring the FS environment and remains a stable load in that area. If an app is using it as its control interface, than it must do a little more as requested, but the additional application activity now made available by the presence of FSUIPC creates the much heavier portion of the CPU load, not FSUIPC itself.

This is a brief rehash but with some new info of a previously posted topic: The environment is FS9, W98, 766 MB RAM recognized with VCACHE chest, FSUIPC 3.30, AS2004 MR2, Radar Contact 3.1 latest release, AdvDisp 2.11. The problem started, maybe with the previous 2.2x FSUIPC release but going back one further than the last 2.2x all is OK. When exiting a flight, I get back the main menu with the bitmap but no text showing. Going to windowed mode does not help. If I stay in full screen mode with no other key presses, I can get out with the ESC key which brings up the exit Dialog. Any other key execution, even after the alt-enter window mode, hangs FS9 and task manager (ctrl-alt-delete list) is required to exit. I have further with 3.30 narrowed it down to the following: FS 9 alone, load flight, exit flight OK. FS9 with RC alone, load flight, exit flight, OK. FS9 with AS2004 alone, load flight, refresh AS, exit flight, not OK. FS9 with AS2004 alone, load flight, refresh AS2004, exit AS2004, exit flight, not OK. It seems in my specific environment that weather updates or writes are causing the problem. In all tests above the aircraft (at different locations and aircraft) are parked so no enroute updates are occuring. Any pointers to give before I post on the AS forum?

Environment: W98SE build 2222, Ti4200 NVidia Driver 53.04, FS9, DX 98.0b. No add-on apps running. RAM 766 with VCACHE cheat, AdvDisp 2.123. With 3.22 using default (or any) aircraft, default scenery location, AI at 80%, after activating End of Flight and confirming, it returns to the FS9 menu background only with a map faintly showing through. I can escape out of FS9 OK to exit with exit dialog showing. No menu boxes other than the main background shows. The previous version 3.21x operates correctly returning to the full FS9 menu display. There is no problem within a flight of getting into the ALT menu bar and selecting. All tabbed option in 3.22 look correct. It is just the display of the main FS9 menu after a flight has ended that does not have any contents. This is unique to 3.22. I tried several video driver settings but had the same result. Any ideas? This is a fully registered version.

Firstly, I am aware of the differences between AS wxRE and 2004. The problem appears with or without global writes on or off for 2004. I expect 2004 does execute a call to clear weather on its refresh command and JSkorna of hifi support seemed to think so. Neither version worked with that option checked with 3.14. Both worked OK without that checked. Another user reported rolling back a version of FSUIPC and 2004 started working again. I did not have that problem either with earlier versions. It could be a timing issue of AS starting to write before dynamics are finished clearing. All this is in FS9 while sitting on the ground near an airport so it is probably a global issue only since it is described by AS personnel of only affecting the ground environment in FS9. I'll have more details soon looking at the logs with the option on and off. Thanks for your reply and clarification.

Please comment, Pete. I just posted this in the Active Sky forum in response to complaints about AS2004 not writing to FS9: A revelation with FSUIPC 3.14: Neither AS2004 nor wxRE 1.92 was updating at least airport weather as seen visibly and as reported by FS9 ATIS. On one of the first FSUIPC 3.14 tabs, I unchecked Clearing Weather Stops Dynamics. I can now see overcast again (as in the same METAR used above) and while FS9 ATIS reported clear skies it did correctly report the reduced visibility. Before that I had scattered with unlimited (20 M) visibility reported by FS9. BTW, the FS9 Dynamics slider is set to 0. This was just a quick test and I tried one other saved weather scenario in wxRE of freezing drizzle and it also worked after unchecking the FSUIPC setting above. So to me it looks like with that setting checked, it stops writing when the clear weather call is received. It should be noted however, that AdvDisplay does show the correct METAR regardless of that setting. So, maybe it is time to let FSUIPC.ini be rebuilt if that is what is causing the error. It does not appear to be a problem with either AS version.

This type of discussion is very frequent especially on the Active Sky forum at http://forums.avsim.com/dcboard.php?az=&forum=171 What the programmers there do for FS9 is to have two close cloud layers generated to give a denser appearance from above. They are still working on it in AS2004. Also, be sure your 3D cloud density is set to max and see if that helps if you can withstand the FPS load.

A colleague at work now uses Borland C++ Builder for a RAD environment, then modifies the output. I think it avoids the Pascal intermediate compilation that Delphi uses. I think that earliest Windows versions did use Pascal though noted by the order of parameters in kernel calls. When I used VC++, the use of C as well as inline macro-assembler was why I chose MS compilers on the MS OS platforms. Either way, the optimizatons are available with common libraries. But now I better stop because I've drifted from the topic.

"Are you volunteering, then?" I'll just volunteer JD. Matrix manipulations scare me. OT, but I believe he still programs in VBasic. Someday maybe he'll try VC++ since sometimes you can get more efficient tuning with it even though the same MFC libraries are used. This is because it allows C code within it where you can get down and dirty with its structures. Anyway, I'm no longer fluent in programming but retain enough to comprehend someone elses source.

If the gate position info can be determined perhaps taxiway nav info can also be determined. The cpu can perhaps take the load while the aircraft is on the ground to apply a little AI for programs like Radar Contact to indicate ground control ops based on the afd file info to take you between runways and a gate chosen from what's available according to gate airline coded properties. It has been requested on the RC forum and perhaps with FSUIPC making a taxi routing matrix available while an aircraft is on the ground, application writers such as JD at RC could take advantage of it. I have not fired up AFCAD2 to see if taxiway idents are built into the available taxiway properties but it would be nice to retrieve and use them so our virtual ground controller can issue taxi commands and the pilot can follow the airport layout diasgrams and/or use the signs at larger airports. Perhaps it should be a seperate .dll only loaded for ground operations so as not to burden the cpu at other times. Any takers?

Perhaps an inquiry on the AFCAD discussion group over in the PAI forum section of flightsimmer.com might help. I believe Lee Swordy (AFCAD author) visits there and might have a response since AFCAD2 does show parking/gate properties including aircraft radius, airline code, and other data. Since AFCAD2 graphicly displays asnd can edit those properties perhaps he might be willing to give some specifics as to how to read that information. As an aside, the newest AFCAD2 can now save/edit/create navaid info in upper scenery layers so he must know the structure very well. I also suggest checking out the updated SDK libraries over at Microsoft since their additions a couple of weeks ago.

Pre-SDK release, it seemed to be the consensus on the AFCAD forums at ProjectAI that most runway privileges had effect when: 1. The same privileges were extended to both ends of the runway. 2. Runway privileges only seemed to affect parallel runway operation, i.e. Left for TO and Right for Landing. At KMSP with two parallel and one cross, in FS9 I tried to set the cross for TO only (it is not exactly perpendicular to the parallels so it can be "safe") and the two parallels landing only. If the wind favored the cross AI landed on it anyway. Now that some SDKs have been released, perhaps we will have more control.

In FS2K2, I found that FS ATIS on departure at least did not pay attention to runway permissions modified with AFCAD. I read your annoucement and SDK portion regarding using current AI status history within 80 nm of the destination and making that available for application developers to determine destination traffic patterns and therefore active runways. Now in AdvDisplay you can capture ATIS info to display. My question is, can that text be made available for parsing to determine active runways to cover the condition for airports where AI is not currently active. Do you know how far from destination that can be obtained by a developer in the background listening on the destination frequency with an appropriate interface? That could be an adjunct to your current airport AI status feature. Just another idea to throw around. Also, once FS9 pays more attention to modified runway permissions, I wonder if ATIS info will follow it. Great job and I am looking forward to jd's announced implementations in RC 4.

Maybe we are looking at this as a complex situation where a simple answer might suffice. If we are talking about deploying spoilers as ground spoilers to be deployed in addition to reverse thrust durinng a roll-out, then perhaps the addition of an auto-spoiler or spoiler armed switch to the panel should be considered. These deploy when the throttle is brought to idle and the wheel sensors indicate the aircraft has contacted the surface. An increase of the throttle above idle retards the spoilers. The switch I use (programmed by Mathias Lieberecht at http://www.baepanelproject.com) then toggles back to disabled after the first deployment during the roll-out as the throttle is increased for taxi. This keeps the spoilers from engaging as the throttle is adjusted during taxieing back to an idle position. The spoilers can still be deployed by other means as fitted and necessary if that is their function other than ground spoilers. For any other combination, it would have to be in the panel programming. As an aside, the term speed brake can also apply to drag inducing devices usually expanding from the fuselage tail cone and are not lift destroying devices. These are used on smaller aircraft. AFAIK there is no throttle automatic tie-in for this type of device.

Any chance of mapping an unassigned linear axis as a vernier into an assigned axis? The sensitivity of the steps on regular trim clicks is often too coarse or takes too many clicks for a major change. On my CH stick, the inline trim pots are way too sensitive and also provide a non-stable center position. I'm thinking mostly of elevator trim here to stabilize altitude and airspeed without having autopilot active. I generally get the throttle set and keep my eye on the VSI and/or Glide Slope indicator for final trim, but clicks on panel control or the in-line stick pots just don't cut it. Some time in the future perhaps.

http://forums.avsim.net/dcboard.php?az=5480&page= is the link on the Active Sky forum that gives recommendations for these settings.

While dealing mostly with winds aloft, there has just been a release of AS WXRE 1.92 available for download. This version corrects some issues in FS2004. Here is the URL for info: http://forums.avsim.net/dcboard.php?az=5411&page= The above URL should be in one long line.

You are of course right on, Pete. At one time we briefly discussed splitting up the FSUIPC ini file into a global section and an aircraft specific section. If this were done then for a specific model FSUIPC could be used for "tricks" such as enabling spoileron type control based on sampling the IAS and aileron deflection by using the increment spoiler control and for rules using conditional statements. It's just another neat feature idea (in my opinion, only) for a future release, where the modeler does not provide this enhancement. The basic question remains, if anyone knows, if there are seperate left and right spoiler control messages. If not, then it would definitely have to be a non-compliant feature of the model itself bypassing the gaming message engine, very difficult to say the least. Your original suggestion of increasing aileron effectiveness by scale definitions or even perhaps with increasing the area as defined in the .cfg or airfile is the practical solution, of course, but I can dream while not flying, can't I?

Just to clarify: It is normal for heavy jets, etc, to have a relatively small aileron area on the outward portion of the wings due to all the necessary hardware as we approach the fuselage such as milti-section flaps, etc. Therefore, since at high speed most of the airflow is toward the outer wing and at slow speeds most of the airflow is at the inner wing area where the ailerons are not relatively effective, spoilers synced to aileron control are enabled at the slower airspeeds. It is not a question of the aircraft model effectiveness per se' of the ailerons themselves. How it is incorporated into the model with appropriate sync and enabling thresholds I do not know, nor even if it is possible.

I have not had enough experience with 2K4 yet, but the complaints stated that AI in busy airports disappeared when long taxi lines occurred with halting progress due to dense landing traffic.

On a few forums, there are some posts complaining that the stuck AI aircraft time-out where they just disappeared if in a static position for more than fifteen minutes in FS2K2 was reduced to just five minutes in FS2K4. The complaints state that is a little too short for taxi lines at busy airports. There might be a feature opportunity here if the timing is trappable and modifyable, or the value itself that sets the timer can be modified.

Like the idea, but I have one suggestion: Is it possible or even realistic to have the spoiler steps as an exponential function - that is the first step variation is large followed by smaller steps? If so, then less steps would be needed offering less of a load on the PC system. Then I have a question if this could be bypassed and go directly to full spoilers for the automatic deployment of ground spoilers which go full on detecting throttle idle and surface engagement.

I use RC 3.1 and AS WXRE 1.91 all latest builds. FSUIPC 3.11 full registration, ADVDISP 2.11 (roll-back, tried newer versions). WIN98 SE, DX8.1, 766 RAM, 2.53 GHz CPU, NVidia clone TI4200 128 display. FS2K2 only, Hercules Digifire 7.1 audio card, Inbtel mobo based on 845PE chipset - on board audio disabled. All possible background stuff off including subordinate processes of antivirus (Notrton 2K3) and firewall (BLack Ice Personal PC Protection, Pest Patrol, Ad Subtract, etc.). Tested with default aircraft to avoid Reality-XP gauges (JL2, 4, FLA). Two problems: 1. In either RC or AS, if I let audio run in loops such as ATIS or AS's Flightwatch (audio only), after a brief period with AS only or RC3.1 only, the sim crashes hard, with RC use displaying a basicly null pointer (Address 0:0) error. 2. Using RC only for test, the audio pauses frequently occasionally giving a weird scrathing sound. I have tried all DX acceleration settings including off. Just using FS ATC with neither RC or AS running does not exhibit problems. According to jd of RC, he just calls a declared function of PlaySoundA to winmm.dll. Since I can not tell if FSUIPC aggravates the problem because I can not use these with FSUIPC removed, I thought perhaps you might have some ideas.