ShuRugal

Forgive me, then. I was under the impression (based only on my own observation of what gets posted here, of course) that one of the functions of the volunteer testing team was to operate as go-betweens for the purpose of collecting/replicating bug reports posted here. If my observations have given me unrealistic expectations of the extent of the testing team's responsibility in this department, I apologize. As far as slamming testers goes, that is absolutely not my intent. The intent of my post was to highlight what I (and others) perceive as a failure of the system. Of course I don't expect every tester to have intimate knowledge of every bug. But when someone brings up a bug which has a major impact on gameplay, has been outstanding for two years, and has very high visibility in the community (at least among player who operate that module), and the first response of one of the most prominent members of the testing team is "I've never even heard of that bug.", then -obviously- somewhere along the line, something fell into a hole.

this is exactly the reason the current system is not good enough. How does the testing team not know about bugs which have been ongoing problems for two full years, reported by many players on the forums and the tracker? there is even a threaddedicated to tracking issues with the KA-50 which has been open this entire time, updated on a regular enough enough basis to remain on the front page of the bug subforum, even though it is not sticky (even though it should be). Are you also unaware of this? How many of the bugs in that thread are you, individually or collectively, unaware of? This is why the system is not good enough. This is why we ask for a more transparent system. I, personally, had assumed that these bugs were getting attention (they've been reported enough), but were either simply difficult to crack or low on the priority list. To find out that, after two years, a prominent member of the testing team and a very active go-between between the community and the devs has no idea these problems exist.... need i say more?

same. I'll be getting the Cobra, but I'm not interested enough in the F-86 to buy it on launch.

check your graphics options, could be some post-process effect turned on doing weird things.

well, the alternative is no better: around the time of 1.2.x, patches were coming so fast and furious that practically every day something was fixed and something else broken.

Right, that's what my idea addresses. It'd basically be taking the Beta Forum to the next level and putting more ability in the hands of the devs to focus the information flow.

This thread might be too far along for my own two cents to attract any useful notice, but I'll chip in an idea anyway: One thing I can think of that would provide the developer team with material benefit in a public-facing bug tracker would be the ability to gather more data about specific bugs. What if, instead of opening the entire tracker on a read-only basis, or establishing a tracker tha the public can feed into wiki-style, we did something a little different: Tracker for designated high-priority bugs. The bugs that go into this tracker would be at the discretion of the devs. The bugs posted to this tracker would then be open for comment by registered users for the purpose of providing information about under what circumstances they encounter the bug, tracks of the bug, and their system information. This would provide a means for the customers to materially contribute to the bug-resolution process, while allowing the devs the discretion to focus their efforts on what the dev team has decided needs priority. And if anyone wants to whine about their bug not getting priority... well, that's no different than what we already have, and it would happen in the same place (on these forums) since posting of bugs to the tracker would be handled by the testing/development teams.

switches in two locations first, the bottom right-most circuit breaker bank, make sure the 3 switches on the left are on. second, above the pilot station, turn the switches for left and right engine de-icer on. Once this is done, system will engage dust-protection and automatically de-ice when ice is detected.

the thing to keep in mind when deciding is that the UH-1 and MI-8, while both fully functional aircraft in the sim, are still very far from complete as far as missions goes. You will also find them difficult to employ if you like multiplayer, as most multiplay missions are geared around combat, and both these aircraft are pretty helpless against AAA-capable platforms. I can't wait to see more missions designed around the MI-8, though. I, bought it last weekend and s far I like the way it handles in the air. The loadout options are also impressive, those GUV pods are something else.

so, what it boils down to, is that behaviour in the sim after hydraulic failure is unrealistic, because under real condition, you could never hope to continue flying the helicopter in such a state. Which brings us back to another old problem: why does the KA-50 have dual hydraulics if they always fail together? If one takes battle damage and fails, the other immediately begins loosing pressure and fails moments later. They don't cross-feed at all, do they?

okay, lemme see if i understand this correctly.. The actuator for the booster lies in-line with the control linkage. The actuator is supplied pressure and locked into a position. when pilot moves the stick, it operates the spool of a 4-way valve to operate the actuator, and the whole thing moves as a unit. The AP has it's own 4-way which operates the same actuator, allowing the controls to move without pilot input. presumably, there is a fail-safe as Busmanni described which locks the actuator in center of travel in the event of hydraulic failure. Have i got it right? in this way, the AP can operate without disturbing the pilot controls, but still maintains control integrity in the event of hydraulic failure?

I would be very interested to know how this is achieved. I am genuinely curious how a mechanical linkage can be made to transmit forces in only one direction while still functioning. this does make much better sense, for the behaviour seen in the sim.

I know for a fact that it did in BS1, I don't think it does in World, but so much has been broken since World got rolled, that is hardly an indicator of anything.

Is there any plan to complete these? I would love to have a campaign dedicated practicing proper handling techniques like this.

Alright, consider a control linkage: When the pilot moves his stick, the mechanical linkage pushes or pulls on the swashplate, producing control output: If we add a hydraulic assist system and let the autopilot have some command over it.... then when the AP pushes the controls, the pilot's controls, being mechanically linked, will also move: Unless something breaks: Now, we could design an AP system that would move without the pilot's control also moving (IE: behave like a non FFB stick in the sim). It would have the control linkage from the pilot interrupted with a hydraulic actuator: This way, the AP can move the swash independent of pilot input: The problem with this, is that if there is no hydraulic pressure, then now the pilot moves his stick, and until he has moved it further than the travel of that actuator, nothing happens to the swashplate: And the inverse would be true as well: with such a system, if the hydraulics failed, the pilot could hold his stick manually in exactly the correct position to maintain stable flight (a hover, say) and the helicopter would be all over the place, because every gust of wind acting on the rotors would push the controls back and forth the full throw that the AP actuators have, and the pilot would only feel it through the stick when they ran out of travel.

I still don't think it can work any other way. Kill the hydraulics, and the helicopter remains flyable. If the ap control box were between the stick and swash, it would be impossible to fly.

I fail to see how the AP could not move the stick IRL. If the AP had 20% (it's authority) control independent of the cyclic, and the hydraulics went out, the cyclic stick would suddenly have 20% free-play in all directions. While it is not impossible for someone to design a system that worked this way, it would be uncharistically stupid for a company otherwise noted for its brilliant engineering. I can't seem to find it now, but there was a diagram floating around a few years back (could have sworn it was in the manual) detailing the linkages in the KA-50, and clearly showing that the hydraulic assist was parallel to the primary control linkages. It's been a while since i watched for it specifically, but I know for certain that pre-World BS1 and BS2 you could watch the stick in the cyclic move on its own in Route mode, and I have seen videos on these forums demonstrating this effect with a FFB sick as well.

In real life this is not a problem because in real life the physical position of the cyclic stick and the physical position of the swash plate are fixed together: there is no overcorrection bump because when the AP moves the flight controls, the cyclic stick has to move with it, so clicking to disengage the AP does not cause the stick to jump (unless the pilot's hand jumps because of the reduced pressure on the stick). The reason it jumps in the sim is because, with a non-FFB stick, the physical joystick you are holding is not fixed to the virtual controls in the aircraft. This means that when the autopilot moves the virtual stick, and your stick has not moved with it, when you press the trimmer and disengage the AP, the controls suddenly jump to where your physical stick is, instead of where the virtual controls are.

my specs are here: http://forums.eagle.ru/showpost.php?p=2068954&postcount=4 I have disabled multi-monitor output, to no avail.

I just resolved master.eagle.ru via tracert, but I still hang at "connecting to master". I don't get "could not connect", it just sits there forever and won't actually connect.

no, the upgrade probably broke a configuration somewhere that DCS was dependant on. A clean install would probably solve it, but I really don't have time for that shit.

I have resorted for now to dumping things like anisotropic filtering, lowering viewdistances, etc. It runs now, but it looks (comparatively) like shit.

I suggest you re-read my post before you patronize me (again). I said I do NOT have the software engineering background to roll back OS-level changes...

Every time I have flown the KA-50 since integration into World, I have had this problem. Every mission, single player, multiplayer, all weather conditions. The only thing that changes is the severity of the problem. Sometimes it will only pop up every couple minutes, other times it is so bad i can't get a shot off without continuously thumbing the laser. I actually like that the rudders are chained (though i can see how some people might like the option to unchain them). I have my pedals set up with a fair amount of exponential curvature, so that I have more precise control available when performing rocket or (boresighted) gun runs. In this case, centering the rudder is desirable because it keeps them in the high-resolution range of travel. No, the dive is a result of the simulator using input from the joystick to simulate pressure from the pilot's hand on the real stick: In the real thing, the autopilot operates by moving the control stick (you can see this if you put into route mode and release the stick. IF you engage Alt hold, collective will move 'on its own' as well). In the real helicopter, there will be no dive, because the position of the stick is always 100% the position of the swashplate. If the real pilot moves the stick without pressing trimmer, he is overcoming the centering force and the correction force from the AP. He won't have to move stick further to compensate for AP, just press harder for the same movement. The problem with the way it is simulated is that we -do- have to overcompensate our movements for the AP. With a FFB stick, this should not be the case, but I can't test this as I don't have one. If the dive still exists with a FFB stick, then there is a bug with that functionality.

If it were not for the KA 50, i would never have found DCS. So from that perspective, it has generated, from attracting my attention... DCS Black Shark BS2 Upgrade BS2 Standalone A-10C UH-1 FC3 P-51D MI-8 ... eight sales, for a total of ~$350. I plan to spend more money on future modules, as well. Unless, of course, if ED should persist in their neglect of the Shark. If they'll let one fall into decay, why not more? Hell, they might even stop supporting all previous modules each time they release a new aircraft. They've never promised otherwise, right?