Blizzhackers

How can i tell if I am hostiled? I cant find any address/pointer.
all I found was ASMPTR(D2CLIENT, TestPvpFlag_I, 0x4FCE0) but when Call that function using


or

it returns me 0

when I memory read that address it showed me 232 as value and hostile didn't change it. any ideas?

I tried to do changed and unchanged value scan with CE but it didn't seem to work.

I also tried this code but it returned me 0



any suggestions?

TestPvPFlag(playerId, yourId,

Also it has a non-standard calling convention, so you need to edit the way ProcCall does it.

Found this from d2helpers.cpp but not sure what to do with it. I would have to convert it to opcodes but how? using http://ref.x86asm.net/coder32.html? or is there any better methods?

Check the last byte of packet 8c is another way.

I am not hooking packet function here.


I am terrible noob at C++.. but how would function look like in c++ ?

just looking for function that would input d2 handle and return true if hostiled


edit: Shaggi said me to convert this to autoit


so I am on my way to it.


gut I am not sure what RosterUnit * unit = *D2CLIENT_PlayerUnitList means. could anyone explain that? Partt of code I cant understand is * unit = * Does it mean I have to multiply something?



Or is it something like this?


Could anyone explain me that C++ loop in plain english please? and what does unit->pNext mean?

Edit2: Shaggi suggested me this loop instead


but it outputs me


which means that there has to be logic problem in that loop because it ends with 0

also in C++ source there is if(unit->dwPartyFlags & PLAYER_HOSTILE) { which I am not sure what it does. I think it means
if BitAnd( readd2memory($Diablo_MemHandle) + $dwPartyFlags , $PLAYER_HOSTILE )
Correct me if I am wrong about that if

Edit3:
Here's latest code I could come up with but it's still buggy


for those who arent friendly to Autoit ReadD2Memory returns value of address.

There must be some logic problem or something.

You basically can't call it from AutoIT unless you want to do a lot of hard conversion work. And if you don't understand the C enough to convert it, I'd suggest you learn C.

Here is the correct source..
(According to public source)
Would be equilivant to

this didn't seem to work. But it seems to list all players in game





Maybe we should use my pointer read udf instead?

May be you should learn some programming (not scripting) language in order to write proper hacks.

You should not speak. You know nothing about what you are talking about. Allow me to demonstrate:

It doesn't matter if it's programming or scripting language. What matters is wether that language can call DLLs or not. If you have programming language that doesn't allow you to call functions from DLL files you wouldn't be able to write proper hacks at all.

AutoIt has ability to call dll files which means it has access to whole WINAPI which is what all hacks on this site use. Before you say that you can't write proper hacks in autoit you should see some hacks made by Shaggi. His maphack that ins entirely in autoit and that actually reveals map in d2 is just 1 example.

Finding out if I am hostiled is something that you can read out from memory all you need to do is read memory. There were chicken for 1.11 patch that worked just with memory read so it's possible.

So all I need to know is proper addresses and offsets and data types. You don't give any information at all so you're not helping.

Although I agree that in C++ it would be easier since most of code is already written, but it doesn't automatically mean that AutoIt can't do that and if there weren't D2BS source there wouldn't be difference in difficulty.

Just curious:
Why do you want to do an autoit conversion?

Why don't you use simple/elegant solutions?

Of course you can do things with dozen patches.
But if some company cares and you don't have got experience in antidetection mechanisms they most likely catch a sensitive patch.

I can tell you if you rely on public code you will find some bad strucs/pointers or even worse c and c++ code butchering.(no pun to your username intended)

Depending on the code you rely on you will have got real difficulties to create an autoit conversion.

Firk surely didn't intend to insult you but a lack of c++ knowledge will give you a hard time.

Example:
Public code that handles pointers to classes/strucs wrong.

You assume the code is right and the results are daft since the error was in the c++ code you relied on.

@Vampirewolve youre're right. What do you mean by Why don't you use simple/elegant solutions?


Just thought it would be good that way.. everything would be in 1 language and easy to handle. if I'd keep IsHostiled function in dll I would have to edit dll's source but now I can have all in 1 file.

If I'd see C++ dll that has function IsHostiled then I could tell if that public code is right.

For example hostile chicken.

Unless you want to create a bot that resists on hostile or something similar that makes TestPVPFlag better than adding bools for example there is no need to use the TestPVPFlag function.


If you want to do an autoit conversion of some public hacks you will have to do a conversion of PacketSend, PacketReceive and Decompression anyway.

With Packethandling you can skip memoryreading and patching in many cases.

All you have to do is to check the last byte of packet 8C.
That check is slightly faster than TestPVPFlag anyway.

FYI on affecting relationship updates you receive 2 8c packets for example
8c Player A You 00 "hostile State"(Forgot the stateid but easy to find out anyway)
and then
8c You Player A 00 "hostile State"


You got the choice between packet handling and memory reading many times but in some cases memory reading is the better solution.
For example quest state reading.
Public hacks do it with a terrible wall of "ifs" on Quest State packet.(No array created etc it rather resembles notes)
A better solution is memory reading since you can also check if you did the cowking quest for example or if finished quests are still open(a bit buggy for some quests but that's blizzards fault)


There are some but it doesn't mean they are used or strucs/ptrs are updated.

That's one of many ways how to butcher code.

In the end you can reduce most public code to 5 more or less public code from tools/hackitmodules till 2005.

Mystery solved...
RosterUnit.dwPartyFlags only show the relation between parties.. which is kinda obvious based on the name lol

reversing testpvpflag shows, that the rosterunit struct contains a loop to a list of playerrelations:



Updated struct:


Following code illustrates the use:


Each PlayerRelation struct has generally 8 as dwFlags if the rosterunit is hostiled towards dwPlayerID

E: The code will then end up being
In autoit, and
in C++