Перейти к содержимому
Korean Random

GPCracker

Пользователь
  • Публикации

    2 765
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    59

Последний раз GPCracker выиграл 27 ноября 2018

Публикации GPCracker были самыми популярными!

Репутация

2 014 ⭐⭐⭐⭐⭐

О GPCracker

  • Звание
    Piranhas Team
  • День рождения 05.11.1994

Основная информация

  • Пол
    Мужчина
  • Город
    Москва
  • Интересы
    Схемотехника, программирование и телекоммуникации.

Контакты

  • Сервер WoT
    RU / CIS

Посетители профиля

23 412 просмотра профиля
  1. В рамках XVM необходимость подредактировать лишнюю флешку не является большой проблемой, у них огромная аудитория, многие мелкие моды, затрагивающие флешки, так или иначе подстраиваются под XVM. Хотя я сильно сомневаюсь, что редактирование флешки - это единственный путь. К примеру, лично я уже довольно давно использую хитрый способ добавления своих методов и атрибутов к классам и объектам через прототипы. Причем в рантайме (monkey-patch). Делается все достаточно просто - сначала подгружаем свою персональную флешку с этим веселым кодом (кстати, код загрузчика флешки прописан здесь - флешка просто аккуратно подбрасывается в конец списка подгружаемых флешек-библиотек), а потом просто берем и делаем вот так (можем вызывать нашу собственную функцию хоть прямо из питона). Приведенный код добавляет к контейнеру слоев миникарты метод добавления нового слоя, на котором потом можно вполне спокойно размещать свои персональные маркеры (класс маркеров, добавление маркера в питоне). Теория этих танцев с бубном неплохо описана здесь. Вполне возможно что данную методику можно и для хуков использовать (а не только для добавления функций), правда этот момент я не проверял. Давно уже хочу заняться более подробным исследованием данного вопроса (ибо monkey-patch - это именно то, чего больше всего не хватает в AS3), возможно даже написать небольшой гайд на эту тему, но все никак не доходят руки.
  2. Для питона есть более четкий вариант, написанный на питоне. Правда я его давненько уже не обновлял, хотя и причин особых вроде как не было.
  3. GPCracker

    Как создать форму(Окно) в ангаре

    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.
  4. GPCracker

    Как создать форму(Окно) в ангаре

    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.
  5. GPCracker

    Некорректное формирование уведомлений

    Странно как-то все это. Самое что интересное, раньше такой проблемы не было, и группировка происходила правильно. То-ли я чего-то не замечал. И как-бы у меня страница уведомлений открыта практически постоянно в браузере, и на контент я перехожу по уведомлениям, так что уведомления практически всегда читаются раньше, чем сам контент. Меня больше всего здесь настораживает то, что в обоих случаях забаговалось только одно уведомление, которое было перед моим ответом в каждом из случаев. Тут более интересная ситуация. Первое уведомление на тему 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
  6. GPCracker

    Некорректное формирование уведомлений

    Каждое сообщение в отслеживаемой теме генерирует уведомление. Если с момента последнего чтения темы новых сообщений появилось несколько, то они (уведомления) группируются в одно уведомления с перечислением отвечавших пользователей. В приведенном на скриншоте примере есть два сгруппированных уведомления (четвертое снизу и второе сверху). Но список пользователей в них перечислен так, что мои сообщения оказываются между сообщениями перечисленных пользователей. То есть уведомления о новых сообщениях в теме группируются как-то неправильно, к примеру уведомление о сообщении от StranikS_Scan сгруппировалось с Pavel3333, хотя между этими сообщениями есть мое, где я ответил на сообщение Pavel3333, то есть однозначно прочитал тему. Иными словами, новые уведомления почему-то группируются с уведомлениями об уже прочитанных ранее сообщениях. Есть весьма навязчивое ощущение, что там проблема с индексами, ошиблись где-то на единичку, потому как сгруппированным (на скрине) должно быть третье сверху уведомление, с содержанием Mr 13, night_dragon_on, а второе сверху должно содержать только Mr 13, тогда все получается ровно. Как по идее должно быть (отредактировано в браузере).
  7. При формировании текста уведомления список ответивших в теме пользователей считается некорректно. В приведенном ниже примере ожидаемая последовательность (согласно скриншоту): 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
  8. GPCracker

    Универсальные короткие ссылки на форуме

    @Mr 13, получилось просто шикарно. Кстати, насколько я понимаю, идентификаторы отдельных сообщений уникальны в рамках форума? Если это так, то можно еще добавить возможность использования ссылок типа https://kr.cm/f/c/337090/ (ссылка на комментарий без указания идентификатора темы)? Просто сообщения иногда перемещаются/отделяются модераторами, а ссылки типа тема-комментарий сначала "находят" тему, а потом уже ищут в ней нужный комментарий. В некоторых ситуациях ссылаться непосредственно на комментарий без привязки к теме может быть весьма полезным.
  9. GPCracker

    Универсальные короткие ссылки на форуме

    А ты попробуй в текстовый/markdown readme запихать, причем так, чтобы у англоязычных пользователей она тоже по-человечески выглядела, то есть соответствовала списку требований в шапке :)
  10. Поскольку форум зачастую используется как официальная переговорная площадка, причем довольно большим количеством модификаций, временами очень сильно не хватает постоянных и осмысленных коротких ссылок на различные объекты на форуме (разделы, темы, профили). Собственно, ссылок, которые бы удовлетворяли следующим требованиям: Краткость (ссылка не должна быть слишком длинной); Вечность (ссылка не должна иметь периода устаревания); Осмысленность (по тексту ссылки должно быть четко понятно, куда именно она ведет); Неизменность (при переименовании раздела/темы/пользователя ссылка должна оставаться рабочей); Ссылка не должна содержать 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. Тема была подробно расписана из соображений сделать обсуждение более понятным без путешествий по длинным цепочкам ссылок.
  11. Скорее всего уже не актуально, но на всякий случай оставлю это здесь.
  12. GPCracker

    Мод на улучшенный режим прицеливания.

    Реализовать перехват нажатия/отпускания ПКМ не проблема, как и смену режимов прицеливания. Проблема в том, что на ПКМ есть как минимум два ванильных бинда - автоприцел по клику и "отвязка" орудия от прицела по зажатию (режим обзора). Как минимум один из биндов прибит намертво, частично в скриптах, частично в файлах конфигурации игры (xml). Для реализации этого функционала картофельные бинды придется куда-то деть. Вопрос в том, куда (само переназначение можно сделать путем редактирования scripts/command_mapping.xml, разделы CMD_CM_FREE_CAMERA и CMD_CM_LOCK_TARGET, это как минимум, а вообще, поиск по KEY_RIGHTMOUSE в помощь; ну или перехватом на уровне чтения этого файла внутри самого мода). P.S. В силу недостатка времени и сил на разработку и поддержку модификаций самостоятельно заниматься этим у меня нет возможности. Однако я вполне могу оказать посильную помощь информационного характера в рамках публичной темы на форуме. P.S.S. И вообще, не нужно заваливать меня личными сообщениями, если ответы задаваемые вопросы могут еще кого-то заинтересовать, пусть даже чисто теоретически.
  13. В этом плане ничего не поменялось, техническая возможность получать практически все данные о событиях клавиатуры никуда не исчезла. Проблема в другом. Насколько я понимаю, полного понимания сути вопроса до сих пор не достигнуто. Ладно, попробую объяснить более наглядно. Бинд - это связь, связь между некоторой командой и сочетанием клавиш, нажимаемых на клавиатуре для выполнения этой команды. На существующем примере: "переключить прицел" - это команда, KEY_E - это сочетание. На одно сочетание может быть привязано несколько последовательных команд, как и для одной команды может быть задано несколько различных комбинаций клавиш, в этом нет никаких технических сложностей. Проблема "двойного бинда" заключается не в самой процедуре привязки нескольких команд на одно сочетание, а в сути используемых команд. Дело в том, что при вызове команды AvatarInputHandler она выполняется не полностью, а только лишь частично. Оставшаяся ее часть вычисляется уже на стадии пересчета прицела, который [пересчет] выполняется независимо от событий клавиатуры с интервалом порядка 0.04 секунды (порядка 25 раз в секунду). Это сделано из соображений оптимизации, поскольку выполнять математические вычисления с большей частотой (та же мышка с небольшим откликом и приличным dpi, к примеру, способна генерировать события перемещения десятки раз в секунду) не имеет практического смысла, так как пользователь все равно не увидит разницы, а процессор это достаточно сильно нагружает. На сервере так вообще, если мне не изменяет память, судя по имеющимся в клиенте константам, сцена пересчитывается с интервалом 0.1 секунды (всего 10 раз в секунду). Так вот, команда переключения прицела пинает AvatarInputHandler "на запись", поэтому вместе с ней в одном интервале обновления не должно быть никаких других write-команд AvatarInputHandler, к таким командам относится и сброс автоприцела, о котором идет речь. Именно по этой самой причине, дабы предотвратить вызов других команд AvatarInputHandler одновременно с переключением прицела (и не только, сюда относится любая write-команда), и блокируется выполнение команды со стороны модификации, если событие клавиатуры уже было "съедено" чем-то другим на стороне клиента игры. Поведение с блокировкой "двойных биндов" применяется исключительно к потенциально опасным командам, их я перечислил чуть выше, а не ко всему подряд. P.S. Пытался ответить еще вчера, но какие-то ******* отрубили электричество по всему дому...
  14. Ну в чем-то я с этим согласен... я действительно уже несколько устал отвечать на одни и те же вопросы с одним и тем же смыслом, но из разных углов и в разных вариациях. Потому периодически нервничаю и временами генерирую пусть и не очень понятную простому пользователю, но достаточно исчерпывающую документацию по тому или иному часто задаваемому вопросу. К сожалению, по некоторым вопросам (в особенности связанным с общей логикой работы модификации) нарисовать наглядную картинку попросту невозможно, или она так же будет наполовину состоять из текста, да и с рисованием на компьютере, собственно как и на бумаге, у меня не очень. Начертить сложную деталь не проблема, а вот рисовать и вообще в графический дизайн не умею от слова совсем.
  15. Соответствующая логика работы обработчика событий клавиатуры прописана здесь. В переводе на понятный русский это означает: модуль AvatarInputHandler клиента игры (он отвечает за прицеливание в игре) запущен, курсор не откреплен (курсор в нормальном состоянии прикреплен к прицелу, то есть при перемещении мыши перемещается и прицел, при зажатии Ctrl он открепляется, прицел больше не реагирует на мышь, появляется значок курсора на экране, и можно взаимодействовать с элементами пользовательского интерфейса; именно поэтому для некоторых [завязанных на AvatarInputHandler] функций и не работают сочетания содержащие Ctrl), режим прицеливания поддерживается (в данном случае сочетание будет работать только если игрок находится в снайперском или аркадном режиме прицеливания), событие (сочетание клавиш) не было обработано (не используется) клиентом игры. Комментарий: для базовых "переключателей" модуля AvatarInputHandler. Причина последнего: выполнение привязанного к событию клавиатуры на уровне модификации действия изменяет состояние модуля AvatarInputHandler (переключает режим прицеливания), выполнение "параллельно" другого действия (например, сброса автоприцела, но это всего лишь частный случай), но уже по инициативе обработчика клавиатуры на стороне клиента игры (внутри самого AvatarInputHandler) может повлечь за собой "параллельный" (в пределах одного интервала обновления) доступ к общим параметрам и тем самым спровоцировать непредсказуемое некорректное поведение (глюк/исключение/вылет с непредсказуемыми характеристиками). Такое явление достаточно вероятно, поскольку часть внутренних параметров AvatarInputHandler обновляется в отложенном режиме с определенными интервалами времени (интервал обновления/пересчета прицела), а базовая обработка событий клавиатуры происходит по факту их возникновения (сразу); таким образом существует крайне высокая вероятность того, что обе команды (команда клиента и команда модификации, в рассматриваемом случае это отключение автоприцела и переключение режима прицеливания) будут выполнены модулем AvatarInputHandler в один и тот же интервал между обновлениями прицела, а если учитывать то, как написан код этого модуля, то вероятность возникновения конфликтной ситуации, с учетом многочисленности и разнообразности привязанных к клавиатуре действий на стороне клиента игры, стоит оценивать как достаточно высокую. Причем в данной ситуации речь идет о глобальном поведении обработчика событий клавиатуры внутри модификации (игнорирование уже обработанных клиентом игры событий), а не о частных случаях вроде назначения отключения автоприцела и переключения режима прицеливания на одно сочетание (событие). Тут стоит принимать во внимание тот факт, что отсутствие конфликта между двумя конкретными действиями в рамках управления модулем AvatarInputHandler не означает отсутствия конфликта между любыми двумя действиями, также необходимо учитывать, что внесение любых изменений со стороны картошки, в том числе и не затрагивающих прямо обработку одной из команд, может повлечь за собой возникновение конфликта там, где его раньше не было (на ровном месте), и при этом сам факт появления такого конфликта будет абсолютно не очевиден при анализе изменений в клиенте игры (применение аналитического подхода к исправлению ошибок будет проблематичным). К тому же, как показывает практика, подобные ситуации крайне сложно отлаживать, потому как при возникновении исключения при отложенной обработке данных в трассировках ошибки почти никогда не содержится информации о том, что стало источником некорректного набора исходных данных (некорректного состояния). В общем, если коротко, в целях предотвращения возникновения проблем по принципу WTF у пользователей, возникающих из-за "с виду правильной, но не очень удачной" конфигурации модификации, а также вопросов в том же самом стиле у меня (и других мододелов, кстати, тоже), на стадии анализа логов питона с целью выяснения причины возникновения исключения (неведомой ошибки, сопровождающейся той самой трассировкой в логах), во всех ситуациях, где модификация меняет состояние AvatarInputHandler тем или иным образом, использование любых обрабатываемых клиентом игры и имеющих отношение к командам для AvatarInputHandler биндов (так называемых "двойных биндов") заблокировано на уровне модификации в рамках глобальной политики обработки событий клавиатуры. Если еще короче, то на всех функциях, которые пинают AvatarInputHandler "на запись" при использовании "двойных биндов" событие клавиатуры обрабатываться со стороны модификации не будет. На текущий момент такими функциями являются Advanced Arty, SPG Sniper Mode, TargetScanner - AutoScan, TargetScanner - ManualOverride, AimCorrection - Target Mode. И собственно, ответ на вполне логичный вопрос, зачем вообще весь этот огромный пост нужен. Затем, чтобы желающие подрубить [себе] возможность использования "двойных биндов" таки имели представление о причинах, по которым данная возможность изначально была заблокирована.
×