paulca

Possibly one of Jeppesen's apps like the airlines use. http://ww1.jeppesen.com/aviation/mobile-efb/

When I first watched it I couldn't work out why the controllers were American using American style radio telephony. Then I remembered most of New England has English place names like Manchester and Caldwell.

Not strictly A10 related, feel free to move, but... If you enjoyed the A10C IFR challenge mission or you find IFR flight interesting, you have to check this out. From what I can tell he has no auto pilot, he is completely blind for most of the flight and is flying through some seriously busy airspace. [ame] [/ame]

Personally I had already bought the Ka50 and the A10C before it became DCS World + Modules.

The reason Linux has not taken off as a gaming OS is mostly eco-political. The market share chicken-and-the-egg. Studios don't spend the effort to support Linux as it only has about 5-10% of the desktop market while Windows has 75-80%. Yet, if Linux has good games supported on it the market share would certainly increase. There is also the fear of open source, not just the licenses and the Microsoft initiated rubbish about viral licenses and dynamic linking, but the warranties (lack of) and the danger posed to £££ companies not getting the support they need from the developers. One aspect that scares £££ companies is that components they need support for in Linux are often not even developed by one team, but multiple different teams around the world. This is alien to their ways of working. They want a small number of "Partner" companies who have a shared interest in £££ who will sign NDAs and Partnering agreements and what not and the Linux culture does not provide this or even support it in a lot of cases. What WILL change this is if Valve or some other company release a physical gaming console that runs Linux. Last I heard Valve were making a hash out of their SteamBox machine and it was running slower than Windows, but if they manage to get it working properly and manage to make some good sales, the amount of games supporting Linux will sky rocket.... or Valve will fail and it will flicker out again until someone else has a good go at it.

I just have to debunk a few myths here as I find them. 1. WINE = Wine Is NOT (an) Emulator. It's what the name stands for. So, regarding comments like, "Yes, but we want performance so that's wine out" are just poorly educated rubbish. Wine is a reimplementation of the Windows API. Wine is FASTER than native Windows API in a lot of cases. The downside is it does not yet implement 100% of the Windows API or the DX APIs. So if your game calls an API function that is still just a stubbed method you get a log statement just saying "Not implemented". Sometimes this is benign but other times it will crash the game. You 'can' import native DLLs to fill the gaps, but those DLLs depend on other unimplemented functions in other Wine DLLs so you have to import those too. I have gone down this road several evenings and given up after the mess got too great. I ran 2 Eve Online clients simultaneously on my Linux machine using Wine for quite a few years and it exceeded Windows performance. The trouble was that various things began to change in the game as offical Linux support was dropped and the process of getting each update to work got harder and harder. I eventually had no choice but to retreat to windows. 2. Linux has always had OpenGL support, certainly for the last 15 years! I have fond memories of "Tux Racer" in OpenGL as one of the smoothest running games at the time. DirectX support was only via Wine and in more recent years. A SERIOUS advantage to Linux as a gaming OS is that the OS is 100% customisable. I once had a boot CD which did nothing more than run a low-latency gaming Linux Kernel, an optimized X Server display and spawn Unreal Tournament. No shell, no desktop, no pesky background services. Just kernel, display and game. Oh and a RAM disc so the CD was not used after boot. Windows on the other hand is a jack of all trades, master of none and quite annoying and invasive in what it decides it should or shouldn't be doing at the worst possible time.

Thanks. Do you have to switch versions to switch maps? I gather that NTTR doesn't work in 1.5, but does Caucacsus work in 2.0? Is there a summary of the differences between T3 and T4? Pro/cons?

Is there a basic summary of V1.x version V2.x? The thread is a bit long to rummage through. * Any gotcha's for upgrading? * Does the steam key for V1.x work with 2.0 out-of-steam install? * Major/minor pros * Major/minor cons ?

You will only notice the difference between flap 7 and flap 0 if you actually obey/monitor the rotate and wheels up speeds. ie. At Flap 7 the wheels will lift a bit sooner. This is more true the heavier the plane is. Getting airborne sooner is good. If you are using long runways and just flooring it to around 150, then pulling back till it lifts, you might as well just use Flap Up. I believe the retract speed for Flap up is around 170-180kts. They appear to auto retract around 200kts.

ALT mode will only engage if you are in a level turn. Make sure the autopilot switch is sync'ed, move it back to ALT/HDG and down to ALT again after you enter the cockpit to be sure.

I suppose it's not such a big deal, I just have to move the zoom slider back beyond center, it's just that the center detent is a good "reference zoom", if you know what I mean.

Actually not sure I can change the center point of the axis :(

The problem is the zoom axis is absolute and not relative to the default FOV. I have the zoom axis assigned to the "Throttle friction" slider on the warthog throttle. No matter what I do with these suggestions center position is always the same... too zoomed in for 21:9. I can reset the default field of view with RAlt+Num0 and when I hit "Num Enter" it resets to that point, but as soon as I move the zoom axis back to the center detent it's back to where I started. What I need is a way to forcibly say that "0 zoom is this FOV" so that "Center" on the zoom axis becomes that new FOV. Now I can see an issue where full zoom out would increase even further, but I'd happily accept the zoom out maxing out before the end of the slider. Oh! Ah! Ah ha! Can I not just adjust the zoom axis center and curves?

You need to edit your Slew-X Slew-Y axis. (Might be Joy_X, Joy_Y whatever is assigned to slew, x, y) It needs a very, very special axis to get sensible control. The issue is that it takes virtual no pressure on the little nipple to go from 0 to MAX_AXIS. So to have any chance of getting sensible response you need to step it. I can't find the setup thread I used :( But this may help.. http://forums.eagle.ru/showthread.php?t=95729&highlight=HOTAS+Axis+tune Mine is a little different, but the above (Post #6) might be better. For mine output stays 0 for about 15% of the axis when it jumps to a very small output value and remains there right up till the far edges when it jumps to a slightly higher value. The idea is to give up on it as an axis and use it as if it only has "off" "slow" and "fast" settings.

Well the R-Alt Num 0 doesn't work for me as I have zoom on an Axis. As soon as I hit R-Alt Num 0 the view snaps to centre (like hitting num 5), but the zoom stays where it is with regards to the zoom control. ie. no change the zoom axis is still master. I'm not entirely sure that zoom == fov. I have never studied photography much but I seem to recall they are different things. So it looks like I will either have to offset the zoom axis or edit the LUA files.

Ah, I didn't know that key combination. Thanks, I'll try it.

I was lucky enough to get myself an Acer X34 21:9 monitor. Res is 3440x1440. The game selects the resolution fine and the game works fine, but the FOV doesn't appear to adapt. To explain, the default zoom level has increased so that I see the same horizontal field of view as I did on 16:9. This means that everything feels zoomed in, I have less vertical FOV and I have to move my zoom slider to 50% zoom out of I feel like I have my face in the instrument panel. Is there a quick fix to edit the FOV?

Your kinda a bit unlucky if they were driving past your house at the time. I'm just glad nobody ever choose this approach in Belfast.

Is it disc access? What kinda of RAM and video RAM do you have? Does the HD light flicker coincide with the stutters? The only noticable stutters I get are when DCS has to load a texture or something that has just come into draw distance. I get the odd random stutter, but they are barely perceptible and on a busy Windows system these are hardly surprising, that's just how windows rolls, there are things that it feels are far, far more important that your game that it needs to do in the background and the worst possible moment.

One of the best ways to address your issue is to use the TGP first. Find your target. TMS Up Short so you get "Point" track. TMS Up Long to set it as SPI. Switch right MFD to maverick and set it to SOI China Hat forward long to slew all sensors (including maverick) to your SPI Get yourself in position and turn directly towards the target. You should see the circular maverick 'sight' over the target, sometimes it takes a few seconds to slew over. Repeatedly press TMS up short to "Lock" the maverick. Fire once locked.

Is there anyway to get the dude to walk faster when he's down?

I was having a play with some basic aerobatics. Started in hawg style with some single point target cuban 8s. It does these fine of course. For a single target point on the down legs they have to be very steep. However when I wanted to extend the 8 further down the runway and pushed a little negative G at the top of the loop, before the inverted down leg... The master caution went off, the left engine shut down and my NAV system reboot. I took a break stage left, got it all (minus the EGI nav) back online and the show resumed. Did the same thing again trying to do a square loop. Once I put about -1G on it the engines began to fail and the electronics started to reboot.

I know I have been warned multiple times for comparing combat aircraft to airliners and GA planes. I am frequently told that GA and civil planes are designed docile and nose heavy allowing high positive stability, easy to trim, along with low coupling etc. (Don't both the Dash-8 and Learjet have yaw dampers to help them anyway?). Most combat aircraft are on a knife edge with neutral to rearward balance to get high pitch and roll instability for maneuvering. This is so much the case with modern fighters that it's impossible to fly them without the computer stabilization. The A10 can be flown with out it, but the coupling is even greater and I believe I read somewhere that is a 'feature' of the air frame. Never tried to snap roll it in the Sim, but it will pull out of a dive at 6g and it will spin ... eventually and self right with hands off... usually. However... isn't a snap roll induced by back pitch to the point of high speed/high alpha stalling it usually resulting in a hard roll/yaw one way or other? Similarly to a normal vertical spin the rudder is only used to induce the yaw so it spins in the direction you want rather than randomly? Then ... that's what the "Performance limits" beep is all about. If you get a constant tone, you are at alpha limits, if you get a rapid beeping and keep pulling it snaps on you, if you are very aggressive and very slow it will spin on you. But I don't have any real life facts to back it up.

TIR works for me in training missions, but I did notice that some of the training missions lock out the external views etc. So maybe some missions have a bit too much "View override". Is it all missions?

Can you not just use East? The world is round you know. N54* 40' 30 W012* 11' 10 == N54* 40' 30 E347* 49' 50