All Activity

I think I can send those files to you Arcc? Is that okay @BIGNEWY? (because of rights of those files)

I understand your Point but this is not my opion. Its a simulation. I find it hard to tune things up to compensate anything. But think the zoom option is your way to go. IRL the pod would not be so bad, that anybody can't see a target in the mfd. But it is not cystal clear when you have digital zoomed in max.

Similar idea to the brake problem. ..

Same here, one click will release all four MK-82 Bombs at once which is very weird. All the Bombs are located on pylon #2, #3, #5 & #6. To me this is a programming error / Bug. ED should enable single activation for each of the weapon station switches (#2, #3, #5 & #6). Then It will be up to the player to enable how many bombs he/she need for one click (it can be one, two, three or even all four). It's almost 1 year since the first post. Quite frustrated with this new F-5E FC. Hope ED will take action ASAP.

Yep just gotta hope it arrives in a somewhat timely manner. Some of the assets in DCS (trees in particular were really bad for shimmer) just really benefit from anti-aliasing. It's particlarly bad in VR, where the jaggies are extremely in your face and you have to pump the resolution to absurd numbers to get past it. Or you just enable DLAA and take the tradeoffs. It doesn't help that MSAA has never worked particularly well in DCS in my experience either, some have said it's due to the switch they made from forward rendering to deferred.

Agree！Agree！

I just don't understand why anti aliasing should be necessary if the screen resolution is high enough to not see a single pixel. Anti aliasing was introduced at a time when screen resolutions were much lower than today and single pixels were large enough to cause a jagging effect for non perpendicular lines. Nowadys I simply switch of anti aliasing completely for the sake of sharper contours and higher fps rates.

That definitely seems to be the way forward. At least ED have indicated they are not done yet with spotting dots so there’s hope for future improvement.

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.

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 in terms of a sandboxed 'writeString()' method. Mods that require deeper file system access could accomplish that thru a self-compiled Lua .dll module (and take responsibility for whatever vulnerabilites that results in). Access to os.execute() should probably be prohibited unless explicitly enabled. Not sure how to do that securely. The only way I've seen it used is by the SRS scripts to launch the SRS client when connecting to an SRS-enabled server. As above, I'd appreciate feedback on whether any mission/mod makers believe it would break their content. @BIGNEWY Are you and the team interested in concrete implementation suggestions from the community? If so, we could discuss sth. here. If not, I'll save myself the effort.

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