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

Фото

Как сделать свой мод на XFW


  • Чтобы отвечать, сперва войдите на форум
42 ответов в теме

#41 GPCracker

GPCracker

    Piranhas Team

  • Пользователь
  • 2 251 сообщений
  • WoT Server:RU (Русский)
  • Город: Москва

Опубликовано 15 Октябрь 2016 - 22:44

Такой подход есть смысл использовать?

Типичный пример кода на костылях. Список участников боя берется из арены, но перехват события осуществляется в GUI.
Это в стиле "подождем очередь в булочной, но закупаться пойдем в мясную лавку". Если информация берется из арены, то и хук надо ставить там же, на отработку получения этой самой информации.
Либо вообще на более высокий уровень идти, там приходят уже распределенные ивенты (например, g_sessionProvider). Арена - это достаточно низкий уровень. Но на высоких уровнях требуется классовая организация кода. В частности, через g_sessionProvider добавляется листенер-объект/класс, уже не помню, через который можно получать события на арене.
Выделяешь ли ты свой код в функцию - это особого значения не имеет. Многие подходы сами по себе дикие костыли.
  • 1

#42 STREJlA

STREJlA
  • Пользователь
  • 18 сообщений
  • Nick: STREJlA
  • WoT Server:RU (Русский)

Опубликовано 15 Октябрь 2016 - 22:50

Типичный пример кода на костылях. Список участников боя берется из арены, но перехват события осуществляется в GUI.
Это в стиле "подождем очередь в булочной, но закупаться пойдем в мясную лавку". Если информация берется из арены, то и хук надо ставить там же, на отработку получения этой самой информации.
Либо вообще на более высокий уровень идти, там приходят уже распределенные ивенты (например, g_sessionProvider). Арена - это достаточно низкий уровень. Но на высоких уровнях требуется классовая организация кода. В частности, через g_sessionProvider добавляется листенер-объект/класс, уже не помню, через который можно получать события на арене.
Выделяешь ли ты свой код в функцию - это особого значения не имеет. Многие подходы сами по себе дикие костыли.

Что означает приставка g_ в названиях ивентов?


  • 0

#43 GPCracker

GPCracker

    Piranhas Team

  • Пользователь
  • 2 251 сообщений
  • WoT Server:RU (Русский)
  • Город: Москва

Опубликовано 15 Октябрь 2016 - 23:46

STREJlA, Вообще, подходов к реализации многих вещей в настоящее время существует два.
Первый - это городить систему хуков и логики для анализа того, что с этих хуков приходит. В настоящее время наиболее популярный подход. Достоинства - простота кода, отсутствие классов и необходимости сложного анализа кода картохи. Минусы - сильно проседает на сложных проектах.
Второй появился не так давно, после того, как картоха поняла, что первый метод ведет за собой кучу различных перекрестных костылей, вроде того, что ты скинул, когда связываются несвязанные вещи для получения результата, и они стали систематизировать код. В частности, от системы прямого обращения к объектам (раньше в файлах обработчика техники можно было увидеть обращения к миникарте, например), в особенности к элементам графического интерфейса, они перешли на систему событий, когда существует объект, который инициирует события (g_sessionProvider), и к которому обращаются различные источники событий (Arena), и объекты, которых это событие интересует, на него подписываются (GUI).
Второй подход состоит в том, что ты создаешь свой обработчик, и "аккуратно подкидываешь" его в систему картохи. Он как-бы становится полноценной частью системы. По факту, хуки идут только на месте этого самого "подброса". Все остальное делают за тебя скрипты WG - вызывают методы твоего объекта при возникновении внешних событий. А уже в своих методах ты эти события обрабатываешь, как тебе нужно. В большинстве случаев, при правильном подходе, все необходимые события ты получаешь, и количество необходимых хуков и перекрестных костылей резко падает практически до нуля.
Плюсы второго подхода - он более аккуратный и красивый, ни с кем не конфликтует, поскольку ты ничего не патчишь (хуки на добавление в список твоих элементов не в счет, они прозрачные), и требуется значительно меньше различной логики. Минусы - из-за большого количества необходимой обвязки увеличивается немного количество кода (однако его логика несколько упрощается), большое использование классов и других, не совсем понятных новичкам программирования вещей.
Можно привести достаточно простое сравнение. Скажем, нужно добавить танку возможность стрелять ПТУРами. Первый способ - это навесить ПТУРы в отдельных контейнерах на башню. Просто, но не очень практично, они там как-бы немного лишние. Второй способ - это стрельба ПТУРами из пушки (как делают почти все отечественные современные танки). Основная сложность - это сама ПТУР, зато в остальном - это как-бы такая же часть боекомплекта, как и остальные снаряды. Как-бы решили задачу добавлением нового снаряда в боекомплект, не перепиливая при этом систему.

Что означает приставка g_ в названиях ивентов?

Не в названиях ивента, а в имени переменной. Что эта переменная глобальная и содержит уникальный экземпляр объекта.

Изменено: GPCracker, 15 Октябрь 2016 - 23:36

  • 2





0 пользователей читают эту тему

0 зарегистрированных, 0 гостей, 0 невидимых

© Mr 13