Перейти к содержанию

MaxSerro

Стажёры
  • Постов

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

  • Посещение

Репутация

0 Навыки не прокачены
  1. Возможно, ты имел в виду это видео: https://youtu.be/oV74F6i2cyA - и следующие за ним части
  2. @Xipho, привет снова! Прошло уже довольно много времени с момента, как я обратился за помощью по улучшению кода на форум, но я не забывал о своей программе и улучшал ее как только мог. Условимся, что сброс по одной бомбе - это 100%-ая эффективность программы, сброс по две бомбы (имитация нажатия отмены приказа клавишей S не поспевает) - это 50%-ая эффективность, а сброс по три бомбы - это 0%-ая эффективность, то есть никакая. Программа сейчас идеально работает в одиночной игре, то есть со 100%-ой эффективностью, но при определенном диапазоне искусственной задержки, которую я поставил, чтобы процессор не был нагружен на 100%. Если точно, то я подобрал 1-40 мс задержки; если >40, то программа уже не поспевает. Напомню, что интервал времени между одной сброшенной бомбой и следующей составляет 200 мс. В одиночной игре эффективность 100%, а вот в мультиплеере снижается до 50% (НИ РАЗУ не была 100%) и иногда до 0%. Уменьшение искусственной задержки до 1 мс ничего не дало, а 25 мс - оказалось слишком много. Я решил, что это нерешаемая проблема, так как соединение не идеально. Я предполагаю, что механизм работы сетевой игры следующий: каждый клиент шлет в локальную сеть данные об изменениях в игровом процессе на своей клиентской стороне, например, перемещении юнита из точки А в точку Б - всем остальным клиентам; эти клиенты в случае успешного получения данных уведомляют об этом того клиента, что им прислал данные; уведомление приходит - и игровая ситуация меняется у всех. Топология сети - полносвязная: если лагает у одного, лагает у всех. Так вот, у меня возникла мысль, а можно ли перехватить данные, которые клиент, управляющий бомбардировщиком, шлет остальным клиентам? Сейчас, скорее всего, картина следующая: я делаю запрос на сброс бомбы, данные о сбросе отсылаются всем клиентам, мне возвращается подтверждение на то, что сбрасывать можно, и бомба сбрасывается. Но только после того, как произошла запись в память моего клиентского компьютера, происходит имитация нажатия клавиши S. А ведь между моим запросом и подтверждением, а далее записью в память моего компьютера - проходит слишком много времени, чтобы моя программа успела отреагировать на сброс отменой приказа! Я хочу перехватить данные еще до того, как они уйдут в локальную сеть и вернутся ко мне. Возможно ли это? Если да, есть ли у тебя соответствующее видео на эту тему? Я что-то находил, но там говорилось про перехват данных, полученных из локальной сети, а мне нужно перехватить то, что я шлю в локальную сеть. С помощью каких программ можно это сделать? Думаю, если зафиксировать, что в одном сетевом пакете, описывающем прошлую игровую ситуацию на моей клиентской стороне, а в другом пакете по следующей ситуации - число бомб у выбранного бомбардировщика уменьшается с 3 до 2 или с 2 до 1 бомбы, то можно успеть остановить дальнейший сброс всех бомб. UPD: Я уже видел уведомление о закрытии форума в начале 2023 и второпях написал этот комментарий по теме сразу же, как пришла мысль об улучшении работы программы по сети. Надеюсь, успеваю?
  3. Не-не-не. Смотри. Я указываю бомбардировщику бомбить вражескую цель. ТОЛЬКО когда он сбросит одну бомбу (а это ему еще нужно долететь до цели), имитируется нажатие S. Не сразу после того, как я ему задал атаку, а именно после того, как был сброс! Соответственно, чтобы понять, был ли сброс, лезем в память.
  4. Да, так и есть, все по методичке с канала "Михаил Ремизов", с видео, посвященным ESP-hack. Я ориентировался на код, предоставленный им, и подстроил под себя. А есть альтернативы им? Спасибо за советы. Много новых, пока что не известных для меня функций, нужно поизучать. Не знаешь ли, снимал ли кто-то уже какие-нибудь видео по взлому с применением этих функций? Интересно посмотреть на наглядную демонстрацию их работы.
  5. Спасибо, но необходимости в том, чтобы слать несколько клавиш - нет по той причине, что вражескую цель все равно выбирает игрок, а не компьютер самостоятельно. Нет стремления написать бота, который бы воевал за меня.
  6. Не забанят 😀 Я не играю в турниры, да и даже если бы играл, этот чит никак не отследить, потому что: 1) Сбрасывать по одной бомбе не запрещено. Если игра допускает такую возможность, почему это должно быть под запретом? 2) Чит никак бы не спалили, потому что моя программа не встраивает чужеродный код в игру, а лишь имитирует нажатие клавиш.
  7. Нет :) Представь себе юнит - бомбардировщик. У него в боезапасе 3 бомбы. По умолчанию, при указании ему атаковать цель он очень быстро сбрасывает бомбы одну за другой, так что все бомбы будут сброшены практически сразу (между сбросом одной бомбы и последующей проходит 0.2 секунды). Однако, если вовремя нажать кнопку S, нажатие на которую эквивалентно отмене приказа для юнита (юнит должен перестать атаковать заданную цель), следующая бомба не будет сброшена, если она вообще у него есть. То есть, допустим, бомбардировщик атакует цель изначально с 3 бомбами. Сбрасывает одну бомбу (остается 2), но кнопка S быстро нажимается и не дает ему сбрасывать дальше, допустив сброс только одной бомбы. Аналогично, затем он атакует цель уже с 2 бомбами, жмем S - остается 1 бомба. Конечно, далее останавливать его после сброса оставшейся одной бомбы - бессмысленно, но программа это тоже сделает и ничем не помешает. Для своевременного нажатия кнопки S необходима отточенная реакция, что очень почитается на турнирах по данной игре. И эта программа, по моей задумке, должна автоматизировать реакцию человека. Сброс по одной бомбе нередко нужен, потому что имеются цели, уничтожаемые менее, чем 3 бомбами. Рационально - экономичнее расходовать бомбы, так как пополнять боезапас можно только на аэродроме, до которого бомбардировщику нужно еще успеть вернуться.
  8. Спасибо. Собственно, то, о чем я и думал. А что насчет таймера вместо бесконечного цикла? Велика ли разница между ними в плане оптимизации?
  9. Пишу на С. Есть острая необходимость в быстром чтении из памяти трех переменных, обработки прочитанных значений и отправки в окно игры имитации нажатия клавиш клавиатуры. При этом нужно, чтобы была возможность включать и отключать эти описанные операции через нажатие горячих клавиш. Например, Ctrl+M включает постоянное чтение, обработку и при определенном условии имитацию нажатия клавиши, а Ctrl+B отключает. Сейчас реализовано так. Программа запускается, вместе с ней запускается бесконечный цикл while (1) {...}. В нем два блока: 1) Первый блок считывает нажатие зарегистрированных горячих клавиш через if (PeekMessage(&msg, NULL, WM_HOTKEY, WM_HOTKEY, PM_REMOVE) > 0) {...}: если нажато Ctrl+M, он делает флажок mode истинным, если Ctrl+B - ложным. 2) Второй блок срабатывает, если флажок истинный, через if (mode) {...}. В нем происходит считывание из памяти нескольких значений, их обработка, и при определенном условии в окно игры шлется нажатие клавиши через PostMessage(hWnd, WM_CHAR, 0x00000073, 0x001F0001) (на самом деле PostMessage(...) срабатывает три раза, так как нужны еще WM_KEYDOWN и WM_KEYUP до и после WM_CHAR соответственно, но не суть). Считывать из памяти нужно действительно быстро: имитация нажатия клавиши должна успеть произойти за 0.2 секунды прежде, чем значение определенной переменной успеет обновиться. В вопросе оптимизации мне уже не нравится наличие бесконечного цикла, который очень сильно нагружает процессор и большую часть времени зря (зря считывает из памяти, обрабатывает и ничего не нажимает). Это приводит к тормозам и, как следствие, к тому, что сымитировать нажатие, когда надо, моя программа не успевает. Это очень иронично: возможности языка С позволяют считывать значения достаточно быстро, но язык настолько быстрый, что уже даже сама игра тормозит от нагрузки процессора бесконечным циклом. Заменять ли бесконечный цикл на таймер? Если да, то чем он лучше? Если нет, то нужно ли добавлять Sleep(...) с некоторым значением в общий цикл while (1) {...}? Если добавлять Sleep(...), то это будет тормозить так же и PeekMessage(...): реже будет отлавливать нажатие горячих клавиш. Тогда, наверное, лучше разбить на два потока: один поток будет обрабатывать нажатие горячих клавиш, а другой - все остальное? Знаю про функцию GetMessage(...) в качестве альтернативы PeekMessage(...). Она стопит работу другого кода программы, пока не получит сообщение, в данном случае горячие клавиши. Имеет ли смысл помещать ее в этот поток по отлову горячих клавиш на замену PeekMessage(...)?
  10. Я в курсе, как это называется, и уже упоминал слово "отладчик" в своем посте в правильном контексте. Речь о написанном вручную коде, который будет триггерить на выполнение инструкции Ассемблера в игре. В итоге (пораскинув мозгами ночью) я всё равно уже решил подойти совершенно с другой стороны, отказавшись от вручную написанной сторонней отладки, а воспользовавшись некоторой информацией из памяти, потому что это менее ресурсозатратно для компьютера. Однако, тема вручную написанной отладки, на мой взгляд, интересная.
  11. Найдена инструкция в игре (в моем случае Red Alert 3), отвечающая за изменение определенного значения. То есть, заменяя эту инструкцию "ничегонеделаньем", соответствующее значение меняться перестаёт. Мне важно узнавать о том моменте, когда эта инструкция выполнилась. Предполагаю, что нужно прикрутить некий отладчик к игре, как это реализуется в Cheat Engine, но хотелось бы, чтобы это было реализовано через код, допустим, языка программирования C. Выполнилась инструкция, случилось событие - и мы его ловим, обрабатывая информацию, как захотим. Вариант - просто подменить код в игре, встроив тот, что будет уведомлять об исполнении инструкции - не подходит, потому что в эту игру можно играть не только одному, но и нескольким, и игра периодически во время каждого матча проверяет, различаются ли версии игр. И в случае, если версии различаются, матч останавливается. В любом случае я не считаю данный вариант желательным, потому что это вряд ли единственная игра, которая может сагрессировать на интеграцию чужого кода в нее. Имеет смысл придумать некую универсальную слежку за инструкциями для всех игр.
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, Вы автоматически соглашаетесь соблюдать наши Условия использования.