Herra Tohtori

My FreeTrack is configured correctly. Reducing the sensitivity would either reduce situational awareness (smaller range of movement) or add a latency to the head -> camera movement chain, making the head tracking unresponsive. And it doesn't change the fact that if you're adjusting some settings in cockpit panels (say, radar settings) and have to keep glancing away from what you're doing, it feels very unnatural for the cursor to move with your view. Essentially you have to re-position the mouse cursor over the control you want to manipulate every time you look away. The reason it feels un-natural is because the cursor in-game is a virtual representation of your hands. Your hands don't move when you look around in the cockpit. You can glance to the side while keeping your hand immobile, close to the control panel. As per my suggestion, the mouse cursor would be tracked as a location in the cockpit's surface, and moving the mouse left would naturally translate to cursor moving "left" on the surface currently in use. It would even be relatively simple to transform the mouse directions to follow the pitch/yaw/roll settings of the head tracking (so that if you roll your head 45 degrees, sideways movement of the mouse still moves the cursor "horizontally" in your view). But the key idea is to fix mouse movement relative to the airframe, rather than keeping it as a classic, free-floating cursor that just moves along when you look elsewhere. Naturally, the cursor modes should be freely toggleable. Caveat: I have no idea how it would actually feel to use this if it were implemented. It's just an idea, and I was interested in hearing what other people thought about it. It would have to be tested, and I'm sure it would take some getting used to. But saying that "correct head tracking set-up" removes the problem is just not true. Adapting the head tracking set-up to be useable with clickable keyboard is probably possible, but doesn't remove the problem, only alleviates the symptoms. At the cost of some of the range or responsiveness of the head tracking.

I had this idea and I thought it was sort of nifty, and considering my (abysmal) experiences with clickable cockpits in all flight sims I've tried that have them, I wanted to share my thoughts here. The problem I have with clickable cockpits is that if I want to use head tracking, it's nearly impossible to stabilize your head and keep the view pointed in one place long enough to accurately manipulate the cockpit controls with a mouse. This becomes even more difficult if there's some turbulence or g-forces that also move your view slightly. The problem, of course, is that the cursor is still moving relative to the screen, independent of anything that happens in the game - like changing the view direction. In other words it's hard to use with head tracking of any kind. It's a really nice feature, though, so I wondered if it would be possible to improve somehow... And I got this idea. What if you were to map the controls in the cockpit onto a 2D surface like an U/V texture map (that part is actually already done - assuming the UV mapping of the cockpit is done in a continuous, sensible way you could just use the textures as reference), wrap the control map on the cockpit walls and panels - and then constrain the mouse movement to this 2D surface while you're in "clickable cockpit" mode. The effect this would have is that the mouse cursor would follow the edges of the plane's cockpit panels. It would also stay put on certain position - say, over a certain switch - if you don't move the mouse away from it, even if you look away from that point. You could, for example, leave the mouse alone, look outside for whatever reason (like staying in formation or avoiding enemy attack) and then look back to controls, and the clickable cockpit cursor would be where you left it. Obviously, it should be switchable between the "regular mode" where cursor moves relative to screen X/Y position and moves along when you turn your head, and this new mode where it would move relative to the cockpit surfaces. Possible problems would include slower transitioning from one side of cockpit to another, but I'm pretty sure some smart stuff could be done to make sure you don't "lose" the cursor - such as a button that brings the cursor to the point in cockpit closest to your current view. Any opinions? I would really like to be able to use the clickable cockpits, but as it is, it's nearly impossible to use with head tracking.

Late to the party, but posting in a legendary thread anyway. Models made from factory drawings are, by virtue of the work process, accurate 3D representations of the original objects. So if the artist who recreated the FW-190 cockpit was a professional, it's pretty likely that the model is accurate representation of that particular cockpit that the drawings were made of. There are, however, things that can change how the cockpit would be perceived in real life vs. in a game. First thing that comes to mind is, like the cockpit model's designer said (quoted earlier in the thread), that when you render a 3D model to a 2D surface, you are doing a projection, and projections don't always necessarily fully correspond to what reality looks like. You could have an orthographic projection (like technical drawings), perspective projection (which is usually what is used in games since it's quite cheap computationally), stereographic projection or equal-area projection or whatever fancy you want to do. The point is, these things rarely match 1:1 with what human visual perception would produce in a real thing. Secondly, again like has been pointed out in the thread, there are actual physical effects which are rarely modeled, but would significantly affect the visibility ahead and over the nose. Refraction, specifically. I feel people have been looking for a "clear shot" right from the view point behind the gunsight to get the "smoking gun" for the bar's existence that they've largely ignored the best picture to illustrate the significance of the refractive effect of the windscreen. Here it is: Why is this a relevant image? Well, despite being outside the cockpit, the camera is still pretty much in the same plane (elevation) as the pilot's head would be. You can see through the windscreen, you can see the elevation of the gunsight in the cockpit, and most importantly you see past the windscreen as well. To gauge the effect of the refraction, you only need to follow the upper edge of this aircraft's engine cowling all the way to the front left corner of the windscreen. Do you see it yet? You don't. And that's the point. You don't see the engine cowling when you look through the windscreen - and that's because the light you see coming from the "lowest" point on the windscreen actually entered the windscreen high enough that it was not blocked by the cowling. The same effect has already been illustrated here wonderfully by some empirical experiments, so I'll just try to make an illustration of what's happening here. Animated version of the effect at different angles of incidence: So, what can we make of this? It seems pretty clear to me that the 3D models of FW-190 cockpits are correct - the location of the outer edge of cockpit glass is probably exactly where it's supposed to be (notwithstanding possible design changes that may cause variations between specific types of aircraft). It also seems obvious that the perspective and refractive issues are probably the main culprits to why the "bar" seems to be high enough to partially obscure the Revi viewport's lower portion. The ideal fix would be to implement a refraction shader on the canopy glass; this would have the advantage of working from all angles of view and making the glass look like glass. The not-so-ideal fix would be to alter the geometry of the cockpit model so that it would appear to pilot's eye position approximately how the pilot would have seen it. In other words, having the edge of the glass slightly lower so it doesn't obscure quite so much of the useable view of the gunsight. This can, however, be a bit of a problem because if you start making changes to 3D model based on making it look "right" from one angle, you risk making it look odd from some other angles. If it's just the cockpit mesh being modified, though, there's not that much of a risk of that issue. Simplest "fix" would be to shift the gunsight and pilot slightly up... :P ...and the easiest thing to do is for us virtual pilots to just adapt to it and create firing solutions that aren't hampered by this "bar". It really isn't that big of a deal either way - we're talking about apparent location difference on the order of centimetres... if you're really pulling lead on something, a few more degrees of visibility on your gunsight's lower edge won't help - but you'll still be able to set up sideways deflection shots where the target travels horizontally through the gunsight, and you can track it all the way from your side windows. I reckon that's more or less the way the actual FW-190 pilots did deflection shooting because the nose gets in the way irrespective of the "bar" blocking gunsight or not.

Hello! Some time ago, when I was just getting used to the P-51D by flying some of the gunnery training missions, I encountered a strange bug. The mission I was flying was the simple aerial gunnery training mission with two P-51D drones flying in a very predictable pattern. Initially, everything worked fine, although my aircraft actually had some difficulty catching up to the other aircraft (most likely because I'm not really familiar with the tolerances of the engine and I was experiencing some strange engine seizures, so I tried to keep my engine at lower than normal RPM's and boost pressures). In the middle of the mission, however, I noticed something weird. My bullets stopped catching the enemy fighter, even though I was well within a reasonable range. I had to get right up to their tail to inflict any damage or even hit them - the bullets would just not go far enough. External camera confirmed that the bullets had extremely short range when this issue happened - in fact when I further experimented, I ended up flying through ricochets from the ground. At first I thought it was an issue with my gunnery. Then I thought it was something making muzzle velocity too slow and thought it might be that bullets didn't inherit plane's speed properly - but then I did some mental math - my fighter was going slower than 360 km/h, which means less than 100 m/s. The muzzle velocity of AN/M2 machine guns is cited as 860 m/s, which means that at most my aircraft's velocity was roughly 1/10th of the muzzle velocity. Whether the muzzle velocity relative to aircraft was 860 m/s or 760 m/s, the bullets should still keep going much, much further than they actually did. So clearly, problem with object speed inheritance wasn't sufficient to explain the issue. Since this behaviour seemed interesting, I made a video of it, accessible here: Unfortunately, I have no real tools to determine what the initial muzzle velocity of the projectiles was when the bug occurred; I guess it would be possible to interpolate that from the video. It's possible that muzzle velocity was affected by the bug, or it wasn't - it was hard to tell. The more interesting part of the video is the improbably high drag coefficient of the projectiles - they seem to slow down so fast that before the tracers go out my aircraft starts to catch them. Ricochets, being slowed down by the impact, actually end up going past my aircraft as I fly through them. I haven't reproduced the behaviour yet (I've been busy with other stuff, both RL and other games) so I don't know if this is a consistent bug, sporadic bug, heisenbug or a fixedbug. I hadn't made a forum account yet at the time I encountered the bug, so it's entirely possible that it has disappeared after some update. If needed I'll try to reproduce the issue and provide further information (logging, tracks, video). Has anyone else ever seen this behaviour? My system is Win7 64bit, i5-2500K, 8GB RAM, GTX660Ti 2GB VRAM, for performance reference (game runs quite well).