Bestandskraft

I just reproduced this issue on a private (non-dedicated) and a public (dedicated) server. The following seems to be true (tried various times): Whenever the Pilot clicks "Fly" first, the RIO will have the correct mission pressure automatically set. Whenever the RIO clicks "Fly" first, the RIO will instead have 29.92 initially set, regardless of mission pressure. These were all starts from "parking lot" (with engines running).

I just successfully reproduced this issue on a public server. Also, I noticed that contrary to my initial post, the discrepancy between the pilot's and the RIO's wind direction equals the magnetic variation of the theater. For example: Nevada: Pilot's wind direction 036, RIO's wind direction 048 Caucasus: Pilot's wind direction 089, RIO's wind direction 095 This leads me to conclude that 1) This is not necessarily an host-client issue. 2) This may instead be related to the magnetic variation being applied to wind direction in the pilot's cockpit, but not in the RIO's, or vice versa.

Indeed I was the host and client simultaneously. I will be able to reproduce this on a dedicated server only in about 2 weeks; if in that case I witness the same error I'll report again.

Perfect, thanks guys!

IAW pp. 259-260 of the game manual, "The WCS also performs additional computations so that the crew is provided with […] time-to-go to a selected destination point". I have not seen a time-to-go indication to the current destination point anywhere in the jet. Could anyone please point me to that indication?

I was the pilot and host, the RIO was the client.

In a simple multiplayer mission I created, the wind direction indicated on the pilot's ECMD differed from the wind direction indicated on the RIO's ECMD by 15 degrees (NEVADA). The wind speed, as well as TAS and GS were identical in both cockpits. I have not tested whether this also occurs in SP.

When entering an MP mission that has a QNH different from standard (29.92), the altimeter is initially automatically set to the actual QHN for the pilot, but not for the RIO, in which case it is initially set to standard pressure. I have not tested whether this is also the case in SP.

The groundspeed indication both on the ECMD and the TID does not take into account the aircraft's pitch. For example, in a no wind situation, with 90° positive or negative pitch (disregarding AoA), your groundspeed should be zero. In the game, in this example, the groundspeed instead equals true airspeed. While I have found no information in the RL or game manuals on how the actual aircraft calculates and displays groundspeed, the behaviour described above seems counterintuitive.

I have thought about the problem and the available evidence again and I think the issue might be a wrong implementation of the DYK mode itself. Unfortunately the pages describing DYK mode in the declassified Viggen flight Manual (M5800-370011 Del 2) are incomplete and I cannot read Swedish, so what follows is informed conjecture based on the phrase "Bomb are released when the release Parameters are fulfilled on the target marked when the trigger is pulled" on page 301 of the game manual, the phrase "Computer will release bombs on the designated target when the trigger was pulsed" on page 303, the provided HUD pictures and my understanding of conventional bombing in general. I believe that at step 5 on page 302, the radar locks onto the target. At this time, the trigger may be pressed at any time which will cause the target location to be entered into the CK and the HUD picture will jump to step 9, but the bombs will not yet be released. Instead, the pilot needs to follow the steering cue in order to bring the aircraft onto the proper delivery wire. Once the CK determines the required bomb range is reached, bombs will be released automatically provided the trigger is still held. If the pilot does not follow the (upwards) steering command, the aim-off angle will be too small, thus the required bomb range will be reached at an insufficient altitude to clear fragmentation or the ground, in which case HUD step 11 will be shown. Steps 7 and 8 only occur prior to the trigger being pressed, and indicate a diminishing range to the target, which if too low means that regardless of pilot maneuvers, the minimum safe altitude will be undershot and/or the bombs will not arm if released.

Please find attached an .acmi recording of the attack and a .kml file for displaying the target. This might help analysing the problem. Place the .kml into C:\ProgramData\Tacview\Data\Static Objects\. DYK bug.zip

Hi Rudel_chw, I have released the bombs one human reaction time after the wings appear, so this cannot be the explanation. Further tests on the same target have revealed the following: With a 36° dive angle and the bombs pickled once the two vertical flashing bars appear (these indicate that I need to break off immediately IAW the manual, i.e. that I have missed my release window), the bombs hit precisely. With a 22° dive angle and the bombs pickled once the two vertical flashing bars appear, the bombs fall significantly long, as one would expect. It might be interesting to note that in my video, the steering cue after bomb release actually appears in the lower part of the HUD (superimposed over the central vertical line), which, IAW the manual, would mean that after bomb release I should push over to bring the aiming cue over the steering cue, thus killing myself. In my test with the 22° dive angle, the steering cue appears at the top of the HUD, which seems logical since following it will result in a normal dive recovery.

Hey guys, I have for the last several hours attempted to attack targets with M/71s in DYK mode. So far, during all my attacks (approximately 20), my bombs have fallen significantly short of the target. My settings: - B1 defined as target (TAKT-IN-9-B1) - Loadout: 8 M/71 low drag - DYK attack mode selected - Target Motion measurement disabled (TAKT-IN-221-LS) - Radar lock on trigger unsafe (TAKT-IN-252-LS) - No wind - QNH 1013 - Temperature 15°C - Target at sea Level - QFE set to 1013 - Release with 490 KTAS @ 3331 ft ASL, 27° dive angle - Airbrakes out It is interesting to note that in Bunyap's DYK tutorial, the exact same problem is visible (note that at 15:50 he is aiming at the center bunker in the farthest row, but both the first bomb and the center of the bomb stick actually impact short of the mark).

Here you go. As far as I can tell, the problem occurs with all bombs and has occurred in all versions of Tacview. Tacview-20171210-123910-DCS-ajshdballisticsoneplane.zip.acmi.zip

In DCS Tacview replays, in all previous versions including the current one, telemetry produces invalid TAS values during the first second of a bomb's lifetime (see attached screenshot). Aside from the "jump" in the TAS value at second 1, a comparison of the actual game in slow-motion and the Tacview replay shows that a bomb dropped in the game comes into existence at precisely the same TAS as the launching aircraft, while in Tacview, the initially displayed TAS of the bomb is significantly lower than the aircraft's TAS. Both problems may be related. Vyrtuoz, is there anything you can do about it or is this an issue with DCS?

There is a problem with Tacview 1.6.1 that can be best seen when opening the attached file in both 1.6.0 and 1.6.1. 1.6.0: 1) Select the FAB-100 as the object of interest. 2) Select "Altitude (ASL)" as Primary Y axis type. 3) Select "Distance (Ground)" as X axis type. 4) Notice how a realistic trajectory is displayed. So far so good. 5) Switch Primary Y axis type to "Distance (Ground)". 6) Notice how the Y axis ground distance is 0 ft until about 6040 ft of X axis ground distance, then suddenly jumps to 16795 ft (the total ground distance travelled). One would expect a function of Y = X to be displayed instead (for every foot of ground distance, the bomb flies one foot of ground distance). 1.6.1: 1) Select the FAB-100 as the object of interest. 2) Select "Altitude (ASL)" as Primary Y axis type. 3) Select "Distance (Ground)" as X axis type. 4) Notice how no trajectory at all is displayed. With other recordings at this point you seemingly randomly do get a trajectory, however when trying to execute step 5) above, again there is no trajectory displayed. Vyrtuoz, if in addition to fixing the above bug you have some time to spare, I would love to see a feature that optionally displays the total ground distance travelled for any projectile independently of a .csv data export, which would facilitate ballistic analyses. Tacview-20170603-223638-DCS-Ballistics.zip

With the AJS-37 released, having an official in-game value based bomb range etc. calculator seems more useful than ever. Any chance of getting one?

OK, it took me over two hours to (partially) figure this out: The door gun mouse control works (for me) under the following conditions: 1) When switching to a door gunner position from the pilot's seat, TrackIR Aiming (RShift+T, no menu option exists) must be ENABLED prior to the switch. After the switch, it must be disabled. If TrackIR Aiming is disabled PRIOR to the switch, moving the gun with the mouse will not work until switching back to the pilot's/copilot's seat and restarting the procedure. 2) When switching to a door gunner position from the copilot's seat, the same is true as for 1), however, the Flexible Sight must not be enabled when switching. If it is, one will not be able to move the gun with the mouse after the switch. For unknown reasons, sometimes the gun will still work even though the Flexible Sight was enabled at the time of the switch, but the only way to make sure it works is to have the Flexible Sight disabled. 3) When switching to a door gunner position from the other door gunner's position, no restrictions apply, provided mouse gun control worked with the gunner being switched from. This is obviously bugged, but knowing the workaround at least allows one to use the door guns normally until a fix is made. By the way, I still cannot move the copilot's gun with the mouse.

Hey guys, I am unable to move the door guns, either with TrackIR or the mouse, even though the mouse is mapped to Gun Left/Right and Gun Up/Down in the UH-1H Gunner tab. I also noticed that the "Camera Aiming ON/OFF" Option is not present in the OPTIONS - SPECIAL - UH-1H menu as advertised in the manual, which may have something to do with my issue. This is both in 1.5.5.59992 and 2.0.4.59428. Any ideas?

@ Malefic Rage: Makes sense, after reading a couple of reviews of the 6700k and the 6800k+ it seems that the 6700k can be overclocked to a higher frequency with a lower temperature much better, even with an AIO water cooling solution which I'm aiming at getting. Thanks.

Does anyone have any experience or speculation as to how 1) the new Broadwell-E CPUs, specifically the 6850k and 6900k, would run DCS, especially compared to the 6700k, with and without overclocking? 2) an ultra-wide resolution of 3440x1440 would affect performance on a GTX 1080, especially compared to 2560x1440? Does anyone have any good/bad experiences with running DCS in 3440x1440 other than performance, e.g. with regard to advantages/disadvantages of a 21:9 aspect ratio?

Frederf, you may wish to report your findings on the public bugtracker, more so since a report about some of the issues detailed in your post already exists (https://leatherneck-sim.mantishub.com/view.php?id=81).

Sorry if this has been answered before, but would it be possible to implement sling loading on the Blue Flag server? For example, heli pilots could transport one crate inside the heli, and additionally another crate via sling loading. This would at the same time make transport jobs more interesting, and might also serve to mitigate the fuel shortage.

GUMAR, you may want to post those bugs that have not yet been addressed in the new bug tracker (https://leatherneck-sim.mantishub.com).

Note: A link to the .pdf version of the "MiG-21 Pilot's Operating Instructions" referenced in this thread can be found at http://forums.eagle.ru/showthread.php?t=138880. Page numbers referring to that manual refer to the hardcopy page number, not the .pdf page number. This question might only be interesting or answerable for those with in-depth knowledge of the real aircraft's fuel system, but bear with me if you will: 1) Page 76 of the manual states that when performing a lamps test with ground power connected and the Battery as well as the AC GEN ~ GND PWR switches ON, the No. 1/3 TK GP empty (1/3 ГР. ВАКОВ) lights illuminate only with the No. 1/3 TK GP Pump circuit breakers turned on. For me, this implies that neither the DC generator nor the Inverter PO-750A No. 1 exclusively power the mentioned lights; it is probable that they are powered by the battery. 2) Page 94 of the manual states that when flying with partially filled fuel tanks, one should check the amount of fuel contained in the tanks on the ground, before starting the engine, by turning on the No. 1 TK GP Pump circuit breaker for 2 - 3 minutes and making sure that the No. 1 TK GP empty caption does not illuminate. For me, this implies once again that the DC generator, which is not functional without a running engine, does not power the No. 1 TK GP empty light. 3) Page 195 of the manual states that No. 1 TK GP Pump is powered by the DC generator. It does not directly state, however, that the No. 1 TK GP empty light is also powered by that generator. 4) Bullet point 6, column 3 on page 4 of a German MiG-21U manual (http://www.mig-21-online.de/Vorschriften/Anlassen_66.pdf) states that when switching on the No. 3 TK GP Pump prior to starting the engine, with the battery on and external power connected, the No. 3 TK GP empty light will illuminate for a short time, then extinguish. From points 1) and 4) combined I deduce that contrary to the current in-game implementation, when doing a cold start and with the battery on, but with the No. 3 TK GP Pump circuit breaker turned off, the No. 3 TK GP empty light should not be illuminated, even when performing a lights test. From points 1), 2) and 3) combined one COULD deduce that doing the check as per page 94 of the manual, one is not in fact checking the functioning of the No. 1 TK GP Pump, but only of the No. 1 TK GP empty light, which would illuminate if there was insufficient fuel in the tanks. Therefore, when doing a cold start, the engine and/or the DC generator switched off, but the No. 1 TK GP Pump switched on, only the No. 1 TK GP empty light is actually capable of working, but not the No. 1 TK GP Pump itself. In this case and contrary to the current in-game implementation, when starting with fully filled tanks, the No. 1 TK GP empty light should not be illuminated unless doing a lights test as per 1). HOWEVER, what I find strange is that as per 2), one is supposed to switch on the No. 1 TK GP Pump circuit breaker for 2 – 3 minutes. If it was just about checking the light, this would surely not be necessary. Also, if the No. 3 TK GP empty light illuminates for a short time when switching the No. 3 TK GP Pump circuit breaker to on, I fail to see why the same should not be true for the No. 1 TK GP empty light and the No. 1 TK GP Pump circuit breaker. In this case, the check as per 2) would not make any sense, as the light would always come on, at least for a short time. Maybe, however, the No. 1 TK GP Pump can also be driven by DC external power, which would enable the pilot to perform the low fuel check without the DC generator operating. In this case, the fact that external DC power needs to be connected to perform the test is not mentioned on page 94. In conclusion, here is what I think should happen during a cold start: When the battery and DC ground power are switched on, both the No. 1 and No. 3 TK GP empty lights should not be illuminated. When the respective circuit breakers are switched on, the lights illuminate for a short time, then go out (except if there is insufficient fuel in the tanks, in which case the No. 1 TK GP empty light remains on; assuming the tanks are even less full, the 450 liters remaining and No. 3 TK GP empty light would probably also come/remain on). The No. 3 TK GP Pump is normally driven by the battery bus, thus it can also be driven by DC external power or the DC generator if those are available, while the No. 1 TK GP Pump can only be driven by the DC generator or DC external power, but not the battery alone. While doing a lights test, both lights come on, provided the circuit breakers are on. The only problem with this hypothesis is that it does not handle the fact that the No. 1 TK GP empty light would still illuminate for a short time in all cases when switching on the circuit breaker, which it is not supposed to do according to page 94 if enough fuel has been filled in the tank. Maybe the No. 1 pump is built differently from the No. 3 pump and the short illumination of the light does not occur, or page 94 implies that only a prolonged or constant illumination of the No. 1 TK GP empty light is a problem. It is worth nothing that according to the real-world English manual, the No. 3 pump is switched on after engine start and not prior, as stated in the German manual. If both the No. 1 and No. 3 TK GP Pump circuit breakers remain off, the green lights will remain off for the entire duration of the flight. The fact that both fuel pumps also remain off will probably lead to a flameout even prior to fuel depletion. If both the No. 1 and No. 3 TK GP Pump circuit breakers are switched on after starting the engine, as per the real manual, the green lights, other than quickly illuminating at the moment of fuel pump switch-on, will remain dark from the time of entering the cockpit until the fuel level drops to the respective values, in which case the lights illuminate. Could anyone who was able to follow my train of thought please check it for any logical flaws or incorrect assumptions regarding the real MiG-21Bis' fuel system and/or "fill in the blanks"? If my reasoning is correct, I plan to submit this as a bug report. Otherwise there are just too many unknowns to determine how the system really works, even though it is clear from the real-world manual that some aspects of the current in-game implementation are most probably unrealistic.