riojax

Meanwhile is fixed i did a hack to use them: https://www.digitalcombatsimulator.com/en/files/3302948/

When you view to backwards it is possible to get the view out of the canopy using normal FOVs.

Is it possible to add the Soviet liveries to CCCP? Thanks on advance.

I think that you are talking about this bug report: https://forums.eagle.ru/showthread.php?t=226581 This bug report is about the console, inst. and flood lights. Sorry on advance if i'm wrong on my assumptions.

The first file show the flickering only when the maverick camera is on. The second is anytime but in other global light conditions. F18_flicker.trk F18_flicker2.trk

The issue is still present in the update 2.5.2.20036.

Any news on this matter?

Ok, those two tracks was recorded on 2.5.2.19682@openbeta after a full dcs_updater.exe update and repair. Also i will update the original post with recorded videos. The file 18-rdr2.trk is the most complete. 18-rdr1.trk is shorter but the idea is to show the same once restarted DCS. Video 18-rdr2 link: https://streamable.com/ry7hk Video 18-rdr1 link: https://streamable.com/rafgb 18-rdr2.trk 18-rdr1.trk

This track was recorded the same day that i published the original post, anyway if you want a new one, no problem, i will make a new one with the latest OB version. P.S. For the next time maybe is better to say that before than simply label it as "not a bug". Making the original post took me a lot time.

Maybe this is related to this one: https://forums.eagle.ru/showthread.php?t=216195

Still present in the latest hotfix.

Yep, for me also in this case the "not a bug" is a bold assertion.

I'm pretty sure that it takes around 0.5s to lock, also i'm checking the video (thanks a lot for this interesting footage) and it seems to take around 0.5s (like 0.2 to 0.8s) for example: 6:17, 6:42 and 6:55 The last one (6:55) is very interesting, because it's almost the same than my test on 0:29 or 4:20 About to the 2s lock, i did see it only when it's a close formation group and the match speed is similar like in the 7:13 of the footage (doppler issue) but this is uncommon. Also thank you a lot for your post, as usual are pure gold.

[REPORTED] RWS radar stabilization and tracking loss Hello, I'd testing the current RWS and the locking time must to be around 0.5s using the 6 bars, at now it's like 3s to 4s. I only found an APG-68 public video, but the 65/73 performs almost the same on locking time: Also i'd found some radar problems, the numbers are the old video time to see it: When you change the rotation direction -> 0:10 High G drift with high angle -> 0:29, 4:20 Problems with the radar locking and cursor move -> 0:53 Fast rotation at very low speed -> 1:26 Fast rotation at high elevation angle -> 1:42 Fast rotation at level -> 5:14 Slow rotation when the contact is far from the center in azimuth -> 2:45, 3:10, 4:01 and 4:41 No memory follow while locking -> 4:36 Update: Still present in 2.5.2.19682@openbeta. Video 2 link: https://streamable.com/ry7hk Video 1 link: https://streamable.com/rafgb Tracks attached: in post #22 Old video: Video link: https://streamable.com/i8b1l Track attached: 18-radar_track1.trk Thank you ED a lot for this module :) Regards. 18-radar_track1.trk

A dedicated server for linux will be a great boost for the current MP. This for sure. I really hope to see it.

Correct. I tested a bit the MP issues, and for example, it seems to load a lot objects (and data) from the server, in a lot of very small packets. Also if you loose packets the server-client sync can be problematic (in loading and also playing). I can recommend to check the connection and use always a wired network because wifi almost always loose packets (and adds some noticiable latency). For me a thumb rule is: more latency = exponential load times. Also is remarkable the VERY high VRAM usage at now, and for this is very important to have less pre-radius range. The VRAM is limited and the RAM is a lot slower, when you haven't VRAM the system uses RAM for graphics, and this is slow. Other issues is when a player enters in the server, this will lag to all players and also the current high resource consumtion for objects. A mission with a lot objects will be very hard to the server and the clients (on load times and running fps). Anyway, DCS 2.5 is improving a lot and very fast, i'm sure that those problems are known and ED are doing their best work to fix it and also creating new content.

I updated the post with new data using the latest OB.

I was making a new mission, only with the Stenis, a client F-18 and the Tarawa, when i started the mission i did see an huge fps drop (the half that i usually have, this is around -40fps) Later i discovered that this is only when the Tarawa is into the view. For example, out view: https://image.ibb.co/gmkAC8/Screen_180621_205415.png Into view: https://image.ibb.co/h7mp5T/Screen_180621_205429.png Trying to find the real culprit, i swapped the Tarawa for a Carl Vinson, no FPS drop. Out view: https://image.ibb.co/nn5ozo/Screen_180621_205617.png Into view: https://image.ibb.co/nkY8zo/Screen_180621_205625.png I know that the Tarawa is WIP, but maybe this problem is related to a high poly, a texture error or the smoke, and this can be pesky to fix once the model is finished. P.S. Tested on the 2.5.2 Update 5 Thank you on advance!

Testing the CCRP and CCIP modes i did found that the CCRP mode is too inaccurate, this bug report seems to be related: https://forums.eagle.ru/showthread.php?t=210460&highlight=ccrp The CCIP mode works like a charm, with a pretty realistic error. The test was without wind, turbulences, etc. with the TGT point in the exact coordinate of the white tire and with the plane started in mid-air (perfectly aligned), also differents altitudes was tested and always seems to have a similar error. The track is attached. Maybe the error is related to the waypoint/possition or the INS system, but the target diamond appears to be in the correct place. Thank you on advance! 18-ccrp_ccip.trk

Yep, Oculus banned a lot methods to tune the displays, for example, the NVidia control panel, and yes, it's lame policy. About the washed, and more blabla, when you have the monitor well calibrated (using 2.1 or 2.2 for gamma value), all is perfect. No washed colors, too much saturation, etc. I recommend you invest 15 minutes to calibrate the monitor and test the 2.1 or 2.2 gamma setting ingame. P.S: Anyway, the current hud tint is too dark and the sopebird textures are a lot better/realistic.

No, the default gamma for consumer monitors is 2.1 or 2.2 I recommend you to calibrate your monitor for the standard gamma of 2.1 for low end. If you don't have a calibrator and don't want to have one, you can do it using the MK1 Eyeball and webpages like this: http://www.lagom.nl/lcd-test/ Don't forget to have very well calibrated the Black level and the Saturation (white and colors) this is the most common problem in consumers monitors. Also the gamma in DCS must to be 2.1 if your monitor is well calibrated for this gamma. About the VR, this is the same, you must to calibrate it like a monitor.

This is awesome, a lot better than the current texture. For me it's almost perfect (ED please, use this texture) Thank you a lot! :)

Thank you :)

These are videos from reals F/A-18A and C using the radar. At first we will analyze the lock time (seconds) on real dogfights using different ACM modes. REAL LIFE F/A-18 vs F-5 (ACM) Video link: GACQ: 0:46 - 0:48 -> 3.0s lock time REAL LIFE RAAF F/A-18A vs F/A-18A (ACM) Video link: GACQ: 0:17 - 0:20 -> 4.0s lock time BST: 0:25 - 0:25 -> 0.3s GACQ: 0:50 - 0:52 -> 2.5s GACQ: 1:15 - 1:17 -> 2.5s (VERY HIGH G's) VACQ: 4:29 - 4:30 -> 0.5s GACQ: 8:23 - 8:24 -> 2.0s GACQ: 8:54 - 8:56 -> 2.0s The lock time is variable in the real life because you have different probabilities of have the antenna in the correct position to lock the target. Also the RCS of the F-5 and the F-18 differs. But we can get these times for some ACM modes: GACQ: from 2s to 4s. (from 2s to 2.5s is the usual) VACQ: arround 0.5s BST: arround 0.3s These are similar dogfights using those ACM modes in the current DCS 2.5 Open Beta. DCS F/A-18C vs F/A-18C (ACM) (current EA state) Video link: https://streamable.com/xsjb1 Track attached: 18v18-dog2.trk Unusual lock times: GACQ 0:17 - 0:27 (10s) VACQ 0:52 - 0:58 (6s) Usual lock times: GACQ 0:28 - 0:31 (3s) GACQ 0:32 - 0:36 (4s) GACQ 0:38 - 0:40 (2s) VACQ 0:59 - 1:01 (3s) VACQ 1:04 - 1:05 (1s) VACQ 1:05 - 1:08 (3s) VACQ 1:13 - 1:15 (2s) VACQ 1:15 - 1:19 (3s) BST 1:23 - 1:24 (0.5s) BST 1:26 - 1:26 (0.5s) GUN 1:53 - 1:57 (5s) GUN 2:19 - 2:22 (3s) * As you can see, the VACQ lock times are very high, it must be around 0.5s, on the other hand the GACQ, BST and GUN modes seems ok. Great job ED! * Also is remarkable two strange locks marked as "unusual lock times". EDIT: The next text is outdated and it's only stored as a history archive. DCS F/A-18C vs F-5E (ACM) (old EA state) Video link: https://streamable.com/s9wv7 Track attached: 18v5-dog1.trk * All modes are too unreliable and it's almost impossible to get good timings. DCS F/A-18C vs F/A-18C (ACM) (old EA state) Video link: https://streamable.com/jx3vn Track attached: 18v18-dog1.trk * All modes are too unreliable and it's almost impossible to get good timings. (I didn't found a real video for the WACQ mode, but also seesm to be unreliable) At first i'd think that the problem can be the antenna movement speed, but if we compare the real bar scan movement with the DCS simulated it's almost the same. REAL LIFE F/A-18C (RWS) Video link: The full 140º bar scan takes 3s DCS F/A-18C (RWS) (old EA state) Video link: https://streamable.com/yqwhw The full 140º bar scan takes 3s (Also the AACQ RWS mode didn't work for me, probably it's WIP.) Later i tested the RWS scan reliability on DCS and the result was a lot of contact loses and very strange behaviours, for example, when you change from ACM to RWS the radar works and at few seconds seems to be blanked, also i tested if the problems are related to only OPR or STBY modes, and it seems the same. Video link: https://streamable.com/nmeqs Track attached: 18-rws1.trk Maybe the ACM lock unreability and the RWS contact loss are related (too low sensibility maybe?) P.S. Thank you ED for this module, it's awesome! 18v18-dog1.trk 18v5-dog1.trk 18-rws1.trk 18v18-dog2.trk