The question is kind of edgy. The point is that most of the people are lazy to perform some kind of research on how to extract dynamic data on runtime and prefer hardcoding rather than dynamic data extraction (DDE
), but sometimes the reason is that they don't have enough experience to achieve such result.
When it comes to the cheating scene, people prefer hardcoding just because it's much easier to dump some variable's offset and then just paste it into the project, rather than spending time on figuring things out. It can be understood in case you're working with some game that doesn't have any kind of data maps, but... what about Source Engine
? It brings you brilliant ability to dynamically and reliably extract offsets by name and... people still hardcode offsets. It's sad that most of unknowncheats
users never tried digging deeper into this, but just shit-talk on how DDE is slower/worse than hardcoding. Funny thing is that when it comes to logic and arguments - they can't really say much, but scream about performance and wasting of time. The reality is that you have to change all the offsets from update-to-update
, and personally I think it's bloody retarded. Why not spending an hour to make a flexible API? It's much more useful since you don't have to create some global/static variables to store offsets and the code looks pretty much like that:
C_BaseEntity *C_BasePlayer::GetActiveWeapon()
{
// Loop through the datamap structure looking for the string you pass, cache the offset and use it further.
DATAMAP_CACHE_CREATE( m_hActiveWeapon, GetPredDescMap(), "m_hActiveWeapon", NULL );
// Take the cached offset and extract the value.
return DATAMAP_CACHE_EXTRACT_VALUE( this, m_hActiveWeapon, CHandle ).Get();
}
Instead of this:
inline C_BaseCombatWeapon *GetActiveWeapon( void )
{
CBaseHandle hActiveWeapon = *MakePtr( CBaseHandle *, BaseEnt(), gStaticVars.m_hActiveWeapon );
return dynamic_cast( g_pEntList->GetClientEntityFromHandle( hActiveWeapon ) );
}
Another sad thing is that most of cheat "developers"
are trying to imitate the behavior of their "heroes"
on the unknowncheats
forum. However, they definitely don't know what they are even saying and sometimes their posts contain terms and things that don't even exist in the Source Engine
or are called differently. But they don't even give a shit about that (obviously because people who read their posts are unintelligent). Then these people try to replicate their "knowledge"
by spreading wrong information on how things work. This can be simply called "cancer"
, since you can't control the spread of this shit-talk and misinformation, but people who seek this "knowledge"
are goddamn sure they're right.
The same thing happens when it comes to virtual functions. The thing is that in Source Engine
there's a public SDK
available and you definitely can just use its headers in order to achieve functionality of some certain interfaces/abstract classes, but people who can't handle SSDK
keep on using some hardcoded calls such as:
INetChannelInfo *pNetChannel = ( ( INetChannelInfo * ( __thiscall * )( void * ) )( engine + 0xD4 ) )( engine );
Isn't that just ugly? Why not using SSDK headers instead to make code look pretty?
INetChannelInfo *pNetChannel = engine->GetNetChannelInfo();
Looks better, isn't it?
This is something I never understood besides the fact that people who hardcode can't simply operate with the SSDK code, probably because it's "too complicated"
. Use your own brain and critical thinking when making a decision on how to make your project since it's yours.