Source.Python forums

Posted: **Wed Jan 22, 2020 5:54 am**

I have this:

@PostHook(airaccelerate)
def post_hook(stack_data, ret):

    # CBasePlayer pointer.
    pointer = stack_data[0].get_pointer(0x4)
    index = index_from_pointer(pointer)
    player = playerdict[index]

    # CMoveData pointer.
    pointer = stack_data[0].get_pointer(0x8)

    new_velocity = make_object(Vector, pointer + 0x40)
    old_velocity = player.velocity

    if stack_data[2] > 0.00001:
        for i in range(2):
            d = new_velocity[i] - old_velocity[i]

            if d != 0.0:
                wishdir = make_object(Vector, stack_data[1])
                gain = d / wishdir[i]

                accelspeed = stack_data[3] * stack_data[2] * TICKINTERVAL

                print(gain, accelspeed)

                if gain == accelspeed:
                    print('ff')

                break

Output with airaccelerate 1.0:

Syntax: Select all

2.5999991896173777 2.599999636709697
2.5999982694367216 2.599999636709697
2.5999983129257602 2.599999636709697
2.599997708347497 2.599999636709697
2.5999983641270976 2.5999999418854713
2.5999988814964086 2.599999636709697
2.5999978331397577 2.599999636709697

In theory they should be equal, because:

Syntax: Select all

// Determine acceleration speed after acceleration
	accelspeed = accel * wishspeed * gpGlobals->frametime * player->m_surfaceFriction;

	// Cap it
	if (accelspeed > addspeed)
		accelspeed = addspeed;

Posted: **Wed Jan 22, 2020 7:54 am**

My first thought is that gpGlobals->frametime is not guarenteed to be constant. Perhaps it changes to reflect the real time passed on a given tick, and not the ideal exact same time every tick. I haven't combed through the source sdk code to verify.

Also note that the wishspeed is derived from the length of wishvel which is derived from wishdir, which is derived through trigenometry from the player's view angle. So any variation in the player's view angle will have a knock-on effect causing every value in the acceleration to vary slightly.

Posted: **Wed Jan 22, 2020 4:54 pm**

Seems like a common loss of precision to me. Though, not sure why you would want to reverse-engineer the calculation if you already have the precise result?

Posted: **Thu Jan 23, 2020 4:27 am**

Loss of accuracy in Python float is inevitable. For this, there is module `decimal`

Posted: **Sat Jan 25, 2020 9:59 am**

Can't tell you if your calculation is correct, because the relevant information is missing in your post, but this also seems like a loss of accuracy to me. This might surprise you:

Syntax: Select all

>>> 0.3 - 0.1
0.19999999999999998

Posted: **Mon Jan 27, 2020 4:32 am**

Visit f"http://{0.1 + 0.2}.com"

If you need to compare the values of equality, use math.isclose(a, b)
Problem solved :-D

Source.Python forums

Difference in float numbers.

Difference in float numbers.

Re: Difference in float numbers.

Re: Difference in float numbers.

Re: Difference in float numbers.

Re: Difference in float numbers.

Re: Difference in float numbers.