rcbot_const_mstr_offset needs updating? Options

[JRob]

I tried playing around with rcbot again and it keeps crashing at

CTeamControlPointRound *CTeamControlPointMaster:: getCurrentRound ()

CBaseEntity *pent = m_ControlPointRounds[m_iCurrentRoundIndex];

So I took a look at what that was and apparently, CTeamControlPointRound is found through dark hackery and the magic number at rcbot_const_mstr_offset.

Can you update this? Or also tell people how to find these offsets?

[Nightc0re]

Surely there's an automatic way to find these offsets? Or an easier way to get the data you need from this entity?

It seems horrible that after each update, we have to load up dustbowl and HOPE that nothing else happens early in the structure happens to be 3.

This was my approach some weeks ago, but Cheeseh is using a different approach.
Look here.

Side note to Cheeseh:
You are not using this variable, was this intended?

CODE

unsigned long full_size = sizeof(pMasterEntity);

[JRob]

This was my approach some weeks ago, but Cheeseh is using a different approach.
Look here.

Side note to Cheeseh:
You are not using this variable, was this intended?

CODE

unsigned long full_size = sizeof(pMasterEntity);

He's not doing anything new here, he is adding a magic number to the CBaseEntity pointer.

He isn't even using sizeof(CBaseEntity). Is this even guaranteed to be the right number? The hl2sdk has some definitions for it, but the TF2 code can obviously diverge from the SDK because it was never made for people to mod TF2. If the TF2 team wants to add some extra stuff to CBaseEntity, it won't show up on the hl2sdk unless the people at AlliedMods reverse engineers it. And from what I see, they don't depend on CBaseEntity.

That's why the linux magic number increased. They might have added stuff or maybe changed compiler flags so the offset was increased.

[Cheeseh]

He's not doing anything new here, he is adding a magic number to the CBaseEntity pointer.

He isn't even using sizeof(CBaseEntity). Is this even guaranteed to be the right number? The hl2sdk has some definitions for it, but the TF2 code can obviously diverge from the SDK because it was never made for people to mod TF2. If the TF2 team wants to add some extra stuff to CBaseEntity, it won't show up on the hl2sdk unless the people at AlliedMods reverse engineers it. And from what I see, they don't depend on CBaseEntity.

That's why the linux magic number increased. They might have added stuff or maybe changed compiler flags so the offset was increased.

it was used as a test so it's not being used . sizeof(CBaseEntity) would be the correct way but the CBAseEntity class isn't declared in plugins - that's the problem and this is the way around it

[JRob]

it was used as a test so it's not being used . sizeof(CBaseEntity) would be the correct way but the CBAseEntity class isn't declared in plugins - that's the problem and this is the way around it

How about this? You locate CTeamControlPointMaster::Spawn() which seems to have never changed, and is unlikely to change.

https://github.com/ValveSoftware/source-sdk..._master.cpp#L85

Then you scan the function for this

m_bFoundPoints = false;

Which looks like this in a dissembler.
CTeamControlPointMaster::Spawn() + 0x1A
mov byte ptr [ebx+37Ch], 0

So you know that m_bFoundPoints is located at 892. If you subtract sizeof(bool) and sizeof(CUtlMap<int, CTeamControlPoint *>), I believe you will get the size of CBaseEntity.

This method should work for other classes based on CBaseEntity and maybe there is an easier one to use. It could be automated and more robust than the current method.

[Cheeseh]

this is one way but will need the signature for CTeamControlPointMaster::Spawn() (which might actually include mov byte ptr [ebx+37Ch], 0) in which case it would be redundant to find it this way. you'd need to find a signature at the end of the previous function. Unless it can be found via the virtual pointer - i'll check this at home

[JRob]

this is one way but will need the signature for CTeamControlPointMaster::Spawn() (which might actually include mov byte ptr [ebx+37Ch], 0) in which case it would be redundant to find it this way. you'd need to find a signature at the end of the previous function. Unless it can be found via the virtual pointer - i'll check this at home

I don't know what signature finding code you use, but it should allow you to have wildcard bytes.

So it shouldn't matter if the front of the function has dynamic addresses.

Also, this probably isn't of much concern to you since you develop on Windows, but on Linux, symbols are not stripped and you can locate functions by their symbol names which is why I like hosting TF2 on Linux so much.

Here is my attempt at a signature. It happens to have no wildcard parts and succeeds in locating only that function.

55 89 E5 53 83 EC 24 8B 5D 08 8B 03 89 1C 24 FF 50

.text:00BAAE30 push ebp
.text:00BAAE31 mov ebp, esp
.text:00BAAE33 push ebx
.text:00BAAE34 sub esp, 24h
.text:00BAAE37 mov ebx, [ebp+this]
.text:00BAAE3A mov eax, [ebx]
.text:00BAAE3C mov [esp], ebx
.text:00BAAE3F call dword ptr [eax+60h]

The signature ends before the +60h at the end which could possibly change. However it assumes that the number of local variables doesn't change which I think is a fairly safe assumption, but you could probably make that part a wildcard too.