Гайд Making your cheat great again

Эксперт
Статус
Оффлайн
Регистрация
17 Фев 2017
Сообщения
864
Реакции[?]
420
Поинты[?]
1K
Код:
class ResolverGameInfo
{
   // You can create your public func for init this values.
    public:
    float LocalSimTime;
    int iLocalLastHealth;
    float iWeaponSpeed;

    float EntSimTime;
    int iEntLastHealth;
    float iEnemyWeaponSpeed;

    CBaseEntity* GetBetterPlayerInfo()
   {
       if (iLocalLastHealth > iEntLastHealth)
      {
        if (iWeaponSpeed > iEnemyWeaponSpeed)
        {
              return G::LocalPlayer;
         }
         else if(iEnemyWeaponSpeed - iWeaponSpeed < iLocalLastHealth - iEntLastHealth) {
               return G::LocalPlayer;
      }
      else { return G::EnemyTarget; }
    }
else { return G::EnemyTarget; }
};

// if it returns G::LocalPlayer it is mean you prefer to use BAim because you can very high chance to kill your opponent.
else you need to try Headshot hitchance app
as more, as difference you have between you and enemy's info.

// Example how to use this code
/* Your Rage(HVH) .cpp code.
void GetBestBone(int &bonenum)
{
   ...
   for (int i = 0; i < 8; i++)
   {
      if (i == 0)
       {
            if (nresolver.GetPlayerBetterInfo() == EnemyEnt){ continue; }
        }
     // bla bla Autowall->GetDamage(i);
     if damage > Autowall->GetDamage(i)
     bla bla bla
    }
}
*/

namespace EnemyUsingAA
{
    float hisshittyangles[32];
    float calcdelta[32];
    float hiscurrentfakesanges[32];
    float simtimepertick[32];
    float simtimeper64ticks;
    float anglewhenihit[32];     // store 'true' values
    float anglewhenimiss[32]; /* used for ban unnecessary angles when you can't hit. Be careful, this can make your resolver works slow and not accuracy with a time. */
    float accuracyshots;
 /* used for adaptive resolver, when it is more > it is bad try to fix aa. If it's lower then this type of your logic works correct so you can make this shit to hit tapping all the server with some time if they don't change their AA.  It is Zeus old resolver tactic, be sure. Also don't forget to TraceRay. */
};

extern ResolverGameInfo nresolver;
ResolverGameInfo nresolver;
extern EnemyUsingAA nenemyaa;
EnemyUsingAA nenemyaa;

// FSN

PostUpdate:

if (MenuSettings::ResolverNew)
{
   nresolver.iLocalLastHealth =  G::LocalPlayer->GetHealth();
   nresolver.iWeaponSpeed = G::LocalPlayer->GetWeapon()->GetWeapCSData()->iSpeed;
   nresolver.iEntLastHealth = Entity->GetHealth();
   nresolver.iEnemyWeaponSpeed = Entity->GetWeapon()->GetWeapCSData()->iSpeed;
// if you know what are you doing, store the simtime values for fix LBY breakers.
}
Делаю логику ресольвера. Топ хвх мля.
Кому надо, можете позаимствовать мою логику, не уверен что оно действительно полезно, но вот боди аим классная штука, если реализовать с умом.
 
Я лучше тебя
Участник
Статус
Оффлайн
Регистрация
31 Июл 2017
Сообщения
383
Реакции[?]
448
Поинты[?]
1K
Временами от той поеботы что вы тут строчите тянет на мокрое дело, >>
Пожалуйста, авторизуйтесь для просмотра ссылки.
<< (Кликабельно), для автора кода.
Код:
class ResolverGameInfo
{
public:
    float LocalSimTime;
    int iLocalLastHealth;
    float iWeaponSpeed;

    float EntSimTime;
    int iEntLastHealth;
    float iEnemyWeaponSpeed;

    CBaseEntity* GetBetterPlayerInfo()
    {
        if (iLocalLastHealth > iEntLastHealth)
        {
            //логическое ИЛИ нынче магия.
            if (iWeaponSpeed > iEnemyWeaponSpeed || iEnemyWeaponSpeed - iWeaponSpeed < iLocalLastHealth - iEntLastHealth)
            {
                return G::LocalPlayer;
            }
        }
        //при любом ином случае вернет енеми таргет, зачем лишние операции проводить?
        return G::EnemyTarget;
    };
}
Дальше по списку,
Код:
namespace EnemyUsingAA
{
    float hisshittyangles[32]; // <- 32, вопрос нахуя?
    float calcdelta[32]; // <- 32
    float hiscurrentfakesanges[32]; // <- 32
    float simtimepertick[32]; // <- 32
    float simtimeper64ticks;
    float anglewhenihit[32];  // <- 32
    float anglewhenimiss[32]; // <- 32
    float accuracyshots; 
};
32, мда, сколько там из них тимейты? сколько там из них мертвы? а их точно будет 32? и все 32 будут с АА?? типичный удел воробушка - резервировать/хранить хуеву тележку лишних данных, юзай vector и заполняй по нужным критериям, будет гораздо проще сортировать/фильтровать данные + выиграешь по времени выполнения за счет избавления от лишней сборки и обработки.

Делаю логику ресольвера. Топ хвх мля.
Кому надо, можете позаимствовать мою логику, не уверен что оно действительно полезно, но вот боди аим классная штука, если реализовать с умом.
Логика юзлес (параша), удали компьютер, из окна, у тебя не выходит.
 
Эксперт
Статус
Оффлайн
Регистрация
17 Фев 2017
Сообщения
864
Реакции[?]
420
Поинты[?]
1K
Временами от той поеботы что вы тут строчите тянет на мокрое дело, >>
Пожалуйста, авторизуйтесь для просмотра ссылки.
<< (Кликабельно), для автора кода.
Код:
class ResolverGameInfo
{
public:
    float LocalSimTime;
    int iLocalLastHealth;
    float iWeaponSpeed;

    float EntSimTime;
    int iEntLastHealth;
    float iEnemyWeaponSpeed;

    CBaseEntity* GetBetterPlayerInfo()
    {
        if (iLocalLastHealth > iEntLastHealth)
        {
            //логическое ИЛИ нынче магия.
            if (iWeaponSpeed > iEnemyWeaponSpeed || iEnemyWeaponSpeed - iWeaponSpeed < iLocalLastHealth - iEntLastHealth)
            {
                return G::LocalPlayer;
            }
        }
        //при любом ином случае вернет енеми таргет, зачем лишние операции проводить?
        return G::EnemyTarget;
    };
}
Дальше по списку,
Код:
namespace EnemyUsingAA
{
    float hisshittyangles[32]; // <- 32, вопрос нахуя?
    float calcdelta[32]; // <- 32
    float hiscurrentfakesanges[32]; // <- 32
    float simtimepertick[32]; // <- 32
    float simtimeper64ticks;
    float anglewhenihit[32];  // <- 32
    float anglewhenimiss[32]; // <- 32
    float accuracyshots;
};
32, мда, сколько там из них тимейты? сколько там из них мертвы? а их точно будет 32? и все 32 будут с АА?? типичный удел воробушка - резервировать/хранить хуеву тележку лишних данных, юзай vector и заполняй по нужным критериям, будет гораздо проще сортировать/фильтровать данные + выиграешь по времени выполнения за счет избавления от лишней сборки и обработки.


Логика юзлес (параша), удали компьютер, из окна, у тебя не выходит.
32 это количество данных об 1 таргете.
Этот неймспейс юзается для каждого отдельно, лол. 64 нет смысла делать, большинство антиаимов работают вкупе с фейками, а это уже в два раза меньше реальных углов. Лбу так я вообще молчу, там флики никогда не больше 32… либо это какой-то хуевый лбу.
Насчёт логики? Почему хуня? Тебе показать как оно заеб*сь бодит когда есть такая возможность?
Сам проверял свою писанину, выходил с береттами и убивал чувака со скаром, если он был близко и не давал в жбан.

То что код написан неправильно, это понятно. Учимся, меняемся.
Может быть ещё что-то обьяснить?

Ах да, ещё момент. Это лишь подсказка, написана на скорую руку, я толком даже не занимался этим кодом, кроме боди аима.
Ты хочешь чтобы я выложил фулл код уже готовый, правильно сделанный с идеально работающим резольвером?
Так извини, такого ещё нет
 
Эксперт
Статус
Оффлайн
Регистрация
17 Фев 2017
Сообщения
864
Реакции[?]
420
Поинты[?]
1K
std::vector? он не такой быстрый на сколько я знаю
У меня вопрос. Есть ли вообще смысл заморачиваться над скоростью работы чита, когда речь идёт о настолько мизерных различиях, что ими можно пренебречь. Что вот реально 1 к 10 шанс что вооот в этот промежуток времени в 0.2 мс или даже меньше, что в этот промежуток сработает аимбот и успеет попасть в жбан? Да мне кажется что это решает уже после абсолютно всех возможных поправок на скорость передвижения, на флики, на точность аима, на пинг, на то когда твоя анимация обновится и пока на следующий тик заработает IN_ATTACK, что эти поправки даже по отдельности влияют в десятки - сотни раз больше, чем то что было упомянуто выше.
Единственное с чем я согласен, что код написан хреново, но он же работает?
 
Я лучше тебя
Участник
Статус
Оффлайн
Регистрация
31 Июл 2017
Сообщения
383
Реакции[?]
448
Поинты[?]
1K
std::vector? он не такой быстрый на сколько я знаю
в руках кс кодера - возможно. За то что я об этом думаю полагается 1.1 на форуме. Практически 95% вас, во всех возможных функциях снова и снова получаете одни и теже данные, чтобы сделать одни и теже проверки, за счет чего теряете половину времени выполнения абсолютно впустую (если кратко: половина кода обычного чита для кс - пердеж в лужу), в сей связи вывод: большинство читов на кс абсолютный фейл с точки зрения оптимизации.
З.Ы, я из тех кто задрачивается так, чтобы даже на калькуляторе запустилось без лагов и проеданий. Для меня - если есп проедает хотябы 0,5 фпс это фейл.
 
midnight.im
Администратор
Статус
Оффлайн
Регистрация
1 Июл 2015
Сообщения
1,649
Реакции[?]
2,171
Поинты[?]
161K
Практически 95% вас, во всех возможных функциях снова и снова получаете одни и теже данные, чтобы сделать одни и теже проверки, за счет чего теряете половину времени выполнения абсолютно впустую (если кратко: половина кода обычного чита для кс - пердеж в лужу), в сей связи вывод: большинство читов на кс абсолютный фейл с точки зрения оптимизации.
Здесь я согласен, в хуке по нескольку раз перебирать игроков, а после еще и в отрисовке не совсем правильно. Но что ты предлагаешь? Сохранять информацию в "массив" например каждый тик, и после работать уже с ней? Особой прибавке не заметишь.
 
Эксперт
Статус
Оффлайн
Регистрация
17 Фев 2017
Сообщения
864
Реакции[?]
420
Поинты[?]
1K
в руках кс кодера - возможно. За то что я об этом думаю полагается 1.1 на форуме. Практически 95% вас, во всех возможных функциях снова и снова получаете одни и теже данные, чтобы сделать одни и теже проверки, за счет чего теряете половину времени выполнения абсолютно впустую (если кратко: половина кода обычного чита для кс - пердеж в лужу), в сей связи вывод: большинство читов на кс абсолютный фейл с точки зрения оптимизации.
З.Ы, я из тех кто задрачивается так, чтобы даже на калькуляторе запустилось без лагов и проеданий. Для меня - если есп проедает хотябы 0,5 фпс это фейл.
Молодец, согласен насчет оптимизации. Но смотри. Допустим я сделаю в этот массив залив только той инфы, которая не была перед этим? То есть сравняю старое значение с новым. И если не совпадает то запишу новое. А если совпадает то смысл заполнять…
И так делает большинство стакеров, а остальные не морочат себе голову и записывают все подряд и получают образ антиаима который полностью хранится в чите. То есть теперь ты можешь просто брутфорсить до тех пор, пока значение о котором я писал (мисшот) не станет равно нулю. То есть грубо говоря будет брутфорсить на те углы которые сто процентов будут реалами в этот тик. В итоге ставишь getEyePointer.y = одному из близжайших углов в которые ты уже попадал и направляешь туда аимпоинт.
А далее дело уже за самим человеком который настроил миндамаг. Если опонент пользуется фристендом то не разумно стрелять и наносить по 1-5 дамага в голову, верно?
Вся суть этого топика в том что ты пользуешься данными опонента. Ты собрал инфу и воспользовался ею против него же.

Способ однозначно не идеальный, потому что на первых порах и при смене антиаимов всё будет сбиваться. Но я уже написал, это лишь прототип. Который естественно нужно дорабатывать, нормальный автоматический резольвер пишется месяцами, постоянно дорабатывается и подстраивается под обновы и антиаимы сразу двоих игроков. Локалки и соперника.
 
Здесь я согласен, в хуке по нескольку раз перебирать игроков, а после еще и в отрисовке не совсем правильно. Но что ты предлагаешь? Сохранять информацию в "массив" например каждый тик, и после работать уже с ней? Особой прибавке не заметишь.
Походу кодерам Aimware следует бы поучиться у IDreem. :LUL:
 
Я лучше тебя
Участник
Статус
Оффлайн
Регистрация
31 Июл 2017
Сообщения
383
Реакции[?]
448
Поинты[?]
1K
Здесь я согласен, в хуке по нескольку раз перебирать игроков, а после еще и в отрисовке не совсем правильно
не обязательно, в паблике уже лет 12 копится вагон годных примеров. делаешь свой класс который оборачивается над игровыми классами (для получения и сортировки), и класс в который он скадывает данные постоянно (для хранения). К класу хранения данных добавляешь прототипы функций и контейнеры для подписки (события) по типу тех что в шарпе. Из других классов банально наследуешь этот класс с данными и для каждого класса нуждающегося в отдельном разборе данных пишешь свой обработчик нужных событий и передаешь callback для обработчика классу в который складываются данные, чтобы обработчик каждого отдельного класса вызывало в цепочке и оперируя основными данными в одном единственном месте, сможешь получать их из любой точки кода без лишних хлопот.
Но что ты предлагаешь? Сохранять информацию в "массив" например каждый тик, и после работать уже с ней? Особой прибавке не заметишь.
как в событиях отсеять данные которые изменились от данных которые остались прежними думаю объяснять не надо. if(newValue != previousValue)
да и опять же, выше сказано про события, можно записывать углы в конкретный класс который с ними работает.
Молодец, согласен насчет оптимизации. Но смотри. Допустим я сделаю в этот массив залив только той инфы, которая не была перед этим? То есть сравняю старое значение с новым. И если не совпадает то запишу новое. А если совпадает то смысл заполнять…
И так делает большинство стакеров, а остальные не морочат себе голову и записывают все подряд и получают образ антиаима который полностью хранится в чите. То есть теперь ты можешь просто брутфорсить до тех пор, пока значение о котором я писал (мисшот) не станет равно нулю. То есть грубо говоря будет брутфорсить на те углы которые сто процентов будут реалами в этот тик. В итоге ставишь getEyePointer.y = одному из близжайших углов в которые ты уже попадал и направляешь туда аимпоинт.
как раз таки в связи с отсутствием оптимизации отчасти возникает подобнаяя колизия (когда отработка тормозит и данные становятся не валидными прежде чем будут использованы функцией)
В этой связи попробуй взять цель "в вилку", типо как артиллеристы (перелёт-недолёт), а дальше подогнать угол нацеливания делением отрезка пополам. Думаю итераций за 5-10 будет очень хорошая точность. а еще можно захватывать данные (риалы ) на момент записи в классы. и ты всегда будешь знать их. МАГИЯ.
 
Эксперт
Статус
Оффлайн
Регистрация
17 Фев 2017
Сообщения
864
Реакции[?]
420
Поинты[?]
1K
не обязательно, в паблике уже лет 12 копится вагон годных примеров. делаешь свой класс который оборачивается над игровыми классами (для получения и сортировки), и класс в который он скадывает данные постоянно (для хранения). К класу хранения данных добавляешь прототипы функций и контейнеры для подписки (события) по типу тех что в шарпе. Из других классов банально наследуешь этот класс с данными и для каждого класса нуждающегося в отдельном разборе данных пишешь свой обработчик нужных событий и передаешь callback для обработчика классу в который складываются данные, чтобы обработчик каждого отдельного класса вызывало в цепочке и оперируя основными данными в одном единственном месте, сможешь получать их из любой точки кода без лишних хлопот.

как в событиях отсеять данные которые изменились от данных которые остались прежними думаю объяснять не надо. if(newValue != previousValue)
да и опять же, выше сказано про события, можно записывать углы в конкретный класс который с ними работает.

как раз таки в связи с отсутствием оптимизации отчасти возникает подобнаяя колизия (когда отработка тормозит и данные становятся не валидными прежде чем будут использованы функцией)
В этой связи попробуй взять цель "в вилку", типо как артиллеристы (перелёт-недолёт), а дальше подогнать угол нацеливания делением отрезка пополам. Думаю итераций за 5-10 будет очень хорошая точность. а еще можно захватывать данные (риалы ) на момент записи в классы. и ты всегда будешь знать их. МАГИЯ.
Предугадать антиаим сразу не выйдет. Тут не канает. Либо нужно учитывать что длинна вектора смещения модельки игрока не превышает минимального значения которого я даже не знаю. То есть обьект не двигается, только антиаимы.
Если я буду записывать в таблицу уже типа предсказанные реалы после попадания то надо учесть что ни я, ни соперник не двигался, а разброс оружия был минимален. Плюс многие юзают динамик фейклаги, фейкфолки, могут изменять АА, так же нереально предсказать когда именно поменяется позиция модельки персонажа, когда он будет стрелять и тд.

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

Паша уже где-то писал что он спецом не занимается хвх ибо это довольно тяжело и с каждым годом всё большего всякой фигни надо добавлять и учитывать
 
Я лучше тебя
Участник
Статус
Оффлайн
Регистрация
31 Июл 2017
Сообщения
383
Реакции[?]
448
Поинты[?]
1K
Предугадать антиаим сразу не выйдет.
давай поясню: когда тебе приходит с сервера позиция персонажа, тебе не нужно её предугадывать, и на фейки поебать. отлавливай позицию на входе в переменную (брыкпоинт на запись на нужную ячейку памяти)
 
midnight.im
Администратор
Статус
Оффлайн
Регистрация
1 Июл 2015
Сообщения
1,649
Реакции[?]
2,171
Поинты[?]
161K
не обязательно, в паблике уже лет 12 копится вагон годных примеров. делаешь свой класс который оборачивается над игровыми классами (для получения и сортировки), и класс в который он скадывает данные постоянно (для хранения). К класу хранения данных добавляешь прототипы функций и контейнеры для подписки (события) по типу тех что в шарпе. Из других классов банально наследуешь этот класс с данными и для каждого класса нуждающегося в отдельном разборе данных пишешь свой обработчик нужных событий и передаешь callback для обработчика классу в который складываются данные, чтобы обработчик каждого отдельного класса вызывало в цепочке и оперируя основными данными в одном единственном месте, сможешь получать их из любой точки кода без лишних хлопот.

как в событиях отсеять данные которые изменились от данных которые остались прежними думаю объяснять не надо. if(newValue != previousValue)
да и опять же, выше сказано про события, можно записывать углы в конкретный класс который с ними работает.

как раз таки в связи с отсутствием оптимизации отчасти возникает подобнаяя колизия (когда отработка тормозит и данные становятся не валидными прежде чем будут использованы функцией)
В этой связи попробуй взять цель "в вилку", типо как артиллеристы (перелёт-недолёт), а дальше подогнать угол нацеливания делением отрезка пополам. Думаю итераций за 5-10 будет очень хорошая точность. а еще можно захватывать данные (риалы ) на момент записи в классы. и ты всегда будешь знать их. МАГИЯ.
Ну ты клонишь к тому, что в индиго хороший класс для работы с игроками?
 
Я лучше тебя
Участник
Статус
Оффлайн
Регистрация
31 Июл 2017
Сообщения
383
Реакции[?]
448
Поинты[?]
1K
Ну ты клонишь к тому, что в индиго хороший класс для работы с игроками?
не сказал бы что лучший пример. Если найду на жестком диске скелетон сорс систем бота 2014 года - опубликую в своем разделе. Там более внятный пример централизированой сборки и обработки.
 
Сверху Снизу