GPCracker

Неточный сканер может делать захват, только если текущей цели нет. Для переопределения нужно "попадать в контур" (если используется XRay - то в "контур за текстурами"), поэтому если сканер "захватил цель", достаточно просто удерживать прицел в зоне цели. Прыгать с одной на другую он не будет, если не "цеплять за контур" соседних танков. Это касательно TargetScanner. Что касается автоприцела, сканер (TargetScanner) сам или его результат (TargetInfo, то что горит надписью на экране) можно подключить через конфиг в соответствующей секции, если есть нужные плагины в сборке мода. Все подстановки TargetScanner и TargetInfo за пределы мода отключены по дефолту.

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

Смысл пакетов не в том, чтобы добавлять что-то там, а по большей мере в том, чтобы мод выглядел одним файлом, а не набором файлов, смешанных в одной куче с другими модами, из-за чего неопытному юзеру почистить его весьма проблематично. Тут удалил файл пакета и все. В этом и смысл. Что касается ЭЦП и другой подобной клиентской защиты - скажу так: после ее ввода все читерасты дружно будут качать патченый экзешник, откуда выпилена проверка ЭЦП. Или что-то в этом роде. Реальной пользы в плане античита от этого на ломаный грош примерно, а вот геморрой от этого будет порядочный у всех практически мододелов. Реальный способ избавиться от читов - перенести все критичные расчеты на сервер... хотя прикол весь в том, что они изначально уже на сервере. Накрутить себе 100500 золота к примеру у тебя никак не получится при всем твоем желании. Отсюда и достаточно известное высказывание - "читов в WoT не существует, есть только слишком уж хорошо помогающие игрокам моды". Так что весьма крутой античит в игре еще с незапамятных времен стоит, считай. Вот в этом да, есть проблема. Впилить фичу без очередного факапа - это не про WG. Причем проблемы именно с самой концепцией, так сказать, не столько с качеством кода. Это явно говорит о том, что на начальном этапе разработки, где определяется что мы делаем, и как это в конце должно выглядеть, у WG явно проблемы. Или функционал в процессе упиливается серьезно в количественном и качественном плане, чтобы уложиться в сроки. Ну да, что есть то есть. Идею картоха взять может, а вот обработать по красоте - с этим как обычно проблемы. Не совсем. Не видят смысла те, кто не хочет его увидеть видимо. Смысл в пакетах есть. Главное чтобы они не стали "очередной не доведенной до ума фичей". За себя могу сказать что я в принципе не против, если все будет по красоте. Но ждать такого от картошки, учитывая многолетний, так сказать, опыт - это по меньшей мере глупо.

Вот в том и дело, почему я и говорю, что нужно писать имя автора и название мода в ивент, или их аббревиатуры хотя бы, кому в лом использовать полные имена, или они прилично длинные. Кстати, как там насчет вложенности эвентов, как в FMOD, реализуемо? Всмысле создать группы, и писать что-то типа имя_группы/имя_ивента. Неспроста ведь ограничение на символы в именах. Надо будет как-то самому пошариться в звуках, только со времен FMOD времени найти на это никак не могу.

Клиенту игры поверь все равно на размеры имени ивента, если оно в пределах допустимого. Для разработчика такой префикс не особо проблема, если он везде одинаковой длины, и именование выглядит все также в ровный столбик. Тем более формат строки никто не отменял. Зато коллизий при любом раскладе не будет. В то же время видно, что это за ивент, и из какого мода/банка. Если можно использовать слеши в имени, или вложенные имена, как это было в FMOD (/xvm/xvm/sixthsense например), то еще проще. (Имя автора)/(Имя мода)/(Название ивента). Все четко, все понятно что и откуда, если банков в моде несколько, можно еще предпоследним элементом добавлять имя банка. Upd. "Event names can contain only letters, numbers, and underscores. They must also start with either a letter or underscore." Жаль, однако. Тогда придется делить при помощи underscore.

Определенно есть! Основная проблема в том, что решаем не мы, мы тут только флудим немного в надежде повлиять на ситуацию...

Типа того. Я о том, что питон нужно запускать не в основном потоке программы, а параллельно.

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

А там что, все в один поток работает? Лол :)

Матрешка :)

Грустно однако. Там иногда весьма интересные вещи озвучиваются.

Не, ну не у всех же есть возможность там побывать, я так понимаю, это в Минске? Запилили бы хоть онлайн трансляцию на твиче, или видосы расшарили :)

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

Эээ а почему широкой массе про это практически ничего не известно? Или картоха делится инфой выборочно?

Об этом уже в "профильной теме", так сказать, упомянули. Все-таки, намного проще понять что и откуда взялось, когда все прописывают свои объекты в своих файлах, а в общих указывают только о своем существовании :) Та же тема, что и с пакетами, идея примерно та же - рассортировать файлопомойку - папку res_mods на конкретные блоки - моды. Тут как-бы вообще немного странно, с одной стороны, WG пытается вылечить шишку от граблей, на которые наступили уже давно так, с другой - наступают на аналогичные, только немного в другом виде. Такое ощущение, что с координацией между отделами там что-то явно не так. И речь даже идет не о решении сложных конфликтов, а даже о банальном - скажем, озвучка орудий + кастомный звук на возгорание/килл/или еще что-то, реализованные отдельными модами по предложенной схеме с этим файлом. Понятное дело, друг про друга эти моды изначально не в курсе, и файлы в них разные. Юзер просто не сможет их вместе сам поставить, ибо ему придется мержить файлы из двух и более модов в один. Кстати, разработчик ответил :)

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

Ну тут как раз таки более-менее понятно, точнее как всегда :) Хорошо хоть тут разработчик есть, надеюсь, в ближайшее (относительно) время пофиксят.

Тогда очень сильно напрашивается как минимум все объекты/замены звукового мода прописывать в его персональном файле, а в общем указывать только порядок поиска замен по данным из модов (порядок загрузки, если по простому), типа того, как реализовано с ресурсами, в виде paths.xml. Иначе все это дело превращается просто в адскую кашу, и черта с два разберешь, что к какому моду относится.

@ribbed, если я правильно понимаю, все работает в данном примере по принципу замены на этапе поиска одного на другое (звуков и прочих объектов wwise) через настройки в audio_mods.xml, и все моды по сути упираются в этот общий xml файл, который нужно как-то совместно всем звуковым модам редактировать? При установке нескольких звуковых модификаций, я так понимаю, этот файл нужно мержить из двух файлов? Кстати, раз уж в соседней теме подняли вопрос про пакеты, данная коллизия в виде этого файла на уровне пакетов как-то решаться будет? Или я неправильно понял идею, описанную в доке?

Почитал тут ваши обсуждения, так сказать, закралась одна мысль - а может WG просто лочит загрузку всех левых банков, чтобы оно "не мешало тестированию"? Да, кстати, проверка всех доступных версий это конечно хорошо, а в оригинальных банках наверняка есть какая-то сигнатура версии сборщика этого банка? По ней разве нельзя точно вычислить версию, чем картоха собирала?

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

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

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

Магия прям. Конфликт какой-то походу. Значит придется мне XVM ставить и разбираться, откуда ноги растут у этого бага.

Причина достаточно простая - перенос парсинга хоткеев в процедуру чтения конфига. Чтобы при ошибках в них краш был не в процессе игры (ну точнее баги при обработке нажатий на клавиатуре), а в процессе загрузки мода, что по сути прерывает просто его загрузку с выбросом трейса в лог и все (мод просто до конца не прогрузится и работать не будет, игра запустится нормально). One or more keys could not be recognized. Пару страниц назад об этом писал. Параметр переименован для совместимости с парсером, чтобы в процессе передачи параметров не заниматься этим самым переименованием, а просто передать блок конфига по кейвордам.