arcivanov

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

Справедливости не существует и в жизни.

Разработчики очень редко придумывают алгоритмы распределенной синхронизации, этим занимаются университеты и прорывы в алгоритмах бывают очень редко. И в Арме и БФ3 все те же артефакты что и в DCS. Я архитектор проекта с бюджетом в несколько миллионов и занимаюсь распределенными системами 13 лет. Никто не утверждает что лучше быть не может. Я вам показываю, что есть верхние, теоретические пределы поведения распределенных систем, что можно обменять один тип лага на другой тип лага или что можно читануть вычислив будущий результат пробабалистически, подгоняя рендеринг под результат и что увеличение fidelity симуляции увеличивает запросы на качество синхронизации и своевременность данных. Настоятельно рекомендую почитать что-нибудь из научной литературы, типа IEEE Transactions on Parallel and Distributed Systems. Узнаете для себя много нового.

Нет, любая игра так не работает - вы не имеете предствления о том, что говорите. Вам Чиж привел пример реализации с фантомами выше. Так работает Arma2, Battlefield 3 и т.п. Во-первых я указал 200мс не пингов, а задержки синхронизации транзакции. Во-вторых транзакционная атомарность даже с неустойчивым 1-phase commit очень сложный и очень медленный алгоритм, минимальные задержки которого растут как О(t), где t - общее время распространения информации от координатора (сервера) ко всем клиентам, т.е. суммарный RTT (сигма два раза пинга на каждом хосте). Т.е. задержка синхронизации это несколько раз суммарный пинг игры. То о чем я говорю, предполагает квантование игрового времени, чтобы получить правильную картинку каждый квант (схоже с тем как сигналы гейтов стабилизируются каждый такт в процессоре). В играх реального времени, таких как DCS, этот процесс работать не может, т.к. если кванты миллисекундные, пинги должны быть максимум десятки микросекунд для десятков клиентов, чтобы успевать в транзакцию. Если пинги десятки миллисекунд, кванты будут секундные, а траектории и поведение кусочно-линейное (ракета будет лететь по сегментарной дуге перескакивая, показания приборов отменятся\скачкообразно меняться раз в несколько секунд). Во всех остальных случаях ни о какой точности речи не идет.

Вы хотите, чтобы на сервере была координированная картинка с задержкой. Тут возникают проблемы играбельности и причинно-следственные проблемы (causality). Играбельность: все данные о вводе рулят самолетами в прошлом, что крайне неприятно, задержка в 200мс будет ощущаться руками. Causality: Предположим, что максимальная задержка координации клиентов 200 мс, т.е. "координированная реальность" отстает от реальности на 200мс. Вы нажимаете на гашетку, ракета сходит с пилона и улетает, отстреливается игровой триггер. Информация о всех этих событиях пришла на сервер на 150-ой мс. Но на 100-ой мс вас уже убило ракетой, т.е. выпустить ракету вы не могли и выстрелить триггер тоже, хотя эта информация придет к вам на клиент только еще через 50 мс. Начинается рекурсивный butterfly-effect, нужно постоянно откатывать транзакции на всех клиентах, чтобы отменять действия после того как они уже не могли произойти. А клиенты-то на разных пингах сидят, т.е. откатываемые транзакции-то разной длины. Eve Оnline, к примеру, так и работает, но там все события просто записываются в базу данных и ни о какой симуляции и реальном времени речи не идет.

Разные системы моделирования более или менее чувствительны к пингам и потерям пакетов. Если предположить, что попал/не попал вычисляется во время пуска (есть дальность, есть скорости, есть тип самолета, есть вероятность попадания ракеты по цели с данной скоростью с такой-то высоты, есть значение генератора случайных чисел => мгновенное вычисление попадет ракета или нет на стадии пуска), то этот алгоритм вообще от сети практически не зависит: проходит сообщение всем заинтересованным что ракета X попала в цель Y, лететь будет следущие 10 секунд по типу траектории f, идите рендерите ее вне зависимости от того куда цель Y летит. Если такого вычисления не делать, а действительно симулировать принятие решений ракетой и получение ракетой информации о цели в реальном времени, то ракета не может получить информацию о цели лучше чем та, что доходит с лагом. Различные промежуточные варианты тоже возможны, но чем реальнее тем чувствительнее к качеству сетки. На 600-700ms пингах даже печатать невозможно, не то что нормально ракету симулировать.

Не кажется, DCS вам ответить прямо не может - вы клиенты. Я с вами корпоративной этикой не связан, могу говорить без обиняков. Есть RTT, причем RТТ к каждому хосту разный - у меня и моих друзей пинг 10ms и пакеты не теряются, пришел один товарищ у него пинги от 150ms до 650ms и 10% packet loss. Попробуйте по нему пострелять, вас ждет интересный результат. Помимо пингов есть потеря пакетов и изменение последовательности пакетов. Вне зависимости от того протокол UDP или TCP, пакеты могут приходить в разной последовательности (в TCP этот процесс неконтролируемый и выглядит как длительная задержка). Каждый packet reordering приводит к задержке равной одному пингу на пакет: пришло пять пакетов об обновлениях подряд, обработать их не получается, т.к. ждем еще один который был до них => задержка шесть пингов минимум + информация уже устарела на 5 пингов же => влетел в гору, не разбился, потом подскочил и оказался в небе. Большинство алгоритмов умнее и стараются долго не ждать, но отсутсвие информации не заменить ничем, любая интерполяция - это гадание.

Вы небось из тех, кто до самой смерти в вечный двигатель верит, да? Есть такая штука как законы природы в общем и законы модели в частности. В реальном мире есть абсолютный предел скорости передачи информации - скорость света. В DCS есть тоже абсолютный предел скорости передачи информации - скорость связи. Информация ни об одном событии не может распространится быстрее чем пакеты будут доставлены. В некоторых случаях требуется несколько пакетов к каждому peer чтобы сообщить о событии, т.е. уже имеет значение RTT (round-trip time). А если информация теряется, то ее нужно повторять, через задержку, т.е. задержки при плохой связи одного или нескольких участников могут быть секундные. В распределенных системах не существует "событие X во время T0" - информация о событии распространяется неравномерно и теряется в процессе, т.е. можно говорить о том что событие X (например попадание ракеты) может быть произошло с какой-то вероятностью во время T0 +/- Terror в радиусе R. Если скорости Mach 4, а Terror - секунды, то R может исчислятся километрами. Говорить можно только об относительной одновременности (relativity of simultaneity). Когда вы играете в локалке, Terror стабильно и исчисляется десятками или сотнями микросекунд, т.е. вероятности высокие, а радиусы маленькие. Вам кажется, что игра работает как в оффлайне. Когда игра в интернете из Бобруйска по DSL с допотопной АТС, то Terror будет секундное, радиусы километровые, а вероятности как монетку подбросил. Вам кажется, что игра сбоит. Алгоритм при этом, может быть одним и тем же. Я смотрю вы хорошо учились в школе. Пару килограмм нуль-траспортировки и единорога вам не завернуть? Вот посмотрите как в других играх делается "онлайн похожим на оффлайн". DayZ Arma2, на сервере под 30+ человек. Автобус ездит внутри домов, потом вдруг перескакивает обратно на дорогу, уезжает в лес, и т.п. Никакого сбоя алгоритма нет, есть информация, которая задерживается и теряется при передаче. С 6:45. PS: Невежество - великая сила.

Складывается впечатление, что на дворе ранние 90ые и про компьютеры кто-то что-то слышал, но руками сам не трогал, а сети известны только рыболовные. Существует такая вещь как десинхронизация в multiplayer. В зависимости от архитектуры, или каждый сервер следит за "своими" объектами и выдает информацию об их состоянии всем остальным в группе, или один сервер следит за всеми объектами и выдает информацию о всех объектах всем клиентам. В обоих случаях возможна десинхронизация, т.к. информация об обновлениях может теряться по пути к клиентам как в первом так и во втором случае, а в первом необходимы атомарные системы разрешения конфликтов и координации пересечений и столкновений, информация о которых должна быть одинакова у всех. Ракета летит со скоростью Mach 4, т.е. 1.3 км\с. Десинхронизация в пол-секунды дает промах в 0.65 км. Опять же в зависимости от сетевой архитектуры, десинхронизация на разных машинах будет разной, в первом случае она может быть ОЧЕНЬ разной (зависит от частоты транзакционной синхронизации между членами группы), во втором случае будет зависеть от пингов и потери пакетов на каждом конкретном хосте. Т.о. во-первых в сетевой игре сколько игроков столько различных треков (которые пересекаются в какой-то немаленькой эпсилон-окрестности), во-вторых отличить сбой модели от лага будет ОЧЕНЬ сложно (в случае пиринговой архитектуры значительно сложнее чем в случае с клиент-сервер). Вы платите $40 за игру, а не $40 тыс, поэтому 2 программистам тратить 3 недели на поиск чего-то, что может быть обычной потерей пакетов совершенно разорительно. Хотите помочь? Покупаете N (N > 10) игровых компов (чем больше тем лучше) с одинаковыми top-shelf гигабитками, хорошую медь (CAT-5e+/350MHz+), switch со store-and-forward, прогоняете тесты на потерю пакетов ото всех ко всем и убеждаетесь, что пинги остаются микросекундными на нескольких мегабайтах трафика, а пакеты не теряются. После этого играете, записываете и если проблема все еще там отсылаете треки, по ним уже можно будет разговаривать. Все это потребует каких-то 100 - 150 человеко-часов и $15-20 тыс железа. Дерзайте.

Не надо читать Википедию как библию, там информация не обновляется регулярно и нужно ходить по ссылкам. К сентябрю 2013 F-15 c AESA (v2 + v3) должно быть 54. Т.е. v3 как минимум 26 уже. В общей сложности планируется только 178 AESA F-15C/D, а к 2025 году их уже спишут, т.е. чуть меньше трети проапгрейдят к началу FY2014. 120D универсальна, но как раз F-22 с AIM-120D еще не летает, пока не закончат патчить софт до 3.1а.

Человек хочет ТТХ приближенные к реальным. Реальные ТТХ F-15C вот такие.

Я про текущее положение вещей.

CBU-97 стоит $360000, т.е. где-то 30% от стоимости одного AIM-120D.

Кстати да :) AIM-9X Block II. :)

Если подробно переносить ТТХ, то на F-15C стоят AN/APG-63(V)2/3 и висят ракеты AIM-120D (C-8 ). Может получится неудобно. :)

Возможно. Называется это Interrupted Continuous Wave Illumination. В ракетах В-В это не реализуют в США, т.к. у AIM-120 своя голова наведения, но вот в RIM-162 ESSM и SM-2 Block III/MU2 это все есть и AESA может выдавать целеуказание десяткам ракет одновременно. ICWI приделывается софтом к полуактивной голове.

Там еще и F-18 (какой-то) упоминается.

Как в симуляции я не знаю, но там 0.945кг октола. :)

BLU-108 имеет активное наведение.

Сказано на 30 сек, что Р-73 имеет макс дальность 30 км, т.е. 19 миль, 16 ммиль. В конце показывают скриншоты сайтов и там какие-то числа в скобочках.

Поезд ушел с патентами. Также медленно разлагается при температуре ниже температуры кипения, т.е. просто со временем (стр 3). К трению и удару в 2 раза более чувствителен чем RDX, в 5 раз более чувствителен чем AP (стр 20, таб 1.8 ). Там же в 1.3.4.1, на стр 17, без ссылок, сказано что заводов по производству ADN в России больше нет.

Динитрамид аммония открыли в СССР в 70-ых(!), тут же засекретили, но как отдельностоящий окислитель так и не использовали (только в смеси). В США частная компания SRI открыла его же в 1989-ом, запатентовала по всему миру, после чего СССР разгласил, что открыли первыми, но поезд-то уже ушел. Проблема этого "нового" ADN в том, что помимо дороговизны он охотно детонирует и разлагается на свету.

Помнится Аршавин, набегавшись, что-то тоже интересное сказал в этом самом контексте. :music_whistling:

Вы этого не слышите, вы это додумываете. Ничего из вышесказанного я не говорил - вы выдаете свои комплексы за мои слова. Еще раз: Факт №1: русскоговорящего населения планеты (родной + другие) - 258 млн. Факт №2: англоговорящего населения планеты (родной + другие) - 1.8 млрд. Факт №3: английский - международный язык бизнес, технического и научного общения; русский таковым не является. Это не плохо (убого) и ни хорошо (круто) - это факт, такой же как и то, что сейчас в северном полушарии осень, а в южном - весна. Факт №4: английскую версию можно продать большему количеству клиентов за большие деньги с клиента. Все остальное, про убогость и крутость - это исключительно вербализация ваших личных комплексов, не более. Вам уже даже ED указали не читать между строк и додумывать за автора, а читать, что написано. Если бы я хотел сказать, что русский "убогий", я бы так и сказал, хотя, в этом случае, скорее всего, сказал бы это по-английски. :smilewink:

Во-первых, я вас обоих забыл спросить. Во-вторых, это ветка русскоязычная, а не русская. В третьих, вы лоббируете свои интересы, я лоббирую свои. В моих интересах, как клиента, чтобы у ED были высокие продажи, куча денег и возможность нанять больше народа для производства большего кол-ва модулей, и чтобы они не отвлекались на вещи которые не позволят увеличить производство, такие как перевод на русский, украинский, монгольский, суахили и квебексий диалект французского. Вы имеете полное право критиковать что вам вздумается. Но вы так же имеете право быть осмеянными за детскосадовское нытье про то как вам в самолете не поставили русские тултипы, и как это просто совершенно убивает весь игровой процесс и как это обязательно нужно сделать ПРЯМО СЕЙЧАС И ДАЖЕ ВЧЕРА, даже если подобный шаг пойдет компании в убыток. Незнание английского языка на уровне "международного английского" или хотя бы на уровне достаточном для игры в LoMac/FC/DCSW, в современном мире есть не признак патриотизма, духовности, соборности и кавайности, а простого невежества - точно так же как незнание таблицы умножения. И мне, как клиенту которых хочет покупать продукт этой компании и в будущем, не очень понятно зачем ED, в таком случае, должно концентрироваться на очень узком рынке, который еще и, в следствие вышеуказанного невежества, будет иметь весьма ограниченную покупательную способность. И, в последних, только очень закомплексованный человек может перейти от разговора об экономической целесообразности локализации к таки евrейскому вопросу. Настоятельно советую перехать upstate и поменять профессию на инженерно-юридическо-медицинско-научную. Можете вдруг выяснить, что ваши комлексы неполноценности связаны не с национальным происхождением, а с родом деятельности и уровнем дохода.