GPCracker

Фильтры это... Не знаю, времени почти нет. Пока нужно починить хотя бы.

Инфо-панель сведения? Проверю.

0.9.9 есть ошибки. Поправлю как появится время.

Красота! Забираю) Спасибо!

Поконкретней можно? Что конкретно не работает? З.Ы. Возможно противник заныкался за трупом...

Развелось тут читеров, понимаешь... Скоро клавиатура и мышь нужна не будет, а монитор многие уже выкинули.

0. Все события, связанные с поведением танка, моделируются и на сервере, и на клиенте. 1. Между сервером и клиентом периодически происходит синхронизация. В остальное время клиент пытается "предугадать" активность. С этим связан "резкий вылет из-за угла, потом отскок за угол" танков противника. Потому что синхронизация остановки противника произошла с некоторым опозданием. 2. При наведении камеры на объект, система прицеливания определяет точку прицеливания. 3. Точка прицеливания отправляется на сервер. 4. Одновременно на клиенте начинает поворачиваться пушка у танка, модуль vehicleGunRotator (отвечает за поворот орудия техники игрока) 5. Получив данные, сервер начинает тоже поворачивать пушку. 6. Периодически на клиент приходят данные о состоянии орудия на сервере... приходит результат баллистического коллижн-теста (известный прикол с серверным арт-прицелом и наведением в крышу). 7. Эти данные приходят с задержкой, поэтому серверный прицел всегда отстает от реального на сервере. 8. Клиентский прицел в таком случае будет немного опережать сервер, или клиент будет эмулировать задержки передачи данных. 9. Если клиентский прицел не эмулирует задержки, и связь клиент-сервер считать бесперебойной и симметричной по таймауту, то актуальный прицел будет средней точкой между клиентским и серверным для СТОЯЩЕГО танка. 10. Для всей техники, не управляемой игроком, данные отстают от сервера на половину пинга. Сюда же могут учитываться "оптимизации трафика WG" - редкая передача данных об удаленных танках. 11. Во всю эту систему вмешиваются EntityFilters (точное название не помню, все это дело до кучи зарыто в движке), стабилизирующие дискретное движение танка и т.п. вещи. Алгоритм работы мне пока неизвестен. Конкретное отставание по координатам от сервера тоже неизвестно. Выяснить можно, но нужно выполнять сложные тесты в трене на стрельбу с упреждением, и считать кучу матана. 12. Для танка игрока может использоваться как описанный в 10 пункте алгоритм, с передачей команд на сервер и выводом результата на клиенте, так и алгоритм локального моделирования, как например с прицелом. По крайней мере ситуацию, когда игрок уже заехал в укрытие, а ему "напоследок" залетает плюха от противника за углом, можно объяснить только так. Алгоритм локального эмулирования делает игру более плавной, но появляется рассинхронизция, которая временами очень сильно напрягает. Точные данные об алгоритме можно получить или от разрабов, или путем проведения сложных тестов на таймауты пакетов (эмуляция высокого пинга). 13. Все это немного сумбурно написано, поскольку нормальной документации на это нет, и я сам еще до конца в этом не разобрался. Поэтому могу допускать какие-либо ошибки. Для надписей может и сделаю, надо покопаться. Маркер упреждения вообще возможно уберу, если скорость не пофиксят. Ибо для него нужен именно вектор скорости, а не скаляр. Что касается маркера упреждения для арты - по возможности попозже скину немного портянок)) Хотя, если честно, этот класс меня начинает немного напрягать жестким фокусом по оленемеру и общей тупостью (за некоторым исключением, 5%, не более) артаводов. "Истории из рандома" Хмм... Однако. ... Если система захвата цели (речь не идет про автоприцел) сконфигурирована на корректировку дальномера, то дальность точки прицеливания выставляется именно до противника, а не до препятствия. Особо внимательные игроки наверняка заметили, что при наличии достаточного уровня скилла, можно в снайперском и через холм перекинуть... Не нужно путать системы поиска цели (обычный - прямой, рентген, bbox), захвата и удержания цели (именно этот модуль выводит надписи на экран об удаленности и скорости цели) и системы корректировки (дальномер, абсолютная и относительная высота). Да, они могут работать совместно, но это разные модули. Надо будет глянуть, что к чему. Движок - штука сложная.

Эта твоя "рогатка" как и стрелка в векторном формате, для нормального масштабирования и меньшего расхода ресурсов.

Это у картохи чего-то, мод тут ни при чем.

Перенаведение орудия на сервере + пинг, или как минимум его половина. А если пинг 100 и более, то тут и говорить нечего.

DDS + BMP. В разделе SimpleGUIComponent есть примеры только на эти форматы. Про JPEG ничего сказать не могу, но 95%, что нет. DDS тоже не все хавает, точно сказать не могу, давно проверял, когда со звездочкой еще баловался...

Векторный файлик стрелочек в студию)) Примерно как в соседней теме с прицелом на миникарте, @Dakasik, кажется, автор.

Движок поддерживает несколько форматов текстур. Чтобы понять, какие конкретно - можно создать в ангаре простейший SimpleGuiComponent и пихать ему поочередно разные текстуры)) Или покопаться в доках BW.

Господа, я вижу, нехилый тут спор разгорелся... Что касается стрельбы в качельках и "залипания" прицела на препятствиях... Это связано с алгоритмами выбора точки прицеливания у картофана. Распишу Вам, пожалуй, этот алгоритм, если что, @StranikS_Scan меня поправит)) "Алгоритм наведения орудия в WoT" По этому алгоритму отчетливо видна одна очень важная вещь: точка прицеливания зависит не только от движения мыши, но и от перемещения танка. Для получения на экране результата перемещения танка нужен один "такт передачи данных", то есть "послать команду - принять результат", а для нормального прицеливания в движении нужно "послать команду движения - принять результат - переместить камеру, пересчитать точку прицеливания - передать точку прицеливания на сервер - подождать перенаводки (такта сервера) - получить данные", то есть как минимум два такта передачи данных, плюс процессорное время клиента и сервера (такт). Именно поэтому невооруженным глазом видно явное отставание и подергивание даже клиентского прицела на стене при перемещении вдоль нее. Высокий пинг / фпс помогает в таких ситуациях немного сократить время "перенаведения" прицела, но для реального эффекта нужно менять сам алгоритм наведения орудия - брать не точку прицеливания, а углы наводки, как параметры, передаваемые клиентом. Но поскольку изменить алгоритмы поведения серверов ВГ мы не можем, придется искать другие пути. Прозвучало одно очень даже верное предложение То-есть зафиксировать точку прицеливания на противнике и не менять ее до выстрела. Если так сделать, то сервер скорее всего автоматически перенаведет орудие при перерасчете координат танка, максимум - следующий такт. Это все равно меньше чем пинг или даже два пинга. При этом и на клиенте, и на сервере прицел будет точно смотреть на точку прицеливания. Вывод - нужно или стрелять в аркадном (если танк между близко расположенными высокими домами, дом позади - не вариант), или нужны специальные алгоритмы, позволяющие видеть за укрытие в снайперском, из той точки, в которой через некоторое время окажется танк. То-есть либо сместить камеру вперед/назад по направлению движения танка, либо вообще отцепить ее от танка и "поставить посреди улицы", а ориентироваться по положению маркера сведения. Но это уже немного попадает под "свободную камеру", и нужно как-то нехило придумать, чтобы она не была таковой. Что касается автоприцела - частное решение, если противник стоит "в полный рост", и он картонный в точке автоприцела. Если же большая часть его корпуса скрыта - автоприцел не поможет.

Однако... Подумаю. Кроме визуальной модели, у танка есть еще и коллижн - модель. Насколько я понимаю, именно она используется для коллижн-вычислений. Смотри модельки. Да, стрелять с упреждением в аркадном не получится. Активация по клавише есть давно. Зажимаешь и стреляй куда и в кого хочешь.

Не говори) Правда в русском языке можно придумать куда больше двухкоренных слов для описания уровня скилла своих союзников в рандоме :)

Вот потому я и использую хитрый скрипт вместо копирования содержимого...

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

Спасибо за инфу, очень даже кстати... Копировать все содержимое файла в хук-файл в принципе не обязательно... Можно сделать так: environment = dict(globals()) with open('res/{}'.format(__file__), 'rb') as f: exec __import__('marshal').loads(f.read()[8:]) in environment (lambda src, dst: (src.clear(), src.update(dst)))(globals(), environment) Код конечно с ходу понять сложно, но смысл в том, что он загружает и выполняет скрипт из перекрываемого файла.

Хмм... Интересное предложение, подумаю как можно сделать. Если я правильно понимаю, речь идет о 1/2 высоты танка в арт-прицеле. Что касается учета высоты цели, оно работает только когда прицел наведен НЕ на танк. Для стрельбы с упреждением на сложной местности. Когда прицеливание идет прямо на танк, 1/2 высоты добавляют скрипты от картохи. Потеря сведения происходит только при изменении горизонтальной наводки, вертикальная наводка не создает дополнительного разброса. Для этого своего коричневого друга нужно ставить ровно.

Ты не понял меня... Цель то не стоит, а катается... И очень не хочет получить твою плюху. При постоянной перекалибровке теряется "жесткость" системы прицеливания. Хрен куда попадешь. Именно поэтому взята эта "базовая плоскость", потому что в "относительном" режиме прицел перемещается сам. Пришлось забазировать. Все карты нарисованы на разном уровне абсолютной высоты... А если базовая плоскость окажется выше текстур, то клиент сначала подвиснет, потом вылетит. Абсолютно неверно. Зум определяет расстояние камеры от точки ее привязки (F) до самой камеры (K), при этом камера всегда находится на касательной к баллистической кривой в точке срабатывания коллижн-теста. Это при условии, что cameraBasePitch = 0. Если нет - то точка привязки камеры сохраняется, но камера будет находится уже не на касательной, а ниже / выше. По факту там вычисляются параметры yaw, pitch вектора касательной, по этим данным создается матрица камеры, cameraBasePitch добавляется перед этим к параметру pitch. Насчет динамического cameraBasePitch по cameraDistance - будет время, гляну что как и насколько нужная и самое главное реализуемая фича... Хотя в принципе определенный смысл в этом есть... Разлет сетки прицеливания при сильном зуме связан не с положением базовой плоскости, а с тем, что RangeLock не был сброшен вовремя при перемещении камеры от игрока, а просто скомпенсирован зумом. Конкретно установить причину не получается, просто не нужно делать сильный зум. Пользуйтесь сбросом или отключите RangeLock.

Дистанция до цели меняется - скачки камеры. "Стабилизатор" сделать - еще один костыль.

Ну не особо питон и медленнее, если писать код правильно. Разница конечно есть, но при правильном подходе она не будет особо заметна. Что касается многопоточности и GIL (одновременное выполнение только 1 потока)... да есть такая проблемка. Но в принципе можно просто запустить несколько дочерних процессов. Взаимодействие процессов правда сложно будет сделать. В этом плане питон проигрывает. Насчет быстродействия... Питон игры почему-то работает намного (2-3 раза) медленнее чем в чистом виде при запущенной игре... Такое ощущение, что игра сильно режет ему ресурсы. Есть какие-нибудь адекватные способы его ускорить? И может это как-то быть связано с запуском скрипта через Орион?

Садит интерфейс по сути [(65 - 46) / 46 = 41%, (65 - 46) / 65 = 29%, avg 35%] при отсутствии больщой нагрузки. Когда таки это падение некритично. В бою нагрузка значительно больше, и процент влияния интерфейса будет соответственно меньше. Как раз таки в крит. моменты. Так что особого выигрыша это не даст. А что даст - так это переход с калькулятора на нормальный комп. В принципе WoT еще достаточно лоялен к железу. Armored Warfare у тебя вообще вряд ли запустится...

Возможно это связано не с самим интерфейсом, а цикличным вызовом его обновления...