GPCracker

Это ты в игре можешь оценивать человека по стате как игрока, хорошего или плохого. Здесь нет игроков, есть пользователи модификации и просто посетители. И мы не статой меряемся, а мод обсуждаем и разрабатываем. Так что еще раз прошу воздержаться от неконструктива и офтопа, пишем исключительно по теме. Все офтопы в ЛС и в специальный раздел. Контур в первую очередь предназначен для обозначения и подсветки техники. Бронепробитие показывает маркер. Этого вполне достаточно, ИМХО. Тем боле пробой сильно зависит от точки попадания в противника. А рандом... он такой рандомный, тем более у картохи.

А что там думать? Дописать пару строк кода в нужное место и делов. Если тебе прямо хочется этим пострадать - го в ЛС, расскажу, чтобы тут не офтопить. А фич/баг-лист только на AAS уже неслабый накопился за семестр, не говоря уже про другие моды.

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

Внимание всем! Что касается обновы. Картошка перепилила часть классов на уровне движка игры. За счет этого они немного смогли в оптимизацию. Для выравнивания движка и питона игры перепилили корневые классы. Сейчас за отрисовку контуров отвечает другой класс, поэтому нужно переносить хуки и немного менять логику. Делов не на 5 минут далеко, и тестировать в процессе нужно, так что быстро пофиксить не получится. Тем более, у меня сейчас сессия. Вылеты скорее всего именно из-за рассинхрона между старыми методами интеграции и неподконтрольностью им нового класса, по сути, из-за непоследовательной обработки. Костыли, которые мешали коду картохи вмешиваться в процесс добавления/удаления контуров и позволяли полностью обрабатывать данный процесс моду больше не работают. Так что обнова/хотфикс будет КТТС. Да, и рекомендую прекратить неконструктивное и неинформативное общение в теме дабы не напрягать всех остальных чтением этого диалога. Для подобного есть ЛС и отдельный раздел на форуме. Если у кого-то есть информация по поводу вылетов, связанных с контурами, высказываться можно, но конструктивно и информативно.

Обсуждалось, и не раз. Пока не представляется возможным. И есть более приоритетные задачи.

КЭП. Забанят сразу, инфа 100%. За скрипты, мешающие нормальному функционированию игры. И нечестное поведение. Два выстрела с малым кд по адекватному игроку - и картоха ловит репорт с реплеем в саппорт, а ты получаешь заслуженный бан.

Ну смотря что нужно - если передать - пост выше. Если попросить - обратиться к свойству нужного объекта флешки как к обычному питоновскому. Насчет того, как юзать DAAPI и EI и как оно вообще работает, написано тут

С чего ты взял, что тут виноват мод? Скрипты, приведенные выше, не имеют ИМХО никакого отношения к моду.

Он походу тут всех за***ть решил... На рейтинг глянь)

Без него я не играю. Другой вопрос что я уже давно не катал... А вот это точно к моду не имеет никакого отношения.

Адаптировать нужно именно скобки, а никак не мой мод. Это уже не ко мне. Что имеется в виду под стратегическим и арт-режимом?

Не понял вопроса.

Все подробно обсуждалось и не раз. Я даже описывал алгоритмы. Читай внимательно форум и описания функционала. Народ, никто не наблюдал случаем подобных проблем?

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

Потому что кому-то стоит перечитать доки на питон. Ибо то, что происходит вполне логично.Значение любой переменной в питоне есть ссылка на объект. Не сам объект, а именно ссылка на него. Поэтому меняя значение переменной, ты меняешь не объект, а ссылку. Копируя значение, ты копируешь ссылку, сам объект не копируется. Это объясняет два явления: 1. Импорт функции, который произошел до установки хука, скопировал ссылку на старый объект. Поэтому и не работает. 2. Изменение атрибутов класса затрагивает все объекты этого класса, ибо объект подтягивает методы из класса. Упрощенный пример, в комментах аналогия >>>a = 5 # function def >>>b = a # function import >>>a = 6 # hook install >>>print b # imported function call 5Бесплатный совет: не ставь хуки на независимые функции (функции модуля).

-del- З.Ы. В код особо не вдавался. Поэтому не сразу понял прикол. WG API, как я понял, не выдает нужной инфы. А получить ее по-другому проблематично? М.б. не переписывать файл кэша энциклопедии, а просто грамотно его патчить? Или вообще патчить централизованно, а получать например как-то так? З.Ы. Хранить данные замены в самом скрипте - не самая лучшая идея. З.Ы.Ы. И чего-то пошуршал-пошуршал и наткнулся на это Вообще, отказоустойчивость - весьма важная характеристика. Чем реже требуется обновлять мод, тем оно лучше, ИМХО.

А еще, лично мне по крайней мере, не хватает кнопочки "посмотреть историю только непросмотренных уведомлений". А то когда понакидают 10+ постов новых, сиди и считай их в полной истории. Как говорится, чем больше, тем веселее... Или я чего-то не знаю?

Пункт 3 это из разряда "местные эксперты советуют", пункт 2 из разряда "альтернативный вариант". Возможность такого переноса впилена еще давно, просто не все про нее знают.

"Дальнейшее обсуждения тонкостей BW" С этим сейчас большие проблемы, в особенности у тех, у кого скоро сессия :(

Спроси у @Xotabych.

Я давненько уже не катаю, задача была оперативно пофиксить, разбираться было особо некогда. Насчет метода, да, я уже в курсе про эту тему с наследованием. Но все равно спасибо за инфу :) Вижу вы там на 4ке оперативно в модах копаетесь :)

Тут не так все просто. Удалить/добавить тег - этого мало. Нужно распределить танки на группы таким образом, чтобы у каждой группы был свой контур, и эти группы не пересекались, т.е. не должно существовать такого танка ни в один момент времени, который будет находиться сразу в двух группах. Это написано черным по белому (ну или у кого как) в конфиге и я не раз это уже говорил в теме. Удаляя тег в блоке include ты расширяешь группу, удаляя обязательность для танка соответствовать какому-то требованию. Соответственно, если группа А требует тег Х (include), группа B требует отсутствие тега Х (exclude), то удаляя тег Х из селектора группы А, ты обозначаешь, что для группы А значение тега неважно. В таком случае возникает спорный момент, и танк без тега Х попадает сразу в обе группы, что приводит к выбрасыванию соответствующего исключения (ошибки) с последующим возможным крашем мода. Это обусловлено ограничениями движка игры, что невозможно удалять конкретный контур у танка. Поэтому контура добавляются и удаляются синхронно. Это и является причиной блокировки мультиселекта (явления, описанного выше). Ключевой подход к организации необходимой структуры заключается в том, что если группа А требует тег Х, то группа В должна требовать отсутствие Х, либо возможность пересечения групп должна блокироваться спецификой тега. Например, если группа А требует ally & player (техника игрока), группа B (союзники) требует ally & !player (думаю, выражение понятно, теги без ! в include, c ! в exclude), группа С - !ally, то пересечений между группами быть не может, это очевидно. Кстати, для группы A достаточно написать просто player, поскольку player всегда ally. Аналогичный подход осуществляется и по части остальных тегов. К примеру, нам нужно подсвечивать противников только в прицеле (А) и союзников только в прицеле (И) + союзников не в прицеле (С) другим цветом и самого игрока постоянным контуром (D). Для этого есть тег target. Общие наборы тегов будут такими A (!ally & target), B (ally & !player & target), C (ally & !player & !target), D (ally & player). Про необходимость тега ally вместе с player я уже говорил, но привожу такие примеры чисто для наглядности алгоритма. Для упрощения написания структуры тегов удобнее использовать граф ветвлением на 2 - граф деления по тегу на две категории - есть и нет тега. Неиспользуемые группы (для которых контур не нужен) прописывать в конфиг нет необходимости.

К фразе "не работает" и другим ее вариациям с подобным смыслом следует прикладывать логи и описание происходящего. З.Ы. Сколько раз уже нужно об этом сказать, чтобы народ это без подсказки делал? Как гласит народная мудрость, правильно заданный вопрос содержит половину ответа.

"Дальнейшее обсуждения тонкостей BW"

Порылся в очередной раз в доках BW и немного поигрался с клиентом. Атрибута matrix там нет, поскольку, ... сходу и не заметишь :)только напрягает один момент - наследование идет не от MatrixProvider, а от MatrixProviderLiaison, последнее слово в переводе "связь", возможно это локальная матрица, нужно проверять... хотя с другой стороны, зачем тогда атрибут local? В общем, по докам BW вопросов больше чем ответов. Пока не потестишь хрен поймешь. А насчет статичного матрикса - он и вправду мне нафиг не нужен - в динамических расчетах эта хрень просто адски будет жрать ресурсы. Это я к теме про маркеры на миникарте интересуюсь - ищу более адекватные варианты чем тупо перемножать матрицы. эээ что-то я не совсем понял. Через node compoundModel'и с именем этой части ты получаешь ноду, к которой аттачится другая модель (модель наследуется от аттача), assembler.addPart(gun, TankNodeNames.GUN_JOINT, TankPartNames.GUN, skeleton.gun, mathUtils.createIdentityMatrix())которой потом управляют через локальную матрицу, последнюю, как я понимаю, прикручивают подобным образом self.__compoundModel.node(TankPartNames.TURRET, self.turretMatrix)т.е. self.turretMatrix это локальная матрица орудия.Влез в старый VehicleAppearance turret = self.modelsDesc['turret'] gun = self.modelsDesc['gun'] gun['_node'] = turret['model'].node('HP_gunJoint') gun['_node'].attach(gun['model'])Те же яйца, только в профиль.Опять залез в доку. Наткнулся на комментарий типа Attaching it causes the attachment to appear with its root node with the same position and rotation as this node.Написано что параметры ноды, к которой аттачишь и рута аттача соответствуют по параметрам... Но в то же время не сказано, что это одно и то же.И к тому же, получить по ноде модель (от которой можно получить world-matrix-provider), которой она принадлежит, тоже не вариант. Хотя в то же время модельки по прежнему подсасываются из vehicle.typeDescriptor. По сути, старое работало как-то типа BigWorld.Model(vehicle.typeDescriptor.gun['models'][vehicle.appearance.damageState.modelState]) В новом варианте имя модели улетает сразу на движок, подцепиться к модели ствола уже не вариант... Хотя я кажется понял смысл из патча - они убрали отдельную модель (PyObject) и тем самым похерив расчеты, которые для нее велись, получили прирост производительности. Хмм... Походу единственный вариант получения информации о положении ствола - это анализ ноды, к которой прикреплен ствол. Самое что интересное, они и ноду саму по себе пропатчили, как минимум, один атрибут дописали точно. Короч, обновленная дока с описанием Компаунда явно лишней не будет.