MBot

While the reliability of tracks the longer they run is a known issue, the problem with the Viggen is completely different. Tracks playing the Viggen consistently result in the aircraft crashing within seconds to minutes. On the other hand I have recorded tracks of half an hour with precision flying, including bomb deliveries, air-air refueling and carrier landings which consistently replay perfectly. There is clearly something wrong specifically with the Viggen. You can't record a track with the Viggen flying a simple circuit without crashing. Go ahead and try it.

I can't comment on the Fw-190 and Bf-109, but have recently played tracks flying the F-5E, the Su-33, the Gazelle and the AV-8B and they all worked flawless.

Yes this seems to be the same one.

That is not correct, this is a problem specifically about the Viggen. Tracks for other aircraft play back correctly.

I am still contemplating how to go ahead. I am having a lot of fun with the AV-8B lately and it is a very cool aircraft. But being heavily geared towards CAS, it doesn't work particularly well with DCE, which is strike orientated. A prototypical Harrier campaign, with amphibious landings, V/STOL operations, FARPs and CAS missions is probably best achieved through a highly scripted linear campaign. A Desert Storm style dynamic campaign set in Nevada revolving around the Kuwaiti kill-boxes might work, as the Iraqi army was basically deployed statically in the desert. But for this to be fun I feel we would need to have more suitable air defense, especially AAA such as the 57mm S-60 guns and also 37mm. Less deadly MANPADS such as SA-7 and SA-14 would also be desirable.

While "black - no return" is the usual convention with radars, this is not actually the case with the Viggen. Here, black indicates a return.

E-mail sent. Thank you for taking the time even on a day like today. Merry Christmas.

In a TILS approach to Nellis, about 6 km from the field the commanded flight path makes a sudden jump and then displays bogus information. Sometimes it switches back and forth between correct and false flight path, sometimes it shows false path until touchdown (the case in the screenshots below). The HUD also never switches to the descent rate mode before touchdown.

After a go-around, the system does not automatically switch back to LB1.

1. Close to L1 in LAND NAV mode and heading towards LB1. 2. Make a flip-flop (LAND P/O -> LAND NAV). System correctly switches to LF1. 3. Switch the nav system to NAV and then back to LAND NAV. This should restore an approach towards LB1. This doesn't work, the system returns to LF1. 4. Make a flip flow again (LAND P/O -> LAND NAV). System switches back to LB1. I think this is not correct either, according to the manual a flop-flop should always result in a short-approach. Edit: Tested at Nellis.

I have a question regarding the behaviour of the radar altimeter. Let's run through the following scenario. 1. Alt 100 m AGL, HÖJD CISI on RHM. HUD displays 100 m. 2. Turn the pressure know until the barometric altitude show 1000m. HUD display remains at 100. 3. Start to climb. When passing 550 m AGL, the marking on the HUD indicate that radar altitude is lost, as expected. Altitude displayed on the HUD continues to raise smoothly. 4. When at 700m AGL level off. The HUD displays 700 m. The barometric altimeter shows 1600 m. 5. Start to turn the pressure knob and subtract 100 m worth of pressure. The HUD will show 800 m, the barometric altimeter will show 1700 m. True altitude remains 700 m. At the end of this procedure, the altitude shown on the HUD is neither radar altitude nor barometric altitude. It can be adjusted higher or lower with the pressure knob, but does not display the actual altitude according to this pressure. Is this the correct behaviour that should be expected?

The Terrain Avoidance radar mode is very unreliable. Sometimes it works, sometimes it doesn't display relevant terrain. Note that betwen the first and second screenshot, the terrain is displayed at almost the same range, while I closed a considerable distance to the mountains. I do not think that on screenshot 1 the terrain displayed are actually the mountains ahead but some ground closer (and lower). On screens 2, 3 and 4 the radar display does not match the terrain I see on the horizon line in the HUD.

Well, I opened in up again, twice. This is already the n-th time I had to open the base to fix problems and it is always a chore, because I have to uninstall it from my seat first. I couldn't find any apparent problem, everything looks in order. It sounds a little different each time I put it back together, and frankly I think now it is even worse. RPzydZFsP3w I really love the stick's design and it is really exactly what I was looking for. But I am very unhappy with the numerous problems I had so far and am pretty sick about the number of times I had to open the thing. Say what you want about the Logitech 920, but I didn't have to open this one ever. Was I just very unlucky and got a Monday-model?

A little report on prolonged use. After about two months, the grip started to make groaning plastic sounds again and I had to tighten all the screws of the grip again. More interestingly, the rubber cover on the base started to make really loud "grinding rubber sound". The gimbals in the base is also emitting various sounds, a strong mechanical one and a little squeaking like it should be lubed. I love the stick for playing, but this thing is like an orchestra. Edit: Here is a video: IVc6NDqIjL0

I updated the first post with V1.05 which runs on the latest version of the Dynamic Campaign Engine. This is a proforma update only provided as is. Frankly I haven't played the MiG-21 in a long time and I am really not sure how well this campaign plays at all. What do you think, is it worth it to keep this one updated or should it be left to die?

First post updated with version 1.01. No changes specific to this campaign, just a maintenance update to bring it up to the latest standard of the Dynamic Campaign Engine. I didn't run any gameplay tests, fingers crossed that everything is still in order.

There is one important thing I forgot to mention. Apparently DCS changed the AI taxi logic. No AI flight will start to taxi after you have started to taxi until you take off. This is important to keep in mind, especially if you spawn at a remote corner of the airbase. In large packages this might cause delays in take-offs and forming up that might jeopardize the whole mission. Generally it is best practice to wait at your parking position until every other flight in your packages started to taxi to take-off. Once the leader of the last flight started to move, you are free to taxi as well. Doing your start-up beforehand is safe.

You can find the newest version of DCE in the new Wild Weasel campaign: https://forums.eagle.ru/showthread.php?t=198447 Do not expect too big of an update for DCE, it is primary various bugfixes collected over the past months and a hand full of new features. Here are the important changes: -Destroyed scenery objects are now carried over to the next mission via the new scenery destruction trigger. This removes the need to explode scenery objects at mission start, which in turn allows aircraft to spawn directly at mission start (previously they were spawned 2 seconds into the mission to protect them from scenery destruction explosions). -oob_air is simplified a bit by removing the rooster table and replacing it with a single number entry. -In oob_air and db_loadouts, the tasks “CAS” and “Ground Attack” are replaced with a generic “Strike” task. This means that you no longer have to duplicate loadouts to work both against vehicle (CAS) and static/scenery (Ground Attack) type of targets. “Strike” will work against both of them. -The way support is assigned to packages was changed to make it compatible with additional custom specialized tasks and make it easier to add additional custom support tasks in the future. In order for the ATO to try to assign support to a flight, the loadout in db_loadouts must list the respective task in the new support table. So if the loadout lists “Escort” and “SEAD” in the support table, the ATO will try to create a package with SEAD and fighter escort. Most support is optional, meaning that the ATO will try to assign support to the package if it is available but will also go ahead without if this isn’t possible. The support tasks “Laser Illumination” and “Flare Illumination” are mandatory, meaning that the ATO will not create a package if no aircraft is available to provide this support. -Support for the following new custom tasks is added: Laser Illumination: A single aircraft accompanying the package to provide laser designation of the target. The laser is scripted, meaning that any aircraft can do it, regardless of in-game capabilities, if the campaign designer defines it. Flare Illumination: A single aircraft flying ahead of the package to drop battlefield illumination flares over the target. Escort Jammer: A single aircraft accompanying the package doing nothing in particular. Might be useful for example for a Viggen with jammer to accompany strike Viggen. Might be expanded in the future if more in-depth jamming is supported. -db_loadouts is structured differently. -Basic support for helicopters is added. This is not detailed enough for playable helicopters but serves to populate the campaign with helicopters as targets and for immersion. So if you want to use the new set of scripts in existing campaigns, you need to update oob_air (Strike task unification, number), db_loadouts (new structure, support table) and the targetlist (Strike task replacing CAS and Ground Attack).

Join the F-5E Tiger II of the 64th Fighter Weapons Squadron at Nellis AFB, Nevada and participate in a 1976 combat exercise to train Wild Weasel anti-SAM tactics in the Nellis Air Force Range. F-4E Phantom II of the 39th Tactical Fighter Training Squadron will train radar suppression with their AGM-45 Shrike missiles, while the Tigers provide the strike elements to knock out the missiles. It is a delicate business and coordination within the large packages is key, as the time window to hit the suppressed SAM batteries is limited. This is a mini-dynamic campaign of just about 5 missions. It is basically an excerpt of some of the latter missions of the Desert Tiger 76 dynamic campaign. The purpose of this mini-campaign is to provide an easy entry to the DCE system for everyone that does not want to invest the time into a campaign spanning over too many missions. It concentrates on the interesting SAM attack missions so also those that did not progress deeply into Desert Tiger 76 have an easy opportunity to experience them. In addition, since the unit count and general scope of this campaign is greatly reduced, it will run a lot better for those with performance problems. Even though this is a mini-campaign with only small number of aircraft and targets, it still boasting the usual dynamic campaign features such as resources and damage tracking and automatic mission generation. Single player and 4 player COOP (with the usual limitation inherent to DCS) is available. Download V1.0 Installation instruction in Read Me. The campaign uses a nice custom skin available here: https://www.digitalcombatsimulator.com/en/files/2636020/ (default skin will be shown if custom skin is not downloaded) Wild Weasel v1.0.zip

I have updated the campaign in the first post to version 1.05. There were no changes to the campaign itself, but it was updated to the latest version of the Dynamic Campaign Engine, which should fix a couple of bugs that have been fixed over the past months.

This has been a bug in DCS, but it should be resolved with the recent DCS 2.2. In any case, I will release an updated version of the campaign shortly.

Fantastic skins KIZIR, I just love the old liveries. These will be my new standard. It would be great if they could be made official, so they can be used in missions and campaigns. Have you looked at VMA-214 in 1989/90? They actually flew the "Land Camo" on Night Attack Harrier II.

Also the ground stabilization of the DMT when not being "locked" on the ground, during slewing, seems greatly simplified. I assume during slewing the DMT should be ground stabilized by using information from the INS and the radar/baro altimeter, deducting slant range by assuming flat terrain and applying trigonometry. Now if you put the DMT on a ridge line on a hill ahead, you can easily see how this is not the case. Put the DMT TV just below the ridge and slew left/right. Observe how it perfectly tracks the ground in the vertical axis. Now move the DMT up slightly, beyond the ridge line and onto terrain many kilometers in the background. Now slew left/right. The vertical tracking immediately changes to perfectly track the new ground again. The ground tracking seems to use game data directly. Now I understand that the ARBS is still subject to changes during the Early Access, so let's see how this develops.

Yes the principle to do this won't change.

I am slightly confused with the implementation of the ARBS in DCS. The TV is either slaved to the velocity vector or perfectly stabilized to any selected and freely slewable point on the ground. There does not seem to be any locking of targets based on contrast. On the other hand the TAC manual talks lengthy about the need to lock on targets based on contrast and it has an entire section about tactical considerations to do so (including recommendations to fall back on alternative delivery methods if no satisfaction lock can be achieved). I understand that DCS has its limits but this seems like a rather significant simplification of the ARBS.