GPCracker

Угу, вроде робит :) bpc.flashObject.as_applyConfig({"alpha": 0.01, "size": [10, 20, [1, 2, {}]]}) DebugUtils.LOG_DEBUG("" + json.size); [GUI] (scripts/client/gui/Scaleform/Flash.py, 51): DEBUG.GUI ('10,20,1,2,[object Object]', ()) Спасибо.

Эээ тут момент такой есть, один из параметров список, скажем {"alpha": 0.01, "size": [10, 20]}Оно в таком раскладе отрезолвится?

Перевод выглядит реально в стиле "я твой дом труба шатал" (в смысле связь слов) :) www.translate.ru генерит немного получше переводы, чем гугл и яндекс.

Нихрена не могу понять, что я делаю не так... var config:Object = null; DebugUtils.LOG_DEBUG(json); try { config = JSON.parse(json); } catch (error:Error) { config = null; } DebugUtils.LOG_DEBUG("Fucking!! " + config);На выходе имеем [GUI] (scripts/client/gui/Scaleform/Flash.py, 51): DEBUG.GUI ('{"alpha": 0.01}', ()) [GUI] (scripts/client/gui/Scaleform/Flash.py, 51): DEBUG.GUI ('Fucking!! null', ())Собирается все без ошибок, это часть функции, получающей аргумент json через DAAPI.На входе на питоне конструкция вида bpc.flashObject.as_applyConfig('{"alpha": 0.01}')

Вывод: делать свою флешку :)

Удалось завести пока только первичный вариант GUI. Пока работает через отладчик (то есть пинается руками в процессе), но в моде все должно создаваться, обрабатываться и деструктиться само. А это еще дополнительные классы-обработчики, и дополнительная логика. С ней как раз и идет работа. Плюс по части флешки - нужно немного поправить и оптимизировать классы, и разобраться с некоторыми не очень простыми моментами по части архитектуры. Не говоря уже о том, что уже 1 сентября, и началась учеба. В этом году времени будет не шибко больше, чем в прошлом, если не меньше даже. Это на втором курсе мы как-то ничего не делали, и закрывались на хор, поэтому там и обновы были чаще чем у картохи. На 4 такое не катит. Более серьезные предметы, которые реально надо вкуривать, больше всяких лаб, на которые нужно писать отчеты, курсовые работы в количестве 2 штук, обе кафедральные, и КРБ до кучи надо бы уже начинать потихоньку проектировать. Плюс еще работа.

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

Хмм... Довольно интересное предложение. Тоже натыкался на этот root1 и на main, только вот не совсем понятно, откуда берутся эти константы. Немного сказывается то, что с флешом я вообще раньше толком не работал. Сначала даже не понял зачем везде "as" :) Блин с питоном проще, его хотя бы через отладчик в рантайме пинать можно. А флешку хрен пропатчишь в рантайме. Или там есть какие-то свои козырные подходы?

Прикол в том, что ведь GUI это не только инфо панель, но и панель информации о текущей цели и панель информации дальномера. А вот это уже неприоритетным назвать как-то не получается. Я пробовал катать в трене без GUI - даже учитывая что я знаю, что и как работает, все равно тяжеловато ориентироваться, что сейчас творится внутри мода. С GUI тот еще концерт. Просто так, обычной вьюшкой его не загрузить - оно будет уничтожать батловую, если окном - то оно будет поверх всегда, даже поверх панели счета, а вот это уже перебор. Для решения проблемы с zIndex нужно аттачить ее в нулевой индекс потомком к самой BattlePage. А система построена так, что получить BattlePage внутри флешки задача весьма нетривиальная. Получить через питон - как нефиг делать, но DisplayObject пробросить через DAAPI туда-обратно не вариант. В общем, задачка явно нетривиальная. Хотя кой-какой вариант есть. Если пропатчить класс BattlePage прикрутив к нему функцию-конструктор, которую потом вызывать из питона, то разрулить вопрос в принципе можно, но что-то больно костыльно как-то... Хотя другие варианты, которые приходят в голову еще более костыльные. Подумаю на досуге, что к чему... Может удастся скомпоновать более-менее приемлемое решение.

Я же говорю, что тут все держится на костылях. Переписывать все почти с нуля надо. В связи с этим переходом на AS3 и не только.Блин, решил тут GUI на флешке запилить... Чего-то пока не взлетает, инит идет нормально, но что-то не взлетает :( Буду сидеть курить примеры на днях походу. Ибо нагрузка достаточно приличная на него будет, и сделать надо нормально. Тут еще заселение козеров, @bash it по работе еще надо. "Код класса миникарты, который отвечает за маркер аркадной камеры, используемый модом как маркер орудия танков" Вот скрины этих элементов, на которые вешается класс. Как видно по скринам, линия идет от центра, а вот картинка грузится углом со смещением. Очевидно, что размер картинки имеет значение. Поправить ситуацию наверное можно через DAAPI, поскольку нужные спрайты висят пабликом. public var directionPlaceholder:Sprite = null; public var directionLinePlaceholder:Sprite = null;Но это нужно патчить скрипт. Кто хочет - может заняться. Мне немного не до этого.Кстати, если получится получить флеш-объект энтри. Там все через инвоуки и айди по соглашению принается, ЕМНИП, так что могут быть некоторые проблемы.

Это "распакованный" файл из атласа, я так понимаю? Назначение атласа и имени зашито на флешке. Там в константах забиты дэфы.

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

Круг отрисовки меняет позицию только у арты в стратегическом (вид сверху) режиме, он расположен в центре прицела.

Еще один КЭП. Читаем ВНИМАТЕЛЬНО то, что написано в шапке. А там написано следующее: Еще раз, несколько короче: ЗА ПРЕДЕЛАМИ КВАДРАТА (НУ ТЕПЕРЬ УЖЕ КРУГА) ОТРИСОВКИ ТАНКОВ НЕ СУЩЕСТВУЕТ ДЛЯ КЛИЕНТА. МАРКЕРЫ НА МИНИКАРТЕ РИСУЮТСЯ ОТДЕЛЬНО ДЛЯ ТАНКОВ В ЗОНЕ ОТРИСОВКИ И ВНЕ ЭТОЙ ЗОНЫ. ДАННЫХ О ПОВОРОТАХ ТАНКА, БАШНИ И ПУШКИ (ТРАНСФОРМАЦИЙ) ДЛЯ ТАНКОВ ВНЕ ЗОНЫ ОТРИСОВКИ НА КЛИЕНТЕ ПОПРОСТУ НЕТ. ВООБЩЕ НЕТ.

Парни, а либу wg для нового боевого интерфейса где можно взять? Они же вроде как впилили в бой тот же фреймворк, по логике старые либы и файлы уже не катят... Кстати, никто случаем не подкинет толковой ссылки на подобный гайдец?

@ger Gauf, написал же. Ничего никуда не девалось. Так что либо у тебя были косяки в конфиге (фича тупо была отключена), либо описанная выше проблема. Upd. В общем, сырая версия есть, и вроде как (поверхностно потестил) работает. Но в ней нет части модулей и полностью отсутствует GUI. Конфиги тоже пока не правил, большая часть в DEV режиме. Из того, что на текущий момент есть: - Корректировка дальномера манульный и таргет режимы (запилено как-бы для всех режимов, но поскольку пока для аркадного нет алгоритмов, там все забито заглушками, остальные режимы вроде ок) - Переход в снайперский для арты - Захват цели (+ корректировка дальномера) - тут впилил достаточно прилично нового, в том числе новые сканеры. - Распилил конфиг, вроде ок, потом еще отдельно потестим. - Вроде как залатал дыру с загрузкой мода, что будет на деле выясним в процессе тестирования. Из того, чего пока нет: - Пока не переносил артоснайп и SafeShot. Возможно, они будут отдельными плагинами. Посмотрим потом. Оба нужно перепиливать, во втором к тому же есть баги задачи на исправление. - Костыль убирающий падение сведения. Причина - потому что это костыль. Есть кой-какие идеи, как это дело залатать, и, возможно, таки впилить и для аркадного режима. - Некоторый затык с радиальным меню. Скорее всего, тоже сделаю плагином, ибо там будут костыли, которые в мейнстрим запускать ну совсем не хочется. - Инфопанель - то же самое, что и GUI. Модуль-калькулятор в общем-то готов, но без GUI он чуть менее чем бесполезен. - Ну и так, какие-то мелочи, которые сейчас сходу не вспомню.

Upd. В общем, удалось таки найти более-менее адекватную по расположению точку, где моды из gui/mods как-бы уже загрузились (ну из старого пути оно еще раньше грузится), но ключевые классы игры еще не были созданы. Из-за чего в общем-то вся свистопляска была. Грузиться в общем цикле, т.е. ставить хуки в основном скрипте мода не очень удобно, ибо после тебя загружается еще куча модов, а поскольку, во-первых, многие мододелы не в курсе, что использование полной перегрузки метода вместо хука порождает проблемы с совместимостью, во-вторых, в некоторых ситуациях по-другому ну просто вообще никак, и, соответственно, твои хуки успешно затираются теми модами, что грузятся позже. В результате вполне очевидно отваливается часть функционала. Для этого изначально была реализована задержка установки хуков через "колобок". Но колобок стартует не сразу, а после старта арены/ангара, соответственно часть методов уже успевает сработать, и ставить на них хуки... "поезд ушел", по-русски. Соответственно, я перенес задержку на потоки, но выплыла другая проблема - клиент у всех стартует с разной скоростью, а задержка описана в секундах. Отсюда и свистопляска с подбором времени (нужно после всех модов, но до старта арены/ангара). В общем, закинул установку хуков в качестве нагрузки на старт gui_personality. Моды грузятся у него в ините, а мои хуки у него перед стартом. В принципе, вроде ОК пока, что будет на деле - поживем-увидим.

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

Ну во-первых, да, ты не тот файл правишь. Во-вторых, в классе, который отвечает за стратегический маркер (package net.wg.gui.battle.views.minimap.components.entries.personal public class StrategicCameraMinimapEntry extends BattleUIComponent, его потомок есть в корне флешки, под именем public dynamic class StrategicCameraEntry extends StrategicCameraMinimapEntry) нет ссылок на атлас, значит он точно внутри флешки. На класс камеры стратегического режима ссылается спрайт 231, и он же ссылается на спрайт 230, 230 на шейп 229. Confirmed.

Смотря как понимать данную фразу. Модуль TargetScanner, который будет в обновлении (после того как я решу траблы с загрузкой мода, которые уже давно обсуждаются, как раз таки та тема с hookInjectTimeout, от которого я вообще хочу избавиться) отвечать за поиск, захват и сопровождение цели во всех режимах (да, в связи с вводом дополнительных сканеров появляется понятие "сопровождение цели" - когда прицел не наведен ни на какой танк, но "непрямой сканер", коробка, эллипс, дает положительный результат по одному или нескольким танкам - если цель в их числе, "время последнего наведения" будет обновляться, "перезаписывать" цель "непрямые сканеры" не будут, для смены цели нужно будет наводиться прямо на танк, но пока прицел находится рядом с танком, цель сбрасываться не будет, отсюда и понятие - "сопровождение") "при выполнении некоторых условий", в зависимости от настроек, будет захватывать и удерживать в памяти некоторое время данные цели. Т.е. для захвата цели нужно чтобы в момент захвата она была видимой. Говоря простыми словами, если ты успеешь захватить цель до того, как она исчезнет. Ничего по сравнению с предыдущими версиями в этом плане не изменится. Что касается того, что захват работал только по кнопке - проблема в том, что скорее всего у тебя из-за конфликта модов не работал фрагмент скрипта, отвечающий за автоматический захват цели и обновление данных в GUI (надписей). Та же самая старая тема с hookInjectTimeout. Решение этого вопроса на текущий момент задача с самым высоким приоритетом, в остальном остается только GUI и различные мелкие плюшки вроде инфопанели сведения (считай то же самое GUI), команд радиального меню рентгеном (то, что пару постов выше я выкладывал), SafeShot, ну и так по мелочи.

Возможно он просто рисуется по сеттингам. Флешку миникарты, с которой траблы (сабж) подкинешь?

ЛоЛ:) Не, ну просто реально никак не подлезть толком. Да даже если и подлезешь, то черт знает через какие костыли. С атрибутами проще - на уровне класса перегоняешь его в property, ну или дескрипторы в помощь (по сути первое частный случай второго). Ничего более адекватного кроме как заоверрайдить их на*** придумать пока не удается. А фулл оверрайд это в какой-то степени генерация проблем с совместимостью и вообще относительно нестабильное решение.

Вот зараза, знатного такого свинтуса тут картоха в очередной раз подложила. Ну вот и как в такую хрень аккуратно подсунуть свой target? в обоих случаях нужно запилить что-то типа (упрощенный пример) target = target or my_targetКартоха как всегда, короч.

Процитированный тобой мой пост - это (если по-простому) одновременно о слонах в одном абзаце, и об апельсинах в другом. Оно никак не связано. Коробка в оригинальном понимании - это всего лишь умноженная слева на статическую матрицу матрица vehicle. В текущей (по крайней мере моей) реализации коробка еще и обновляется в соответствии с изменением углов башни и орудия техники. Понятия "серверная коробка" не существует в принципе. Потихоньку пересобираю модик, попутно исправляя некоторые косяки прошлых версий. Различных нововведений так-то солидно получается, если брать все в куче. Из самого интересного, это наверное возможность произвольно (ну не совсем произвольно конечно, соблюдая правила, само собой) делить конфиг на файлы и переназначать секции, возможность выноса части строк в файлы локализации (упрощение конфига в некоторых местах, плюс за счет этого можно избавиться от некоторых не особо прикольных костылей с поддержкой HTML). Ну а так из нововведений будет то, что захват целей полностью выделен в модули TargetInfo и TargetScanner, которые теперь будут пилотироваться сами по себе, вне зависимости от остального. У последнего получается весьма приличное количество параметров, наиболее интересные вынес в конфиг. Модуль теперь полностью глобальный, и его работа от режима прицеливания больше никак не зависит. Многие модули, которые так или иначе зависели от сканеров, теперь перебазированы на TI. То-есть цель теперь будет не искаться сканерами в приватном порядке в соответствии с настройками, а просто тянуться из TargetInfo. По сути осталось допилить несколько хуков, решить вопрос с костылем по части провала сведения, ну и разрулить с GUI, последнее самая масштабная задача. С одной стороны, и без GUI мод по логике работать тоже будет, но некоторые моменты без такового будут просто непонятными. По науке, надо бы флешку запилить... но не знаю, как получится. Главное, чтобы сама система завелась, а там уже будем думать.

Полагаю у них там свой мир...