Bacab

Hello everyone, I noticed that I had a very hard time dealing any kind of damage to even unarmoured targets using the Mk 20 Rockeye. So I did a test mission with ideal conditions and tried to destroy some trucks with the Mk 20, to no avail. Here are two of my attempts (see attached tracks). Graphically speaking it seems at least one truck should be destroyed in both case but no "hit" event is even logged by DCS. Could someone have a look ? It seems a lot of cluster bombs are not working correctly currently but I failed to find a report specific to the Mk 20 so here it is. I apologise if this bug has been previously reported. Thank you in advance. Mk20_bug.trk Mk20_bug_2.trk

Technically any RF sensor using Doppler processing to discriminate signals of interests among ground clutter is susceptible to a beam manoeuvre performed by its target (albeit at low altitude and in look down). In this regard the Sparrow is not different. This being said I do not know the particularity of this seeker, I only answer from a general perspective about radar seeker.

I am doing the Caucasus campaign and I like it very much so far. I have just done mission 5 ("The traitor") and have a few questions : Thank you in advance for your answer.

Thank you for your answer. Indeed the F10 map says that 109.1 is the ILS for runway 13 I didn't choose Al Dhafra, that's the airport for which the included Instant action mission was done for so it was the easiest to practice ILS landings. Guess I'll have to do my own mission. EDIT: Since I became aware that the ILS on the airfield could be the culprit I had a look at the Caucasus bug list and guess what, the Vaziani airfield (for which the campaign mission is done) regularly pops up has having a bad ILS too. So I basically tested the system on two airfields, find it not to work on two airfields, field in a bug report because I thought if it's not working on two airfields then there is a bug in the aircraft, to finally conclude that indeed I chose two buggy airfield to learn to use the ILS... Grrr

Yesterday I tried the 3rd mission of the M2000 campaign and didn't managed to get the ILS to work so today I tried another mission (Persian Gulf, night landing) and it didn't work either (for what it's worth the synthetic runway didn't work better): none of the ILS symbols (box, lines...) were displayed on the HUD nor on the HSI. They only appeared once I had landed (pretty useless at this point). A track is available attached to this post. I have the correct frequency for the ILS and it was set to On, the PCA shows APP selected and the waypoint 2 was chosen (Al Dhafra runway 13) with correct true heading and slope, as you can see in the track. If I am doing something wrong please tell me, otherwise can someone have a look at this ? Thank you in advance Track recorded on DCS 2.9.0.47168 Open Beta ILS_notworking.trk

I have the same issue.

@Flappie IRL the faster, the better for GBU (within launch parameters). The added speed gives the bomb energy to make more important course correction, especially at the end. Actually several -34 manual state an optimal GS of 500 kts at release for the optimal precision.

To my knowledge SAMP stopped manufacturing bombs (more precisely bombs' body, the filling was done by an other company) because there were not enough orders from the French government. So it was more logical from an economic perspective to source bombs from a foreign supplier. And the French government wasn't very logical either if I remember correctly : at one point the SAMP factory received help from the government to (re)establish a bomb production line but after the first batch of production there was no subsequent order (I think to recall that there was an order but with such volume and short planned delivery that only a US supplier could do it). Nowadays SAMP resumed the production of bombs (I think) but they no longer use their own design : they license build Mk-8X. I believe this has to do with ease of integration onto the plane : the ballistic was not the same between Mk-8X and their proprietary design so the plane manufacturer had to integrate both designs, one for the French with SAMP ballistic and one for foreign customer, usually with Mk-8X ballistic. For a more related to the topic consideration : I think to recall that old SAMP bombs usually had a different weight distribution than the Mk-8X bombs. The casing was lighter and there were more explosives inside, hence maybe the damage difference ingame (even if it might be exaggerated). I am looking for a source to back up my defective memory. None found in my archive however I have found several websites claiming 123 kg of explosives for the SAMP 250 (50% of the mass are explosives) instead of 89 kg for the Mk-82 (35%). I don't know how much blast 30 kg of explosives add but it would be difficult to balance due to the rudimentary damage model in DCS : on one hand more explosive means a stronger blast/a greater blast radius, on the other hand the lighter casing may imply smaller, lighter fragments that travel less and less initial penetration before the bomb body breaks so smaller cratering effects perhaps. Reason for edits : I add details as I found them online.

Having the TGP in either AREA TRACK (Litening) or SCENE (ATFLIR) mode should be enough : you shouldn't need to press the TDC to designate. However if you are in SCENE mode with the Litening then you definitely need to press the TDC in order to designate the reticule (if you prefer this name) as you target point. At least this is what I've experienced but I would like to be sure, hence why I opened this topic. This is the main difference between the two pods in my opinion : the SCENE mode with the Litening you have to depress the TDC to designate while it's not necessary with the ATFLIR in SCENE mode. Currently the SCENE mode and the AREA Track mode of the Litening both behaves similarly except for the inability to move the reticule in AREA TRACK. I'm not sure that's correct IRL : I assume the SCENE mode of the Litening is a ground stabilized INR mode however it seems a bit too insensible to drift (in DCS) if that's the case. Currently it's not working this way : I tried unchecking and checking the realistic TDC slew option but it didn't change its behaviour while using the TGP. It did change its behaviour when the TDC is allocated to the radar though. Maybe I'm wrong and I'm unwilling to test it now because it's a bit late but that's not always correct I think : if you undesignate once while in SCENE mode with the ATFLIR then the pod revert to INR and the cursor is no longer ground stabilised. The diamond is visible with the Litening pod if both the reticule and the target point are at the same spot in SCENE mode. With the ATFLIR it's visible in SCENE mode when the pod has not yet locked the picture and in Designation mode. Currently I have been unable to see the offset cursor : It might have been removed following the controversy about it's real world function VS the way it worked in DCS.

I'm fairly confident that's not how it work actually in DCS (Open Beta up to date 22/01/2022).

Actually this is a very good question. Because having the beam above the horizon is no guaranty there won't be any clutter IRL : their could be a mountain above the flying aircraft, returns from heavy cloud, ground returns from side lobes... And the radar has no mean to know if those conditions are met beforehand. If the ground clutter filter is removed while looking up, it means that in search modes it might be difficult to keep the false alarm rate under control and in track mode removing it might not be enough to keep the track. Keep in mind that the radar of the F-18 in A/A is only using range ambiguous waveform so even if there is a tremendous amount of distance separation in the physical world, in the ambiguous domain, clutter can still be in the same range cell as the useful signal. In DCS I'm under the impression that all radars deactivate the ground clutter filter when looking up since false alarm rate is not really represented anyway (except maybe in the M2000 after the recent upgrade) but is it really the case IRL ? (I don't really know though if that's public available knowledge, maybe it's part of ED generic radar behaviour because there is no better info available).

Hi everyone, I have been looking in the manual and in several Youtube tutorials however I have not found a detailed explanation on how the target point logic works in relation to the TGP. Here is what I understood : (assuming you have designated a waypoint and assigned HOTAS control to the TGP) LITENING II : LOS on the designated waypoint, TGP in SCENE mode. Moving the LOS with the TDC does not change the target point until you have done a TDC depress (reticule changes to a diamond). If you move again the TDC (the reticule revert to a cross) you'll again need to do a TDC depress to move the target point to the LOS. If you initiate tracking in either AREA TRACK or POINT mode, it will automatically move the target point to the LOS. TDC depress will allow you to move the Offset cursor. ATFLIR : LOS on the designated waypoint, TGP in DESIGNATION mode. You can't change the LOS with the TDC until you have done a TDC depress. Once it's done you can slew the LOS and the target point will follow no matter if the TGP is in INR, SCENE or AUTO mode. Is that correct ? If not, could you share how you understood it ? Thank you for your help.

I'm trying to figure out how the sight is supposed to work and I stumbled upon this thread. Even with the picture uploaded by finger I am not sure of what's going on : - I thought the Missile/Gyro switch only changed the axis of motion of the piper (Gyro = two axis, Missile = only vertical axis). However when I look at finger's picture I understand that vertical depression is never computed (not even to account for ballistic drop ?) in air to air when the switch is in the missile position, except in manual & gun mode. Is this the correct way to read the picture ? - When distance is written as D=400-600, does it mean the pilot can choose the distance manually with the twisting grip ? - The target span can be entered by using the red window in all mode except in the fixed 300 m mode, then it is red on the B&W scale, correct ? Thank you in advance for your answers.

Hi everyone, I have built a "pocket" instrument panel using x27.168 steppers, an oled screen and two arduinos (UnoR3 & Pro mini 5V) linked through I2C. Since I only want some basic data, I chose to use the common data plugin. I tested it in the P-47 (no luck) and in the F-5 (it kinda work). It seems like most of the time the instruments are showing the correct value however they regularly displays completely incorrect values. I can't see anything weird when I check the values in DCS bios web interface so it could be my programming on the arduino's end. However I find it odd that as soon as I press the pause button all the instruments that were showing abnormal values go back to displaying correct data. Do you have any idea of what may cause with this kind of behaviour ? Thanks for the help. EDIT : It's working now ! The issue was a dynamic allocation in my code that was not freed and only occurred when the altitude was changing, hence why It worked when the game was paused.

Hi, As said in the title, in the "Rhubarb radar raid - Wels site" mission, the AI wingman systematically crash into my plane or into an other AI while taxiing. Moreover your wingmen try to take off as soon as possible, not waiting for you and then announce they are RTB as soon as they are in flight. Currently I have been able to complete the mission once by modifying it so the player's group is immortal while on the ground and by preventing the AI from taxiing before me by racing them so I can take off first. I'm playing the OB v 2.7.2.8165 I can't post a track file since, while only a few minutes long (due to the unskippable briefing), it already weights more than the 5 MB limit. Instead I have attached three tacview tracks Here are several screenshot of the issue in action: Tacview-20210626-140710-DCS-P47D-RRR-CHANNEL.zip.acmi Tacview-20210626-140131-DCS-P47D-RRR-CHANNEL.zip.acmi Tacview-20210626-100024-DCS-P47D-RRR-CHANNEL.zip.acmi

Hi, I tried to do the Yarwork mission for the P-47 on the Channel map twice and each time I had a CTD while approaching the coast south of Boulogne. I have been looking at the log and the error seems to be : 2021-04-18 07:40:16.949 ERROR GRAPHICSVISTA: Can't open model wheat_green. 2021-04-18 07:40:16.949 ERROR EDTERRAINGRAPHICS41: model "wheat_green" not found Here is the zip file containing the dxdiag data and the crash log : dcs.log-20210418-074048.zip Thank you in advance for your answer

Hi, I am having issues with the ME that seems to be specific to my installation. However I'm unable to find their origin and I would like some help. When I open a mission and select certain flights, I can't see all the flight's controls, there is a grey box instead : If I had an other flight previously selected it shows the controls but the load out page and the preview is the one of the previously selected unit: I tried running a DCS cleanup and repair but it didn't solve the issue. The issue appears both in Opend Beta and in the stable release. I do not use mods but I do use third party softwares : Tacview and SRS. Here is the dcs.log file. It seems to run into an issue with the GUI but I don't know what to do with that info. dcs.log Thank you in advance for your help.

Hi everyone, I have noticed while trying to set up a supersonic interception of a group of Tu-22M3 in the ME that the group does not respect the speed it was assigned in the ME. The instantaneous speed is not the one set in the ME (and in the trk attached even the average speed is incorrect). Sometime one airplane is going faster and sometime it slows down (in the trk attached the 3rd plane is the one whose speed is constantly changing). I've seen this with the GS being locked but also if I try to lock the ETA (with GS unlock). Is this the intended behaviour ? I thank you in advance for your answers. Trk : Tu-22M3_fix_GS_bug.trk Miz : CA-Formation_test.miz ACMI : Tacview-20210108-215356-DCS-CA-Formation_test.zip.acmi I just had the idea of testing this exact same mission with exactly the same parameters but with only one airplane in the group and everything work has intended. Trk : single_Tu-22M3_speed_test.trk Miz : CA-Tu-22M3_speed_test.miz ACMI : Tacview-20210108-220515-DCS-CA-Tu-22M3_speed_test.zip.acmi

Hi, I encountered some weird behaviour while flying the Hornet : I'm in RWS with LTWS boxed. I put the TDC over a "brick" and designate it. Then, with the TDC still over the trackfile, I command an AACQ: As you can see the TDC is over the target but the B-sweep line "jumps" to a far away target during the acquisition process. Then I find myself with the wrong target locked : The track corresponding to those screenshot is attached. I have been able to reproduce the bug several times. The mission I used is "Ode to Mongo". The track was made with DCS World Open Beta v2.5.6.52437. Thank you in advance for your answer. AACQ_bug_F18.trk

This is exactly why I asked the question: just to learn more about the plane, indeed you don't need it to fly but it's always good to know how things are done. I thank everyone for their replies even if the question has not been answered.

Hi, While flying the Harrier I was intrigued by the fact that, though I kept my aircraft aligned with the "commanded heading marker" on the HUD (which is called the bug I think), I was still drifting away from the waypoint. Here I made a mission with 60 kts wind and you can see the "bug" is directing me to the geographic heading of the waypoint and I have to compensate the drift so my ground-track stays in line with the waypoint heading to actually fly toward it. I am pretty sure the "bug" should be drift corrected so I think this is an issue, am I correct ? Thank you in advance for your answer.

Hi, I'm currently learning how to fly the F-5E and I would like to know (out of curiosity) what is the link between the AOA units displayed by the AOA indicator and the real AOA in degrees. Thank you very much for you help.

Just did it. I have missed the "bonus target" since I did not try to refuel but otherwise destroyed the enemy HQ and got home safely. The SEAD component of the flight was useless but the blame is on the AI which jettisoned its AGM-122 when engaged and was subsequently killed. I went for a very low (200 ft) and fast (450 kts GS) level pass. After viewing the briefing it seems I did not load the snakeyes I wanted for this mission and therefore I was lucky DCS do not take into account fuze arming delays otherwise it would have all been for nothing. The Igla shot and missed but the Tunguska shot down my (remaining) wingman (AI is terrible, it didn't use chaffs or even tried an evasive manoeuvrer). I wonder if the EW escort was useful. I agree with those that said the default loadout behave weirdly. I had a very hard time taking off with it because of the yaw it induced.

Depending on the missile seeker it may need a specific waveform to guide (for instance the seeker may rely on CW illumination of its target). Upon detection of this waveform the RWR will issue a launch warning. I was explained that's how the launch warning work in the F-16 for instance. If the missile home without requiring a specific waveform then you should'nt have a launch warning, you'll only know that you are locked. However if the RWR detects a missile emiter then it will display this emitter (likely as the most urgent threat to deal with). More elaborate logic might be used than this simple one but that's a good start to begin to understand RWR. An other way to detect a missile launch is through a dedicated device that monitor the IR signature of rocket engine. (the mirage in dcs has this feature). However I read somewhere that those where prone to high false alarm rate and therefor not as useful as they might be. Envoyé de mon G8441 en utilisant Tapatalk

I don't want to diminish his work but I'm quite sure he is wrong on this one. If you read the discussion on the subject on acig you'll see there is no definitive proof of that anywhere. Envoyé de mon G8441 en utilisant Tapatalk