klem

Yes, it works in MP (I hadn't thought to try it when offline didn't work) but it also used to work in offline too. Even in MP it still has the edge of screen distortions from adjacent screens but it works. Why would I want two versions of the openbeta? And what advantage would that bring, the offline play would still not work. (If you mean a side by side with 1.2 then I, and I suspect everyone else, already have that.)

Still no luck but some more info for the devs (not sure it changes anything). Latest update to 1.5.1.47025.99 did not help. I tried renaming my Saved Games folder to DCS.openbetaHold so that a new folder DCS.openbeta folder would be created (this protects my controls settings etc.). In all the various tests I tried, changing between the old and new folders did not solve the problem. Bottom line: Setting NOT full screen made no difference. It works as 1Screen across either three or four monitors (5900 or 7820). It does not work as 3Screens on either 5900 or 7820. It does not work as Centre screen 5900/1080 plus Bottom screen 1920/1080 (total 7820/1080). I have not tried without bezel correction. I am forced to fly 1Screen but I hate the stretched side screens. EDIT: When I say 'does not work' I mean it crashes while loading the mission.

More logs Sorry, you probably want these (attached). Logs.zip

Game crash since update tonight to 1.5.1.47025.98 (version from autoupdate.cfg). UPdate commenced when I tried to launch from desktop icon (DCS_updater.exe). ERRORS: ERROR: Failed to download CoreMods/aircraft/MiG-15bis/Textures/MiG-15bis.zip ERROR: HTTPS failed with curl error (51): SSL peer certificate or SSH remote key was not OK INFO : Switching to plain HTTP Log attached. Crashes when trying to Fly in an Instant Action, a mission or campaign. I tried a tip in another post and changed my time zone to Europe and did an Update from All Programs, just a quick flash of a box and nothing. Tried a Repair and still crashes. Tried Moscow time Zone - same, back to UK time - same. Help! autoupdate_log.txt

Thanks Yo-Yo. The fixation on the 5 minute guideline has caused more irrelevant arguments than I can count. If BCO is operated and historical records show that overheat comes into effect after a period of time and you model it then so be it and its up to us to manage it. If there is historical evidence of mechanical failure after a period pf time then that is indeed where Russian Roulette comes into it and if there is that evidence you could of course program in a random time for failure beyond 5 minutes. I think it was Al Deere that told of a sortie in his Autobiography where he is returning to England after a long drawn out combat over France where he had left BCO operated continuously way beyond the 5 minutes. I think it was about twenty minutes, I'll have to re-read the book. Anyway it eventually began to run roughly but after correcting things the engine cooled down and performed perfectly well for the rest of the flight. It may even have been an earlier mark of Spitfire but it was a testament to the general reliability of the Merlin. What this argument sometimes comes down to is 'the LW' not wanting 'the RAF' to gain unfair advantage but accurate modelling will defeat those arguments. Other than that I don't think there is any practical reason why it should not be operated beyond the five minutes, after all we don't have persistent damage modelling (damage or wear carried forward to the next sortie) and we can assume that having reported it to the ground crew it would have been checked and the engine replaced if necessary, or that we were assigned another aircraft.

Could the devs please let us know what they have listed to look at as far as multi-monitor issues are concerned and in particular the basics: Distortion/edge bands in Surround when using bezel compensation. GUI click-point positions. Map view distortions (squished onto centre monitor)

On startup from the desktop icon nothing appears to happen for quite a while suggesting it was not double clicked. In fact it is starting with no visible indication but the temptation is to try to start it again. Can a splash screen be put up immediately it is started? Also when joining in multiplayer there is a long period of black screen before the next screen opens suggesting it has crashed. Can that be fixed too please?

And I still can't find how to change from perspective to plan view. The buttons down the side don't do it. :( EDIT: Dohhh! It's not perspective, it just looks like that. It's the basic squished map problem.

Nice. Not sure which was more interesting, the landing or the facial concentration :)

Of course, it is just a demonstration which is why I focussed on the in-flight video operation of the flaps.

It wasn't aimed at anyone bongodriver. It's just a saying from business. Many of us are asking for it, some don't want it or don't think it's necessary so I thought I'd skip the argument and offer a solution. As you say, the key-driven trimming has reasonably realistic timing and as that has already proved possible it seems likely that something similar could be implemented for a rotary. Oh, and Solty, my rotary trimmer is on a separate unit to my X52 Throttle so I do have to take my hand off the throttle to adjust it. It's an old X45 re-hashed into a plastic box with a multi turn pots. Even when it was still just the X45 I had to take my hand off the X52. There are many controller possibilities/combinations.

Old School: "Never bring a problem to the table without offering a solution" The most effective solution (Yo-Yo might disagree due to coding) would be to implement a delay based on input demand. For example, the actual rotations animated are 4 turns = 1440 degrees. This also corresponds to the flap cycle shown here: and the flaps and trim were intended to be used together. In that demonstration it takes about 20 seconds to do the 22 movements of about 60/70 degrees at a gentle pace. In this video Klaus (?) lowers the flaps in flight over 18 movements in about 15 seconds: That's about 80 degrees per hand movement and about 96 degrees per second. Lets say we're as quick as Klaus: 96 degrees per second, 18 hand operations in 15 seconds. The output range of a HOTAS or other, even muti-turn, trimmer pot is typically 0 to 65535. So every change of input of 65535/15 seconds = 4369 deg/sec.. Lets say a change of input of 4000 should incur a delay of 1 second and proportionally for any other change of input values. It's just a slope. Can't that be done? Once the code is established it can be applied to any trim with adjusted parameters to suit wheel size, RL rotations etc.

Thank you Sporg. I didn't know that. It changes the argument completely. I'd still like to use my rotary and wish they would find a way to make that possible.

Yo-Yo could you explain something please? Is my understanding correct that the elevator trim, as modelled, cannot move the elevator beyond the deflection range that the stick can? As I tried to say here: http://forums.eagle.ru/showpost.php?p=2516177&postcount=150 If that is correct I do not see where any exploitation in combat can be obtained using quick-fire trim change because even with a single turn pot it cannot change the elevator deflection faster than a stick can by just pulling it back. If the aim is simply to ensure that only a 'realistic' trimming action can be achieved in normal flight then that's a reasonable point but I do not see how that can be declared to be combat 'exploitation'. It's just a bit of a convenient cheat, like it is in the P-51D which has about 500 degree RL rotation on a typical HOTAS 300 degree pot which is manageable. Yes a single turn pot would be almost impossible to use on the 109 due to sensitivity (unless scaled right back) but you have provided keys as an alternative for those that can't use it. Why stop those that can? Like some others I have multi-turn trimmers for a better experience and I would really like to be able to use a rotary. Also, with the likely trim range that would be used for takeoff and landing even a single turn pot could be scaled back for better control over a smaller range. It would be the users choice.

http://forums.eagle.ru/showthread.php?p=2516567#post2516567 Bumped.

http://forums.eagle.ru/showpost.php?p=2516177&postcount=150 I'm bouncing this back to life as it's arisen in another thread where I thought it was a problem with of "1.5". It really needs to be changed.

I'd like to get us off this point because I feel guilty about introducing it. It wasn't what the OP wanted to hear. I only asked the question because I thought it was a '1.5' problem. I realise looking back that I ran into problems because since last fighting the 109 off the runway, many months ago, I have installed a 10-turn trim pot system and before that I was using my X-52 pots which I always zero'd by the markings on the rotary which my new pots don't have. I now have to zero them by the cockpit indicators/markings which is where the problem became evident. I never bothered with 109 elevator trim for takeoff before anyway but now my pots are often way off neutral when I get into the cockpit. (Cockpit checks have become vital!) HOWEVER, I think this whole Trims issue has been driven off track by a myth. You will have noticed that when trimming the 109 elevator the stick moves. Why? Because you are applying aerodynamic force and therefore movement to the elevator with the aerodynamic force you cause at the trim tab when you adjust it. That elevator movement moves the stick via the control cables. The elevator only has a limited physical range of movement. I believe that is the case whether you move the stick forward/back with your sweaty hand on the stick or you get the Trim tab to do the job for you. Whatever manual deflection you apply or whatever aerodynamic force you apply through trimming there is only the same limit of movement the elevator can make. So where's the myth? It has been said that the argument for not providing trimming on a single turn pot is that it could provide unfair advantage (exploitation) by enabling the elevator to be moved rapidly with a twist of the trim pot. Moved beyond what? The elevator has finite mechanical limits achievable through the control column. The trim tab can't take it beyond that and its quicker to pull back the stick than wind the trim tab even with a single turn pot. I suppose you could pull fully back, hold it there and wind on some extra 'up' elevator by applying Down trim (the tab moves UP). But is that really going to make much difference? Aren't you more likely to live or die by your tactics than in a perfect turning circle fight? And doesn't your opponent have a similar system anyway? If I've misunderstood the argument then perhaps someone could explain otherwise I think the basic argument for removing pot-trimming doesn't have any value.

That's just the point SithSpawn, the option of an axis is already there, its just that it's been porked to turn it into a 'banded' pot. Still I think we've done this to death, I only hope the design team are seeing this.

Yes it works with a HAT switch but the axis input is there and it seems unnecessary to eliminate it just because it's tricky for some people to handle. If the real result of swinging the trim from fully negative to fully positive is damage to the airframe then let's have it. If it's a case that full trim movement in a quick rotation of a Rotary is unrealistic them slow it down. Currently it's completely at odds with the aims of ED/DCS which are to give as realistic as possible a simulation. It works fine in the P-51D, how is that done?

Many thanks for the answer. To be honest I think that's ridiculous. Many of us would like to have the nearest representation possible to the modelled a/c, most designers try to achieve that and it's what we've come to expect from DCS. Why is it that the 109 gets this odd treatment and no others do (please, no others!) It must be a big downer for people building cockpits and for someone like me who has 10-turn pots for trims. And even with a one turn pot, if people are daft enough to whack their one-turn trim pots from one end to the other and break the a/c that's their lookout. A time-delayed rotation of the trim/animation cant be that difficult to achieve and as you say the HAT option is always their anyway for those that can't come to terms with using an Axis. All they've done is remove it for those that can rather than solve the problem. This is still in beta, correct? Anyway, the sim has curves adjustments, people can use JoystickCurves and of course 10-turn pots if they want to build something or adapt an old stick. Fortunately for me I don't fly the 109 often and was only trying it out in 1.5 but that's a complete cop-out.

I can't see that this has need said in here so... when I assign the elevator trim to an axis (which works just fine in other aircraft like the P-51D) I find that it does nothing until I reach about 90% rotation. Then it hits a spot where it acts like a switch so that either side of that spot the wheel rotates fully forward or full aft. I can, with micro-adjustments, get it to move partially but it is completely impractical to fly like that. Does anyone else have this problem or know an answer? I thought I'd ask here before posting as a "1.5 bug". EDIT: no the axis isn't 'banded', it's a virgin axis.

Thought I'd add this to show what I achieved on my 27" screens. First a zoom level looking down at the instruments alongside a full screen photo of my knees in P-51D Ferocius Frankie. My RL knees are directly below those in the photo Also one looking not so far down and then one looking forward. Finally a small adjustment to my actual view to cleanly separate the upper screen instruments from those I have on the screen below, it avoids cutting off the lower part of the gauges. A good job ED !

One thing I hate about those videos is that you never get to see their hand movements. Another thing I hate is that young face and clear eyes but that's another story. Beautifully smooth turns and rolls. Yo-Yo we're waiting :)

Well, we Brits wouldn't want to make it easy would we ? :)

Everywhere I look I see MH434 quoted as a IXb. Strangely a careful look at the wing/cannon/machine gun patches suggest it has a C wing (now?). On the b wing the cannon and two m/guns were evenly spaced with the inboard m/gun at the inboard side of its gun bay. In the C wing the inner m/gun is moved to the outboard side of it's gun bay giving wider spacing between it and the cannon than between the two m/guns, as it appears in very photo I have seen. It was built at Castle Bromwich (with a Merlin 66 engine): http://www.airhistory.org.uk/spitfire/p063.html According to this it was ordered as a MkVC but most were delivered as 'MkIX', presumably a front end switch but still with the C wing? http://www.angelfire.com/sd2/spitfirefactory/production.htm According to this website it underwent a major rebuild in 1994/5 so if it ever was a IXb perhaps that's when it changed? http://www.military-airshows.co.uk/spitaw.htm