Tutorial CSGO m_fFlags offset & dwForceJump offset + Bitfields info

  • CSGO recently moved logic from 'client_panorama.dll' to 'client.dll', you must update all code that uses 'client_panorama.dll' and replace it with 'client.dll' or the code will not work.
Hexui Undetected CSGO Cheats Sinkicheat PUBG Cheat

Rake

I'm not your friend
Administrator
Jan 21, 2014
12,497
78,998
2,417
How long you been coding/hacking?
5 Years
Coding Language
C++
If you know me then you know that I am leading the holy war against pasting. In today's episode we will talk about bitfields, bunnyhops and bullshit.


What are the m_fFlags and dwForceJump offsets?

99% of people people don't have any idea what these variables are so I'm gonna explain it. People are writing 4/5/6 in decimal to dwForceJump and they don't even know why...

I see this in every pasted CSGO cheat and it's been taught in thousands of tutorials but not a single one tells you what they are. Today we will set the record straight!

m_fFlags and dwForceJump are both bitfields

A bitfield is typically a 4 byte variable where each bit is a bitflag. A bitflag is a bit that represents a bool. Why? To conserve memory and be efficient, better to use a bit than a 1 or 4 byte bool, especially when it comes to networking, every bit saved = less lag. As an integer is 32 bits, you can encode 32 bools into one integer, that's a big savings in memory.

Homework
  1. 3.8 — Bitwise operators | Learn C++
  2. 3.8a — Bit flags and bit masks | Learn C++
  3. O.1 — Bit flags and bit manipulation via std::bitset | Learn C++

So when you read/write integers to these variables or view them in cheat engine you're only working with an abstract form, unless you're viewing the actual bits.

m_fFlags
m_fFlags is used for model animations ant other things. The two most common bits which are used are the "on the ground" and "client" bits. Here are the m_fFlag and some other constants defined in the Source Engine SDK in const.h

The first 10 are the important ones

C++:
// CBaseEntity::m_fFlags
// PLAYER SPECIFIC FLAGS FIRST BECAUSE WE USE ONLY A FEW BITS OF NETWORK PRECISION
// This top block is for singleplayer games only....no HL2:DM (which defines HL2_DLL)
#if !defined( HL2MP ) && ( defined( PORTAL ) || defined( HL2_EPISODIC ) || defined ( HL2_DLL ) || defined( HL2_LOSTCOAST ) )
#define FL_ONGROUND (1<<0) // At rest / on the ground
#define FL_DUCKING (1<<1) // Player flag -- Player is fully crouched
#define FL_WATERJUMP (1<<2) // player jumping out of water
#define FL_ONTRAIN (1<<3) // Player is _controlling_ a train, so movement commands should be ignored on client during prediction.
#define FL_INRAIN (1<<4) // Indicates the entity is standing in rain
#define FL_FROZEN (1<<5) // Player is frozen for 3rd person camera
#define FL_ATCONTROLS (1<<6) // Player can't move, but keeps key inputs for controlling another entity
#define FL_CLIENT (1<<7) // Is a player
#define FL_FAKECLIENT (1<<8) // Fake client, simulated server side; don't send network messages to them
// NON-PLAYER SPECIFIC (i.e., not used by GameMovement or the client .dll ) -- Can still be applied to players, though
#define FL_INWATER (1<<9) // In water

// NOTE if you move things up, make sure to change this value
#define PLAYER_FLAG_BITS 10

#define FL_FLY (1<<10) // Changes the SV_Movestep() behavior to not need to be on ground
#define FL_SWIM (1<<11) // Changes the SV_Movestep() behavior to not need to be on ground (but stay in water)
#define FL_CONVEYOR (1<<12)
#define FL_NPC (1<<13)
#define FL_GODMODE (1<<14)
#define FL_NOTARGET (1<<15)
#define FL_AIMTARGET (1<<16) // set if the crosshair needs to aim onto the entity
#define FL_PARTIALGROUND (1<<17) // not all corners are valid
#define FL_STATICPROP (1<<18) // Eetsa static prop!
#define FL_GRAPHED (1<<19) // worldgraph has this ent listed as something that blocks a connection
#define FL_GRENADE (1<<20)
#define FL_STEPMOVEMENT (1<<21) // Changes the SV_Movestep() behavior to not do any processing
#define FL_DONTTOUCH (1<<22) // Doesn't generate touch functions, generates Untouch() for anything it was touching when this flag was set
#define FL_BASEVELOCITY (1<<23) // Base velocity has been applied this frame (used to convert base velocity into momentum)
#define FL_WORLDBRUSH (1<<24) // Not moveable/removeable brush entity (really part of the world, but represented as an entity for transparency or something)
#define FL_OBJECT (1<<25) // Terrible name. This is an object that NPCs should see. Missiles, for example.
#define FL_KILLME (1<<26) // This entity is marked for death -- will be freed by game DLL
#define FL_ONFIRE (1<<27) // You know...
#define FL_DISSOLVING (1<<28) // We're dissolving!
#define FL_TRANSRAGDOLL (1<<29) // In the process of turning into a client side ragdoll.
#define FL_UNBLOCKABLE_BY_PLAYER (1<<30) // pusher that can't be blocked by the player
#else
#define FL_ONGROUND (1<<0) // At rest / on the ground
#define FL_DUCKING (1<<1) // Player flag -- Player is fully crouched
#define FL_ANIMDUCKING (1<<2) // Player flag -- Player is in the process of crouching or uncrouching but could be in transition
// examples: Fully ducked: FL_DUCKING & FL_ANIMDUCKING
// Previously fully ducked, unducking in progress: FL_DUCKING & !FL_ANIMDUCKING
// Fully unducked: !FL_DUCKING & !FL_ANIMDUCKING
// Previously fully unducked, ducking in progress: !FL_DUCKING & FL_ANIMDUCKING
#define FL_WATERJUMP (1<<3) // player jumping out of water
#define FL_ONTRAIN (1<<4) // Player is _controlling_ a train, so movement commands should be ignored on client during prediction.
#define FL_INRAIN (1<<5) // Indicates the entity is standing in rain
#define FL_FROZEN (1<<6) // Player is frozen for 3rd person camera
#define FL_ATCONTROLS (1<<7) // Player can't move, but keeps key inputs for controlling another entity
#define FL_CLIENT (1<<8) // Is a player
#define FL_FAKECLIENT (1<<9) // Fake client, simulated server side; don't send network messages to them
// NON-PLAYER SPECIFIC (i.e., not used by GameMovement or the client .dll ) -- Can still be applied to players, though
#define FL_INWATER (1<<10) // In water

// NOTE if you move things up, make sure to change this value
#define PLAYER_FLAG_BITS 11

#define FL_FLY (1<<11) // Changes the SV_Movestep() behavior to not need to be on ground
#define FL_SWIM (1<<12) // Changes the SV_Movestep() behavior to not need to be on ground (but stay in water)
#define FL_CONVEYOR (1<<13)
#define FL_NPC (1<<14)
#define FL_GODMODE (1<<15)
#define FL_NOTARGET (1<<16)
#define FL_AIMTARGET (1<<17) // set if the crosshair needs to aim onto the entity
#define FL_PARTIALGROUND (1<<18) // not all corners are valid
#define FL_STATICPROP (1<<19) // Eetsa static prop!
#define FL_GRAPHED (1<<20) // worldgraph has this ent listed as something that blocks a connection
#define FL_GRENADE (1<<21)
#define FL_STEPMOVEMENT (1<<22) // Changes the SV_Movestep() behavior to not do any processing
#define FL_DONTTOUCH (1<<23) // Doesn't generate touch functions, generates Untouch() for anything it was touching when this flag was set
#define FL_BASEVELOCITY (1<<24) // Base velocity has been applied this frame (used to convert base velocity into momentum)
#define FL_WORLDBRUSH (1<<25) // Not moveable/removeable brush entity (really part of the world, but represented as an entity for transparency or something)
#define FL_OBJECT (1<<26) // Terrible name. This is an object that NPCs should see. Missiles, for example.
#define FL_KILLME (1<<27) // This entity is marked for death -- will be freed by game DLL
#define FL_ONFIRE (1<<28) // You know...
#define FL_DISSOLVING (1<<29) // We're dissolving!
#define FL_TRANSRAGDOLL (1<<30) // In the process of turning into a client side ragdoll.
#define FL_UNBLOCKABLE_BY_PLAYER (1<<31) // pusher that can't be blocked by the player
They are defining the variables by using the shift left bitwise operator. So when you see ( 1 << 4 ) it means, shift the "1" bit left 4 spaces. The first bit is called the "zero bit" so when you see 1<< 4 it's setting the 4th bit, by moving the bit 4 places to the left.

So it starts off as 0000 0001 with the first bit set, then when you shift it left it becomes 0001 0000.

How many bitflags are there? Alot but for the player I think there is 10 or 11 based on:
C++:
#define PLAYER_FLAG_BITS        10
Now this is just a the source SDK from 2013, so who knows, there could be more in CSGO and other source engine games.

How does the game check these bitflags?

With the "AND" or "&" bitwise operator:
C++:
if ( GetBasePlayer()->GetFlags() & FL_ONGROUND )
FL_ONGROUND = 0001, the first bit is set

if you bitwise AND 1 with 1 the result is 1.

C++ booleans work like this:
false = 0;
true = !false; -> this means that any value that is NOT ZERO, resolves to true

Conclusion:

If the FL_ONGROUND bit is set, the result of the operation is "true" because the result is nonzero.

So how we check this in our hacks? Same way:
C++:
if (GetAsyncKeyState(VK_SPACE) && m_fFlags & (1 << 0))
{
    writeMem<DWORD>(clientdll + dwForceJump , 6);
}
Wait a second what the hell is that 6 doing there?

dwForceJump
dwForceJump is a bitfield like m_fFlags encoded in a 32bit integer, so it's defined as an integer but it's bits are checked using bitwise operators.

When you're reversing it in Cheat Engine you will typically see it displayed as an integer or as a byte, either way it's in decimal notation not binary. When viewing it as decimal you will notice:

4 = not jumping
5 = jumping

So what's with this 6? Why does this source code I found set it to 6?

When you set it to 5, it forces you to jump you can also use +jump, but you will notice if you just overwrite it with 5 it gets stuck on 5. It stays on 5 and doesn't change back to 4. If you press the space bar again, you won't jump the first time because the state is improperly set.

Because it's set to 5, you can't reset it to 5 again!

But if you write 6 to it, it will reset to 4, allowing you to write 6 again and trigger a jump.

To explain it further, in the reversing process you would try many different values:

C++:
//These make you jump
0000 0010 = decimal = 2
0000 0011 = decimal = 3
0000 0110 = decimal = 6
0000 0111 = decimal = 7

//These don't make you jump
0000 0100 = decimal 4
0000 1000 = decimal 8
Notice the pattern? Setting the 0 bit or the 1st bit makes you jump, but setting the other bits does not. The trouble is depending what value you write, it doesn't always reset the value back to decimal 4 or 0100 in binary.

In these cases the game doesn't properly detect you're "not jumping" and doesn't allow you to jump again. Why? Continue reading

How does the game check if you're jumping?
C++:
bool    IsJumping( void ) { return m_bJumping; }
m_bJumping gets it's value from m_fFlags, and checking the FL_ONGROUND bit
C++:
bool CMultiPlayerAnimState::HandleJumping( Activity &idealActivity )
{
    if ( m_bJumping )
    {
        if ( m_bFirstJumpFrame )
        {
            m_bFirstJumpFrame = false;
            RestartMainSequence();    // Reset the animation.
        }

        // Check to see if we hit water and stop jumping animation.
        if ( GetBasePlayer()->GetWaterLevel() >= WL_Waist )
        {
            m_bJumping = false;
            RestartMainSequence();
        }
        // Don't check if he's on the ground for a sec.. sometimes the client still has the
        // on-ground flag set right when the message comes in.
        else if ( gpGlobals->curtime - m_flJumpStartTime > 0.2f )
        {
            if ( GetBasePlayer()->GetFlags() & FL_ONGROUND )
            {
                m_bJumping = false;
                RestartMainSequence();
            }
        }
Basically jumping is assigned a time, when the time is up and you're on the ground, m_bJumping is set to false. But this doesn't show us how m_bJumping is set to true...

Let's look at the movement functions:
C++:
if (m_nButtons & IN_JUMP)
{
Jump();
}
Ok so m_nButtons is a bitfield and it's doing a bitwise AND with IN_JUMP to check the IN_JUMP bitflag. If it's set, it calls the Jump() function.

the m_nButtons bitflags are defined in in_buttons.h:
C++:
#define IN_ATTACK        (1 << 0)
#define IN_JUMP (1 << 1)
#define IN_DUCK (1 << 2)
#define IN_FORWARD (1 << 3)
#define IN_BACK (1 << 4)
#define IN_USE (1 << 5)
#define IN_CANCEL (1 << 6)
#define IN_LEFT (1 << 7)
#define IN_RIGHT (1 << 8)
#define IN_MOVELEFT (1 << 9)
#define IN_MOVERIGHT (1 << 10)
#define IN_ATTACK2 (1 << 11)
#define IN_RUN (1 << 12)
#define IN_RELOAD (1 << 13)
#define IN_ALT1 (1 << 14)
#define IN_ALT2 (1 << 15)
#define IN_SCORE (1 << 16) // Used by client.dll for when scoreboard is held down
#define IN_SPEED (1 << 17) // Player is holding the speed key
#define IN_WALK (1 << 18) // Player holding walk key
#define IN_ZOOM (1 << 19) // Zoom key for HUD zoom
#define IN_WEAPON1 (1 << 20) // weapon defines these bits
#define IN_WEAPON2 (1 << 21) // weapon defines these bits
#define IN_BULLRUSH (1 << 22)
#define IN_GRENADE1 (1 << 23) // grenade 1
#define IN_GRENADE2 (1 << 24) // grenade 2
#define    IN_ATTACK3        (1 << 25)
Does dwForceJump = the m_nButtons bitfield ?
dwForceJump isn't a random variable that randomly makes you jump when you write 6 to it and it's sole purpose is not jumping. The m_nButtons bitfield is set by what buttons you're pressing then the game logic checks this bitfield to decide what logic and animations to execute.

C++:
#define IN_JUMP            (1 << 1)
// 0010 in binary
This means to make the game detect the input which triggers the jump function, you want to set the second bit. So therefore any 4 byte integer that's written to dwForceJump that has the second bit set will make you jump.

These integers all have the second bit set:
2,3,6,7,10

If you write any of those to dwForceJump it makes you jump.

The problem is, not all values will reset it back to 4. It needs to be reset back to 4 for everything to work correctly.

Not that 4 is a special number, but because 4 = 0000 0100 in binary and that is the "default on ground" settings.

But guess what? Setting the 1st bit also makes you jump. So now I'm not so sure.

It's definitely a bitfield because if you view the assembly instructions that test/cmp the address, it uses bitwise operators checking the first bit and doing a bitwise OR on the 1st and 2nd bit.

I was pretty sure is was the m_nbuttons bitfield but it's not, because when you do any other button presses for movement, it doesn't change...

Does dwForceJump = the m_nButtons bitfield ?
No, but m_nButtons gets it's value from dwForceJump. So we need to trace backwards from m_nButtons to dwForceJump.

Read the next post for more!
 

Attachments

You can download 0 Attachments
Last edited:

Rake

I'm not your friend
Administrator
Jan 21, 2014
12,497
78,998
2,417
So what the hell is dwForceJump ?

dwForceJump is an instance of kbutton_t, specifically the state variable.

C++:
struct kbutton_t
{
    // key nums holding it down
    int        down[ 2 ];
    // low bit is down state
    int        state;   
};
C++:
static    kbutton_t    in_jump;
More specifically dwForceJump's 0 bit represents in_jump.state

It's not defined as a bitfield but the game source code treats it as one, having 3 bitflags in it.

so dwForceJump is actually the in_jump variable which is just a button struct that keeps track of the jump hotkey being pressed.

If you do "find what accesses" on dwForceJump you find this instruction I mentioned earlier:


You can see it doing a bitwise or with the number 3

Here it is in IDA:


This is the function from the SDK:
C++:
void KeyDown( kbutton_t *b, const char *c )
{
    int        k = -1;
    if ( c && c[0] )
    {
        k = atoi(c);
    }

    if (k == b->down[0] || k == b->down[1])
        return;        // repeating key

    if (!b->down[0])
        b->down[0] = k;
    else if (!b->down[1])
        b->down[1] = k;
    else
    {
        if ( c[0] )
        {
            DevMsg( 1,"Three keys down for a button '%c' '%c' '%c'!\n", b->down[0], b->down[1], c[0]);
        }
        return;
    }

    if (b->state & 1)
        return;        // still down
    b->state |= 1 + 2;    // down + impulse down
}
so dwForceJump is actually the in_jump.state variable which is just a button struct that keeps track of the jump hotkey being pressed.

If you hold the jump button it returns and so it stays as decimal 5 or binary 0101

If you let go of the jump key it gets reset back to decimal 4, or binary 0100

This happens because button state is bitwise ORed with 3 per this:
C++:
line  b->state |= 1 + 2;    // down + impulse down
ORing it with 3 sets the 1st and 2nd bits.

So why is this third bit set all the time, why does "on ground" = 4 instead of 0?

Because if you read deep into the source code you will find:

bit 0 = key down
bit 1 = impulse down
bit 2 = impulse up


The impulse up bit is always set, which is bit 2, when bit 2 is set it's decimal 4.

"In physics, impulse is the integral of an applied force, that which acts to change the motion of an object"

What is impulse down? Well XBOX controllers have impulse triggers, they aren't just binary up or down, they can detect the force being applied to them. For instance on a joystick for a flight simulator there is the slider that increases your thrust/speed, you can impulse up and down, which is why there are 2 impulse variables. So apparently source engine supports this functionality, but obviously it's not used in CSGO...but wait, if we press the space bar really really fast, impulse down gets set! Doesn't really do anything, but interesting nonetheless.

In another key function in mp/src/game/client/in_main.cpp we see:
C++:
void KeyUp( kbutton_t *b, const char *c )
{  
    if ( !c || !c[0] )
    {
        b->down[0] = b->down[1] = 0;
        b->state = 4;    // impulse up
        return;
    }

    int k = atoi(c);

    if (b->down[0] == k)
        b->down[0] = 0;
    else if (b->down[1] == k)
        b->down[1] = 0;
    else
        return;        // key up without coresponding down (menu pass through)

    if (b->down[0] || b->down[1])
    {
        //Msg ("Keys down for button: '%c' '%c' '%c' (%d,%d,%d)!\n", b->down[0], b->down[1], c, b->down[0], b->down[1], c);
        return;        // some other key is still holding it down
    }

    if (!(b->state & 1))
        return;        // still up (this should not happen)

    b->state &= ~1;        // now up
    b->state |= 4;         // impulse up
}
So impulse is set to up when the key is released/not pressed.

We can completely disregard the impulse up bit. Here is actually some more info from the source:
Code:
KEY BUTTONS

Continuous button event tracking is complicated by the fact that two different
input sources (say, mouse button 1 and the control key) can both press the
same button, but the button should only be released when both of the
pressing key have been released.

When a key event issues a button command (+forward, +attack, etc), it appends
its key number as a parameter to the command so it can be matched up with
the release.

state bit 0 is the current state of the key
state bit 1 is edge triggered on the up to down transition
state bit 2 is edge triggered on the down to up transition
Conclusion:
dwForceJump is the kbutton_t.state variable for the jump button. It's defined as an integer, but is used as a bitfield. There are 3 bits. When the zero bit is 1 you jump, when it's 0, you don't jump.

Why does writing 6 to it work? 6 = 0110 in binary

In the game source code 6 is never used, nor do they ever set both those bits at the same time, those bits that are set are the impulse up and impulse down flags, they would never both be true at the same time. So this is completely illogical, someone was just mashing buttons and found out that 6 works, now the whole world is writing this value and I don't think a single person knows why.

The key down bit is not set, so why do we jump?

Because this assembly:
Code:
mov eax, kbutton_.state
test al, 01 = check bit 1
jne 0xDEADBEEF = jump if bit 1 is set
or eax, 03 = bitwise or with 3
mov [esi+8], eax = set the variable to the new value from the above bitwise OR
Ok so when we set it to 6, the 1st bit is not set, so it passes the JNE, then does a bitwise OR with 3
6 =| 3
0110 =| 0011
the result is 0111 or 7 decimal

Keep in mind, never logically, should this ever happen, it should never have all 3 bits set, the button can't be moving upwards, moving downwards and be down at the same time.

You can prove this by putting a conditional breakpoint on "test al, 01" with conditional "eax == 6". In the course of gameplay, EAX is never 6.

Now the 1st bit is set, resulting in us jumping the next loop

So writing 6 to it is just an insane mistake that ends up working for totally un-intended reasons.

Writing decimal 2 or binary 0010 makes more sense

Only setting the 1st bit makes you jump, but the subsequent instructions change the value to 0.
 
Last edited:

Rake

I'm not your friend
Administrator
Jan 21, 2014
12,497
78,998
2,417
Just when you thought I was done with this insane thread, I have made a proper bunny hop which utilizes std::bitset so the mongrel horde has no excuse to be setting random integers anymore.

C++:
#include <windows.h>
#include <iostream>
#include <bitset>
#include "mem.h"
#include "proc.h"
#include "csgo.h"

using namespace offsets;

bool bStatus = false;

//m_fFlags from SDK using bit shift format
#define FL_CLIENT    (1<<7)    //256 in decimal
#define FL_ONGROUND (1<<0)    //0001

// ^ same as
//const int FL_CLIENT =    1 << 7;
//const int FL_ONGROUND = 1;

// or as binary literals
//const int FL_CLIENT =        0b1000'0000;
//const int FL_ONGROUND =    0b0000'0001;

const int JUMP_BIT_MASK = 0b0000'0001;

//dwForceJump jump state bitmasks using std::bitset
//this will be the used to set the bits and then a copy will be made to use as the src buffer of WPM
std::bitset<8> DoJump{ 0b0000'0001 };

/*
m_fFlags 1st bit
0 = not on ground
1 = on ground

dwForceJump 1st bit
0 = do nothing
1 = jump
*/

int main()
{
    DWORD procId = GetProcId(L"csgo.exe");
    HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, procId);

    uintptr_t clientdllAddr{ 0 };
    clientdllAddr = GetModuleBaseAddress(procId, L"client.dll");

    uintptr_t localPlayerAddr{ 0 };

    std::cout << "-=Ronbledore got that cake=-\n";
    std::cout << "F1 = Toggle | SpaceBar = Jump\n";

    int flags{ 0 };
    BYTE jumpState{ 0 };
  
    while (!(GetAsyncKeyState(VK_INSERT) &1))
    {
        ReadProcessMemory(hProc, (BYTE*)(clientdllAddr + dwlocalPlayerAddr), &localPlayerAddr, sizeof(localPlayerAddr), NULL);

        if (GetAsyncKeyState(VK_F1) & 1)
        {
            bStatus = !bStatus;
        }

        if (bStatus && (GetAsyncKeyState(VK_SPACE)))
        {
            //Read Current Flags & Jump State
            ReadProcessMemory(hProc, (BYTE*)(localPlayerAddr + m_fFlags), &flags, sizeof(flags), NULL);
            ReadProcessMemory(hProc, (BYTE*)(clientdllAddr + dwForceJump), &jumpState, sizeof(jumpState), NULL);
            std::bitset<32> DoJump{ jumpState };

            //if on ground -> jump
            if (flags & FL_ONGROUND)
            {
                //to set the the bit we do a bitwise OR with the bitmask
                //jumpState |= JUMP_BIT_MASK;
                //mem::PatchEx((BYTE*)(clientdllAddr + dwForceJump), (BYTE*)&jumpState, sizeof(jumpState), hProc);

                //or
                DoJump.set();
                jumpState = DoJump.to_ulong();
                mem::PatchEx((BYTE*)(clientdllAddr + dwForceJump), (BYTE*)&jumpState, sizeof(jumpState), hProc);
            }

            else
            {
                //to unset the the bit we do a bitwise AND with a bitwise NOT of the bitmask
                //jumpState &= ~JUMP_BIT_MASK;
                //mem::PatchEx((BYTE*)(clientdllAddr + dwForceJump), (BYTE*)&jumpState, sizeof(jumpState), hProc);

                //or
                DoJump.reset();
                jumpState = DoJump.to_ulong();
                mem::PatchEx((BYTE*)(clientdllAddr + dwForceJump), (BYTE*)&jumpState, sizeof(jumpState), hProc);
            }
        }
        Sleep(5);
    }

    return 0;
}
 
Last edited:

Rake

I'm not your friend
Administrator
Jan 21, 2014
12,497
78,998
2,417
Sir, how does oring with 3 clear those bits?
try turning your brain on, there are 3 links at the top of the thread, a video tutorial and a complete explanation with like 1,000 words

if you can't figure it out, go outside and play with sticks and give up on game hacking

we're not babysitters for retards
 

iPower

Piece of shit
Escobar Tier VIP
Fleep Tier Donator
Jun 29, 2017
600
21,708
67
Sir, how does oring with 3 clear those bits?
try turning your brain on, there are 3 links at the top of the thread, a video tutorial and a complete explanation with like 1,000 words

if you can't figure it out, go outside and play with sticks and give up on game hacking

we're not babysitters for retards
Actually this time the guy is right. Or doesn't clear anything, it sets the bits according to a mask. He's referring to this: Screenshot
 
  • Like
Reactions: Rake

Rake

I'm not your friend
Administrator
Jan 21, 2014
12,497
78,998
2,417
Sir, how does oring with 3 clear those bits?
Sorry, not only was I an asshole but I was also the retard in this situation, iPower is correct, to fix the tutorial you just change the word "clear" to "set" in that one sentence, which I've already done
 
Last edited:
  • Like
Reactions: Kekz and Petko123
Attention! Before you post:

Read the How to Ask Questions Guide
99% of questions are answered in the Beginner's Guide, do it before asking a question.

No Hack Requests. Post in the correct section.  Search the forum first. Read the rules.

How to make a good post:

  • Fill out the form correctly
  • Tell us the game name & coding language
  • Post everything we need to know to help you
  • Ask specific questions, be descriptive
  • Post errors, line numbers & screenshots
  • Post code snippets using code tags
  • If it's a large project, zip it up and attach it

If you do not comply, your post may be deleted.  We want to help, please make a good post and we will do our best to help you.

Community Mods