GPCracker

Костыли - они везде костыли.

Ну там два батника. msgfmt - это компилятор, msgunfmt - декомпилер. Берешь AdvancedAimingSystem.mo, тянешь его и бросаешь (drag&drop) на нужный батник (сначала на декомпилер). Рядом с оригиналом появляется AdvancedAimingSystem.po - текстовая версия, которую нотпадом++ править можно. Что собственно и делаешь. Дальше берешь AdvancedAimingSystem.po, который ты правил, и аналогичным образом кидаешь на батник, но уже на компилятор. Лучше его переместить сначала куда-то, ибо компилятор затрет оригинал AdvancedAimingSystem.mo, лежащий рядом. Полученный новый файлик AdvancedAimingSystem.mo кидаешь с заменой в папку с игрой и радуешься жизни. З.Ы. Каждый раз декомпилить необязательно. Можно просто править AdvancedAimingSystem.po и компилить его :) З.Ы.Ы. У меня тут сейчас правки, так что скинуть сорц того, что залил вчера, уже не могу.

Куда перекинуть?

Плохо искал. Там есть файлик, в папке с локализацией (AdvancedAimingSystem.mo), в нем содержатся все строки, там HTML форматирование, поэтому в xml их пихать не очень прикольно. В XML просто вместо текстовых полей проставлены макросы gettext. Выкачиваешь файлик из этого поста, декомпилишь файл локализации, правишь и компилишь обратно.

Сильно сомневаюсь что это что-то даст... А вот переключение XVM в режим стандартных линий должно решить проблему... правда ценой отключения этих самых линий.

В общем, небольшой подгон для желающих потестить. Перед установкой очень сильно рекомендую папку с модами забекапить. В текущей версии нет части обвеса, некоторые костыли пока впиливать не стал, в частности выравнивание маркера орудия при наведении в небо. Есть идеи как сделать нормально, но когда доберусь пока непонятно. Но основной функционал в виде корректировщика, захвата цели, панельки сведения, и еще чего-то по мелочи запилил. Пока не добавлял артоснайп, сейфшот, и цель для радиального меню, ну м.б. еще чего забыл. AdvancedAimingSystem.zip З.Ы. Надеюсь, никаких зависимостей не пропустил... А то билдер еще пока не адаптировал, собирал частично руками. З.Ы.Ы. И ничего толком пока не конфигурировал, в особенности GUI. Конфиг тестовый.

Сегодня убедился, что картоха как всегда все делает через одно место. Как раз в теме AAS есть обсуждение, подымаю свою флешку для GUI. Проставил в конфиге gettext-макрос (ну я использую несколько измененный формат, с терминатором ";", но сути дела это не меняет). А форматтер прописать забыл. По идее оно должно было улететь по DAAPI во флешку в неизменном виде... А нифига подобного. "Суперкод by Kartoxa" пытается резолвить через "родной" i18n мою строку! Причем, судя по трейсам, вызов идет от C-кода. Ну понятное дело, все это фейлится, ибо мой файл картохин парсер не видит. Вот такой подводный камень в нашем огороде нашелся :(

Ну в принципе разницы-то никакой, мод же нормально работает xD

Эта калитка уже давно стоит... Люди же четко написали "проблема с XVM". На чистом клиенте все ок. Проблема не в слое. Я специально кинул ссылку на нужное место в репо XVM. Проблема в том, что они патчат все сущности класса, а не только камеру. На последнем ночнике вылезло. Как линии на миникарту ввели.

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

Эээ... Вообще есть, но там очень давно не обновлялось, ибо то что есть - это "плохие хотфиксы". З.Ы. Файла исходника не существует единого, их много, но все собирается билдером в один и потом компилится.

Ну скорее всего они чего-то не допилили. В логах есть чего?

На чистом клиенте все ок?

Спроси у @Ekspoint, м.б. он помнит, я давно в этой теме не копался, конкретики уже не помню. Я одно время делал ему "смежную штуку".

В питоне есть такое понятие как очередь звуков. У каждого звука есть таймаут актуальности. Прошло времени больше - звуковое событие удаляется из очереди. Решение состоит в том, чтобы увеличивать время актуальности эвентов. Это настройки xml, если речь идет про стандартные звуки.

Даже если у тебя и получится его создать, ты сможешь создать только точный дубликат, и даже не сможешь его толком настроить... конечно, за исключением случаев, когда картоха сама предусмотрела конфигурацию из питона. Можно. Если ты сможешь приаттачить его чайлдом к нужному объекту (но там есть некоторые подводные камни), либо отловить событие перемещения нужного объекта по экрану. Хотя может более опытные товарищи тебе чего более интересного подскажут.

1. Откуда информация? 2. В большинстве случаев в моде используется именно для расчетов траектории. Так что непринципиально в принципе.

Это для BWGUI. Для флешек оно не нужно, там таких проблем нет. Учитывая область применения, внесение туда патчей в настоящий момент неактуально. Тогда почему они используются для отрисовщика траектории в стратегическом режиме к примеру? shotDescr = BigWorld.player().vehicleTypeDescriptor.shot BigWorld.wg_trajectory_drawer().setParams(shotDescr['maxDistance'], Math.Vector3(0, -shotDescr['gravity'], 0), aimOffset)Или к примеру в расчете положения маркера орудия, который ну явно не для трассеров считается? <кусок кода собирать по частям влом, все в файле VehicleGunRotator.pyc>

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

Рут флеш наследуется от класса Flash, UI от классов фреймворка. По факту, в случае с рутовой флешкой ты грузишь независимую флешку, в случае с UI - флешку грузит фреймворк. Соответственно, рутовой флешкой рулишь чисто ты, UI еще управляет фреймворк. Плюс еще фреймворк предоставляет часть методов для перегрузки, что местами упрощает даже разработку. После перехода на AS3 поведение UI элементов аналогично ангарным, только в боевом режиме немного отличается структура интерфейса, в частности немного другой набор контейнеров. В общем, там куча различий, но могу сказать, что использование корневой флешки оправдано в настоящее время только в двух случаях - если это устаревший AS2, который не сможет загрузиться фрейсворком (правда не факт, что картоха не выпилила его поддержку из Scaleform), в таком случае проще и эффективнее просто перейти на AS3, либо если эта флешка должна быть независимой от фреймворка, т.е. она не относится ни к боевой, ни к ангарной части интерфейса, а такие случаи довольно редкие. Если в случае с AS2 набор классов был довольно малым, то сейчас в принципе можно без проблем конструктить как вьюшки, так и компоненты. Опять вопрос насчет разницы вьюшки и компонента. Тут чем больше рассказываешь, тем больше нужно пояснять... Короч, буду писать гайдец - напишу, что, куда и зачем нужно. По крайней мере в части вещей боевого интерфейса уже успел разобраться.

Скорее всего придется таки использовать AS3.

If you are annoyed of this game QC, what could you say about delving inside this game? :)

@leeuniverse,

Классы другие, принципы те же. Как появится время - обновлю гайдец. Сам сейчас клепаю боевую флешку с вьюшкой-лоадером и панелями-компонентами BattleUI. Нужно. Хотя в принципе и адобом пользоваться никто не запрещает. Там немного разные принципы, но должно работать. Честно говоря, там все зависит от компилятора. Лично я боевую сейчас делаю на AS3 в FlashDevelop. Ладно, а то на работе длинные посты набивать не вариант, работать надо :)

Да я понял, что там написано, я про то, что инглиш на выхлопе переводчика немного кривоват. , параметры текстуры при экспорте/импорте задаются только добавленными тобой параметрами из BW, или что-то нативное (от Blender) еще используется?