Matpocob

Живая видеоинструкция по эксплуатации и обслуживанию техники Второй мировой. Автор (думаю целая команда) находит и реставрирует оригинальные учебные фильмы (часто немецкие, с аутентичной озвучкой и субтитрами, есть японские, английские и американские), по которым готовили техников и пилотов. Это уникальная возможность увидеть, как на самом деле «закручивали гайки», заправляли баки и проверяли системы самолетов, которые сегодня считаются легендами. Очень рекомендую. Затравочный: Maintenance of the Dornier Do 217 bomber Канал: Look in The Past War Archives

хроническая вербализация негативных переживаний направленная на поиск решения проблем Злодей, Руслан, это ловушка! Они тебя вводят в заблуждение! И раз мы в теме предложений! Я предлагаю игнорировать эти манипуляции! Гляньте-ка, ну, ну гляньте, самолёты они на посадке ломают и видите ли денег за это хотят, ух пфх..., шх.. ахты.. су..ёп... где мой тапок? Я сейчас здесь всё задамажу!

Пытаться притянуть за уши теорию о том, что И-16 был украден или скопирован с Gee Bee Model Z, может только человек, бесконечно далекий от авиации. Наличие лицензионного двигателя и общая компоновочная схема не делают самолет копией. Это спор ни о чём. Чистейшей воды "пердёж в лужу собственной мочи", того, кто придумал так гнать в адрес Поликарпова, нужно как минимум пожизненно лишить права рассуждать об авиации - за профнепригодность и неуважение к конструкторскому наследию, кастрировать и оскоблить для верности.

А это тогда как назовём? xD

Преждевременное финиширование "Коммандера", опытным путём установлено, что он завершает свою работу за 2 минуты до фактического конца миссии, и это делает больно. Ситуация: миссия 160 минут (с 08:17 до 10:57). Я приземлился в 10:54 на полосу, короткий пробег не более 30 метров и остановка, начал разгрузку, а в 10:55 "Коммандер" уже обрубает всё с сообщением, что после этой отметки ничего не учитывается. В итоге, хотя самолет и груз доставлены, я получаю минус по баллам. Можно ли как-то подправить этот таймер или хотя бы сделать оповещения честными? Если он всё равно отключается на 2 минуты раньше, может, пусть он пишет "осталось 8 минут" вместо "осталось 10"? Чтобы игроки понимали реальный дедлайн и не теряли прогресс в самом финале 20-ти минутного вылета не успев буквально на 20 секунд с выгрузкой, потому, что коммандер рвет провод за 120 секунд до своего фактического срока из сообщений (ранее он минуту воровал, а теперь с запасом прихватил две). В конце концов, раз в момент отключения коммандера, мой самолет цел, на полосе, экипаж жив и даже если груз не выгружен, то хотябы 0 давать, а не минус по очкам? Без наездов, просто мысли в эфир.

PS: А если серьезно, то смерть, она на то и смерть, чтобы РАЗ в ВСЁ. Без гипотез о реинкарнации и спасении "души".

Остап явственно понимал, что оппонент пошёл на удушающий, он принялся давить на святое, в самый центр его жадности ... эта пытка была, невыносима. Оказалось, что-то всё чего он так давно и страстно желал было уже доступно, стоило ему только раздобыть достаточно денег на донат... Как, всё-таки жаль его, бродягу, мечтающего о Рио-де-Жанейро. Мечтам не всегда положено сбыться. Заседание можно считать закрытым, граждане присяжные и заседатели. Расходимся. P.S.: Тему можем закрывать в архив, для благодарных потомков.

Суть нашего общения как раз в том, что "последовательность" в журнале вылета - это лишь отражение того, в каком порядке события "плюхнулись" в базу данных или были обработаны скриптом. Если тайминг плавает, значит, нарушается причинно-следственная связь, а это уже не "объективный лог", а просто список действий. Предлагать мне запустить свой сервер для проверки логично, но это лишь подтвердит, что на своем сервере я получу свои логи, а не те, что выдает ваш API. Разница в том, как именно ваша система парсит и выдает эти данные наружу. Не злись, я уже разобрался. Как я и говорил, "вопросов по архитектуре системы стало меньше". А твой ответ про "неважность времени" лишь подтвердил мои догадки о том, как это работает. ...И последнее: не воспринимай это как критику кода, я пишу это как перфекционист, который болеет за UX проекта. Обиды и ссоры - это контрпродуктивная шелуха, которая только мешает достигать цели, а цель - это твой проект, максимально привлекательный, интуитивно простой и доступный любому пользователю. Сейчас лента событий выглядит перегруженной: когда урон по одной цели или пожар двигателя размазывается на десятки строк, визуальная составляющая теряется. Когда я вижу "километровую ленту" сообщений, возникает неопределенность: я нанес этот урон одной цели или "накрыл" осколками сразу десяток? ИМХО, было бы значительно удобнее, если бы логирование учитывало группировку событий: Сведение урона: если урон наносится одной цели в одном временном окне - логичнее суммировать его в одну строку. Идентификация: если целей несколько - критически важно видеть их индексы/ID для понимания масштаба воздействия. Фильтр "наводнения": длительные события (вроде пожара) лучше выводить как сводное событие, а не как поток однотипных записей. Это избавит статистику от эффекта "рулона обоев" и сделает её реально читаемой. Я почему-то уверен, что многие игроки со мной согласятся - сейчас это главный барьер для восприятия данных (ну не любят люди скролить сотни метров, а статистику читать любят). Надеюсь, ты рассмотришь это как предложение по улучшению UI, а не как попытку учить программированию (я околофутбола, мне просто хочется больше комфорта для себя, ну и для всех остальных конечно пусть это вот...)

Однако, теперь стало понятно, в чем суть разночтений по таймингам: если статистика строится не на временных метках самого движка, а на времени обработки события твоим скриптом записи в базу, то итоговая хронология, я полагаю, напрямую зависит от очередности и скорости обработки пакетов этим же скриптом. А значит, "хронология", которую мы все видим - это не то чтобы объективный лог сервера, а лишь результирующий лог работы твоего парсера. Становятся понятны причины искажений: например при высокой нагрузке на скрипт записи реальный порядок событий в базе данных неизбежно смещается относительно реального времени. Однако подозреваю, что это найболее удобный вариант в угоду упрощения кода. Ах вижу, что тебе определенно нравятся риторические вопросы, так как прямого метода для выгрузки посекундного лога (с привязкой к тикам движка) в открытом API естественно и ожидаемо, банально нет. Там доступна только та же сводная стата, что и на сайте, а доступа к "соку" сырых логов сервера у нас, опять же совершенно логично, нет. Сваггер просто "выдыхает" ровно то же самое, что уже есть на витрине сервера в готовом виде, но это явно не то, что могло бы пролить свет на то, что и как работает. И поскольку я заранее знаю твой возможный ответ на мой следующий возможный вопрос, то задавать его просто не стану, чтобы не затягивать время и не отвлекать тебя лишний раз. В любом случае, вопросов по архитектуре системы стало меньше, любопытство почесал, спасибо за разъяснение того, как именно формируется эта стата.

Zlodey, кстати, интересный кусок, отдельное спасибо. Посмотрел на тайминги и структуру тиков - появилось пару вопросов по теме статистики, если ты будешь свободен. Правильно ли я понимаю, что ты работаешь с событийной моделью движка, где все события внутри одного тика (включая критические состояния пилота) прилетают одним паком, и серверная часть не всегда успевает отделить хронологию повреждений внутри самого тика? По сути, это "лейка с фильтрами" при API логировании движка игры, и ты сейчас обрабатываешь это через свои авторские скрипты-обертки на стороне БД. А как в таких случаях выставляется приоритет событий? Вот например, если попадание снаряда и "смерть" прилетают в рамках одного тика, скрипт пишет их в базу как одновременные, или у тебя стоит какой-то внутренний буфер для предсказания последовательности (тут и зарыта "собака" из-за которой пишется за одну секунду целая серия разнесенных в реале по времени событий)? Очень интересно, как удается выравнивать эту дискретность по сути, чтобы стата не теряла доли реализма, хочется понять границы возможностей самого движка (там где разрабы делятся, такая каша навалена, что найти, что-то для трезвой оценки... прям в край проблематично). Просто насколько мы впринципе, как клиенты, можем быть тогда требовательны к точности, если двигло ила допускает такие разбросы? И еще, там небось "мусора" сыпет выше крыши, нет ли шанса упустить на фильтрации такого потока, что-то важное? Только не злись, я ж в роли подглядывателя под локтем не по своей воле, работу не прошу, просто любопытство чешется.

Это тебя еще свои не сбивали, там вообще "щикардос", мой тебе совет, забудь, времени не стоит. К слову о времени и экономии, пока ты тянул раненую пешку на одном движке, потея над триммерами, ты мог уже сделать новый вылет, закрыть цель и перекрыть убыток по очкам. Героизм в стате - штука убыточная, тут математика важнее подвигов. "Система работает так как задумано и менять ничего не планируется".

Я указал буквально: "если есть техническая возможность". Раз это настолько сложно или невозможно (читай "нецелесообразно") реализовать в рамках вашего текущего функционала, то опустим этот вопрос, он закрыт. Я "жыж" не претендую на доступ к закрытому коду или перестройку архитектуры сервера, просто предложил идею для развития геймплея. Живите долго и процветайте.

А если грузовики разные, есть ли вариант выводить инфу по ним, через %n (ID: %i), например? Ты только не хмурься, у вас в прем.стате прям всё классно расписано, мы любим мелочи, почему бы тогда и нет? Детализация погружает в атмосферу (если есть техническая возможность).

Заказал себе на амазоне эту пушку-ракету, жду когда привезут!

Ханко, не кипишуй. В условиях местной "диктатуры" цитирование администрации - это уже риск. Могут и думать матом запретить, если у кого-то настроение будет не в масть. Прямо по Родари: "С тех пор как мы ввели налог на воздух, вы стали реже дышать! Это возмутительно!". Дышим реже, вдыхаем носом, держим подольше, выдыхаем в карман, про запас... Кстати, к вопросу о механиках и "воздухе": Заметил странный рецидив в логах. При сбитии (пилот 210_OMAKC постарался) статистика схлопнула все события - от попадания до моего фактического крушения - в одну секунду. Хотя по факту я еще прилично "свистел" до земли, и смерть пилота наступила именно в момент удара (я кувыркался ну никак не менее 6-8 секунд). Насколько я помню, Zlodey этот момент ранее фиксил: добавлялись проверки логических состояний в скрипты, чтобы события разносились по таймингам. Сейчас же опять видим "кучу малу" в статистике. Это какой-то откат версии или логика условий снова начала давать сбои при определенных триггерах? Хотелось бы ясности по этому механизму, а то стата превращается в гадание на кофейной гуще.