Swim, Speed and wall hacks

[rock5]

If the address is correct then I suspect the hack doesn't freeze it but maybe nopes(disables) the code there. Can you see exactly what the hack does with that address?

[gloover]

Sorry rock, I'm not so good in disassambling , so I cannot say what or where the hack exactly do this. I hopes someone here may know how it works.

[lisa]

All you would have to do is look at that address in CE and see if it changes or not.

I would agree with rock and it probably NOP's that section of memory, basically changes the bytes to 0x90

[rock5]

I thought noping required changing it to 0x90 but the problem is, how many bytes do we nop?

Edit: Ok, I got it to work. Noping (0x90) 12 bytes from that address causes it to not fall. Now how exactly are we expecting it to be used during botting?

[lisa]

I thought noping required changing it to 0x90

I would agree with rock and it probably NOP's that section of memory, basically changes the bytes to 0x90

of course, lol I did a sneaky edit
I could say it was a typo but yeah I am just out of practise in the memory stuff.

Edit: Ok, I got it to work. Noping (0x90) 12 bytes from that address causes it to not fall.

grats

Now how exactly are we expecting it to be used during botting?

no idea

[gloover]

Now how exactly are we expecting it to be used during botting?

For example onstuck or by Boss which is to trong.

The idea was to use this as a function in <onPreSkillCast>.

the function could be written as a userfunction included something like

Code: Select all

function Suicide()
memoryWriteFloat(getProc(), NoFall_addr, some pointer which should be found);  -- some similar procedure to fly/swim or wallclimb

repeat
actual_Z-position = get Z position
new Z-position = actual_Z-position + 30
yrest(800)
player:update()
until not player.Alive
end

so, now someone whos more gifted as me may translate this in lua

[rock5]

So you want to use it for suicide. Your right, it causes death. I didn't notice that yesterday. Looks like it has to be a certain height to cause death. You'll have to work out how high it needs to be. Seems to take a long time though, maybe a 'too hard' boss would kill you before you 'die'.

Seeing as this hack can only be used for suicide I've included a suicide function in the file. It might need some tweaking to get just right.

Last thing, it can't turn off nofall if nofall is enabled when the bot starts as it wasn't able to ready the original addresses. If you find you need to restart the bot while nofall is enabled I might have to have it save the bytes to addresses.lua so they get loaded when the bot starts. Just means I'll have to do a bit more work on it.

[gloover]

Nice rock - u rock it!

You've right the time passed till suicide is done may between 8-15 sec. but only if you are not moving - if the bot is runing, the death comes very fast (4-6 sec). so I did this

Code: Select all

	<onPreSkillCast><![CDATA[
		local target = player:getTarget();
		if( target.TargetPtr == player.Address and target.MaxHP > player.MaxHP * settings.profile.options.AUTO_ELITE_FACTOR) then
		
			cprintf(cli.lightred, "Mob to strong, SUICIDE!\n");
			-- kills yourself
			SlashCommand("run ReturnPet(1)");
			nofall()
	teleport(nil,nil,40,false)
		end
	]]></onPreSkillCast>

and put it off in

Code: Select all

	<onDeath>
		nofalloff()
	</onDeath>

works everywhere like a charm!

The only thing, if the bot was crashed during nofallon - so it cannot be disabled again - That doesn't matter for me. Can force a relog, is better than XP-dept

THX again!

[BorisValkov]

some background info:

the nofall hack used to work without dying, until it was changed, due to the fact that many a guild used it during Guild Siege to enter the enemy castle/fortress...
now during GS, both the fly- and nofall-hack end up in death after a second or two (hint: that is the reason why they took out the water!), as it checks the distance of the ground to your character, and if that exceeds a certain distance then the birdies sing and the angels descend and you die...

[BeyondNames]

I was wondering if there was anyway to use the wall hack with a harvesting waypoint. if there is can you please explain to me how to get it working because i can't even figure out how to use the wallhack at all.

[dx876234]

Whenever I make a transport point in client with the fly function active the characters stops flying and falls down, any idea about why?

-dx

[rock5]

Whenever I make a transport point in client with the fly function active the characters stops flying and falls down, any idea about why?

-dx

This is just the way it works. The game resets the memory value when you port. If you want to fly in the new location, just enable fly again.

[lisa]

I think he meant when he marks a spot for the transport book, more than likely they update player info before doing the marking to make sure the place marked is the one you actually want marked. Try using the nofall hack that is posted somewhere and see if it helps you.

[rock5]

Why would marking a transport point cause you to stop flying?

[dx876234]

Ye I don't know either, I added a timer function to freeze the memory locations and kept right on flying as it should.

Seems some operations overwrite the fly flags somehow.

-dx

[rock5]

I've been doing a bit of testing with the speed hack and I've realized that the pull back threshold is about 20% of the base speed. These are the results I got.

• 75% speed mount, base speed 87.5, best speed 105, percentage 20%
  65% speed mount, base speed 82.5, best speed 99, percentage 20%
  On foot, base speed 50, best speed 60, percentage 20%
  Unbridled Enthusiasm, base speed 57.5, best speed 70, percentage 20%

That's not 100% correct. It happens rarely but it can still pull back at 20% so I suggest 1 point less or maybe 19% instead, that's why 59 is usually suggested as the best unbuffed walking speed.

This leads me to think that the speed hack function should accept a percentage value that it multiplies against the base speed. The problem with this has always been that the function doesn't know if the speed has been changed before, so you could end up raising an already raised speed. I had a search in memory and found an address that holds the base value regardless of whether the speed has been changed or not so we could read that and then multiply that by the percentage.

The benefit of this change is you no longer have to check your buffs to calculate the best speed and you can use the same percentage whether walking or mounted.

The question is, how should I implement it? I see 3 options

• 1. Change the meaning of the accepted value so that so that old values become obsolete, so that speed(50) will mean add 50% to the speed, not set the speed to 50. The option is dangerous as users might update the speed hack without updating their speed values.
  2. Continue to accept the old number values but also accept percentages by using strings, eg. speed("50%"). This would work but is a bit cumbersome. I think 'speed' should accept numbers not strings.
  3. At the moment 'speed' only accepts values between 30 and 106. We could have it accept any value below say 2 as a percentage, eg. speed(.2) So effectively the speed would be set to basespeed + basespeed * .2 which is of course 20%.

I think I like the last option better. So old commands such as speed(59) will still work as expected and speed(.2) will be treated as a percentage and add that percentage to the speed. What do you think?

[rock5]

I thought of another option. The only reason we have 'speed' accept values is to cater for the different base speeds that you might have. But if 19% is the optimal speed increase and we have speed("on") set the speed to +19% and speed("off") setting it to the base value (the real base speed that is gotten from memory, not 50) then you'll only ever really need those 2 functions. We don't really need it to accept other percentages. Why would we?

I think that's all that's needed. Just change speed("on") and speed("off"). This is now my favorite option. What do you think?

[Bill D Cat]

I thought of another option. The only reason we have 'speed' accept values is to cater for the different base speeds that you might have. But if 19% is the optimal speed increase and we have speed("on") set the speed to +19% and speed("off") setting it to the base value (the real base speed that is gotten from memory, not 50) then you'll only ever really need those 2 functions. We don't really need it to accept other percentages. Why would we?

I think that's all that's needed. Just change speed("on") and speed("off"). This is now my favorite option. What do you think?

I like this option, but to keep it more in line with the swimhack's fly() and flyoff(), how about we use speed() and speedoff() instead?

[rock5]

I like this option, but to keep it more in line with the swimhack's fly() and flyoff(), how about we use speed() and speedoff() instead?

I could but then I would still have to make it backward compatible and support bother speed("off") and speedoff(). Easy enough to do I suppose.

Code: Select all

function speedoff()
    speed("off")
end

you'll only ever really need those 2 functions. We don't really need it to accept other percentages.

I meant it wouldn't need to accept percentages but, come to think of it, maybe we don't need to accept speed values either. Except I seem to remember some users saying they used it to slow the character down, don't remember why, so maybe not.

[Bill D Cat]

The only reason I'd ever use an option to slow down is if I was following a walking NPC, like Nacy in Ystra Highlands. Most of the time, I just use the keybind option for Walk instead.

So perhaps we could have speed("slow") for a ~20% slower rate in addition to speed("off") which sets normal movement speed, and speed("on") which sets it to ~20% faster.