GPCracker

прописать в конфиге visible false. Уже неоднократно обсуждалось. Пользуйтесь поиском. Тексты можно поменять в файле локализации, размеры в конфиге. Тоже уже обсуждалось. Похожий мод да, есть, где-то в соседних темах ищи, поиск в помощь.

Мне одному кажется, что целесообразнее писать в логе именно так, а не просто 64? Ручной лукап ерроркодов по таблице это как-то времена ламповых ПК где-то. З.Ы. Жаль что данный код прописан на С, и туда просто так не подлезешь :(

Ссылка ищется поиском по теме, ключевое слово attachment. В результате получишь все посты с прикрепленными файлами. Ищешь среди них мои :) Вот ссылка на пост. Это в соответствующую тему, вообще-то. Немного оффтопа. Маркеры пока еще на стадии альфа-теста, последняя версия ищется аналогичным способом, пока еще ничего не тестил и обновлял, даже диффы клиента не смотрел, и вряд ли в ближайшие 4-5 дней буду.

@tsymbalvitaly, используй спойлеры. Да, для сведения, посты можно редактировать. Мод грузится, а вот дальше жесть какая-то. AttributeError: 'module' object has no attribute 'PlayerAvatar' Дословно - в объекте типа "модуль" не определен атрибут PlayerAvatar. Это один ключевых файлов игры, Avatar.py. Посмотрел на декомпиле релиза - файл и класс никуда не делся, откуда у тебя эта ошибка - неясно. Вообще жесть какая-то... Какое отношение TankHangarShadowProxy имеет к загрузке модов, и почему идет повторная попытка загрузить мод? Тоже неясно. Wat?! Что за попытка загрузить xml-ку - файл конфигурации мода?! Игра должна грузить pyc, xml-ки чисто мои... А дальше опять попытка грузануть папку с модами... Что за жесть у тебя там творится на клиенте? Я б на твоем месте перекачал бы его от греха багов подальше. Upd. Перечитал еще раз твой пост с начала... Проблемы появились после установки г***опака модпака, на чистом клиенте, я так понимаю, никаких проблем не наблюдалось. Не стоит ставить первые версии модпаков сразу после релиза патча - они в лучшем случае отработаны на общем тесте, если вообще тестировались.

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

Хмм...

Найди питон-класс нужной вьюшки и посмотри. Хотя на AS3 в этой теме, по крайней мере со взводами неслабо так намутили. btnNotReady = <SquadWindow>.squadView.teamSection.btnNotReady if (btnNotReady) ... btnFight = <SquadWindow>.squadView.teamSection.btnFight if (btnFight) ... Клики на них идут в onReadyToggleClickHandler и дальше уходят в виде ивента. По ивенту оно приходит в BaseRallyRoomView, на метод onToggleReadyStateRequest, потом на DAAPI-метод toggleReadyStateRequestS()/toggleReadyStateRequest(). Находим его в питоне - BaseRallyRoomView.toggleReadyStateRequest = self.prbEntity.doAction(). Ищем дальше... Немного раскопав классы можно найти это: class prbEntityProperty(property): """ Prebattle entity access property. """ def __get__(self, obj, objType=None): """ Getter for property. Args: obj: decorated object objType: decorated object's class Returns: prebattle entity """ from gui.prb_control.dispatcher import g_prbLoader dispatcher = g_prbLoader.getDispatcher() entity = None if dispatcher is not None: entity = dispatcher.getEntity() return entityТакже в коде попадается что-то типаself.prbEntity.togglePlayerReadyAction(True).Что откуда и куда докапывай уже сам, но все действия идут на prbEntity. Статус кнопок, НЯП, обновляется ивентами (вьюшка является листенером). Поэтому лезть непосредственно в классы окна особого смысла не вижу, если тебе нужно отправить взвод в бой или поставить готовность. Надеюсь, ты там не пишешь ботов или еще чего :)

Нельзя хранить Entity внутри модов, его всегда нужно запрашивать по ID, сразу обрабатывать и "отпускать". Для Vehicle есть такая штука как isStarted, ЕМНИП, она true когда техника видима. Перед любой операцией над техникой после BigWorld.entity(id) нужно проверять результат entity = BigWorld.entity(id) if entity is not None: # do the job

А сейчас тем, что мнения адекватной части аудитории расходятся немного с картошкой, а мод я делаю для людей, а не для картошки. У "запрещал" картофана семь пятниц на неделе, сегодня говорят одно, завтра другое, а я типа успевай за ними отслеживать и править - ну их нафиг. В крайнем случае отключу сборку плагина в основном билде и все, будет отдельным файлом лежать. Того, что дает реально неадекватное преимущество игроку в моде не было и не будет. Ага, особенно когда у тебя небольшой монитор (лично у меня 1366*768, ноут), ты пытаешься играть активно на ЛТ и тебе приходится постоянно скроллить чтобы выцеливать и мониторить обстановку. Вот абсолютно нихрена не прикольно пытаться выцепить пиксель перевесом через здание в командирской камере, учитывая что над танком ВНЕ ЗАВИСИМОСТИ ОТ НАЛИЧИЯ ПРЕГРАД ВИСИТ ОГРОМНЫЙ МАРКЕР ТЕХНИКИ. Уберут отображение маркеров для невидимых напрямую танков - подумаем насчет захвата за текстурами. Там есть два параметра: useTargetScan, который подключает асинхронно сканер к процессу поиска цели, т.е. проход сканера в реалтайме, и useTargetInfo, который подтягивает данные из "той самой желтой надписи" (на деле все немного по-другому, и надпись, и подстановка используют один общий ресурс - TargetInfo), т.е. если есть активная цель, и она видима, то она будет захвачена в автоприцел вне зависимости от того, куда сейчас развернута камера. По умолчанию оба параметра выключены. Работает по принципу "до первого положительного результата", т.е. сначала смотрится стандартный target(), если там пусто - делается сканирование (если оно разрешено - useTargetScan), если опять пусто - пробуем получить танк из TargetInfo (опять же, если разрешено - useTargetInfo). Если на одном из этапов что-то найдено - оно отправляется в захват, если нет - следующий этап, не нашли ничего - ну значит ничего. Да, сам сканер настраивается в разделе настроек сканера (немного почувствовал себя Кэпом), поэтому для работы неточного захвата нужно также активировать выключенные по умолчанию расширенные сканеры целей, в частности BBox либо BEps, активация двух сразу из них особого смысла не имеет, ну и если нужен, XRay.

Сделай дамп конфига, посмотри что прочиталось, может накосячил с форматированием где... У меня в трене все четко работало.Через отладчик import sys aas = sys.modules['<gui.>mods.<mod_>AdvancedAimingSystem'] import pprint pprint.pprint(aas._config_)То что в уголках - это зависит от того, откуда мод загружается... Ну думаю очевидно.Если не будет ошибок, то конфиг должен вывалиться в лог питона. Об этом уже давно нехилая часть аудитории говорит. Но картошка редко когда делает что-то по-нормальному. В этом и проблема. "Картошка как всегда". Эээ там же вроде на общий конфиг мода подвязано... Должно в течении сессии работать.

У кого наблюдаются проблемы, прошу прикреплять логи. В чем проблема с автозахватом? я не совсем понял, что имеется ввиду - внутренний или автоприцел?

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

"def callback( time, function ): Registers a callback function to be called after a certain time, but not before the next tick. The callback is executed once and is not automatically repeated, so reset the callback again if regular updates are needed. If multiple callbacks are due to be executed within a single frame, the chronological order in which they were added is maintained. Parameters: time A float describing the delay in seconds before function is called. If a time of 0 is given, then it is guaranteed to be called on the next frame. function Function to call. This function must take 0 arguments. Returns: int A handle that can be used to cancel the callback." Это цитата из документации. Ноль, да, на паузе работает, а вот время для колобков на паузе замирает, на задержках тоже тормозится. Как и BigWorld.time(). Колобок - это в данном случае костыль, по принципу Вовки из известного мультика. Нормальным образом это таймер с флешки. А теперь прикинь, ты кликаешь кнопку, в этот момент окно закрывается по колобку - ты думаешь что это ты нажал на нужную кнопку... А нихера подобного. Вариант 2. У тебя выкинуло окно, а тебя отвлекли или еще что - ты думаешь, окно подождет, потом прочитаю... А нихера. Если есть таймер - его должно быть видно, чтобы пользователь видел, что оно с таймером, и сколько осталось.

1. А BigWorld.callback(), для тех кто не особо в курсе, зависит от скорости времени в игре, т.е. при паузе реплея колобки тоже встают на паузу. Поэтому нельзя использовать колобки для графического интерфейса. И вообще, колобки имеют узкую сферу применимости, относительно привязанных к игровому времени вещей, просто нубокодеры пихают их куда не попадя. 2. Для отображения времени до автонажатия на кнопке нужно писать код на AS, а не д***ить флешку по DAAPI из питона. Без отображения времени временами может возникать баттхерт у народа. 3. И вообще вещи нужно делать правильно и аккуратно, а не через *опу.

В общем, написал еще немного кода :) Очередной тест, иными словами. Изменения относительно прошлого билда: 1. Как всегда немного прибрался в коде, в частности обновил список хоткеев в файлах конфигурации, их там заметно прибавилось. На всякий, если я вдруг что пропустил там лишнее, любая клавиша должна начинаться на KEY_ все, что начинается на что-то другое использовать в качестве хоткея нельзя. 2. Исправил старые баги в плагине расширенной подстановки при захвате цели в автоприцел. Вернул плагин обратно в билд. Надеюсь, что случайно не добавил там новых багов :) 3. Вернул обратно старую фичу, тоже в виде плагина - подстановку при определении цели для радиального меню и зависимых от него быстрых команд по хоткею. Для обоих плагинов приходится городить некоторые костыли, ибо красиво туда попросту не подлезть. 4. Ну и наверное самое интересное в этом билде, из-за чего собственно и собрал его :) - реализовано сохранение координат при перемещении информационных панелей, правда частично, данные сохраняются пока только в течении текущей игровой сессии, т.е. до перезапуска клиента, т.к. с сохранением в файл там тоже не так все просто, вот и решил разбить на две части процесс. В связи с этим конфиг панелей разделен на два блока - статичный, которые редактируется только руками, который с комментариями (по сути то что было снесено на один таб вправо без изменений), и динамеческий, управляемый скриптами, там никаких комментов не будет (пока вообще непонятно в каком формате он будет храниться, как читаться и прописываться обратно), т.к. ResMgr не умеет их читать и писать обратно, в связи с чем динамический блок перенаправляется в отдельный файл. Пока там правда стоят заглушки. Идея собственно в том, что динамический конфиг применяется поверх статичного, соответственно при перемещении панели мышкой в динамический блок добавляется параметр и он перегружает аналогичный в статическом. Ну и само собой, файлы: XModLib.zip AdvancedAimingSystem.zip

Стандартный захват цели BigWorld.player().autoAim(BigWorld.target()) Где BigWorld.target() это определение в кого сейчас наведен игрок, возвращается объект класса Vehicle, DetachedTurret или None, если цель не найдена. Соответственно внутри autoAim уже впилена проверка на то, что сущность это Vehicle. Туда по сути можно вместо BigWorld.target() подставить любой объект класса Vehicle, и если его параметры подходят для захвата, он захватится как цель автоприцела. Это если ты про автоприцел. Если про TargetScanner в моде - долго объяснять, там все не так просто. Вообще без знаний питона не советую туда лезть. Займись чем-нибудь попроще для начала.

Ну если делать по-нормальному, нужен таймер в кнопке. А это редактирование флеша 100%.

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

А метод скорее всего на питоне (который вызывает кнопка).

Если тут каждый, кто это мнение поддерживает, отпишется, тут постов будет еще примерно столько же, сколько и без того имеется :) З.Ы. Тем не менее я тоже согласен с данной позицией. Пакетами неудобно немного дебажить, особенно когда параллельно редактируется несколько файлов, которые должны собираться в пакет, а обновить нужно только один. Да и про гигапакеты со шкурками или еще чем подобным уже говорили, там дебаг вообще веселье будет в таком раскладе.

Ну тогда просто вызывай метод по DAAPI и не парься.

Если вообще просто увеличение угла захвата, то сканер целей давно умеет это делать, через т.н. "неточные сканеры" - BBox и BEllipse (BEps). Что касается подключения его к автоприцелу - там выносилось в плагин и из-за нестабильности было исключено из последних билдов. Если картофан чего опять не намутит, возможно вернется в одном из следующих билдов.

Тебе нужна анимация, или просто событие по кнопке?

У меня сборкой релизных zip-архивов давно уже питоновский скрипт занимается... и не только сборкой архива, сборкой модов из исходников вообще. С пакетами пока не заморачивался, но там по сути те же яйца, только в профиль.

Таймаут?