okopanja

Sadly, the issue is still there. I happened to me in ST. TRK is slightly larger than 50MB, so please download from here: https://drive.google.com/file/d/1tyFsHxi8wddSLFN62ZdN5AZVCCR4VgzU/view?usp=share_link Initially it did refocus briefly on AWACS, and the became normal again. When I reached the congested part of airspace over Kutaisi, the things started to act weird again. Tacview corresponding to the TRK file: https://drive.google.com/file/d/1o2u48Cd8sLR6ST4lw4-ZDCYUcR-1vFM1/view?usp=share_link

@BIGNEWYthis issue appears to have appeared with 2.8.3.37854.1. I think that yesterday's 2.8.3.38090 fixed the issue. Played yesterday briefly with both ST and MT, so a bit more testing would be needed to be sure. I hope @PVNKcan confirm the same...

I tried yesterday after patch and it does not seam to glitch anymore. @PVNKan you please confirm?

Hi @BIGNEWY, starting from @BlackPixxel's post I believe that all following belong to following bug report:

@BIGNEWYI believe you merged bug caused by last MT of prior bug report with actual feature request to have multiplayer player-to-player. Or does this mean we actually get player to player DL at the end? I will try to find the thread where this was also reported...

For me the expected behavior is to be able to slew skhval to stored target point. In one case (ME entered route) it is likely over-performing (e.g. so precise, you can lock target straight way). In second it is totally unusable. Who can this not be a bug? Isn't this a contradiction? Can you advise us how to do this properly if error is on user side?

The prior very long comment on shkval slewing. I described ME vs direct entry into PVI/Abris, and how they differ. To be honest: not sure if this should be called a bug or design inconsistancy, or perhaps the user is doing something wrong.

@Chizhdo we create as a separate bug report?

After playing for two days I observed the following issues: 1. Less severe: wrong symbology for own aircraft: ownship thinks its AWACS ownship thinks he is enemy of itself ownship shows frequently wrong altitude/speed symbology ownship range circles refocus on other aircraft 2. Loss of Radar/EOS functionality severely affecting SA, and even ability to acquire target in BVR mode, properly slewed. Frequent losses of locked target (target remains locked) Unexplainable loss of DL target (detected through own radar) False/true targets shown in wrong location at random This unlike previous issue occurs not only in MT, but also in ST. This results typically with total degradation of situational awareness. @PVNKdo you have anything to add, and do you have idea how to capture the TRK for all these defects?

Do not use HT with DCS. Even with MT it results in lower and less stable FPS.

v0.1.2 release: What's Changed Combined Arms Support: intelligence data can be captured in combined arms modes and transferred once you switch to Black Shark. Prevented overlapping transfers Special notes Combined Arms: although you can capture way more points then BS supports. If the number is larger, SharkPlanner will prune points to supported number and keep only the first 6/10/10 way/nav/target points. With 0.1.0 version the support for BS2 and BS3 2011 was broken during code refactoring. This was fixed in pre-release 0.1.1

English (for Russian translation, please see below): As you may remember I asked about the block diagram of Ka-50s internal systems. The reason is I struggled to understand the interactions between different systems. In particular the SHKVAL's ability or better said inability to slew toward DL target or the target point from PVI-800. After some interaction with other forum members and hands on testing, it appears that shkval will slew to different altitudes: If pre-planned route from ME is used, shkval knows not only exact altitude, but rather exact X/Z coordinates, with precision being higher than e.g. PVI-800. End effect: you can lock the target straight away. If manually entered route (both in ABRIS and PVI-800), shkval will use ASL 0, and inaccurate coordinate entered through PVI-800 (rounding error). For case 2, the results are good enough if your target is at altitudes close to ASL 0, but already at 400-500m ASL cause errors that make it unusable (shkval points way before the actual point). Therefore for SHKVAL to work properly, it needs the knowledge of target altitude. In case 1 this is obviously supplied auto-magically, but in case 2 it renders the slewing feature of SHKVAL useless. The altitude knowledge can be provided through following means: ABRIS database PVI-800 manual entry (at the moment this is totally missing) Ability to select designated altitude manually, before the slewing takes place, which seems to be generally missing (I did not find the way to affect this, I hope that more knowledgeable person will correct me). I took also the liberty to generate the system diagram based on what the module declares. Diagram is in SVG format and can be view in web browser ( In this iteration I did: provide classification of devices with coloring provide tooltip for more obscure devices Things I did not do: create clusters of subsystems. As seen in the graph some of them are subsystems mark devices that looks to be "virtual modeling devices" It appears that both ABRIS and Rubikon K-041 come on top as the top most ranked devices. Given the fact that K-041 Rubikon existed in early prototypes even before ABRIS was added, my conclusion is that despite diagram it is Rubikon K-041 which is probably more important. In short: what needs to be done for SHKVAL slewing feature to actually work? Russian (google translate, sorry dudes the best I can do, I know it sounds terrible): Как вы помните, я спросил о блок-схеме внутренних систем Ка-50. Причина в том, что я изо всех сил пытался понять взаимодействие между различными системами. В частности, способность ШКВАЛ или, лучше сказать, неспособность повернуться к цели DL или точке цели из PVI-800. После некоторого взаимодействия с другими участниками форума и практического тестирования выяснилось, что шквал будет летать на разных высотах: Если используется заранее спланированный маршрут от МЭ, то шквал знает не только точную высоту, но и точные координаты X/Z, причем точность выше, чем, например, высота над уровнем моря. ПВИ-800. Конечный эффект: вы можете сразу захватить цель. При ручном вводе маршрута (как в АБРИСе, так и в PVI-800) шквал будет использовать ASL 0, а через PVI-800 ввести неточные координаты (ошибка округления). Для случая 2 результаты достаточно хороши, если ваша цель находится на высотах, близких к 0 над уровнем моря, но уже на 400-500 м над уровнем моря возникают ошибки, делающие ее непригодной для использования (шквал указывает задолго до фактической точки). Поэтому для правильной работы ШКВАЛ необходимо знать высоту цели. В случае 1 это, очевидно, обеспечивается автоматически, но в случае 2 функция поворота ШКВАЛ становится бесполезной. Информация о высоте может быть получена с помощью следующих средств: База данных АБРИС Ручной ввод PVI-800 (на данный момент полностью отсутствует) Возможность выбора заданной высоты вручную, до того, как произойдет поворот, чего вроде бы вообще не хватает (не нашел, как на это повлиять, надеюсь, меня поправят более знающие люди). Я также позволил себе сгенерировать системную диаграмму на основе того, что декларирует модуль. Диаграмма имеет формат SVG и может быть просмотрена в веб-браузере ( В этой итерации я сделал: предоставить классификацию устройств с раскраской предоставить всплывающую подсказку для более неясных устройств Что я не делал: создавать кластеры подсистем. Как видно на графике, некоторые из них пометить устройства, которые выглядят как «устройства виртуального моделирования» Похоже, что и ABRIS, и Rubikon K-041 занимают первое место в списке самых популярных устройств. Учитывая тот факт, что К-041 Рубикон существовал в ранних прототипах еще до того, как был добавлен АБРИС, мой вывод таков, что, несмотря на схему, это Рубикон К-041, что, вероятно, более важно. Вкратце: что нужно сделать, чтобы функция поворота ШКВАЛ заработала? ka-50.svg

nullI just became awacs with symbology... null

Hi, I did not understand the issue. If you describe it I can test in about 30 mins.

The tool only uses PVI-800 keyboard to enter. ABRIS uses dials (that was voodoo magic to get it work). Since I could not get block diagram from ED, I generated a dependency graph based on module lua files. Guess which devices is the top most ranked. You will need to download the svg and open it with web browser (edge). ka-50.svg

I found another inconsistency: In mission editor I entered the target points and flew again. This time slewing worked with insane precision with even rounding error of PVI-800 being absent, and shark actually knowing exact altitudes of target points. Clearly coordinates can not be accurate that much with INU over the drift, but the paradox is that someone intentionally coded the altitude knowledge in ME and consequently the module uses this knowledge. IMHO there must be a way to specify/obtain altitude of target point in helicopter, otherwise there would not be any sense to built in all that junk weight into it. Here is the track file Ka-50_ABRIS_with_ME_target_point.trk

You were correct, taking of from near coast produced usable result. SKHVAL slewing requires coordinates and the altitude of both helicopter and target point. In addition SKHVAL itself has to be stabilized for this to work properly. The fact that Shark does not know the target point altitude when it needs to slew SKHVAL, but it allegedly knows the altitude when it needs to update the fix point is rather interesting. IMHO: fix/target point altitude can come from 2 sources: manual entry into PVI-800 ABRIS database query With no block diagram (I asked for it some time ago and got declined) to show interconnections we can not really judge if this is realistic or not, but paradox is there. Sadly Black Shark 3 still gives the sensation of unfinished product. IMHO, adding this feature would not hurt much, since there is an inherent rounding (not small) error that requires the pilot to search for the target, by selecting target point and then doing visual identification. This would be beneficial for pop-up attacks.

Here is were it works for me: and here is where it does not. Note: in second case I also have inflight slot similar to the one of the ED's mission and it still does not work.

Here is where it does not work: Ka-50_ABRIS.trk Here is where it works: Ka-50_ED_free_flight.trk Please do not bother, I enter coordinates with my mod, and it appears the track file does not record clickable actions from export scripts. (Bug?) I will create short video.

Interstingly I do not manage to use PVI target point in my own mission to slew skhval. Either from AIR or on ground hot take off. It does move but does not point to target, but simply drifts. Relative movement between 2 target points works, but off course behaves the same. In contrast ED's instante free flight works perfectly. Any cue on what am I doing wrong?

Short update: working on Combined Arms support as a source of intel data... Once completed you will be able to activate planner from within JTAC seat for target point designation and then switch to black shark for actual transfer.

Do you have a screenshot? (will check myself later)

BIOS. Check your PC documentation, but typically F5, F8, F10 or F12 during early startup. Generally, DCS is CPU intensive, hence hyperthreading will usually cause worse performance. There should be setting under Performance.

If you did not turn of hyperthreading yet, turn it off, it should result in more efficient CPU usage and CPU might be able to feed the 3070 better. I had same issue, and got the same advise from another user. In addition I can confirm that MT + HT do not produce better results than only MT.

ben_der talks about VR.