The A2A Simulations Community

If they jump back into reverse, then you didn't have them all the way out of reverse when you hit the parking brake. To get the brake trick to work, close your joystick throttle, then F3 up as far as it will go. THEN hit the parking brake. Advance the throttle, release the parking brake, and now it shouldn't snap back on you.



Never messed with it, but i'll check. Message always displays when Brakes on, so I think it is same as ScherzkeCks.

_________________
-mike

I agree with blackhawk. I remember one time I was doing some testing on the ramp and put the throttles into reverse and then tried to advance them and they wouldn't go. Apparently I didn't get completely out of reverse. The Strat is more sensitive to that than any other airplane I have used in the simulator. It won't come out of reverse by simply pressing F1, you have to press F3 a little to get them out of reverse. Annoying but true.

Same problem here,parking brakes trick helps,does anyone from A2A have any idea why is this happening?

_________________
Владимир Левков/Vladimir Levkov

Aviation is proof that,given the will,we have the capacity to achieve the impossible

The A2A reverse prop pitch implementation on the B-377 REQUIRES that you use F3 to bring the throttles out of the reverse pitch
zone to properly exit that zone. Then you also should move your throttle axis forward to keep the RPM up and avoid plug fouling and engine shutdown.

I have my reverse pitch function relegated to two small Lua scripts which, when activated by the detent switch on my #4 engine throttle of my Saitek quadrant, sends the F1 key, followed by a number of F2 keystrokes to get to full pitch reverse.

Moving my throttles forward sends the correct number of F3 keystrokes to move my throttles (VC) forward out of the zone where my physical throttles then take over.

You can achielve the same results by pressing F1 and then holding F2 until the VC throttles and full back. The pressing
and HOLDING F3 to move the VC throttles out of reverse. You then need to move your physical throttles forward to
complete the operation.

If, when your throttles are pulled all the way back and you happen to have a "noisy" throttle axis, this could cause you
some problems as an erroneous forward throttle movement input will "fight" the reverse pitch function.

Having dual Saitek quadrants with the dentent position makes it easy for my to implement the function as once I pull the
throttles to the detent my hand is off them until I amy ready to exit reverse pitch.

Trying to use the "standard" FSX implementation of throttles to idle (F1) and only pressing F2 will not work properly.
You need to use F3.

_________________
Paul


i5-2500K @4.3Ghz OC - GA-P67A-UD7-B3 - 8GB Corsair 1600mHz

I am curious to know the model number of the throttle quadrant, Gypsy Baron.

I have the Saitek Pro Yoke which comes with a quadrant that plugs into the yoke. I also bought an additional
quadrant that has a USB connector. Except for the means of connecting to my system, they are identical.

Here are links to the Saitek site pages that describe these elements.

http://www.saitek.com/uk/prod/yoke.html

http://www.saitek.com/uk/prod/quad.html

I don't use the yoke but instead also have my trusty old Saitek X-45 stick and throttle. I use the stick
to fly but only use the buttons on the X-45 throttle. I have the throttle axis disabled.

As a side note, I do not use the Saitek software for the Pro yoke and quadrants. All the functions are assigned using FSUIPC4.

I do use the Saitek X-45 software and load my FSX profile that has the more or less universal
FSX functions....brakes, parking brake, flaps up/down incrementally, gear toggle, etc.

_________________
Paul


i5-2500K @4.3Ghz OC - GA-P67A-UD7-B3 - 8GB Corsair 1600mHz

Any updates on this guys?

_________________
Владимир Левков/Vladimir Levkov

Aviation is proof that,given the will,we have the capacity to achieve the impossible

No, because it can't yet be duplicated 100% of the time (or even at all, I believe) on a test machine. If those of us that are having the problem could figure out some common factor that Paul, and BJS, and everyone trying to help could then duplicate... there would be some progress.

Sorry to say, because I'm stuck working around it too, it is something with our "setup" (hardware, OS, etc.). My machine only encountered the issue after the most recent COTS update. Some have solved it by increasing the deadzone in their joystick throttle. Paul has a LUA routine that works, and I've detailed the way to "trick" whatever is causing the problem by using the parking brake at the right time.

I frankly don't know that we're going to get much farther without several more hours and some way to make the problem happen on test machines. I spent hours re-installing and trying to eliminate veriables on my end and the result on my machine was that nothing changed. The parking brake workaround is good enough for the way I fly, and not a big enough annoyance to reinstall windows 7 and start completely from scratch.

Other than the details I've provided in previous posts, the only other variable I can think of with this machine is it was an early windows 7 upgrade from vista.

I, and many others, will continue to watch this thread if you want to continue to try and solve it. I've just reached the point where the time spent fixing it is worth more than the fix.

Way off topic: Paul, your new flak package is amazing! Thanks for all the hard work.

_________________
-mike

Thanks! It's a "work in progress" with the ultimate end being the addition of damage inflicted by the flak
when you fly an accu-sim B17 into the areas ( and eventually the other accu-sim warbirds ).

That aspect is a bit more time consuming to implement, so for the time being enjoy the effects as they
exist in the V2 package

On the B377 reverse pitch issue, I tested using only the F1/F2/F3 keyboard inputs without triggering my
Lua script (which essentially does the same thing) and could not duplicate the problem some are seeing.

I also dug into the code and couldn't find and "logical reason" why some would be having this issue. I'm running
a Win7 x64 system with FSX Acceleration.

_________________
Paul


i5-2500K @4.3Ghz OC - GA-P67A-UD7-B3 - 8GB Corsair 1600mHz

Sorry that you guys have had this nagging reverse pitch problem ongoing.

I cannot reproduce the problem, but I am pretty sure of this: It is not historically accurate for the Reverse Pitch to be linked in any way with the Parking Brakes. Maybe there were other variants in which it was, but according to the manual that I have, the Reverse Pitch inhibit should only be tied to weight on wheels, not parking brakes. I reported that as the bug, to the A2A people, with the "stuck-IN-reverse-toggle-the-parking-brakes-workaround thing" as a possible side effect. Thus it has been my suggestion that if the Developers are so inclined to do a fix (and they are pretty busy with the Warbirds I'm pretty sure, so only they could say), that they should eliminate any link between the Parking Brakes and the Reverse Pitch altogether. My thinking is that if they get rid of the underlying innacuracy, that this stupid little stuck Reverse problem some of you are having might just go away, even though the Beta testers can't seem to reproduce it--but that is just a guess on my part.

_________________
1)i7 980x 4.35 ghz, gtx 470s SLI, Matrox th2go, Creative x-fi
2)i7 2600k, Gigabyte z68x, gtx 285s sli

It seems reasonable to me the throttle would still be in reverse when the parking brake is set. The throttles will not go into reverse unless there is forward movement and they won't come out of reverse until the throttles are advanced using F3. As mentioned many times on this forum, pressing F1 will not do it. This airplane is unique for that feature. Has nothing to do with "realistic." Weight on Wheels is not the detemining factor, it is motion.

As a work-around, don't use reverse. Since Vref is typically in the low 100 knots, the wheel brakes are more than adequate to stop the airplane.

Personally, I am not quick enough pressing F3 to get the throttles out of reverse before the airplane starts backing up.

First, I agree that they have other things in development and this is back burner at best, as it should be in my opinion. Just a thought: Wasn't this COTS update the first time they tied anything in the code to a "wieght on wheels" parameter?



That feature works on my machine after the update.

So I think what you reported is perfect, at least in describing my experience, and we can only wait and see if something similar happens in one of the future projects. If it does, and they isolate it, I'm sure a small hotfix would eventually be possible. There is something reacting to the code differently in some of our setups. Unless we figure out what that is, and someone else can replecate it, A2A have nothing to "fix."

_________________
-mike

Same problem for me as well, parking brake lets it out of reverse. I'm running windows XP with the accelerator fix, don't have the FSX add-on. It worked fine before the update.
Thanks for the update. I just use my wheel brakes more...

[written prior to updating CotS v1.1, see EDIT section at the end of message, later addition in RED and GREENcolour.]

This is a naughty little bug. I've encountered it as well. To me, it doesn't just involve reverse thrust but also closed throttle. The bug is present when:
A) on ground, parking brake enabled
B) flying (yeah, parking brake disabled too).

Tapping the brakes causes the bug to go away on the ground. Even re-applying parking brake doesn't necessarily cause it to stick again. The problem is the flying part...

If I accidentally close the throttles too much on descent, the throttles jam to closed. As parking brakes have nothing to do with it, I have to unjam them by applying some throttle with my joystick, then using mouse, click and drag the throttle levers on virtual cockpit, one lever at a time. This means that if I accidentally close throttles on final, with a high likelihood, I'll crash and burn because I cannot get the throttles open again without a considerable delay since they'd immediately lock into closed position. If I enter a stall on final while my throttles are still jammed, the results are not difficult to guess.

The thrust reverse locks are armed when there's no pressure on landing gear. But the lock should only prevent going to negative pitch... not prevent re-applying (positive) throttle if it was mistakenly closed completely at some point. Could this explain why the problems arise? Maybe the thrust reverse locks are modeled with a bug that locks the throttle levers from moving to either direction when it should only be locked from moving backwards from "closed" position?

It is possible this bug appeared with CotS but it could also be that it came along with something else I did, like when I did joystick re-calibration. If I for example would make calibrations so that 0-100% movement on the throttle lever produced 1-100% movement on the sim, it'd never close totally in the sim, and probably won't get locked. This doesn't solve the bug but would prevent me from having to deal with it.

Along with CotS SP1 update, all this seems to be fixed. I don't need to make any re-calibrations to prevent 0% throttle.


_____


Another problem with thrust reverse is detonation: reversing the pitch seems to make the rpm rise again on "reverse opened throttle"... judging from rpm gauge only. The engineer (or co-pilot) still warns me of fouling the plugs due to low rpm along with pushing engines too hard, and I get detonation damage from thrust reversal. The rpm is probably low idle in "reality" and just fooled on the rpm gauge as every other instrument except that rpm gauge shows as if the engine was operated at very low idle: fuel pressure, oil pressure, etc. warning lights are lit and gauges show very low pressures for example. The rpm gauge is probably just a canned effect and low rpm inherent to FSX prop modeling. Probably nothing you can do about it until the prop modeling from derived from the Spitfire's become adopted to multi-engine aircraft. But that's not going to happen too soon nor do I wish priority for it.

There's something fake with it. 42 inches and 18 rpm on reverse pitch was 125 of torque. 42 inches and 18 rpm on forward pitch was 225 of torque. Anyway, canned effect or not, at least with 125 of torque, with the CotS SP1 update, reverse thrust should not cause detonation damage. I did a 5 minute full power reverse thrust test and no damage.

(To support the canned effect theory, if you have shut down engines while you reverse thrust, they also start to show rpm on the gauges. But that's really not relevant. Doesn't affect gameplay at all.)

_____


Additional bugs:

A separate thing is the lack of turbos in Pregnant Guppy. (They work OK for passenger variant so it's not like I have accusim turned off or such issues.) Live engineer cannot be commanded to handle them and moving the turbo lever manually does nothing. I don't know if this was the case before CotS as Pregnant Guppy is pretty much an extra I don't typically fly it. I loaded it only to do some destructive testing with it as to not wreck the passenger variant.

Lack of turbo controls is no bug. It's a feature. And not a "feature" with quotation marks for irony but an actual feature. At least I suppose it's so, even though lack of turbos on Pregnant Guppy wasn't mentioned in manual. Does Pregnant Guppy still have the turbos stuck to minimum or were they completely removed? Probably removed. CotS v1.0 had some readings on turbo bearing temperatures but CotS v1.1 shows 0 degs on bearings. The turbo-related instruments are totally dead. Which I guess, means that turbos are removed and not set to a constant speed setting. Still wonder on why not replaced with a blank panel. I guess it has something to do with Pregnant Guppy "not exactly" being a mass-production aircraft. (Read: total of one aircraft converted.)

The thing I tried to test was to replicate Pan Am Flight 6 and see how the accusim modeling would respond would I intentionally pump all the oil out an engine. Then I noticed that in a Pregnant Guppy, whether I move oil "forward" or "aft", the oil moves always forward. I cannot empty oil from any engine specific tank. And it seems to be the case for passenger variant as well. Don't remember for sure whether it was like that before CotS.

I know this is a "dwarf with twin-aunts named Betty" scenario. You rarely pump ANY oil from any engine back to central tank as you probably don't want to mix used engine oil with clean, unused engine oil in the central tank. The rare occasion becomes a dwarf scenario when were talking about pumping all (instead of some) oil out of any engine (especially one that's still running). In the case of Pan Am Flight 6, captain ordered it to be done intentionally, to destroy one engine by cutting it's oil supply as both regular rpm control and feathering systems on that engine had failed. He also might have thought that oil pressure loss would cause the propeller pitch control unit to run dry, therefore feathering itself that way.

I don't know how the emptying would go along with the automatized auto filling that is triggered if oil in a engine's tank drops to 10 gal or less. Maybe they flipped some circuit breaker prior to emptying it. I know that circuit breaker panel isn't modeled even in CotS and it might as well stay that way. Dwarfs and stuff - not really relevant. And from hindsight, the captain's attempt to stop the propeller from windmilling by intentionally seizing the engine bearings didn't quite work as well as planned on Flight 6 either... it was ditched in the middle of ocean when another engine died (talk about bad luck).

Pump reversal however is a little more often needed (even though it's not something you need on a routine flight, only in some sort of an emergency) than the ability to completely starve one of the engines from oil. If you had an oil leak on one engine, you might want to do it on three others if you're positive they have more than enough oil - and then pump that oil to the one that has an oil leak. But usually you'd just run the engine if it runs normally and shut it down and feather when it runs low. Or shut it right away and hope that it reduces rate of leak then the oil system is not under pressure so that it can be restarted again on landing for added safety.

Anyway, I hope the pump direction reversal would be fixed as it was a feature on real B-377.

This bug / feature still persists. AFT pumps oil to engine, not from engine. Or is there just a redundant pump called "AFT" that also pumps oil to the same direction? Then it'd be relevant to question: wheres that other switch that allow to drain oil from engine specific oil tank? ...the switch they used on Pan Am Flight 6 (just as an example, I'm sure it has been used in reverse direction in other rare occasions as well).

___


This concludes my collection of spotted bugs.

EDIT: I'll verify whether my B-377 is up to date... it could also be something that's already solved in patches. Will edit when I have checked the status.

EDIT2: I seems I've not installed wos_b377_cots_1.1_update.zip but only B-377, Accusim, Assusim 1.1 patch and CotS (1.0). So I'm not completely up to date. Maybe it'll be solved with that newest patch. I'll edit this if problems persist.

EDIT3: Added comment with RED and GREEN after CotS v1.1 update. Most problems were fixed. Such a nice update.

The oil system now works as it should. It was actually in error in the first release. There is NO provision for
pumping oil FROM and engine back to the reservoir. The two positions of that switch that USED to indicate
direction of flow actually are meant to indicate which pump, of two, is operated. ( If I remember correctly the post
that explained this correction).

EDIT: I just checked the original posting and it stated that the "FWD" and "AFT" labels on the switch refer
to the forward and aft oil pumps. These labels were initially interpreted as being the direction of flow
but subsequent research revealed that this was incorrect. The oil can only be pumper TO an engine,
not from.
In a discussion on this subject a RL SOP was referenced that indicated that the FE should only pump
oil from the reservoir to an engine when the oil level had dropped low enough to require additional oil.
This procedure was meant to insure that oil remained in the reservoir until actually required, thus minimizing
the possibility of having a dead engine with a large quantity of unusable oil in it.

_________________
Paul


i5-2500K @4.3Ghz OC - GA-P67A-UD7-B3 - 8GB Corsair 1600mHz