我们来了解一下引擎是怎么管理实体的吧!我们这里就说说服务端的实体(edict_t)
服务端用 edict_t 这个结构体来保存一个实体,可以说一个 edict_t 就是一个 服务端实体,下文简称实体。
我们在 mp.dll 的源码里经常看到的那些 CBaseXXX 又和 edict_t 有什么关系呢?
引擎只管理小部分实体的功能,更多功能需要我们自己写代码去实现,这里就引入了 实体控制类 这个东西(就是那些 CBaseXXX),类就是C++的那个类。下文简称控制类。
接下来我们就分析 edict_t 到底是怎么跟 控制类 挂上勾的。
我们通常用 CREATE_NAMED_ENTITY( MAKE_STRING("weapon_mp5") ); 来创建一个 weapon_mp5 的武器实体,那我们就来分析这个函数到底做了什么吧!
1. 用户调用 CREATE_NAMED_ENTITY。
2. 引擎在 mp.dll (的导出函数)里查找名为“weapon_mp5”的函数。(你可能会有疑问:我从来没写过这个函数啊?别急,下文分析)
3. 引擎调用“weapon_mp5”函数来创建出一个CMP5类实例。“weapon_mp5”还调用了 CREATE_ENTITY 来创建出一个 edict_t。(用数学老师的话说:CMP5就是实体weapon_mp5的控制类)
4. 引擎把实例的指针赋值到 edict_t 的 pvPrivateData 成员变量里。
5. 引擎返回 edict_t 给用户。
看了上面的步骤,你一定注意到非常关键的一步,“weapon_mp5”函数到底是怎么一回事。
打开 mp5.cpp 你会发现有一行
LINK_ENTITY_TO_CLASS( weapon_mp5, CMP5 );
这行就是关键,它会生成一个函数,这个函数起了类似如下代码的作用:
注:实际上不是这么简单的,只是为了更容易理解。
CMP5 *weapon_mp5() { return new CMP5(); }
再往回看上面的步骤3和4,能理解了吧。
引擎先创建一个 edict_t 然后又 new CMP5 把指针存到 pvPreivateData 这个变量里,到此一个实体就创建出来了。
然后我们还要了解控制类是怎么工作的。首先请你打开 cbase.cpp 你会看到一堆 Dispatch 开头的函数,下文简称派遣函数。
派遣函数用来干嘛呢?当一个实体要 Think 的时候,引擎就会调用 mp.dll 里的 DispatchThink 这个函数,它有一个参数 edict_t *pent 就是要 Think 的实体!
接着才是关键!
我们来看 DispatchThink 的源码:
void DispatchThink( edict_t *pent ) { CBaseEntity *pEntity = (CBaseEntity *)GET_PRIVATE(pent); if (pEntity) { // ... pEntity->Think(); } }
顺便还有 GET_PRIVATE 的源码:
inline void *GET_PRIVATE( edict_t *pent ) { if ( pent ) return pent->pvPrivateData; return NULL; }
我们可以看到它获取了 edict_t 里面的 pvPrivateData 变量,你一定还记得这个变量是怎么来的吧!不记得请马上往回看!
没错,之前引擎创建实体的时候,把 控制类 的 指针 存这变量里了,我们这里就把这个 控制类 拿出来而已!
接着它检查了一下 控制类 是不是 NULL,然后它在 if 里面调用了 控制类 的 Think 函数!
整个过程就是这样的:引擎 -> 派遣函数 -> 控制类 也就是说,引擎是不管 控制类 的,为让 控制类 工作,我们还需要在派遣函数里写东西(虽然HLSDK已经写好了,但是你一定要去看看他是怎么写的)。
如果你写过 AMXX 你肯定会认识 FM_Think FM_Spawn 这些东西,它们就是HOOK了这些派遣函数!
本来还想仔细讲解 LINK_ENTITY_TO_CLASS 的,留到下一篇文章吧!