ZaltysZ

If you have a stick, which centers very precisely, you should try using center based trim method and lowering activation zones. Using Warthog I can still manage to trim with 0.01. That shrinks "double input" the zone around the center by large margin. Also, is FFB disabled in your setup? It was important thing to do for non FFB stick in previous versions (at least) as it interfered with trimming.

Did you remove afterburner detent or idle detent? Removing idle detent simple gives you more travel for the handle, but it does not reflect on the axis in any way (axis start after idle detent end ends past afterburner detent). Regarding assignments. It is likely that game treats Warthog throttle in special way. Controller can have only 32 DX buttons, and there some tricks need to be used if you want to have more than that (i.e. lots of multiposition switches). Start/stop of right engine is accomplished by single button (DX29): pressing it shuts down engine, and releasing it starts engine. It is not treated as usual toggle button, and because of that it can be considered special. You probably have to create TARGET profile, before you will be able to use some buttons freely.

If you are seeing stick jerk, you are probably having trim jump issue, and not AP issue. The usual reasons: 1) Your hand. You do little involounteer movement of your hand when you press trim button. Try using "T" on the keyboard with your other hand to rule out that involounteer movement. 2) You are trimming using center based method and activation zone is too large. You have activation zone 0..5, and you move the stick to 10, then you click trim button, and that tells game lock your controls at 10 and take it as new trimmed position. Then you move the stick to 0 position, but the moment you pass 5 game unlocks controls (as stick gets within activation zone), and this causes oversteer, because game thinks stick is deflected away from trimmed position (10) to position 10+5. Of course, that extra 5 gradually diminishes as you continue to center the stick, but before that you perceive noticeable control jerk. If you are trimming within activation zone (happens constantly when trying to nail helo for stable hover), then your controls get controls activated instantly and you get oversteer instantly. 3) You are using time based method and you fail to center the stick PRECISELY before activation time ends. Amount of oversteer/understeer depends on how far the physical stick is from its real center the very moment activation time ends. I.e. you click trim at position 10, you move the stick towards center, but you overshoot it by 2 (fault of hand, stick spring or stick electronics) and you don't manage to correct the mistake before activation time ends. So you get virtual stick position of 10-2=8 (understeer) for a brief moment, and you perceive that as control jerk. Same happens if you fail to reach the center at all in time, except that this causes oversteer and not understeer for a brief moment.

AP does not care about stick position at all. AP does its job according to yaw,pitch,bank angles of aircraft which were present the moment you released trim button. Pilot and AP are two separate control loops. AP does not move the stick, but it can still affect pitch of blades. I think, I have introduced some misunderstanding with "50-20=30" as it might look like AP cares directly about pilot input. I will make the analogy (and will make it stupid for sake of making it more clear). Let's say you are driving a hypothetical vehicle, which has brakes, accelerator pedal and AP for speed control. You accelerate to 30km/h and tell AP to stabilize that speed. Stabilization means that if you release accelerator a bit, AP will rev engine up a bit by itself, and if you add a bit of accelerator, AP will rev engine down and/or apply some brakes, so that speed will remain 30km/h. Now, if you add lots of accelerator, AP will be overwhelmed as it does hot have the same authority, and despite it trying to rev down and brake, vehicle will still accelerate to 50km/h. So, you are driving at 50km/h fighting AP and winning, but suddenly you realize that you want AP to stabilize the speed at 50km/h. You press the button, and upon doing that you first get AP input (its effort to brake you down to 30km/h) disabled, and then get it memorize the new speed setting (50km/h) on button release. What happens? Vehicle jumps forward at first and easily reaches 60km/h (past the new target speed of 50km/h), because of the delay between disabling AP and enabling it again. "Aggressiveness" of that speed jump depends on the difference between how quickly AP is able to remove its input and how quickly it can reach max of its input. Keep in mind that AP does not care about accelerator or brake pedals. It only cares about speed of hypothetical vehicle, and not about position of brake and accelerator pedals. If we introduced trim system to our vehicle, then that system would care about these positions, but AP would still care only about speed. Overspeed happens in this example not because of presence of AP input, but because of lack (or sudden removal) of that input.

Nope, it happens with time based trim, center based trim and even FFB (which does not require to recenter the stick). This is not trim issue, this is AP stabilization system issue. You tell AP to keep 0, then you input 50, AP wants to keep 0, so it counters your input with -20 (max it can), and net effect ends to be 50-20=30. The moment you press trim button, AP stabilization gets disabled and that -20 disappears, so net effect quickly jumps from 50-20=30 to 50-0=50. This wouldn't be a problem, if AP could quickly go from 0 to -20 again once you release trim button, but it can't, so even after quick trim click you end with so called oversteer. P.S: if you don't have FFB stick, then yes: 4 should be 4) Trim button is quickly clicked(without holding it) and joystick returned to center?

Oversteer happens because of AP, and not because of stick type. Steps to reproduce: 1) Ka-50 is in hover and it is trimmed for hover. Hovering mode is off. All autopilot channels, except altitude, are on. 2) Cyclic is pushed forward, collective is increased to keep the same altitude. Trim button isn't touched at all (Ka-50 still remains trimmed for hover). 3) Once Ka-50 accelerates to 140km/h, cyclic and collective are adjusted to keep helicopter in stable level flight at 140km/h 4) Trim button is quickly clicked (without holding it). Result: huge (significant) nose drop after step 4. I don't have FFB stick myself, however I gave these instruction to my friend and he reported the same issue using FFB stick. I understand why it happens: pilot works against AP (by moving aircraft attitude far away from angles which are tried to be held by AP), and his input gets less effect because AP opposes him; then trim button is pressed, and AP opposition suddenly disappears causing oversteer as pilot input regains its full effect. What I don't understand is why it is allowed to disconnect AP so quickly (on trim press), but connect it so slowly (on trim release). This difference causes abrupt oversteer, which can be fatal at certain speeds. Why it doesn't remove AP input gradually and not abruptly (that would give pilot a chance to lessen oversteer), or why it doesn't disconnect AP only after holding trim longer than lets say 300ms (that way short click would never remove AP input, but only tell it new angles to hold)? My logic tells that such dangerous flaw should not exist in real life approved military design. But... world is wonderful not only in good way :doh:, so it still might be "realistic".

Click-click is when you constantly click trim button while you are moving the stick. Move-move-click is when you move the stick a lot, but click trim only once at the end.

If you have FFB stick and are constantly clicking trim while moving stick, you should get slight over-steer on the first click, but not on successive clicks (granted clicking is frequent enough). This is because it seems that AP manages to remove its influence almost instantly, but lags in applying it. So, fast clicking is like always having stick in trimmed position and AP stabilization off. In other words, you don't noticeably fight AP if you are clicking with enough frequency. This is almost impossible with non FFB stick, because such stick needs too much delay between clicks caused by requirement to recenter it. That delay leaves enough room for AP to catch with you and cause over steer on successive click. This is with center based method. If you use delay based method, it is possible to use such technique: you want to push stick 50%, however you just push it very slightly (lets say 5%) and keep it there, then you just click trim button n number of times, until it reaches that 50%. Click-click is recommended by some manuals from MIL. Reasoning is simple: it is easier for the hand (click-click is like climbing a staircase, and move-move-click is like climbing inclined plane - ramp) and it is safer than click-hold-move because trim forces are not removed for prolonged time, and that means less chance for accidents caused by vibration or wind gusts.

It is not Rotor Pitch Indicator. What flashes and sounds is Rotor RPM push-light. Never acknowledge (mute) it. It sounds for a good reason: your rotor RPM are dangerously low or too high. In your case, RPM are too low, because your blade angle is too high (too much collective) and engines are unable to spin rotors fast enough. There are 2 common mistakes rookie can make: way too much collective or throttles are left on IDLE instead of AUTO position. There is a third one too: rotor is switched to low RPM mode used for fast descents, but this usually happens because of control conflicts, rather than because of rookie mistake.

I think comment from real Ka-32 pilot should be enough, because principles of Ka-32 AP seems similar to Ka-50. I have spent some time reading flight manual of Ka-32, and it mentions same 20% of AP authority, AP disconnection on depressed trimmer, AP remembering angles of yaw, pitch, roll on release of trimmer, recommendation to press and hold trimmer if you want more effective controls. It even goes as far as naming pilot the extension of AP, and it tells the pilot not to fight AP, but intervene when authority of AP isn't enough. Unfortunately, it does not explicitly tell to use either click-click or click-hold-release method for trimming.

Antons were pretty clumsy up high. Dora is a better match for pony.

If use this video as priceless tool for explaining what lurks behind "Würger":

I do not know the etymology, but notch filter is a filter which passes almost everything except some chosen stopband. In context of doppler pulse radar, the notch filter rejects radar returns from stationary objects (i.e. ground). Stationary objects are those, which cause 0 doppler effect (i.e. have 0 closure rate). Notching basically means "forcing to be filtered out by enemy radar". That is achieved by flying a tangential trajectory in relation to radar beam.

Every aircraft has a [corner] speed turning at which has the largest directional change rate. Flying below that speed gives you lesser directional change rate (and less Gs you are able to pull), going above it also gives lesser directional change rate despite high Gs (this is because modern aircraft are G limited, so you will have restriction on degrees/s at high speeds, because of that G limit). Flying at (or slightly above) corner speeds gives you ability to quickly initiate max rate turn. Such turn is very disliked by anything flying on collision course, because it forces intercepting object do the largest changes in its course (pull lots of Gs) and waste lots of energy. Consider these points: 1) Missile has small control surfaces, which are effective only at high speeds. Slow missile = useless missile. 2) Missile has working motor only at initial stages of its flight. This means, that it mostly bleeds energy at final stages and surely does not like anything what helps it to bleed more. 3) Missile has a G limit too. It is something like 30-40 Gs for modern missiles. 4) Depending on rage to maneuvering target, missile might need to pull something like 5 times more Gs than target is pulling, if it wants to stay on collision course. It might not be possible due to lack of energy (in the most cases of BVR) or even due to structural limits. So basically, you should never go below corner speed while in combat. It is like insurance against unforeseen things. Flying at it is a good habit, which helps a lot in non sterile environments. Also it helps a lot in defeating the missile in energy department. It should be a lower bound speed at your tactics, and probably a upper bound (as I understand your intention to minimize rate of closure).

MP3 is a patented format and requires a license for it use (especially in commercial product). I think it is 2500$ per game title. Is it worth?

Maybe that time-line is analogues to watch used in WWII submarines. Let's say we have a target with constant speed and course, we launch a missile, computer calculates the point at which missile will meet the target, then computer calculates the time missile needs to get there, and starts the timer, which will run till 0 by itself. I think, if it was a time remaining until missiles dies, it would be worded differently in the manual without the part "meets/reaches the target".

Not really. Lots of stuff developed before collapse of USSR is not secret anymore. That is because when USSR had dissolved, former states inherited various military material: armored vehicles, aircrafts, guns, and etc. Some of them had no need or could not afford maintenance, so they simply sold that material to other countries. I.e. Moldova sold nearly two dozen of Mig-29S to US.

It would be nice, if vehicle had another checkbox; [ ] MANPAD. So that, little MANPAD soldier would pop up near vehicle the moment it takes defensive position. Of course, that little soldier should get back into vehicle, once vehicle decides to return to formation.

R-27ET is great for tail chases, because it has IR seeker and long burning motor. (it is harder to outrun ET). SARH missiles (like R-27ER) can be problematic in tail chases, if target and launching platform are at similar speeds (doppler radar does not see targets with 0 closure rate). If it is not a tail chase, and range permits, launch missiles in salvos: 1xR-27ER + 1xR-27ET, and PK will increase.

At first, collision detection and graphical representation of trees are 2 different problems. Difference lies mainly in fact, that graphical representation (rendering) can be tied to so called player bubble (i.e. you can render trees only around X km from player/camera and so on), and collision detection can't (because there can be lots of interacting objects across whole map and you need to always check collision for them all). The main problem of collision detection is quickly checking tree presence at arbitrary location. "Quickly" and "arbitrary" basically means keeping whole required data in memory. Collision detection with terrain is usually done by simply checking the height above ground. Terrain elevation is usually read from height map, which basically is 2D array, so reading height of particular point is very fast. One can think, that having second height (or tree) map, where trees are marked, could be used as solution for collision detection, however this is only possible on small maps or with very crudely formed forests as more precise tree placement would require tree map with too high resolution, which would consume too much memory. So we need some other solution, something compact, but fast enough. Quadtree data structure could be that something. Quadtree is data structure, in which each node has no more than 4 child nodes. Basically, you look at whole map as single rectangle (root node), then divide it into 4 subrectangles (nodes), then divide each subrectangle into another 4 subrectangles and so on, until subrectangle size decreases to 3m x 3m or so (chosen cell size for tree). After quadtree is constructed, you do the "clean up": nodes, whose all child nodes do not contain trees or all of them contain trees, are either marked "free" or "forest' accordingly, and their all child nodes are removed. If you want to know if there is a tree (object) at X,Y, you walk along quadtree: you begin at root, then choose child node (rectangle into which X,Y falls in), then choose its child node and so on until you reach node marked with "forest", "free" or "tree". How deep the quadtree is (how much the search takes), and how much memory data needs, depends on how clustered the trees (objects) are. If they are heavily clustered (lots of big forests) and distribution of clusters is not uniform, performance can be pretty high and memory usage low. I hope it clears a bit what is behind "clusters" I have used in previous post.

There was never an INU drift in DCS or BS. The message you speak of is shown when you are 18 km from the INU fix point. It is like a remainder: "Hey, you are approaching a fix point, don't forget to use it."

Waypoints: 1) General fight plan following 2) Tactical awareness: seeing flight plan, ingress/egress waypoints on TAD helps you in not wandering to deep into target area. 3) Marking general location of target, which you received over the radio. Someone tells you coordinates, you create new waypoint with them, then fly to it. Mark points: 1) Quickly marking position of your aircraft. I.e. you are searching for targets in wide area and just found a tank platoon, so you just mark where you are, and send that point to friendlies. 2) Marking position of target. This is useful for: 2-a) cases when it is hard to maintain TGP lock and you have to make multiple passes. I.e. you are low or have to do sharp turns, and TGP gyro constantly messes up ending looking at sky or just floating around. So you mark, attack, turn around, TGP is messed up, but you just tell it to look at markpoint and it looks at target once again. 2-b) doing target approach from right direction (requirement either due to FAC commands or wind as it is easier to bomb without sidewind). So, you create markpoint, make it steerpoint, input course into HSI and make your approach. Hooks: 1) Useful for tracking something you want to be aware of: 1-a) Easily checking your relative position to that "something" on TAD. 1-b) Having direction to that "something" on HUD without making it SPI. That something can be even your wingman (helps in avoiding collisions) or his SPI (i.e. wingman orbits around the column, having his TGP locked on moving target, and you hook his SPI, that way you have directional information to target and can do rapid gun runs).

Modeling collision detection for heavily forested area is not necessary problematic in regards to performance. It depends on distribution of trees and into how much clusters they can be grouped. The worst case is when there are lots of clusters, which contain only one tree. Typically, such one tree clusters are usually ignored (no collision model for them, and their rendering can be turned off) in games for performance reasons.

64 bit OS isn't a problem. 64 bit executable is. You can't "inject" 32 bit DLL into 64 bit process.

Porting is no brainer (not exactly, but let say it is so), when your software architecture features loose coupling between its components and OS specific APIs. If not, porting can easily approach "writing from scratch", and unfortunately, tight coupling is not so uncommon. In addition, even if software architect was a genius, there still can be lots of difficult problems to solve: like OS specific scheduling and memory management issues.