Jump to content
Korean Random

GPCracker

User
  • Content Count

    2,827
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by GPCracker

  1. Во-первых, по умолчанию активны только базовые функции модификации. Все дополнения активируются в файлах конфигурации в ручном режиме. Во-вторых, система в настоящий момент состоит из нескольких независимых модулей, которые взаимодействуют между собой, обмениваясь данными в "безопасном режиме". Именно этот принцип как раз и позволяет выключать одни модули без критических последствий для всех остальных (максимум перестанет работать тот функционал, который базируется на "потерянном" модуле). К примеру, отключение сканера целей делает невозможной работу автоматической корректировки дальномера (потому как для нее требуются данные о текущей цели, получаемые от сканера), но никак не влияет на работу модуля корректировки в ручном режиме. Так же как и отключение модуля, отвечающего за графический интерфейс (информационные панели), никак не влияет на работу того же сканера целей или корректировщика дальномера. Упомянутый выше "рентген" относится к модулю сканера целей (TargetScanner), конфигурация этого модуля определена здесь. Данный модуль отвечает за определение наиболее вероятной цели игрока, иными словами, пытается понять, в кого игрок собирается стрелять (по сути, интерфейс целеуказания). Информация о текущей цели размещается в общедоступном объекте (TargetInfo), любой другой модуль модификации может при необходимости считывать эту информацию, либо непосредственно обратиться к сканеру с запросом на асинхронное сканирование. За корректировку дальномера (для аркадного и снайперского режимов прицеливания) и высоты (для стратегического (вертикального артиллерийского)) отвечает модуль корректировки прицеливания (он же модуль корректировки дальномера). В ручном режиме игрок наводит прицел на объект, удаление до которого максимально соответствует необходимому, зажимает кнопку блокировки дальномера, после чего переводит прицел в нужную точку и производит серию выстрелов, удерживая кнопку блокировки. В автоматическом модуль корректировки просто запрашивает данные о текущей цели и самостоятельно выставляет дальномер, при этом нет необходимости что-либо зажимать, нужно лишь убедиться в том, что сканер целей корректно определяет противника, по которому игрок собирается стрелять. Корректировщик дальномера никак не замещает действия игрока по перемещению мышки в процессе прицеливания, иными словами, не является средством автоматизации прицеливания (aim-ботом). Именно так, если не вдаваться в подробности механизмов работы сканеров. Механику взаимодействия модулей я описал чуть выше. Если я ничего не путаю, не одобряется только использование стратегического режима на обычных танках, якобы по причине того, что это позволяет "заглянуть куда не надо". Однако это весьма сомнительное преимущество, так как смещать зону отображения техники может только артиллерия. Что касается снайперского прицела на артиллерии, то он не дает никаких дополнительных тактических преимуществ, если не брать в расчет тот факт, что изначально корректировка дальномера была только в снайперском режиме, а для артиллерии с ее крайне плохой настильностью в условиях ближнего боя наличие этой самой корректировки крайне важно. Если смотреть на данный вопрос исключительно в плоскости запретов со стороны картошки, то данный функционал по смыслу мало отличается от того же баллистического режима прицеливания, который в игре появился не так уж и давно, да и в списке запретов, если мне не изменяет память, ничего подобного не значится. Никаких танцев с бубном там нет, просто выполняется переход в стандартный снайперский режим прицеливания. Кто светит противника не имеет абсолютно никакого значения, в остальном я уже давал более развернутый ответ. В целом это наиболее распространенные ситуации для использования автоматического режима корректировщика дальномера. Как связаны рентген и корректировщик дальномера я подробно расписал чуть выше. За данный функционал отвечает отдельный модуль (точнее плагин, потому как он жутко нестабильный, да и картошка это дело не одобряет), который может получать данные от сканера целей на общих для всех компонентов основаниях, никакого прямого отношения к настройкам сканера целей он не имеет.
  2. Конечно можно, исходники находятся в свободном доступе на GitHub. Анализируешь код, правишь как тебе нужно, собираешь себе свой персональный мод. А для тех, для кого содержание скриптов не является принципиальным, уже давно в рабочем порядке реализуется специальная система: участки кода, отвечающие за определенный функционал, можно исключить из цепочки выполнения путем редактирования файлов конфигурации. Иными словами, если после обновы какой-то модуль не хочет нормально работать, он просто выключается в файлах конфигурации, пока ошибка не будет исправлена ближайшим полноценным обновлением или хотфиксом. Понятие "лишнее" очень субъективное... у каждого свое собственное понимание того, что именно является лишним. И что, мне в таком случае собирать (и потом еще осуществлять поддержку, что немаловажно) каждому свой персональный вариант? Насколько я помню, я уже отвечал, причем довольно подробно, почему я так не делал, не делаю и делать не планирую. Я уже неоднократно говорил о том, что я не заинтересован в осуществлении коммерческой трудовой деятельности в сфере модификаций. В переводе на понятный русский: я не занимаюсь выполнением каких-либо заказов. P.S. Если эта просьба была адресована не мне, то для обсуждения данного вопроса просьба использовать систему личных сообщений или раздел платных заказов.
  3. Для того чтобы "сделать рабочий мод", нужно иметь доступ к основному компьютеру с установленным на нем клиентом (который еще нужно скачать, разобрать скрипты, проанализировать значимые для модификаций изменения, сделанные картошкой) и необходимым для разработки и сборки программным обеспечением. Это не говоря уже о том, что на полноценную разработку, отладку и публикацию нужно несколько часов времени, идущих подряд, а не в режиме, когда тебя периодически отвлекают, причем на далеко не самые тривиальные вещи. Набирать же текстовые посты на форуме можно с любого компьютера, на котором есть интернет, и времени на это нужно гораздо меньше (чего не скажешь про создание различного рода схем и прочей графики). Так что если что-то с виду кажется простым и легким, это абсолютно не означает, что так и есть на самом деле. Рабочий мод есть. Опубликован несколькими страницами ранее. Все, что публикуется как полноценная версия, по мере возможности тестируется на какой-то конкретной версии клиента, и количество существенных ошибок там минимально. То, что из-за действий картошки у меня на исправления под обновления клиента уходит больше времени, чем на разработку, это не моя личная проблема, это глобальная проблема всех более-менее сложных модификаций, страдаю от этого не только я, да и повлиять на частоту выхода обновлений клиента я никак не могу. И, между прочим, я в эту игру не играю уже больше двух лет. Я ни коим образом не отвечаю за те сборки модификации, которые публикуют другие люди. Исходники модификации находятся в свободном доступе, список необходимого для сборки программного обеспечения я уже публиковал ранее. Между прочим, никто не мешает самостоятельно проанализировать изменения в клиенте игры, внести необходимые правки и выложить в теме patch-файл (за что все окружающие будут премного благодарны). Но почему-то многие посетители темы вместо этого предпочитают выкладывать тут заявления, что я что-то там обещал. То, что многие воспринимают как обещания, не более чем более или менее реализуемые планы, ибо, как говорят в таких случаях в народе, "человек полагает, Бог располагает". А потому любые обещания, даже выраженные в виде прямых задокументированных обязательств (договора), не стоит воспринимать более чем обещания (обязательства) принять все возможные для выполнения этих обещаний меры. Что касается модификаций, если для кого-то эта игра и личная жизнь являются тождественными понятиями, это абсолютно не означает, что это распространяется и на всех остальных. Скорее даже наоборот - игровая тема для большинства здравомыслящих людей это хобби, осуществляемое в свободное от других дел время, и по вполне понятным и объективным причинам люди не заинтересованы делиться подробностями своей личной жизни со всеми не имеющими к ней никакого прямого отношения окружающими лишь с целью обоснования и оправдания выбранных ими приоритетов. @burmisterva, @goretz в общем и целом, предлагаю прекратить дальнейшие разбирательства по данному вопросу по причине их нецелесообразности. Ибо понимающему человеку это объяснять не требуется, а не понимающему - малоэффективно.
  4. Скорее всего, причиной данной проблемы является решение, используемое для исправления "провала сведения" (поиск по теме в помощь). Состоит оно в следующем: в алгоритмах расчета ожидаемой (предполагаемой, взятой по оси орудия без учета разброса) траектории полета снаряда, используемой для расчета координат и параметров (например, приведенной брони) маркера орудия, на расстоянии, которое выставлено на дальномере (расчетное расстояние), от игрока математически моделируется виртуальная стенка. При пересечении границ любого математически видимого для данного расчета объекта (видимыми считаются все реальные объекты, с которыми взаимодействует снаряд, плюс наша математическая стенка) вычисления прерываются, а данные, полученные от коллижн-теста (функция, которая проверяет короткий отрезок упрощенной до ломаной линии параболической траектории полета снаряда), используются для отображения маркера орудия. Если расчетное расстояние меньше реального расстояния до цели (танка противника), то моделируемый снаряд пересечет виртуальную стенку раньше, чем попадет в противника, а значит и отобразить параметры брони в такой ситуации попросту невозможно. Для защиты от подобных ситуаций рекомендуется использовать автоматический режим там, где это возможно. Также подобная ситуация может возникать при использовании автоматического режима при прицеливании в элементы техники, расположенные за виртуальной стенкой, построенной через центральную точку площадки под танком. Данная проблема уже внесена в список ошибок, требующих исправления в рабочем порядке. Для подобных задач (и не только) существует комбинация "автоматический режим + рентген (x-ray) в настройках сканера целей" (последнее нужно активировать в файлах конфигурации самому). Дальномер в автоматическом режиме всегда выставляется в соответствии с актуальным расстоянием до цели (или места, где она ушла из засвета), вне зависимости от наличия объектов между игроком и этой точкой. Это сделано для обеспечения стабильности наведения в ситуациях, когда игрок выезжает из-за угла для выстрела (чтобы орудие не прыгало по высоте сразу после выезда), либо когда игрок ловит танк противника, который маячит на углу или вполне ожидаемо вылетит из-за угла на скорости ("подарок" зачастую уходит еще до того, как противник высунется из-за угла, точнее враг вылетит оттуда аккуратно под плюху).
  5. Проблема здесь по сути та же, что и в случае с AdvancedAimingSystem. Проблемный файл содержит код загрузчика и у модификаций он практически одинаковый (если там вообще есть какие-либо различия), так что предложенный patch-файл по идее должен подойти и для MinimapGunMarkers. Проблема в том, что самостоятельно выполнить сборку я сейчас не имею технической возможности. З.Ы. На досуге нужно будет подумать над тем, как красиво, аккуратно и без лишних костылей вынести бутлоадер в библиотеку, ибо подобные симметричные обновления не есть хорошо. Проблема в том, что хоть код и на 99% там одинаковый (если не считать файлы с конфигурацией), для каждой модификации он свой персональный (в плане привязки к файлу, в котором он определен). Иными словами, у каждого файла своя среда выполнения, и нужно как-то красиво решить этот нетривиальный вопрос, чтобы импорт работал не как ссылка, а как копия, ну или как-то по-другому обойти этот угол.
  6. Краткая история появления AdvancedAimingSystem - мне надоело нажимать лишние кнопки :) Ибо нажимать полсотни раз за бой одну и ту же кнопку, пытаясь упорно объяснить игре, что ты стреляешь в противника, а не в скайбокс на другой стороне локации, это какой-то идиотизм.
  7. Ну так в Windows тоже есть аналог /dev/null, только он как-бы никому <принципиально> не нужен, поэтому мало кто знает его точное название... но он же есть! :) Скорее виртуализировать /dev/null :) Ну или визуализировать.
  8. Странно, как она туда вообще дошла (ну раз ничего при этом не крашнулось)... или они по-старинке, в /dev/null ее отправили? :)
  9. Этот функционал называется "корректировка прицеливания" ("корректировка дальномера" для аркадного и снайперского, "корректировка высоты" для стратегического (артиллерия)). Зажимание кнопки - это ручной режим, применяется в основном для "полных блайндов" (прострел кустов на шару, "где скорее всего сидит светляк"); для светящихся (выстрел на упреждение) и пропавших из засвета существует "авторежим", когда мод "захватывает" (определяет) текущую цель игрока и автоматически "выставляет дальномер", ориентируясь на текущее расстояние до этой цели. Расположенные над прицелом информационные текстовые панели как раз и нужны для того чтобы понимать, какой именно танк противника считается целью (сами панели на работу системы никак не влияют, они нужны лишь для отображения текущего состояния системы). Автоматический режим активен по умолчанию, захват происходит при наведении прицельной сетки на противника (с подсветкой контура цели), некоторые параметры можно настроить в конфиге. Там если хорошо покопаться можно много чего найти, ну не просто же так там в общей сложности около десятка конфигурационных файлов :) Не совсем верно, на уровне библиотеки только выбрасывается исключение, "ошибка" в самой модификации, причем в базовом коде (точка привязки для аддитивных хуков), поэтому в MinimapGunMarkers она тоже проявляется. И вызвана она тем, что картошка в 1.0.2 провела небольшую систематизацию базового кода, а в последнем обновлении просто выпилила ненужный более legacy-код, который, собственно говоря, модификация и не может найти. 2019-02-06 16:13:24.858: ERROR: Traceback (most recent call last): 2019-02-06 16:13:24.858: ERROR: File "HookUtils.py", line 59, in __call__ 2019-02-06 16:13:24.858: ERROR: File "HookUtils.py", line 180, in doStaticMethodHook 2019-02-06 16:13:24.858: ERROR: AttributeError: 'module' object has no attribute 'start' По идее, для решения проблемы этого должно быть достаточно, если картошка больше ничего не сломала. --- a/source/main/injector.py +++ b/source/main/injector.py @@ -17,8 +17,9 @@ # -------------------------------- # # Hooks injection main stage # # -------------------------------- # [email protected](g_inject_loads, gui.shared.personality, 'start', invoke=XModLib.HookUtils.HookInvoke.PRIMARY) -def new_Personality_start(*args, **kwargs): +import gameplay.delegator [email protected](g_inject_loads, gameplay.delegator.GameplayLogic, 'start', invoke=XModLib.HookUtils.HookInvoke.PRIMARY) +def new_GameplayLogic_start(self, *args, **kwargs): g_inject_stage_main() p_inject_stage_main() return З.Ы. Возможности собрать и протестировать у меня в данный момент нет, да и вообще этот patch-файл "собирался" на коленке вручную, так что надеюсь, что он все-таки рабочий :)
  10. @segovia, мне нужен python.log из корневой папки игры, а не конфигурация компьютера.
  11. Все же хотелось бы увидеть логи (python.log), а не только многочисленные жалобы, что что-то там отвалилось. Вполне вероятно, что данный функционал не является критичным и его можно временно отключить. На полноценную адаптацию модификации под изменения в клиенте игры у меня, к сожалению, в настоящее время просто не остается ни свободного времени, ни сил. Честно говоря, такой расклад мне и самому не шибко нравится, но в силу объективных причин я практически никак не могу на это повлиять.
  12. В рамках XVM необходимость подредактировать лишнюю флешку не является большой проблемой, у них огромная аудитория, многие мелкие моды, затрагивающие флешки, так или иначе подстраиваются под XVM. Хотя я сильно сомневаюсь, что редактирование флешки - это единственный путь. К примеру, лично я уже довольно давно использую хитрый способ добавления своих методов и атрибутов к классам и объектам через прототипы. Причем в рантайме (monkey-patch). Делается все достаточно просто - сначала подгружаем свою персональную флешку с этим веселым кодом (кстати, код загрузчика флешки прописан здесь - флешка просто аккуратно подбрасывается в конец списка подгружаемых флешек-библиотек), а потом просто берем и делаем вот так (можем вызывать нашу собственную функцию хоть прямо из питона). Приведенный код добавляет к контейнеру слоев миникарты метод добавления нового слоя, на котором потом можно вполне спокойно размещать свои персональные маркеры (класс маркеров, добавление маркера в питоне). Теория этих танцев с бубном неплохо описана здесь. Вполне возможно что данную методику можно и для хуков использовать (а не только для добавления функций), правда этот момент я не проверял. Давно уже хочу заняться более подробным исследованием данного вопроса (ибо monkey-patch - это именно то, чего больше всего не хватает в AS3), возможно даже написать небольшой гайд на эту тему, но все никак не доходят руки.
  13. Для питона есть более четкий вариант, написанный на питоне. Правда я его давненько уже не обновлял, хотя и причин особых вроде как не было.
  14. Of course they are. Definition of these attributes for a class instance is nothing else than making a placeholder for real sub-objects created in Adobe Flash. Sub-objects (named children) in Adobe Flash have their names that match var names in class definition. These variables (attributes) are always public. They (sub-objects) are also inaccessible by their names without these declarations, so in most cases variables (attributes) are declared, but leaved undefined or preset to null. Most public attributes that preset to null are named children or DAAPI entities. DAAPI is the Direct Access API, it is used for linking Python and ActionScript, more information could be found here (examples are outdated, but structural information is still actual). Objects created in Adobe Flash is already instantiated as a single copy. The only way to get a copy is to make a copy... but I don`t know if it is possible at all (without copying object in Adobe Flash). If you want to replace something you gotta replace it directly, that means you have to edit an existing flash file. To add something in most cases it is enough to add an external flash document with the injection code. ActionScript (unlike Python) is not monkey-patch-friendly, so it is really hard to replace any object in run-time, sometimes possible of course but done a real tricky way hard to understand even for advanced ActionScript coders.
  15. They are created in Adobe Flash. This class is used as an element class (not directly usually, but through inheritance with an additional class in root namespace compiled in flash file with element itself) and is a descendant of MovieClip or Sprite trough a long chain of inheritance.
  16. Странно как-то все это. Самое что интересное, раньше такой проблемы не было, и группировка происходила правильно. То-ли я чего-то не замечал. И как-бы у меня страница уведомлений открыта практически постоянно в браузере, и на контент я перехожу по уведомлениям, так что уведомления практически всегда читаются раньше, чем сам контент. Меня больше всего здесь настораживает то, что в обоих случаях забаговалось только одно уведомление, которое было перед моим ответом в каждом из случаев. Тут более интересная ситуация. Первое уведомление на тему Advanced Aiming System прилетело 20 ноября, ссылается оно сюда (445412), перед этим сообщением последний пост датируется 17 октября, то есть более месяца назад, и поскольку кроме страницы уведомлений других открытых вкладок форума я обычно не держу, то попасть в тему и увидеть сообщение я мог только через уведомления. Следующим постом идет мой ответ, поэтому на момент публикации моего сообщения (445418) уведомление и сообщение (по ссылке чуть выше) уже однозначно были прочитаны. И далее опять те же яйца, только в профиль и в большем размере - произошла группировка уведомлений от сообщений 445429 (второе сообщение Scharfhobel, после моего первого ответа) и 445472 (от StranikS_Scan, после моего второго ответа) на базе уже прочитанного ранее уведомления со ссылкой на сообщение 445412 (исходное уведомление от 20 ноября). Тут правда есть один нюанс - я не помню, обновлял ли я страницу уведомлений после своего первого ответа (445418), или получил второе сообщение от Scharfhobel (445429) в виде подсказки на странице темы. Однако тут стоит также обратить внимание на еще один момент. Уведомления от 22 ноября отображаются нормально и под группировку с исходным уведомлением не попали (они сгруппировались отдельно, и там явных косяков не видно). При этом между ними и исходным (если анализировать по временным параметрам) есть три "левых" уведомления (два цитирования и личное сообщение), и группировки с исходным нет, а между уведомлением на сообщение от StranikS_Scan (445472) и исходным все еще остаются "левые" уведомления (но уже только два, личное сообщение и цитирование), и группировка с исходным уведомлением таки происходит. Однако есть нехилая вероятность, что на момент добавления уведомления от сообщения 445472 к исходной группе уведомления о цитировании и личном сообщении от Scharfhobel не были прочитаны. В общем, если свести все сказанное выше, отслеживается следующая логика работы системы уведомлений: Таки подтверждается тот факт, что уведомления группируются с учетом прочитанности уведомлений, а не контента. Но само по себе причиной рассматриваемой ошибки это быть не может. Уведомления о новых сообщениях в теме группируются к первому непрочитанному уведомлению такого типа (по крайней мере так должно быть, но не всегда работает как надо). Все остальные уведомления группировке не подвержены. Наблюдается интересный глюк, заключающийся в том, что при определенных условиях при поиске ["базового"] уведомления для "пригруппировки" к нему нового, прочитанность "базового" почему-то не учитывается (оно по непонятной причине считается непрочитанным); иными словами, движок группирует новые уведомления к уже прочитанному, считая его непрочитанным, создавая тем самым предмет обсуждения данной темы. Таким образом, проблема не в стратегии группировки уведомлений, а в какой-то ошибке в плане ее реализации. В общем, ставлю на типичную ошибку с индексами (с нуля или с единицы считаются элементы), скорее всего именно из-за этого последнее прочитанное уведомление (возможно с фильтрацией по типу) и считается непрочитанным, отсюда и возникает проблема. Но это всего лишь предположение. P.S. Извиняюсь за чрезмерно длинный пост, но возможно данная информация таки поможет найти причину проблемы. И да, по всей видимости именно из-за этой самой проблемы у меня несколько раз и были ситуации, когда один и тот же человек отправлял два сообщения подряд (с интервалом больше порога слияния), но при этом на второе сообщение уведомление не приходило, точнее оно просто незаметно сливалось с предыдущим (если в других отслеживаемых темах было тихо). Кстати, возможно что и проблема с не приходящими уведомлениями при слиянии сообщений так же связана с предметом обсуждения этой темы. Заинтересованные: + @ktulho, @Pavel3333
  17. Каждое сообщение в отслеживаемой теме генерирует уведомление. Если с момента последнего чтения темы новых сообщений появилось несколько, то они (уведомления) группируются в одно уведомления с перечислением отвечавших пользователей. В приведенном на скриншоте примере есть два сгруппированных уведомления (четвертое снизу и второе сверху). Но список пользователей в них перечислен так, что мои сообщения оказываются между сообщениями перечисленных пользователей. То есть уведомления о новых сообщениях в теме группируются как-то неправильно, к примеру уведомление о сообщении от StranikS_Scan сгруппировалось с Pavel3333, хотя между этими сообщениями есть мое, где я ответил на сообщение Pavel3333, то есть однозначно прочитал тему. Иными словами, новые уведомления почему-то группируются с уведомлениями об уже прочитанных ранее сообщениях. Есть весьма навязчивое ощущение, что там проблема с индексами, ошиблись где-то на единичку, потому как сгруппированным (на скрине) должно быть третье сверху уведомление, с содержанием Mr 13, night_dragon_on, а второе сверху должно содержать только Mr 13, тогда все получается ровно. Как по идее должно быть (отредактировано в браузере).
  18. При формировании текста уведомления список ответивших в теме пользователей считается некорректно. В приведенном ниже примере ожидаемая последовательность (согласно скриншоту): Mr 13, <тема прочитана>, Pavel3333, StranikS_Scan, <тема прочитана>, Mr 13, <тема прочитана>, night_dragon_on, Mr 13, <тема прочитана>. Реальная последовательность сообщений: Mr 13, Pavel3333, GPCracker, StranikS_Scan, Mr 13, night_dragon_on, GPCracker, Mr 13. Получается, что каким-то образом я два раза (четвертое снизу и второе сверху уведомления) оставил сообщение "посередине списка ответивших пользователей", указанных в уведомлении. И причем такое начало происходить относительно недавно, максимум месяц-полтора назад. Заинтересованные: @Mr 13
  19. @Mr 13, получилось просто шикарно. Кстати, насколько я понимаю, идентификаторы отдельных сообщений уникальны в рамках форума? Если это так, то можно еще добавить возможность использования ссылок типа https://kr.cm/f/c/337090/ (ссылка на комментарий без указания идентификатора темы)? Просто сообщения иногда перемещаются/отделяются модераторами, а ссылки типа тема-комментарий сначала "находят" тему, а потом уже ищут в ней нужный комментарий. В некоторых ситуациях ссылаться непосредственно на комментарий без привязки к теме может быть весьма полезным.
  20. А ты попробуй в текстовый/markdown readme запихать, причем так, чтобы у англоязычных пользователей она тоже по-человечески выглядела, то есть соответствовала списку требований в шапке :)
  21. Поскольку форум зачастую используется как официальная переговорная площадка, причем довольно большим количеством модификаций, временами очень сильно не хватает постоянных и осмысленных коротких ссылок на различные объекты на форуме (разделы, темы, профили). Собственно, ссылок, которые бы удовлетворяли следующим требованиям: Краткость (ссылка не должна быть слишком длинной); Вечность (ссылка не должна иметь периода устаревания); Осмысленность (по тексту ссылки должно быть четко понятно, куда именно она ведет); Неизменность (при переименовании раздела/темы/пользователя ссылка должна оставаться рабочей); Ссылка не должна содержать escaped-символов (в том числе русских букв); При формировании ссылки не должно быть подводных камней (gotchas); С точки зрения простого пользователя, наиболее адекватным и простым вариантом решения данной задачи было бы отключение необходимости указания текстового идентификатора (заголовка темы или раздела, никнейма пользователя). Но если я правильно понимаю, поддержка сокращенных до дефиса, или даже до цифр идентификатора, ссылок на объекты на форуме осложнена проблемами реализации такой поддержки без использования костылей и велосипедов, которые в свою очередь создают проблемы при обновлении движка форума? И насколько я понял по предыдущим комментариям, проблема зарыта именно в коде движка и с содержанием форума никак не связана. В таком случае, если судить по довольно обширному списку различных плагинов, полагаю что данную задачу вполне можно решить созданием в рамках такого модуля дополнительной страницы-редиректа, которая бы принимала в качестве параметров целые идентификаторы объектов и перенаправляла пользователя по актуальной ссылке. То есть, например, при переходе по ссылке типа https://kr.cm/forum/goto/?forum=20 пользователя бы перенаправляло на https://koreanrandom.com/forum/forum/20-о-ресурсах-korean-random/ (с виду разница не очень заметна, но последняя ссылка содержит escaped-символы [русские буквы], и в формате ASCII станет очень длинной и практически нечитаемой). Кроме того, ранее (более года тому назад) уже упоминался какой-то вариант решения проблемы со ссылками на форуме, однако без подробностей. Хотелось бы поинтересоваться, как обстоят дела и есть ли вообще какой-либо прогресс по данному вопросу. К тому же, если для разработки решения не требуется административный доступ к форуму (вполне достаточно только наличия самого движка и базового шаблона содержимого), возможно имеет смысл поставить процесс на промышленные рельсы (формализовать задачу и подключить к процессу разработки подобного дополнения других заинтересованных пользователей движка)? В частности, на форуме того же IPS наверняка найдутся желающие в этом поучаствовать, ну или хотя бы подкинуть полезной информации. Ссылки по теме: раз, два. Заинтересованные: @Mr 13, @night_dragon_on P.S. Тема была подробно расписана из соображений сделать обсуждение более понятным без путешествий по длинным цепочкам ссылок.
  22. Скорее всего уже не актуально, но на всякий случай оставлю это здесь.
  23. Реализовать перехват нажатия/отпускания ПКМ не проблема, как и смену режимов прицеливания. Проблема в том, что на ПКМ есть как минимум два ванильных бинда - автоприцел по клику и "отвязка" орудия от прицела по зажатию (режим обзора). Как минимум один из биндов прибит намертво, частично в скриптах, частично в файлах конфигурации игры (xml). Для реализации этого функционала картофельные бинды придется куда-то деть. Вопрос в том, куда (само переназначение можно сделать путем редактирования scripts/command_mapping.xml, разделы CMD_CM_FREE_CAMERA и CMD_CM_LOCK_TARGET, это как минимум, а вообще, поиск по KEY_RIGHTMOUSE в помощь; ну или перехватом на уровне чтения этого файла внутри самого мода). P.S. В силу недостатка времени и сил на разработку и поддержку модификаций самостоятельно заниматься этим у меня нет возможности. Однако я вполне могу оказать посильную помощь информационного характера в рамках публичной темы на форуме. P.S.S. И вообще, не нужно заваливать меня личными сообщениями, если ответы задаваемые вопросы могут еще кого-то заинтересовать, пусть даже чисто теоретически.
  24. В этом плане ничего не поменялось, техническая возможность получать практически все данные о событиях клавиатуры никуда не исчезла. Проблема в другом. Насколько я понимаю, полного понимания сути вопроса до сих пор не достигнуто. Ладно, попробую объяснить более наглядно. Бинд - это связь, связь между некоторой командой и сочетанием клавиш, нажимаемых на клавиатуре для выполнения этой команды. На существующем примере: "переключить прицел" - это команда, KEY_E - это сочетание. На одно сочетание может быть привязано несколько последовательных команд, как и для одной команды может быть задано несколько различных комбинаций клавиш, в этом нет никаких технических сложностей. Проблема "двойного бинда" заключается не в самой процедуре привязки нескольких команд на одно сочетание, а в сути используемых команд. Дело в том, что при вызове команды AvatarInputHandler она выполняется не полностью, а только лишь частично. Оставшаяся ее часть вычисляется уже на стадии пересчета прицела, который [пересчет] выполняется независимо от событий клавиатуры с интервалом порядка 0.04 секунды (порядка 25 раз в секунду). Это сделано из соображений оптимизации, поскольку выполнять математические вычисления с большей частотой (та же мышка с небольшим откликом и приличным dpi, к примеру, способна генерировать события перемещения десятки раз в секунду) не имеет практического смысла, так как пользователь все равно не увидит разницы, а процессор это достаточно сильно нагружает. На сервере так вообще, если мне не изменяет память, судя по имеющимся в клиенте константам, сцена пересчитывается с интервалом 0.1 секунды (всего 10 раз в секунду). Так вот, команда переключения прицела пинает AvatarInputHandler "на запись", поэтому вместе с ней в одном интервале обновления не должно быть никаких других write-команд AvatarInputHandler, к таким командам относится и сброс автоприцела, о котором идет речь. Именно по этой самой причине, дабы предотвратить вызов других команд AvatarInputHandler одновременно с переключением прицела (и не только, сюда относится любая write-команда), и блокируется выполнение команды со стороны модификации, если событие клавиатуры уже было "съедено" чем-то другим на стороне клиента игры. Поведение с блокировкой "двойных биндов" применяется исключительно к потенциально опасным командам, их я перечислил чуть выше, а не ко всему подряд. P.S. Пытался ответить еще вчера, но какие-то ******* отрубили электричество по всему дому...
  25. Ну в чем-то я с этим согласен... я действительно уже несколько устал отвечать на одни и те же вопросы с одним и тем же смыслом, но из разных углов и в разных вариациях. Потому периодически нервничаю и временами генерирую пусть и не очень понятную простому пользователю, но достаточно исчерпывающую документацию по тому или иному часто задаваемому вопросу. К сожалению, по некоторым вопросам (в особенности связанным с общей логикой работы модификации) нарисовать наглядную картинку попросту невозможно, или она так же будет наполовину состоять из текста, да и с рисованием на компьютере, собственно как и на бумаге, у меня не очень. Начертить сложную деталь не проблема, а вот рисовать и вообще в графический дизайн не умею от слова совсем.
×
×
  • Create New...