Blackfyre

Ну вроде все логично, ветер слева - киль(да в целом весь фюзеляж) работает парусом и его сносит вправо, соответственно нос разворачивает влево (в сторону ветра). После отрыва точка опоры пропадает и сносить будет уже вправо. На взлете парируется потребным креном в сторону ветра, чтобы на стойках шасси была равномерная нагрузка. Когда осваивал элку, то этого не знал и работал педалями только.

Кажется так и должно быть. Пока у тебя есть контакт с поверхностью ветер разворачивает киль, после отрыва сносит уже весь самолет. P.S. Мог написать фигню, пусть знатоки поправят.

У вас там 2020 год, НЕ суперкарриер и хитблюровский F-14. Видимо у них какая-то своя реализация была (или есть). В общем, ничего не могу сказать про томкэта. P.S. У нас(хорнетоводов на суперкарриере) ACLS появился только в прошлом году: https://www.youtube.com/watch?v=Cfvv6F5HOI8&t=917s

In what environment(export, mission) it available? AFAIK, in mission scripting we haven't `require` function. By the way, thanks for finding. It is useful for mods.

В редакторе мы частоты и каналы выставляем, а сама работа системы прибита гвоздями(почти) к радиобмену и соответственно не включается не при активном CASE 3.

Так? Если бы ED поправили бы атрибуты юнитов, то можно было бы сразу писать о совместимости...

Это вопрос к переводчику. На английском было "Supercarrier. Signal wands lights and Hold back bar are invisible". Я тут задумался, а где вообще на авике стоп-линия?

MT Supercarrier. Signal wands lights and Hold back bar invisible - fixed Из последнего патча.

Мы не знаем, ED скорее всего тоже, а самое грустное, что это нормально Ну и я придерживаюсь мнения, что сами по себе накопители не виноваты. Хотя сразу после обновления на MT у меня винда стала загружаться строго со второго раза, а в первый раз падает в синий экран на драйвере ntfs.sys... Совпадение? Еще меня беспокоит, то что DCS в меню жрет одно ядро всегда (вечный цикл?). Любителям поковырять редактор миссий мешает.

Почему между собой вспомогательные не общаются? Допустим я бы точно попробовал бы вынести ИИ в отдельный поток и ему может понадобиться читать файлы/сеть или еще что-нибудь. Но это собственно не очень важно. В общем, ты пытаешься решить не ту проблему, что будет делать главный поток если ему нужен какой-то файл вот прямо сейчас, а он еще не прочитан? То что ты описал, делается несколько по другому - через пулы потоков и future в качестве результата, хотя идея та же, только очередь там из функций, а не команд, что позволяет не делать принудительный простой во вспомогательных потоках вообще никогда. И ооочень в теории можно попытаться написать код, который никогда не будет ждать результата, а всегда делать что-то полезное. На практике так если и могут, то буквально десятки людей на этой планете(хотя есть реактивное программирование, но в него тоже могут не только лишь все). За исключеним некоторых "простых" случаев. В случае высоконагруженной СУБД очереди как раз таки в полный рост используются, только у них там цель другая - снизить мгновенную нагрузку и/или распределить между шардами. В целом очереди используются когда у нас есть много каких-то запросов и ограниченный ресурс их выполнения. (Еще очереди типа Kafka или RabbitMQ используют в качестве интеграционной шины, но они там на стероидах, но идея та же).

Преткновение будет не из-за количества очередей, а из-за того что у тебя минимум два потока будут постоянно пытаться в них читать и писать, т.е. внутри очереди будет происходить синхронизация, а это дорого, но более предсказуемо. Вот из-за дороговизны синхронизации у тебя общая производительность уменьшиться (throughput), зато может быть упадет максимальная задержка(latency). Плюс некоторые задачи, тебе вот прямо точно надо выполнить, чтобы отрисовать кадр, иначе будет фигня, которая нам не понравится.

Я бы не делал ввод/вывод на очередях, и не видел что-бы кто-то так делал. Потому что тогда эти самые очереди будут камнем преткновения, ибо атомарность записи/чтения в них придется обеспечивать во избежании спецэффектов. Зато какие-нибудь тяжелые вычислительные задачи (ИИ например) вполне неплохо могут лечь на архитектуру с очередями. Еще в таких оптимизациях всегда приходится выбирать между throughput(производительность, читай FPS) и latency (задержка, читай количество времени на формирование кадра). И есть подозрение, что в случае игры всегда выбирают первое.

Горячее подключение, чтобы можно было джойстики на ходу подключать/отключать. Включается/выключается кнопкой в настройках управления:

Если бы чтение было не асинхронным (в отдельном потоке), то тормозило бы всегда и у всех. Но рано или поздно наступает момент ожидания завершения этого чтения(или записи) и может тормозить не у всегда и не всегда, ибо у кого то уже все прочиталось, у кого-то нет. В общем, асинхронность помогает избежать простоев, но не гарантирует их отсутствие. Но мне кажется у muffler проблема не в этом(не в скоростях чтения/записи), больно предсказуемые пики у него. У меня такие же при включенном хотплаге всегда были.

Да легко. У накопителя все равно задержка в миллисекундах, т.е. на 3 порядка выше чем у памяти. Т.е. достаточно читать буквально один байт и самое главное ждать пока он прочтется, чтобы получить такие вот пики. Правда, в силу того что проблема не у всех, вообще не факт, что проблема доступе к накопителю. То же горячее подключение устройств у ED победить не получилось, или вот ты сам выше приводил пример с мышкой(!). Возможна ситуация когда такая злобная "мышь" влият на очередность завершения функций и где-то возникает ожидание (висит несколько миллисекунд какой-нибудь std::thread::join()). Что-то сказать точнее может быть получится если запустить профайлер в проблемной конфигурации и то не факт, потому что профайлер сам может оказывать влияние.

Я впервые с октября на выходных весь день летал против ИИ (просто разминался), мне не показалось, что что-то изменилось со времен большого ИИ апдейта летом прошлого года. Тогда, ИМХО, они сделали все что ниже аса слабее, аса - чуть сильнее. Но от условий все довольно сильно зависит. Например F-15 в BVR дуэли меня(F/A-18) победил, потому что навык несколько потерян. Другой пример - Су-27 в противниках, если есть большая дистанция и возможность поймать его на 50 милях, то у него нет шансов на любой сложности(он даже не пытается строить предположений о том, что в него может уже лететь 120ка), если же обнаруживаешь его на 20 милях, то от ЭТ можно и огрести.

У него там их три, причем DCS стоял изначально на отдельным от системы ССД и помог перенос на третий. И еще он утверждает, что с первым патчем такого не было, возможно с последующими что-то снова поменяется.

Конечно есть, использование файла подкачки на ССД почти незаметно(то что он есть еще не означает, что оттуда реально что-то читается), а ХДД - заметно сразу, ибо скорости отличаются на порядок, а в некоторых случаях (случайный доступ) на несколько порядков.

Это всегда лучше, не поспоришь. Но может существовать множество причин тому что не совершаешь покупку в начале акции. Лично я так пропустил (здесь было грубое слово) продажу пакета как раз Ка-50+Ми-8, ибо сначала я решил, что они мне не нужны, потом передумал, а акция подошла к концу уже. Ну и в общем по опыту работы с продажами - больше всего покупок совершается в первый и последний день акций(если о нем напоминают).

Ну так считайте тогда сроком 11 число. P.S. Однако согласен с посылом, что где-то за неделю до конца акции о ней стоило бы напомнить, как, в том числе ED, очень часто делают.

Зачем им всегда там кружить? Конкретно КС-130 - это вообще морпехи, чьи сквады могут находиться в составе АУГ. При выполнении задач вблизи суши или над ней "морсие" хорнеты вполне могут тырить топливо у ВС с КС-135. В общем, заправка от Викингов, никак не отменяет заправку от КС-130 или 135. Насколько я понял, Викинги ранее (сейчас СуперХорнеты) используются в основном сразу после взлета и перед посадкой обратно, а если надо кружить 6 часов над каким-нибудь Афганистаном, то там сухопутные заправщики вступают в дело.

Не знаю, что конкретно вы имели ввиду, но сейчас уже прямо так и есть - любой танкер появляется только по желанию автора миссии Мне кажется это вообще самая вредная практика - отмалчиваться (если ты на верной частоте естественно). Можно уже существующую фразу позаимствовать у наземщиков - "Unable to comply". Присоединяюсь к хотелке в общем.

А какой практический смысл для DCS не потреблять всю доступную память, будь то видео или оперативка? P.S. А тему видимо очень плохо искали (первая ссылка в гугле).

Короткий ответ - не пользуйся упрощенной динамикой, совсем. Общественное(в англоязычной части) мнение заключается в том, что она просто не работает.

Я ничего не говорил про "просили", я говорил, про то как это видят разработчики(по их словам). И вопрос на подумать - на сколько было бы меньше желающих упрощенных модулей, если бы полноценные было бы проще осваивать? Или, если перефомулировать, почему вообще появились такие желающие? P.S. Я не думаю, что сейчас слишком трудно осваивать конкретный ЛА, если он не первый. Я думаю, что неоправданно сложно осваивать воздухоплавание, сам DCS и любой первый модуль (хоть Су-25Т, хоть Апач). P.P.S. Если бы ED считали спрос на упрощенные модули достаточно высоким, то они могли бы сделать хоть один новый уровня ГС3, но они говорили, что наоборот будут впредь делать _только_ кликабельные модули.