All Activity

It does. But ... you have to understand how a tape player worked/works. The B-Side is only playable after the A-Side is at the end, or you would have to switch sides and rewind the whole tape (or fast forward the A-Side). Try this: Listen to one track on the A-Side, then press STOP, then press SWITCH SIDE and then press PLAY. You _should_ hear the last track of the B-Side (if there are 10 tracks on your B-Side). Let me assure you, it works. I did it with my Tomcat as well.

Same thing for me, CTD as soon as George WASed missiles.

Three. I use two myself: 2_4 and 2_5. The ones closest to the primary X16 slot are Gen5 but using those makes the primary PCIe drop to x8, so basically the board supports Gen 5 NVMe in theory only. But then again, why would you want one? It’s a lot more expensive and in daily use you won’t notice the difference - unless you’re a content creator who moves massive files around all the time.

Thank you and the team for the quick revert! Unfortunately, that leaves the DCS client and server vulnerable to arbitrary code execution via maliciously crafted mission files. I believe a temporary mitigation should be applied until a more permanent solution has been found. The net.dostring_in() wrapper I suggested above limits the availability of net.dostring_in() from within mission scripting to the "mission" Lua state. I presume that is the primary use of net.dostring_in() to access the a_*() functions from mission scripts. IIRC, there are mission scripts out there that use net.dostring_in("gui", ...) to change/restart missions via the F10 menu. These would be collateral damage of that fix. Please do chime in if anyone has any concerns regarding that mitigation approach. As the dedicated server is also vulnerable, a suitable configuration method for both client and server (no GUI) should be found. Suggestion for a Permanent Fix IMHO, restricting net.dostring_in() use would be a too radical change in terms of API breakage. Given an option to bypass these restrictions, there will always be countless videos and posts suggesting to enable the bypass. I know quite a few people who simply remove the sanitization from MissionScripting.lua without understanding the security implications of that action. Instead, this should be fixed at the root of the vulnerability, most importantly io.open(), os.execute(), and similar functions in the io, lfs, os modules. Arbitrary read/write file system access and executing arbitrary commands are trivially exploitable vulnerabilities. File system read access should be restricted to the relevant DCS directories, i.e., lfs.currentdir(), lfs.tempdir(), and lfs.writedir(). Write permissions should be restricted even further to prevent shenanigans like changing configuration files (fundamental flaw of the now revoked security option). This is similar to what @cfrag suggested. Mods that require deeper file system access could accomplish that thru a self-compiled Lua .dll module.

J and K both harm the spotting dots considerably with DLSS enabled. Particularly as those dots fly in front of cloud cover, as DLSS doesn't like that contrast at all. With just DLAA enabled, the impact isn't anywhere near as severe. Rolling back to the older non-transformer presets (C or F iirc) will also help the dots appear a bit better, but with obvious visual tradeoffs. Ultimately ED should give us the option to disable DLSS/DLAA from running on the spotting dots altogether, in the same way they have the MFD's. That's the only real 'fix' for this one. In the meantime, try settling for just DLAA. If that's still too negative an impact, go back to MSAA.

We have fixed this issue as described below. Take into account that this will only be available in a forthcoming DCS update: Cockpit livery selection was added to the module options. It returns the ability to use custom cockpit liveries. In particular the "Mirage F1 English Cockpit CE and EE version" user mod. Note that the mod contents should be modified by renaming 'default' folders to 'english'.

Indeed it is - thanks Kurdes!

In any case we will know more and better when first motor case appears, when we see on it specific marks which will give answers. This is actually nothing new, more then 20 years is how much this motor is in connection with multy impulse concept

I also have this bug. I've got performance issues with the F4u after latest update too. Very choppy particularly in flyby view. No issues with other modules, I've got a pretty decent system too.

I agree, the company is very interesting and conveys the atmosphere. There's only one problem for me. I don't always understand what needs to be done. For example, the word "saddle" in Russian is used only in relation to a horse. The word "join" would be clearer. For example, "join from the right 1-5 miles away." Option "saddle on the right 1-5 miles away") Perhaps this is the cowboy slang of the US Air Force.

Nice one! Not got round to it yet untill I begin the build but how many M.2 could I populate before PCI Slot 1'# drops its speed?

Reproduced in a short track. Issue reported.

We've just reproduced this

Hello! Thanks for your feedback. Half a year ago, one of the players had a similar problem. It is related to the Apache module. After the hotfix, these crashes stopped. The problem was in communication with the AI George, as far as I remember. I will test the mission, but I think this is the same bug that came back again. Just in case, I advise you to perform a slow check of the DCS files, remove all third-party unlicensed mods, and check the mission again. Also, the log file will help us understand what could have caused the crash.

I thought it will be perfectly clear, anyway, red curve is case if second impulse would be started immediately after first one is finished. Green curve is case if second impulse would be started in 25th second and of course blue curve is with started second impulse in 45th second. One more realistic situation, levelled flight at 10km and starting velocity 500m/s First and second impulses one after another, something like dual thrust motor...and case if second impulse would be started when velocity drop to approximately 1M Combined cases -> Obviously dual impulse is with intention to make rocket with more potential in time when it counts the most, in time when target suppose to be hunted. Fact is that such concept, I think in most cases, gives shorter range and rocket is less agile considering total flight time, but when it matters then such rocket is with potential

That makes sense, perfectly understandable. I will wait for more of the good stuff then

thank you we will check

I've never made fun with @MA_VMF !!! Actually I apprciate his work a lot

thread merged this is reported thanks

Indeed, the icons have disappeared from this file. I really own these planes But I did not make a copy of this file. I lost the icons of my AV8B and my M2000. Thank you Christian

I doubt it but what would be the purpose? It's still one file editing. Maybe you don't want to touch the game files but \saved games\dcs folder is fine? Since every update will revert the changes to the CommandDialogPanel.lua you should have a local copy of both original file and modded one. Then you could run a batch file (one for each) to copy one of them into game files and run DCS. Just an idea.

Да. На сайте доступно здесь.

I'm an older gamer NOT a jet pilot with 20/20 vision. We require a sensible balance between supposed reality and best guess with a bit of artistic licence. Don't be nurfing anything.

If using a FMU-139, 143, or 152 and no fuze in the nose (plugged), keeping it on NSTL is fine as you need the NOSE option in order to have the center solenoid hold the arming loop on the initiator which activates those fuzes. You could select the NOSE only, as the initiator is the only loop since those are electrical fuzes (will double check my work notes but 99% sure you can do that). Mechanical fuzes like the M905 requires the TAIL option as the loop for that goes into the tail solenoid on the MAU-12. Default MK82s in DCS usually always come with both nose and tail fuzes (M904 and M905) so NSTL should've activated the fuses. If you can, can you please post a track. I did have a GBU-10 appear to DUD on me as well the other day, but didn't think too much of it as I was focused on something else.

This. Preset J is superior to K when it comes to image quality, at the cost of some ghosting (depending on the background of the specific scene), but I don’t know it that counts for spotting dots too as I don’t use K. I have been using 2 pixels instead of Auto since the changes to spotting dots were implemented for that exact reason: to work with DLSS.