PhoenixBvo

To be sure you get every custom setting, do the following: Copy your old installation to another folder (e.g. called compare_DCS_Warthog) and do the same with the [user]/Saved Games/DCS Warthog folder as well. Then install the patch over the original (OR delete the original and use the full installer) and use Beyond Compare or some other compare software like winmerge to compare both installation folders and both "Saved Games" folders to one another. Apply a filter to only compare .lua, .cfg and .miz files and you'll see which files have changed AND have the ability to instantly compare each difference inside the files and decide which changes are to be copied to the new installation. This would include your own multi monitor settings, the ingame options (although valid values might have changed between patches, be careful there), input settings, pilot achievements (log), custom labels etc. Be aware that there will be files which have been changed by the devs between patches, so if you don't recognise the differences to be your own settings then just leave the patched version as is. I've applied this method to all patches with LOFC/2, DCS:BS and DCS:WH with no problems and great succes. It saves a lot of time compared to taking notes of all settings and clicking your way through the GUI each time. Moreover, some settings (which tend to be the interesting ones) you just don't find in the GUI. Cheers

I believe that graphic shows triple buffered V-sync (if indeed it is not just an fps cap). There is no way (that I know of) a double buffer system can produce smooth frame rate changes with V-sync. Please enlighten me how such result would be produced if it actually is double buffered. (See my diagram for the underlying functioning of V-sync) If your graph is indeed the result of a DCS:BS session with V-sync enabled, then I assume the DCS application has a way of enabling triple buffering...

Not correct, I'm afraid. Your second option with a 120Hz monitor and around 70Hz capable graphics card without V-sync would still produce tearing in the image, because the new monitor frames will be swapped at time instances when the graphics card is in the middle of producing its next frame. Without V-Sync image tearing will always be a possible annoyance.

Well, V-sync limits the possible frame rates to integer fractions (1/1, 1/2, 1/3 etc.) of the monitor refresh rate. If your graphics card is fast enough to reach the monitor refresh rate (e.g. 60 Hz) V-sync will not reduce the effective (or perceived)frame rate. However, when the GPU dips just slightly under the monitor refresh rate, V-sync immediately halves the frame rate (e.g. 30 Hz). So, V-sync may result in lower frame rates and not in higher ones. However, the human perception works such that changes in frame rate are much more noticable than constant lower frame rate. So if your frame rate without V-sync remains within the range between two integer fractions of the monitor refresh rate (e.g. between 60 and 30 Hz) it would result in a smoother experience to turn V-sync on, even though the resulting frame rate is lower (namely constant at 30 Hz in this example). Does that answer your question? :smartass: EDIT: That is, assuming we are talking about double buffered V-sync. But that's effectively the only option available with DirectX. Triple buffering decouples GPU and monitor rates, but introduces more delay. Everything comes at a price...

Some time ago I made the attached graphic which explains V-sync in connection with either double buffering (the standard) or triple buffering. The checkered boxes are the frame buffers. One is where the GPU writes to and the other is where the monitor reads from. In reality the buffers are swapped rather than copied, but for the purpose of understanding the concept it suffices to imagine them as such. Without V-sync the GPU buffer is copied once the monitor completes a frame. Most likely the GPU will be in the middle of writing a new frame to it's buffer however, causing a partial new frame to be displayed with the upper half belonging to a newer timestep and the lower being from an older time. This is the tearing which you see. V-sync only copies a frame when both the GPU and monitor are ready and holds the GPU when the monitor is still in the middle of a frame. It may be a bit confusing to bring the issue of triple buffering into the discussion, but fact is that V-Sync with double buffering will cause your graphics card to sit around waiting for a percentage of time (even if it's slower than the monitor refresh rate). This is what triple buffering solves.

^Meaning its fixed again in the upcoming patch?

x64 (of course)

Well, in the case of the CBU-87/97 I can actually imagine it to be a viable tactic in RL. I mean, you don't deploy cluster munitions danger close or anywhere in the remote vicinity of friendlies anyway. Secondly, they're comparitively cheap weapons and thirdly area effect anyway, so no pinpoint accuracy is required. That, plus presenting a difficult-to-hit target to the enemy, all points in the direction of tossing in this case.

Uhmm, perhaps it rather depends on the sort of munition you propose (see my previous post).

In one word: speed. Or rather the lack thereof in the A-10. F-16s for example use loft attacks with JDAMs to increase standoff range while using terrain masking, but with the A-10 you just can't give the bomb a sufficiently large amount of kinetic energy for it to be a valuable technique. I suspect that this ability hasn't been implemented in the avionics, because it just isn't practical. EDIT: This because it is a guided munition which needs some ten seconds of flight time to accurately correct its path onto the target (Recommend minimum drop alt for level bombing is ~10.000ft AGL). The CBU tossing, which coolts is so enthousiastic about (haven't had very positive results myself yet :(), requires very accurate flying, but no guidance during bomb flight. Thus release speed is not that critical for accuracy. It still is though for keeping your distance to the enemies fangs, which has been the main reason for my limited success...

bluepilot76 (and anyone trying to keep their settings) what I'd recommend is the following: Copy your old installation to another folder (e.g. called compare_DCS_Warthog). Then install the patch over the original (OR delete the original and use the full installer) and use Beyond Compare or some other compare software like winmerge to compare both installation folders. You might want to backup the [user]/Saved Games/DCS Warthog folder as well. Apply a filter to only compare .lua and .cfg files and you'll see which files have changed AND have the ability to instantly compare each difference inside the files and decide which changes are to be copied to the new installation. This would include your own multi monitor settings, custom labels, the ingame options (although valid values might have changed between patches, be careful there), input settings and pilot achievements (log). I've applied this method to all patches with LOFC/2, DCS:BS and DCS:WH with no problems and great succes. It saves a lot of time compared to taking notes of all settings and clicking your way through the GUI each time. I just hope this advice might help someone out a bit... Cheers

Smeghead, comparing Crysis 2 performance to DCS is like comparing Miss World to a Nobel prize winner. Crysis 2 is all about good looks without much depth in terms of CPU-side simulation and DCS is first and foremost a very intricate simulation with enormous CPU loading. As a bonus we get nice graphics as well, but the bottleneck lies with the CPU. That means your graphics card is waiting on the CPU to produce new data to draw its next frame. Get better CPU+mobo+memory and you'll see a good performance increase, get a better graphics card and you'll see the same performance.

^^ If that's it, then my suggestion would be to plug in a check into the code to see if there is tarmac at (or near) the wheel coords and set the grass friction equal to runway friction temporarily. This might be easier than preventing the wheel to sink thru the tarmac slightly. We have similar problems with a dynamical (spring/damper) simulation of a helicopter undercarriage at the DLR. It isn't that easy to enforce hard boundaries in a numerical simulation with a system of ODEs.

Yes, Teeps, normally I'd agree, but this particular mission just got on my nerves... So, now I just know better what to do. Thanks Grimes.

The problem I have with that mission is not so much JTAC (I got the mystical fleeting red triangle with Group ID 1), but the lack of someone telling me I have succeeded and may go home. Yes, the mission description states you have to hinder the advancing tank columns and you're not expected to kill them all, but how much hindrance is considered enough? Also, my wingman tends to live very shortly, he takes forever to aquire a target for a maverick and then gets eaten by Shilkas... Does someone know the exact success conditions for this mission? EDIT: Thanks zamboni, hadn't read your post yet. Will try the tweaked mission. Does it still progress the campaign if I complete this one?

LOL!! No, that would be after taking off again, of course! Somehow restarting my engines after rearming/refuelling and repair causes oil pressure problems. I follow the complete ramp startup checklist, which works perfectly at mission start. So, why not after a maintenance stop? @hassata: Thanks! Will try that.

My annoyances with an otherwise superb sim: 1): Too many stutters/lag, will try the thread suggested by Hassata, but ED can't expect ordinary customers to know and apply that stuff in order to have a decent sim experience. 2): Toebreaks on the CH Pro pedals remain inverted, whatever I try. This was NOT a problem in the betas. Lua editing (including both copies in C:\users\... and the game folder) is without effect and in-game control setup doesn't change behavior in the sim either. 3): The Wingie still flies straight into the hornets nest when told to attack something with Maverick. He doesn't maintain standoff range to known threats. Or gets too low when using GBUs. Why is that so hard to implement? 4): Warning beeper goes off continuously at starup (known bug). 5): Plane repair. Regardless of damage, when you make a rearm/refuel landing and want to repair, you have to at least shutdown the engines. This causes hydraulic pressure inconsistencies. The dials show values in the green, but trying to raise the gear causes Left Oil pressure warning and later also Right, causing loss of control... (Has been reported somewhere as well)

Yes and that's correct. The HUD is focussed at infinity, so it should be in focus through the NVG.

Either manually lase with the NWS button on the stick, or go to the corresponding DSMS weapon profile page (via VIEW PRO > CHG SET) and set AUTO LS to on & LS TIME to 12 (by scratchpad). Click SAVE and you're set.

Those are UTM coords. Follow this explanation: EDIT: Also, number of digits must be even:

^ Regarding 3, you have to hold short of the runway and then ask for take-off clearance. When you're already on the runway, the controller sees an occupied runway and doesn't let you take-off. Logical, no? :)

In Black Shark it'll send you spinning to earth (and not a long way to go for pulling the ejection seat). Had that happen to me a bit too often at night sorties. EDIT: OK, some are quicker to respond :-). In the Netherlands, there has been an interesting incident where two Apaches flew through a power line spanning a major river. The results were quite the opposite from the BS: Powerlines were cut, tens of thousands of people were cut off from electricity for several days and the Apaches made it back to base with barely a scratch...!!

^ I second those suggestions. Great program +1 ! I'll be using it for sure. However, I also get the runway heading crash. Perhaps simply make it a 3 digit heading field? The program hangs when I try to enter the second digit into the runway field. This is independent of any other data in other fields. Hope that helps.

Sorry to bother you, but that seemed a little too fast. The RWR symbol 11 should be with the third vehicle on that page, i.e. 9A310M1 "Buk" (SA-11), and the SD symbol was actually already correctly assigned to the snowdrift radar Buk TAR 9S18M1 Kupol. So: SA-11 9S470 CP >>>>>>>>>> nothing Buk TAR 9S18M1 Kupol >>>>>> SD 9A310M1 "Buk" (SA-11) >>>>> 11 ;)

Standing by for edit :), with printing that is. EDIT: beat me, thanks man that's fast! rep inbound.