我们来了解一下引擎是怎么管理实体的吧！我们这里就说说服务端的实体（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 的，留到下一篇文章吧！

【HLSDK系列】服务端实体 edict_t 和 控制类