firmek

Just leave it as automatically managed. It's already located on SSD which gives you the best performance. What is quite often misunderstood is that paging file should only be needed when low on RAM. This is absolutely false. Windows will use the paging file all the time, also as a memory for non-performance critical or non-used applications even when plenty of free RAM is available. Becase of this don't turn the paging file off even if on a new system with a lot of RAM - for instance 64GB. Doing so may have a negative impact on the performance and system stability.

They work basically the same way. You need an up and down action for 2 position switch and two up and one down action for a 3 position one. Look for a similar thread under F-5 section. I'm sure it's there, if not start it. It would help to write which keys are you interested in.

As many said Viggen is in-work before the official release. Still it's quite feature complete and overall a stable module. Yes there are things that need to be looked into but really nothing game breaking. HB is also maintaining a good support with steady flow of fixes (just look at the latest update log :thumbup:). If the 4 concerns are expressed with such attention you should begin with staying away from the Harrier. Comparing to other early access, Viggen looks almost like a complete module. I wouldn't be supprised, hell based on recent statements from Cobra I'm sure the F-14 will be really polished for a DCS EA standards. Ad 1. It's a striker, not a fighter so IMO it's perfectly fine to give mirrors a lower priority. Ad 2. Unfortunatelly that's an issue with almost every single module. It's possible to create own bindings by editing the lua or just using the file maintained on the forum. Not everything however is possible especailly if the actions are not defined. I wish every devellopper would ship their modules with a full list of 2 and 3 way bindings for every single switch in the cockpit. Ad 3. There are some parts that could use a higher resolution texture but really, the Viggen cockpit is one of the if not the best at the moment. Ad 4. All devs are facing a challange with DCS moving to PBR. Not every cockpit is optimized and Viggen has some extensive lightning due to the radar screen. Just compare it with some other modules where the radar screen does not light the cockpit at all.

Just to "relax" a bit:

:thumbup::thumbup::thumbup: Though, why trainers are not included?

I'm not really an expert but you seem to mix the insturment with visual charts. If you read a complete document you'll find out that landing on 31 is allowed only with visual rules, during a day, clean weather conditions and only for a relativelly small planes. If it's a night or adverse conditions, even for instance a cloud base at 3000 feet, noone would be cleared to land on 31. Thus we can safely assume that if the wind component does not allow landing on 13 the plane would be diverted to another airport. Look also on the minimum safe altitudes - it's 15.7 k and 9,5 k feets when approaching from any other direction than the sea. Landing on 31 really does not make too much sense in any other then perfect day visual conditions.

Short extract from the Batumi flight procedures. It seems that IFR arrivals are RWY 13 only, departures 31. As for VFR both directions are possible but with limitations. On top of that there is pretty much no infractructure (lights, ILS) on RWY 31.

It is when the files within module are modified which is not the best way to do it anyway. If you use the server.lua stored in saved games the change is IC Green.

Obvioulsy no clue how it looks in reality but +1 to the opinion that the night photos will make the effect looking more dramatic then it's in the real life due to the longer than day time aperture setting.

I'm not proposing to strengthen the air defences around the targets. They are fine as they are. Just to create scattered AAA and maybe flak at over the complete area, maybe around the cities so that flying at low level behind the front line, during ingress to the target would create a risk of being hit by ground fire (as in real life).

Just an suggestion to consider - how about adding some AAA around the cities and maybe even including the flak script. The point is to bring the fight or at least the flights to a higher level then 10-50 meters over the ground where pretty much most are flying. Its quite evident especially in the phone booth mission where majority are flying like they would be piloting a jet engine propelled lawn cutters :D

As far as Tornado is considered I believe only the interdictor variants would make sense for two reasons: it is the reall soul of Tornado after all and on top of that it would bring something unique to DCS where there is still quite a big gap to fill in. Yes, there is the Viggen but at the same time it's quite a different pair of shoes. As you say the electronic warfare is simulated in really an simplified way in DCS while the interceptor variant would mix with already a big, with all due respect more capable and specialized crowd.

If you're interested in running 2.5 open beta you should be able to update 1.5 stable to 1.5 open beta - and then obviously to 2.5 OB when it comes out. Search on the forum how to do this but IIRC it takes as much as running the updater with approporiate args.

Couldn't agree more :thumbup: To be honest I'm not sure where the issues are coming but they look to be pilot related. Haven't experienced problems with F-5, maybe because I fly the Russian aicrafts more so I'm used to diff breaking and don't use the NWS for other purpose than taxi. On top of that there is always a possibility to modify the curvature for rudder peddals.

It's not a joystick issue but the devs which: 1. don't create an approporiate commands 2. don't offer a 2-3 way switches key binding for their module even if the commands are there As for the first point the problem is that there are quite often only a single, toggle command implemented in the module - basically the same key that will go on/off (up/down) depending on how many times it's pressed. There are no separate actions defined to put a switch into up or down position. In such case sorry but it's almost a dead end, this will not work 100% correctly with an up/down or a 3-position switch (2xup/down). Second point is just the devs saving time and transfering the effort to the community. Eventually after the community creates a list of switches they'll just go and put it into the module (see M-2000C for instance). Still this means that usually only the most often used - popular switches have a 2/3 way switch bindings while other are missing. Being fully honest, every module should have a complete list of bindings for every single 2 or 3 way switch in the cockpit created by the devs. I'm really tired about the fact that for every single module that I get I have to go to the lua file to create those list by myself. Then I find out that some switches have only a toggle action instead of up/down representation. On top of that I have to pay attention if the updates didn't change a action binding that I used. There is no issue with the TM Worthog. It's one of the most populare HOTAS and it should be considered as a standard. It also has been working with A-10C in DCS since many years. It's the devs that are not dedicating enough attention to make the support out of the box :thumbdown::thumbdown:

Sorry if this had been already asked but what are the plans for BF after next Wednesday - when 2.5 comes out? Will it remain on 1.5.8 while 2.5 version is tested internally or there is an assumption it'll work with 2.5 Caucasus right off the bat (IMO rather a risky assumption) ? Just to understand if it's a good idea to keep the old 1.5 installs for the time being.

:thumbup: Based on the experience from the past and the 2.5 schedule we should draw a conclusion that if there are release dates communicated the assumption should be that the release will happen on the last possible Wednesday or Friday. Not being critical, just factual and drawing conclusion to limit hype train starting too soon. Should be much healthier this way for everyone. Thanks to ED for the big effort during the long jurney getting here, for as it seems keeping the promise and finally for making the update as easy and smooth as possible. I'm sure 2.5 is going to be great and a major step. Though issues should be expected especially with such a big update. :thumbup:

Just read the original post. All the answers are there. But since I've got aksed: Ad 1.) The question is not related. There are people running 1.5.8 OpenBeta and 1.5.8 - why they had picked one or the other version has nothing to do with the release. Still to answer, there are many people running OpenBeta since a long time just to get the latest updates. Ad 2.) Well if you don't uninstall you'll get as many version as you keep but still it doesnt change anything. After the release you have 2.5 OpenBeta and 2.5 (stable). All other old versions are abandoned and unsupported. ED doesn't have anything to do with what you decide to keep installed on your computer. If you have 1.5.8 OpenBeta and 2.2 OpenAlpha and run the update agreeing on 2.2 being deleted you'll end up with a single 2.5 OB version. Ad 3.) And why not? You get an option. It's the same as you can go to NVIDIA web page and download a 5 year old GPU driver and install it. Doesn't mean it's supported. No reason to really split the hair heare. I wouldn't be supprised that if 2.2 would be forcefully deleted a lot of people would complain. I'm really starting to think that people like to complicate the things way much more than they are.

Can't get any more clear and easy. Great work ED :thumbup:

As I understand: 1.5.8 beta -> updated to 2.5 beta. 1.5.8 stable -> discontinued (obviously it's possible to keep the install but no patches will come out for it after 2.5 release). It will not be updated, new 2.5 install has to be downloaded and setup. 2.2 alpha -> discontinued 2.5 stable -> new install but in order to reduce the download size it'll copy files from 2.2 if it's installed. For those running 1.5 beta that decide to also use the 2.5 beta basically it'll be just an update proces as with any other patch. Nothing more to install. 1.5 stable and 2.2 alpha can be esentially deleted after 2.5 comes out. Anyone correct me please if I got something mixed up.

Well, you know that changing the graphics library won't make DCS to be multi-system. :)

Hard to tell how big the performance impact would be. What I think is that the whole math gets way more complicated. Lets imagine a plane flying absolutelly horizontally. In flat world that basically means moving along a 2D plane. Translation matrix is quite simple to calculate, just by adding a delta distance over a time. If the earth gets round now there is also a vertical component. Extreamly small but still it's there as a "flat" plane patch is basically a hudge circle (being more precise a sphere with constant radius). In other words the question now is if it's only the map that would have to be changed or actually a complete physics engine, including flight models and AI movement calculation.

I'm sure it's North hemisphere that is accounted. Astronomical Spring is: 21'st March to 20'th of June. Metoeorogical Spring is: 1'st March to 1'st June. Lucky for you to consider February for a Spring but the Winter ends in March while Summer begins in June ;)

??? I'm just saying that you could have deleted 1.5 and 2.2 after installing 2.5 - thus saving a lot of download time. With all due respect, it's kind of a strange rationalle to say that since the 2.5 had been prepared by ED for a long time, I'll delete existing installs at least a weak before it comes out, won't fly DCS during this time and spend unnecessary more time for downloding the install...