sinelnic

I have total certainty in doubting that the DCS engine uses the DX10 api, and can affirm conclusively that it will be a total surprise if it used it for the A-10 module.

And that was tricky since it is an aermacchi really... How about this one?

Brazilian EMBRAER EMB 326 Xavante, right? as in

Ok, an easy one to get started...

DCS : Pucará, Carajo!!

Here. If you find the damage modelling in this track "not good enough", then fine. Best viewed from F3 view. Beautiful crash.trk

What, you mean if I get the G940 she won't notice the four monitors by the PC? I think it's a good deal...

Huckle, let me kindly disagree. I like to fly low very fast following roads and rails, and to make hard turns (and recover from them) you need to use full range. You'll need this ability as well when strafing or flying very low to escape a hot area or when being pursued by a SuperCobra tossing hellfires at you like it's the end of the world and you've kidnapped Jesus. And believe me, it will happen...

I did mod my X45 to approximately the same dimensions of the actual stick, but using linear, the poor precision of the stick kept giving me issues near the center position. I then switched to a curved input and what I got is much better handling at low speeds or hover, but sluggish responsiveness when performing high-speed maneuvers. This takes tweaking... Also, I read somewhere about a study some canadians did, about introducing fluy-by-wire controls in helicopters. They found that using a small stick would indeed require curved input transformation, because even with high-precision sticks, the real pilots were at much discomfort with the small movement range of the sticks near the center position. But then ED claims that actual Ka-50 pilots found the linear setup to be the best...

Hola JAG, This device can only take "storage" as input, be it a memory card, or a USB connection to a computer. Hence, what it does not support is "realtime" information streaming. It can display a video, but it first it has to be in a file. So no good for using as a monitor for DCS. Igual la idea era buena, carajo...

What we could do is create a table with different crash scenarios (different speeds, vertical speeds, angles, etc) and then assign each scenario to one of us posters. We can then go rent real choppers and test the scenarios, and write our impressions here. Evil-Bivol can keep track of all responses to forward the empirical input to the dev team, they will surely appreciate the effort.

It is so important that you understand what is happening to you heli due to flight characteristics besides your (like mine) poor handling of the beast. If you already know this please ignore, but let me quickly summarize: 1- 100-200 Km/h +50 meters: the thing handles similar to a plane and there's little to explain. 2- 30-100 Km/h +50 m: The shark begins to handle more like a proper chopper because the wings lose relevance. It becomes much more responsive in pitch and roll. A little curvature in the cyclic axis can really help here.Also, you're decelerating, thus pointing the nose up in relation to the flight path. I won't go into the details here but that also generates roll and yaw tendencies different than those in normal flight. 3- less than 30 km/h +10 m: Below about 22 Km/h, you lose "effective translational lift", which is extra lift generated by the rotors when you're moving forward. This causes you to sink unexpectedly and is a normal cause of Vortex Ring situations if you realize it too late. 4- 0-10 km/h below 10 m: When about 3 m above the ground you get the "rotor-in-ground-effect", which generates extra lift and will in most cases stop your descent. What they don't usually tell you is that this "cushion" will make your chopper extremely extra super duper responsive in the cyclic axes, almost like trying to stand on a spherical soap. The chopper is inherently unstable and will not remain centered without constant control by a proper Pilot (i.e. Not-me). Then a piece of advise here is, don't delay the touchdown, once you're almost there, stomp it. The gear is sturdy! Hope this helps a little!

Migo,That's because of two reasons:1- Sometimes you're not correctly trimmed with rudder in the center but to the right as a "left over" of having been flying fast before the hover. Then, the AP 20% authority has trouble compensating for that deviation2- The Auto turn to target correctly aligns the heli nose with the target, but not necessarily the Vikhr "pipper". This is because the Vikhrs are mounted on the wings and not directly under the nose. You can try this by switching the salvo to high (which releases two Vikhrs at once), when you do this you'll notice the "pipper" moves to the center of the hud and aligns with the nose. When in short salvo mode, the "pipper" will jump from left to right as you release the Vikhrs, because the system fires one from each wing alternatively to keep the heli in balance.

Make sure you're trimmed for hover, as in being trimmed for a perfect hover before engaging auto hover. If your stick has some "centerplay", as in not staying perfectly centered, try to take that into account when trimming for hover. The AP only has 20% authority. Also, make sure that you applied enough collective to keep the VSI at real 0, sometimes it takes a while to settle and begin descending (remember you lose ETL below ~22 kph, maybe you turned AH before this speed).

Go multimonitor. Yes, I'm ignoring what you just said, but again, if you're after immersion, go multimonitor.

Also the differing momentum due to more of the front landing gear being farther from the CG, and less of the rear landing gear being farher from the CG, surely helps to dip the nose... or so Yo-Yo made us believe.

Ooooooohhhhhh so that's what it was... I was soo puzzled by a non-moving dial on my ceiling... too bad it's not simulated, it's really missing.

Try going to: \..\Ka-50\Config\View and editing SnapViews.lua so that at the very end, it looks like: Snap[9][13] = {} Snap[9][13]["viewAngle"] = 120 (or the value of your liking, this is FOV degrees) Snap[9][13]["x_trans"] = 0 Snap[9][13]["hAngle"] = 0 Snap[9][13]["y_trans"] = 0 Snap[9][13]["rollAngle"] = 0 Snap[9][13]["vAngle"] = 0 Snap[9][13]["z_trans"] = 0 Do not use notepad or wordpad, use Notepad++, google for it, it´s free.

You mean head back or wider FOV? you get wider FOV using NumPad "/", and head back using RCtrl+RShift+NumPad "/"

Hi Congo, I use a similar setup only with 3 monitors and desperately planning to get a 4th for the panel, just like you (more on that later). Now what I discovered is that in the "My3Cameras.lua" file I used to configure the, uhm, 3 cameras, there's a tiny little parameter that goes: ViewDx=1 (or 0 or -1, depending on the left, center or right viewport/camera) What this does is rotate the camera along the X axis in proportional reference to the center camera. So, after many tweaking (and specifically for my monitor angles and FOV, which is around 60 deg), found that using -1.05 and 1.05 (left and right), cause an overlap that compensates for my monitor's bezels. You also have a ViewDy parameter but you're the one who has the 4th monitor so I leave it up to you what to use in there :) Could you please let me know a couple of things on your setup? 1- What OS are you using? 2- What CPU do you have? 3- Are you using "windowed mode"? 4- What fps do you get? Thanks!!

Hi ruprecht, my source would be this: http://forums.eagle.ru/showpost.php?p=595278&postcount=16 and for conclusive answers we'd need ED to confirm. Nevertheless, my own experience with single camera view accounted for what grisha has allegedly explained... (i.e. reduced number of objects rendered) I'm right now continuing my tests, having a hard time OC'ing my particular setup. So far I found 3-4 fps increase disabling AA and AF, which is encouraging (you can always buy faster GPUs). About the perspective, yes, either you need very large screens or sit very close to your monitors... which is what I'm doing right now :) but still have to find the correct angles.

Hi Ruprecht, for adjusting the head position you can manually use RCtrl+RShft+(Num/ or Num*) in case you don't have TIR, but you also need to expand the movement limits in server.lua so you can move the head further back, even almost into the seat. About the infinite volume, what follows is a very dry, poorly conceptualised and worsely written explanation. Hope you enjoy! Try to picture your FOV as a pyramid with the camera in the apex (or top vertex) and the "viewdistance" parameter as the length between the apex and the base. The graphics engine must compute every object of the virtual world that falls inside the pyramid's volume. Now if you widen your FOV, you're basically expanding the pyramid volume... until you reach 180 deg FOV, at that time, your pyramid turns into an infite volume body, and even more infinite (!) when you surpass 180. Under this situation what the engine does in my experience is shorten the viewdistance automatically and limit the number of objects (i.e. trees) it displays. You can replicate my experiments narrowing your FOV and seeing if you can spot objects farther away. Try this with different "starting" configurations, although I would believe adjusting FOV in-game should have the same effect. With 3 cameras you're actually having three different pyramids, each one of a finite volume (say 60 deg FOV). Of course this taxes the computer because the covered area is still huge (but not infinite! the pyramids are rotated to the sides!), but this performs much more efficiently in engine terms. The other side effect is correct perspective. In single camera mode with large FOV, the images to the side are completely stretched, because objects there are about 180 deg to the line between your eye and the vanishing point of the computed perspective. This would be a correct projection of the world to your monitors should those monitors be positioned along the same plane. But, you'd normally have lateral monitors rotated towards your eyes, say at 45 deg, and as such, the 1 camera projection is incorrect. You can try this with your own eyes: take a big sheet of paper and put it in front of your eyes, you see a rectangle. Now position the sheet of paper to your side, and rotate it 45 deg, but continue looking forward (i.e. where the sheet was before). Do not move your eyes or head, and you'll now see a paralelogram, which of course is correct. Now the magic part: rotate your head 45 deg towards the sheet, and instead of seeing a paralelogram, you're looking at a rectangle again!! Take your time if you need to, you'll understand what I mean with this poor explanation. Now the same happens with the images in your lateral monitors. With single camera view, the image is stretched as it should be if you kept looking forward to the center monitor. But if you rotate your head to look at a side monitor, the projected perspective remains the same, which is wrong as per the sheet of paper example. When you look directly at a lateral monitor, the vanishing point should be at the center of that monitor and not remain at the center of the central monitor. You achieve this with the 3 camera setup that gives each monitor its own vanishing point. Hope I made any sense. Now, the downside to this, is that if you have three different vanishing points, the perspectives don't match, and you notice this where screens coincide. You'll see the runway for instance coming in a certain direction in the left monitor, and see it in a completely different direction in the center one. For this issue to be solved, the FOV of each camera must match 1:1 to what your FOV would be should you yourself be inside the virtual world looking through a frame the size of your monitors. Thus, you have to zoom in to about 45-50 deg FOV in each camera, and then all three pespectives match and you get as real as it gets a projection as is possible with flat screens. When I tried this, I got to see just a very nice close-up of the HUD in the center monitor, not even covering the full windshield. So in order to be able to see more of the cockpit while keeping the perspective correct, the only option as IRL is to lean back the head... hence the tweak in the server.lua file. So far it takes some getting used to, and framerates are not helping (hence this thread) but the feeling of a correct perspective is to me astounding. I still didn't try this with TIR (as the fps is too low) but I think when I'll do, the immersion will go one true step further. Hope I could make myself clear and that all this is of any use to you guys!

In line with Mr Panzertard's comment here, I'd propose the following thesis: When the AI understands that it is flying in formation, it keeps track of the immediate leader position. When it's told to RTB, it does not, because the algorithm assumes that he's flying a solo route, and thus there's absolutely no need to waste CPU cycles monitoring other aircraft's position until he gets into an approach pattern. Expanding on this, when you order your wingman to depart the formation and attack a target or go recon, he separates from you following a script, and then forgets about your position, only looking for you again when he's asked to rejoin or decides to do so. This can be easily tested...

That's an excellent point Cyclic, thanks! 30 fps with 3 monitors would make me ecstatic. I believe some people brought my CPU to those speeds using air cooling (not stock, obviously), so I'll try and hope for the best. Also found out that I have 1066 RAM but I'm running them @ 800, so some room for improvement there as well I believe... I'll try this weekend and let you know the results. Thanks!

Well... if its specification was to work in daylight only, it would be working as designed... (i.e. "not a bug but a feature") :)