Catweedle

Unfortunately, the ghost/double impacts are still an annoying thing. Kang and myself can confirm this does not only happen with ground but also with A2A ordnance, e.g. two explosions, and/or (small) poofy impact crater separated from actual "explosion" crater. It does not happen always, but it seems that at some stage, even without changing the airframe, it is persistent.

The bug is still around; three short tracks attached: fired L-Mavs from distances 5.5 (...5-5.trk), 6.5 (...6-5.trk) and 7 (...7.trk), all Mavs miss due to latched/auto lase/-r prematurely turning off. Bug is present in both SP and MP (tracks are from SP). No mods installed, only SRS; version used is OB with latest updates as of today. a10c2_lmav_autolase_prob_5-5.trk a10c2_lmav_autolase_prob_7.trk a10c2_lmav_autolase_prob_6-5.trk

That last redundant script pretty much does nothing, at least not visually or damage wise from/for any Viper ordnance. Also, and that has been the case for a few months, so not related to that damage script: - Randomly but regularly: two impacts and craters from one bomb, e.g. JDAM/GBU. - Kills not being counted (score), especially on multi-kills from one weapon. Wiping out all mini-mission's units: score 0; happened yesterday, happens a lot in general. Cheers

onBirth won't really solve your problem for CA-units. Best to make your own event handler via timer.scheduleFunction'ing: - (dynamically) store the (spawned) units in a data base, i.e. table, e.g. via groupID and groupName as key/value - execute a looping function via timer.scheduleFunction every n seconds, iterating over all stored groups and units in the data base - a player entered/is in a unit if that unit returns a getPlayerName() string value I've attached a simple demo mission, you can find the corresponding script (player_in_unit_eventhandler.lua) inside. This is only to give you a rough idea: dynamically spawned units are not included, only the first unit of the group is tested for player presence, etc. player_in_unit_test.miz

As has been pointed out earlier, it is a reported bug, dating back to early November 2020(!). Oddly, a) I did not experience the bug back then, but it happens to me now more often than not, and b) it seems to only happen in MP.

OP's issue has been reported months ago: Let's hope it finally got fixed.

Luckily it was easier to reproduce than expected. The problem is related to switching master modes, most likely while APKWS are selected. I have attached a short track demonstrating the issue, the "CCRP invalid" appears after ca. 40s track time and during the rest of the track. I did the following: select APKWS, toggle through master modes, select GBU-12 profile (profiled for CCRP delivery, CCRP mode selected). 54's and basically any CCRP are affected. I am using the current OB release, without mods except for SRS. a10c2_ccrp_invalid.trk

I got "CCRP Invalid", with symptoms described in the OP, on GBU-12's a couple of times now (in MP), always after landing/rearming, never on the initial flight. The only setting ever touched in the bombs' profile was setting them to CCRP. Re-initialising/-loading the stations did nothing, the only delivery method was CCIP. Another common denominator with the OP was using APKWS, although not in CCRP (wasn't this disabled for APKWS in one of the last patches?). Until someone provides a track, I am afraid we'll be stuck with this problem for a while. One a side note, sleeping JDAM's do not show "CCRP invalid" in the HUD.

Check the units' engagement ranges yourself, ingame or in the ME, and make sure they are between their min. and max. ranges, else they will ignore the task. Esp. MLRS or Scud's have much greater min. (but also max.) engagement ranges. Also, depending on skill settings they might take up to 3(+) minutes to fire -- at least it used to be that way.

It's not going to solve the initiator-problem, and it's certainly not the most effective or secure method, but: you could "password" the mark-commands with something like -spawn sam_site1 #password123.

Same day this thread was created -- the date format here is MM-DD-YYYY.

I can confirm that giving them a target their own firing solutions never hit the target, just as you've shown. I never knew you can actually take direct control of a submarine, at least the Type 093, so I tried it myself. After a couple of tries I was lucky and guessed the correct firing solution, but the torpedo went straight through the ship, no boom. If that is related to not being able to set torpedo depth (it always seems to be 16-17ft), or if it's a bug, idk.​

Without quite a bit of scripting (checking and evaluating known targets, hit detection, setting new task/waypoints, etc.), naval vessels will -- unfortunately -- not do do any autonomous maneuvering. One could try and fake it via trigger zones, though.

Retrieve group via getGroup() on event initiator, then getCoalition() on the retrieved group, which will give you values 0, 1 or 2 for the coalition.

Only clients/players return a value (string) for getPlayerName(), so you could try something like this: function Handler:onEvent(event) if event.id == world.event.S_EVENT_CRASH then local ei = event.initiator if ei == nil then return end local playerName = ei:getPlayerName() -- ... if playerName ~= nil then -- ... end -- ... end end

No problem. :thumbup: Consider asking such questions in the Mission Editor sub-forum, chances are higher you'll get more answers there.

He is talking about the UPP-800 mounts, i.e. launch tubes, not missile launch zone reticle on the HUD.

Please refer to the images 1 to 6. Select the aircraft, (1) on waypoint 0 click the lower add button for advanced waypoint actions. This will open a new window (2) -- click the upper drop-down menu and select Set option (3) and subsequently select Reaction to threat. The default behaviour is (4) Allow abort mission. Click on e.g. (5) Passive defence (or something you find suitable), this will set this reaction type. It doesn't have to be waypoint 0, but make sure it is a waypoint that's ahead of the attack. With this setup the aircraft will usually fight until death. If the aircraft task is CAS, you can set a "Search then engage in Zone" (6) in a similar fashion via adding an advanced waypoint action. The zone can be moved around, resized, and specific groups to attack selected -- try it out.

I'm pretty sure it's a CA-only feature. The "Pilot can control vehicles" box can be found in the Battlefield Commanders UI (button with flags on left side in the ME).

@ Controlling units from airframe slots: yes, but it depends on the mission (maker), i.e. if it has been enabled via tick box "Pilot can control vehicles" in the ME. Then you can control them from any airframe without selecting a CA slot.

TMS Aft short on TGP as SOI changes to INR and doesn't auto-focus -- that's what I was also used to in the old A10-C; long also doesn't reset SPI to steerpoint and actually it doesn't seem to do anything. Is something wrong with my installation, is it WIP? I checked my controls and everything is bound correctly. Solved -- user malfunction.

You may have "Historical list of units" enabled (clock symbol at bottom in ME).

Yes, but that's not what you are looking for in this case. Check the "User manual" (pp. 113); it can be found in your Windows Start Menu->Eagle Dynamics folder, which opens the file DCS User Manual EN 2020.pdf on your hard drive (located in the DCS World/Doc folder).

How can this already been reported for the current patch when the report you are most likely referring to is dating back to 17.07.2020 (https://forums.eagle.ru/showthread.php?t=280972)? The switch has been working fine before OB 2.5.6.55363 was released.

Open Beta - version number: DCS 2.5.6.55363 Installed mod: SRS (latest version) The AAP STEER Switch is skipping -- or rather fast forwarding -- steerpoints, i.e. one click increments not one but two steerpoints, in both directions. The UFC STEER UP/DOWN Rocker switch is not affected. I have attached a short track file demonstrating it, on both hot and cold start A10-C's. a10c_steerps_bug.trk