ButterCookie

Yes, it has been changed some time ago. Here is the changelog post, that describes how to do it now

Awesome, that was quick. Looking forward to the next patch.

Thats interesting. Can you get me a link to these reports? Would like to compare if its the same issue. Didnt find anything in the harrier bug forums. I only did one test with the harrier with the APKWS and that one hit.

Just checked and its still happening for me in the current open beta. what i do to reproduce: -pick a loadout with the targeting pod on one of the wing stations. -attack a MBT from the front or rear. Lock it up in point track -starting at about 10.000 feet, launch at 4,5 miles, about 20 degree dive angle The rocket will impact to the side of the target. See screenshot Edit: just tested with GBU-12 and they are off to the side as well, when TGP is mounted on the wing station. But will still kill the tank, because of the bigger ordnance.

I did the test you asked for, but without any difference, even after flying for 15 minutes before engaging the target. But i found that all rockets seemed to land on the right side of the target, missing by maybe half a meter. I was using a loadout with the rocket pod on the right wing and the TGP on the left wing pylon. When switching the rockets to the left side and the TGP to the right, the rockets would miss on the left of the target. Finally, with the TGP mounted on the centerline pylon, i'm getting accurate hits, again being able to damage T-72, except for when facing their front. But I assume, thats because their armor is too thick from that direction. With that being said, I assume the rockets should hit where the TGP is pointing at, no matter what station it is mounted on, correct?

I encountered the same problem during a mission yesterday. Shooting at tanks (T-72B3 in that case) resulted in an imapct crater from the missile next to the tank and the target being undamaged. Did a short test with 3 tanks in a row, orientated that i would shoot at them from front, side and rear. Only the one that showed me its side could be hit reliably. (Track attached) When i did that same test with BMP-2 as target, i found that the BRM would still narrowly miss the targets facing towards or away from me, but the splash damage was enough to destoy the lightly armored vehicles. Hope you guys at Deka can look into this. BRM test.trk

Waypoint didnt work for me strangely. Guess a target point is needed. Maybe it would work by copying the coordinates of the waypoint to waypoint 40.

Just gave it a try. Didnt notice anything different, except that they now are being guided by a JTAC's laser. So I guess buddy lasing in multiplayer should work as well. Still need to make a target point by yourself to launch them, though.

I noticed today, that LGBs will fly a curve and then miss shortly after aquiring the laser. Tested a bit and it seems to occur when the targeting pod is rotating its head when I overfly the target area. In order for the bomb to keep the track, I need to fly in a way so that i have the target on my side. Track and Tacview attached. LGB test.trk Tacview-20200926-105943-DCS.zip.acmi.zip j17.trk

It got fixed with todays patch, so this thread can be moved to "Fixed bugs". At least its working correctly for me now.

It got fixed by todays patch. Just checked it, and both Viggen and Jeff are now starting normally from Senaki hangars.

I heard that sound as well at the start of a mission. It stopped once the canopy was closed and the ECS was on. Thought it was the pilots teeth clattering because of the cold.

Thanks, lets hope it will get fixed. Funnily enough the AI doesnt care either way, and reverses the Jeff out of the hangar. :lol:

No, they snap to the alignment of the parking spot, wich normally would be fine. All hangars at Senaki-Kolkhi. See the added mission file for demonstration. I put the aircraft there down as AI, but same happens if changed to player aircraft. hangar test.miz

With version 2.5.6.50321, when I place a JF-17 in any of the aircraft shelters at Senaki-Kolki, it will start with the nose pointed towards the rear wall. When placed on an open parking slot, it is oriented normally. I didnt find any other airfields that had this problem, nor any other aircraft modules. Didnt have this problem in the previous open beta version. Already ran a repair, but the problem is still present. Not sure if this is an ED or Deka problem, so I will post in both subforums.

With version 2.5.6.50321, when I place a JF-17 in any of the aircraft shelters at Senaki-Kolki, it will start with the nose pointed towards the rear wall. When placed on an open parking slot, it is oriented normally. I didnt find any other airfields that had this problem, nor any other aircraft modules. Didnt have this problem in the previous open beta version. Already ran a repair, but the problem is still present. Not sure if this is an ED or Deka problem, so I will post in both subforums.

I dont have that stick, but it should. This is made for switches that you cant bind als states to, for example a 2-stage switch you can only map in the "up" position.

Here is what i made so far. Just add it into the default.lua in DCS World\Mods\aircraft\JF-17\Input\JF-17\joystick and place it in a free line after "join(res.keyCommands,{". This includes keybinds for: -Master mode Intercept/Nav/AG -Airbrakre On/Off -Parking brake On/Off -Gear Up/down - Master arm On/Off -Flaps Up/Middle/Down {down = key_cmds.HOTAS_Throttle_T1_Forward, up = key_cmds.HOTAS_Throttle_T1_Center, name = _('Master Mode Forward, else Center'), category = {_('Switch abstractions')} }, {down = key_cmds.HOTAS_Throttle_T1_Backward, up = key_cmds.HOTAS_Throttle_T1_Center, name = _('Master Mode Backward, else Center'), category = {_('Switch abstractions')} }, {down = key_cmds.AirBrake, up = key_cmds.AirBrake, value_down = 1.0, value_up = 0.0, name = _('AirBrake On, else Off'), cockpit_device_id = devices.FCS, category = {_('Switch abstractions')} }, { down = click_cmds.PNT_511, up = click_cmds.PNT_511, cockpit_device_id = devices.GEAR, value_down = 1.0, value_up = -1.0, name = _('Parking Brake on, else off'), category = {_('Switch abstractions') } }, { down = click_cmds.PNT_505, up = click_cmds.PNT_505, cockpit_device_id = devices.GEAR, value_down = 1.0, value_up = 0.0, name = _('Gear up, else down'), category = {_('Switch abstractions') } }, { down = click_cmds.PNT_509, up = click_cmds.PNT_509, cockpit_device_id = devices.WCS, value_down = 1.0, value_up = 0.0, name = _('Master arm on, else off'), category = {_('Switch abstractions') } }, { down = click_cmds.PNT_513, up = click_cmds.PNT_513, cockpit_device_id = devices.FCS, value_down = 1.0, value_up = 0.0, name = _('Flaps up, else stop'), category = {_('Switch abstractions')} }, { down = click_cmds.PNT_513, up = click_cmds.PNT_513, cockpit_device_id = devices.FCS, value_down = -1.0, value_up = 0.0, name = _('Flaps down, else stop'), category = {_('Switch abstractions')} },

Can confirm that this is still present in DCS version 2.5.5.34108 under certain circumstances. I can reproduce this bug with the following steps: - Place a Harrier in the misison editor without any waypoints - Start up the engine - Complete alignment like normal - Switch INS knob to NAV or IFA - Select DATA/WYPT It will also crash when setting the INS to always aligned and there are no existing waypoints, if on the DATA/WYPT page the MPCD buttons for next/last waypoint are pressed. To prevent the crash, i create a mark point by pressing MK0 on the EHSD page, after alignment and before switching the INS to IFA. Also note: the distance and direction for created waypoints are not shown if there where no exiting ones before.

According to MSI Afterburner DCS uses DX11. And, yes, I'm running on a DX12 capable card.

Just checked and both Mavericks are working fine fore me. At first it didnt launch, but that was because i forgot to set the fuse. It wouldnt lauch in that case. Maybe check if you didn't make a similar mistake.

Have the same problem. Tested with MK82 and MK83 in singleplayer, both starting in the air and starting cold. As soon as i press the bomb release I get the breakoff que on the HUD (see second screenshot).

No, this is a "special case", since I have my router set to block all ports, except the ones that i allow to pass through. So it was just me being too stupid/lazy to read everything :music_whistling:

Went to search for that and you are correct. It is mentioned on the Github page and the first post :doh: Well, It's working now.

I ran into a problem today that took me some time to figure out. When I tried to transmit, nothing happened. The green light in the overlay didn't light up and there was no transmit effect, although the audio test was working fine. After quite some time and a few clean reinstalls of simple radio, I found that the reason for this error was that my router's firewall was blocking port 5015, wich SRS apears to be using. I found this strange, as I was using the buddyspike server with the adress 5.189.162.17:5014 (so port 5014). I notice that this is not a fault of simple radio, and most people won't need to open ports when not hosting a server. Just wanted to put this out there.