GPCracker

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

1. Питон - один из самых простых языков, которые я встречал. Синтаксических конструкций по минимуму, и они интуитивно понятны, если знаешь английский. 2. AimingInfo - это данные по сведению, т.е. данные, выводимые на панельке сведения, на которой больше всего текста. Панель информации о танке противника - это TargetInfo, данные берутся из экземпляра одноименного класса (объекта), привязанного к одному из базовых объектов WG. Упрощенно к нему доступ можно получить через getattr(BigWorld.player().inputHandler, 'XTargetInfo', None)Или, если пользуешься классами, можно сделать примерно как здесь. Само собой, вносить туда изменения (менять значения параметра и свойства объекта) крайне не рекомендуется, иначе это скажется на работу AAS. Вывод информации на панельку прописан здесь, это получение макросов для форматирования строки. Вытащить функционал захвата цели из мода получится наврядли, это примерно так 70% кода модификации. Но запилить какой-нибудь плагин, примерно как эти, можно в принципе без проблем. Примеры по AimingInfo (информации по сведению) лежат рядом, но там нет публично доступного атрибута вне мода. Хотя можно просто взять функцию из указанного файла, не забыв про импорты из XModLib. Will see when patch released on RU.

Явные ошибки в скрипте прицелов. Возможно, старая версия.

Запостить скриншоты/видео по спойлер было бы неплохо с отметками что было установлено из модов. Возможно реально я где-то что-то не так делаю, возможно прицельные скрипты лагают или еще что. Все работает, просто включить в конфиге надо. Поведение его несколько странновато временами, но вроде как стреляет с ним нормально. Пока еще тестим, поэтому отключено в конфиге, чтобы новички, кто еще не в теме, не выпали в осадок. Кому надо - знает где включить (з.ы. все там же, в настройках аркадного режима проставить для ручного и автоматического enable True). Настройки шрифтов и текста производятся в файле локализации. Для патча нужно вытащить из пакета файл res/text/lc_messages/AdvancedAimingSystem.mo и положить его в res_mods/<patch>/text/lc_messages/AdvancedAimingSystem.mo, где он лежал раньше, просто извлечь, вносить изменения в пакет не нужно. Далее все по старинке, берем архив с gettext и пользуемся батниками, или заходим на какой-нить сайтик, который умеет *.mo в *.po конвертить и обратно. Конвертим, редактируем *.po все тем же текстовым редактором, что и конфиг (но точно не виндовым блокнотом), конвертим обратно в mo, кидаем в указанный путь в res_mods (если не конвертил на месте). Перезагружаем клиент игры (реплей никто не отменял). Главное не забудь потом подкорректировать размеры панелек в конфиге, они подгоняются под текст руками. Да, gettext можно взять здесь. Используется посредством перетягивания файла на нужный батник. Более-менее подробно про локализации есть здесь. Там же есть и сами батники в архиве под одним из спойлеров.

Видать проблема реально стала насущной, когда длина версии танцует от 3 секций до 5.

Не можно, точнее не нужно. Библиотека она на то и библиотека. Сейчас даже проще стало, т.к. файлов стало меньше, и они не раскиданы по папкам. Кстати, вполне логичный вопрос, который пока не появился, но в скором времени наверняка будет - как патчить файлы, которые внутри пакета? Либо патчить их внутри пакета (неправильный метод, ибо менять сам пакет неправильная политика, но работать должен, если со сжатием сделать все правильно), либо создать файл в res_mods/<client>/ (res_mods/<client>/ эквивалентно res/ внутри пакета, см. доку от разрабов, я скидывал ссылку пару постов назад), файлы res_mods/<client>/ переопределяют содержимое пакетов. Да, кстати, кто еще не заметил - конфиги переместились и немного изменились внутри. Парамеры те же, по сравнению со старым вариантом, но пути оверрайда изменились.

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

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

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

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

Для чисто RAR есть UNRAR, в папке винрара лежит. Запусти в консоли, он выдаст хэлп.

0.2.4 Alpha (XModLib v0.1.5) [14.04.2017] - обновлена система присвоения версий сборкам, теперь версии генерируются git describe. - обновлена система проверки совместимости библиотеки с текущей версией модификации. - исправлена ошибка, связанная с неправильной генерацией zip-архива, точнее с отсутствующими в нем записями каталогов. - осуществлен перевод модификации в пакеты, плагины вынесены в отдельные файлы и пакеты соответственно, управлять ими теперь еще проще. Обновлены пути к файлам конфигурации и ресурсам модификации, также значительно изменен и оптимизирован под новую схему скрипт сборки. - немного улучшен формат макросов, используемых при сборке. - добавлены файлы метаданных для пакетов. Как понятно из патчноута, данное обновление чисто техническое, никакого дополнительного функционала добавлено не было. Тест проводится исключительно с целью проверки работоспособности мода после внедрения некоторых важных технических обновлений и, самое главное, перехода на пакеты. AdvancedAimingSystem_v0.2.4.zip XModLib_v0.1.5.zip Думаю тут уже всем известно, что без XModLib мод работать не будет.

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

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

Как раз таки и возникала проблема на 2.7.12. Кстати, может для кого-то будет полезным, оставлю это здесь.

1. Там не один такой файл, а несколько, плюс конфиги, и они упаковываются потом в один нормальный архив для дистрибуции, подпись снизу - это лишь пояснение что и куда идет.2. Эта функция используется не только для пакетов, но и для общего архива. З.Ы. Надо будет сжатие вынести аргументом :) 3. Буферизация в памяти позволяет ускорить процесс добавления файлов в архив, и соответственно процесс сборки, тем более что с оперативкой все более чем в порядке. ...залез в скрипты этого модуля... Не понимаю, как это вообще в релиз попало. Не удивлен, что там что-то забыли сделать. Upd. Решение, предложенное @POLIROID, добавлять все необходимые директории в архив вручную, работает. def compile_zipfile_string(src_data_blocks, src_bin_comment='', dst_bin_compression=zipfile.ZIP_STORED): def get_parent_dirs(path): def get_parent_dirs_inv(path): while path: path = os.path.dirname(path) yield path + '/' return return reversed(tuple(get_parent_dirs_inv(path))[:-1]) with io.BytesIO() as dst_bin_buffer: with zipfile.ZipFile(dst_bin_buffer, 'w', dst_bin_compression) as dst_zip_buffer: for src_block_name, src_block_data in sorted(src_data_blocks, key=operator.itemgetter(0)): dst_zip_namelist = dst_zip_buffer.namelist() for src_block_parent_dir in get_parent_dirs(src_block_name): if src_block_parent_dir not in dst_zip_namelist: dst_zip_buffer.writestr(src_block_parent_dir, b'') dst_zip_buffer.writestr(src_block_name, src_block_data) #dst_zip_buffer.comment = src_bin_comment dst_bin_data = dst_bin_buffer.getvalue() return dst_bin_dataКомментарии в пакетах не поддерживаются. В общем, картошка как всегда.

Никто случайно не пробовал собирать пакет на питоне? А то что-то не взлетает никак. def compile_zipfile_string(src_data_blocks, src_bin_comment=''): with io.BytesIO() as dst_bin_buffer: with zipfile.ZipFile(dst_bin_buffer, 'w', zipfile.ZIP_STORED) as dst_zip_buffer: for src_block_name, src_block_data in src_data_blocks: dst_zip_buffer.writestr(src_block_name, src_block_data) #dst_zip_buffer.comment = src_bin_comment dst_bin_data = dst_bin_buffer.getvalue() return dst_bin_data src_data_blocks = [('res/scripts/client/...', 'Content'), ...] $$ dst_bin_data > test.wotmodПроверку архив проходит, размеры (сжатый/несжатый) соответствуют, а клиент ругается. Хотя все архиваторы хавают без проблем.

@leeuniverse, first drop reason seems to be a target lost... IFAIK you have disabled GUI, so it is hard to determine it for sure. But gun marker instantly dropped, and this could happen when distance instantly changed from middle range to far, like it happens when target is lost and correction is disengaged. You have been moving your crosshairs in front of a target, but looks like you haven't been targeted it, so target may be lost after few seconds. Non-direct scanners like BBox or BEps were developed at least as a solution to target loosing problem - target size could be mathematically increased and target is being supported for not being lost if you track it by crosshairs nearby. I have posted some pictures in this topic about what is the BBox and BEps before, when I was developing this features. Second drop on himmelsdorf could have one of two reasons. First - manual aim correction on objects (distance to objects locked) when moved to sky with no gun marker correction module. However, if you haven't used a lock at this time... there could be another reason - sky problem by WG. I don't remember a full story, but in training room I also had this issue. IFRC that was an small error in WG code calculating gun marker position if maximum distance of shot (720m AFAIK) is exceeded. I will find it when I have more free time. Upd. Сижу тут переделываю сборщик и патчу код с целью перемещения мода в пакеты. Прогресс определенно есть, но некоторые моменты придется весьма серьезно перерабатывать - плагины, конфиги... на внутреннюю структуру сказаться по идее не должно, изменятся только пути и некоторые моменты в коде. Посмотрим, что получится потом, а пока попробуем запустить хотя бы ядро первого билда :) Попутно впилил систему контроля версий для библиотеки и научил сборщик определять и прописывать версию по данным гита. Upd. Это просто 3,14 какой-то. Собираю архив с "правильным сжатием" (точнее его отсутствием) при помощи питона - ругается. Все параметры вроде ок, размеры соответствуют, проверку на целостность проходит... Upd. Проблему с архивацией удалось решить. Обновил немного константы путей, пилю плагины сейчас. Походу писать код для работы с vfs, уж больно много теперь на нее завязано.

Бывает :) Однозначно стоит. ...указать в доке максимальный размер файла в пакете, максимальный размер пакета (если применимо) и максимальное количество файлов в пакете.

Как-бы у самого формата ZIP есть ограничение на объем. 4GiB (примерно) максимальный размер файла и почти 64k записей (файлов/папок). Подробности по ссылке.

Ты внутрь заглядывал? Это те еще костыли. Не буду даже уточнять, что там криво написано... И написано же - временное решение. Потому что правильное решение - это научить gettext работать с ResMgr, а не кормить ему вручную бинарные данные через костыли. Хотя в принципе и такой подход можно сделать адекватно, но точно не так как в этом пакете.

Sometimes I think I really don't understand what you mean as "bouncing". As long as you use aim distance correction (as a solution to overpass, when shell goes just above the target instead of hitting it), there appears another collateral problem - gun marker drawing. Gun marker (this name is also used in WG game scripts) is a calculated expected 3D collision point, that is projected on your screen as a marker with recalculated dispersion on a distance to this collision point. So, when you move an aiming point (point, you specify with the crosshairs, some sort of invisible aiming laser) closer to your tank, to a place where enemy is expected to be, game found nothing in its place (for game client invisible tank does not exist at all) so normally ballistic collision test passes through this place and uses a far point beyond enemy expected position on a far hill or skybox. So, because of gravity, if shell misses the enemy, it will fly farther and there will be a falldown lower than expected enemy position and aiming point, so gun marker (or its projection on screen plane) will also be lower than crosshairs. This effect while using a correction is a little annoying because it is hard to determine if gun is stabilized if gun marker is lower than crosshairs, and sometimes may be even off screen, if zoom is too high and gun has arty-like trajectory. We prefer it to be centered, of course. This problem was also known as "gun marker dropdown", and fixing this problem (centering the marker) was mentioned as "community decision". An optimal solution to implement this request was creating an "invisible wall" (mathematical object in ballistic calculation for a gun marker), which makes GM collision test algorithm "see" an "invisible target" you want to hit. Distance to this wall is equal to locked distance. That is the trick mentioned as "gun marker fix". So, this approach makes gun marker be drawn at the crosshairs position even in correction mode, but... there is a transition process I mentioned before. When correction is engaged or disengaged, this wall appearance and aiming point movement are instant, but gun should also be relocated, and this process takes some time. Like reactive components in electronics, capacitors and inductors. So, at the first few seconds (normally not more than a second or two) gun marker instantly jumps or drops then smoothly comes back to the center of crosshairs. This transition process could also be seen when moving crosshairs from far object to close and back, for example you hide beyond a building on the one side of a map and aim at the building first then on far side skybox and vice versa - the reason is the same - instant distance change and slow gun movement. It could not be fixed, it is a collateral issue of whole WG aiming system where you specify an aiming point and gun elevation line is aligned to fit these aiming conditions. What about the Server GM - I need to analyse algorithm of its calculation and transmission to client... However I suppose server just send a point on non-corrected (far) distance, so my patch not working for SGM (Server Gun Marker). It is only my thoughts by now and this information still need to be confirmed or refuted. And what about correction and mod's working - training room has shown that a patch ago problem, mod originally was designed to solve (overpass while shooting at invisible or fast enemies), was still intact. Upd. I have looked through WG scripts... Gun marker control is a crazy stuff, but my fix (gun marker dropping fix mentioned before) should apply server and client markers both.

Basic functional still works the old way. Only minor changes and optimizations was performed to implement new features the right way, not by creating crazy crunches or inventing bicycles. Manual distance locking still uses the old algorithm, target locking also working like the old times, only target search algorithm was improved, not correction. All extra functional could be disabled in config. Before executing a block of code in hook, enable parameter is being checked, or other collateral parameter to determine if feature is disabled to miss a code block execution. Most parameters, if they are glitchy, could be disabled in config... or now unreliable parts are stored in plugins, which could be easily removed or added by a user using archive tool, like 7-zip. It looks like you don't completely understand the reason of "bouncing". The gun marker, or reticle, as you call it, is a projection of 3D-point on your screen plane. This point is an intersection of expected shell ballistic trajectory (dispersion is not used in these calculations, only main trajectory) with a ballistic valuable object (an object that causes shell explosion on contact), this object could be a tank, wall, ground or skybox. So, when correction is applied (or released), distance suffers a significant change, so in first time gun still aim at the old point, but gun marker already started to use a new distance for calculations. So it takes time for gun to move, and after that gun marker and crosshairs will match againg. This transition process is known as dropping/bouncing when correction is engaged or disengaged. However, if gun marker is not corrected, in aim distance correction mode it will fall down (in most cases) by a significant height, making aiming in correction mode a little annoying. But without a correction it moves slightly without instant drops or jumps. The first (the really firsts) didn't have this gun marker correction, but the fact of its requirement was a community decision, as long as this correction allows the gun marker match the crosshairs in correction mode (instead of constant and significant dropping while correction is applied, that was really to high in large zoom modes, even sometimes gun marker exited the screen), but adds a transition process when correction is applied or released. The problem of "bouncing", as I said before, is a collateral effect of a distance correction with applied gun marker patch. Without any mod there, of course, will be no bouncing, but you will still have a problem while shooting at invisible or high speed tanks. It is also known as shell overpass (overflying/passing above) problem that mod was designed to solve. If you are wondering if WG has solved a distance problem - I have no information about that and I am really skeptical if they would ever solve it, because due to some developer's comments some of them don't even consider this a problem. This attitude of developers to people and their own project is already a funny mem, but they really don't give a damn fuck to a problem unless they have got this reports in flood-like quantity. A server gun marker has an update delay, so transition process will be more visible. As i mentioned before, I didn't apply significant changes in aiming correction algorithm since the first release, but a lot of changes were made by WG in the gun marker in last few patches. I also have no data about realization of server gun marker by side developers. However, maybe I have just missed some situations while developing a plugin-patch after these changes in gun marker, or skipped a valuable segment of calculations in WG code during analysis, etc. Should be checked when I have more time for that.

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

Хмм... Становится куда интереснее.