还没完成，所以还没更新到ddraw的功能中去。
现在的修改是删掉了AI的一部分，改大了category的缓冲。
0x880c2 eb 65
0x88129 68 00 10 00 00 eb 94 c2 08 00
这个修改方法已经过时了，你可以直接用ddraw for modder来测试，
this mothed had already over-time, try the “ddraw for moder” for test
http://bbs.taclub.net/thread-15110-1-1.html
简短的说下找到bug位置的方法，因为单位种类太多而非法，所以就从这儿开始让TA非法。
第一步是把所有会非法的地方都找出来。
先定位会非法的函数，再看好堆栈的平衡注释掉这个函数，继续找下一个注释直到可以完成载入到游戏中去。
并且依次提高单位种类的数量。
最后定位到二个地方，一个是TA保存COB文件用的二叉树会操作到错误的指针。一个是处理AI文件中weight的函数会导致非法。
简短分析后摸不清二叉树非法的原因，weight中调用了一个根据单位种类数量来执行的函数，所以可以很明显的定位到非法的位置，但现在只是注释掉weight函数。
之后就是大量的记录二叉树的运行记录，并想办法定位到错误指针的来源。这段过程相当枯燥，总之从非法前操作分支的顺序、非法时的寄存器出发，从操作分支时的记录中往回溯，希望找到用错指针的那一次。当然还记录了一些其他数据来记录，最后没有得到什么结果。
再仔细的分析了二叉树数个函数的功能后，确定了TA二叉树的结构，于是在非法的时候，用CE游戏修改器搜索二叉树分支的指针，一步步往上找，但直到定位到二叉树的根，也没有发现其他异常的指针，只有非法的一个分支的指针是错误的。
又因为二叉树中保存的是上百个内存块指针，其顺序和结构可以说是完全随机的，没有办法通过重复测试定位到准确制造错误指针的一步，因此最后认定从二叉树的指针上是得不到更准确的信息了。
这时已经换了记录数种不同的数据，琢磨了琢磨记录起来所有申请的二叉树分支的内存块，因为猜测的是TA的内存机制有问题，想通过这样的记录得到内存申请失败的那一次所在的大概时间，再做下一步。
这样就在从记录的内存块里面搜索非法时的指针时注意到，非法时的上一层的分支所指过来的那个指针，跟别的指针不一样，普通像是0477D130，但这个指针像是0477D131。注意到这个后，就寻思到是某个地方以1为操作数来操作内存块时出了错，但是程序中以1为操作数的代码非常的多，也没有办法确定这种代码可能的样子，所以没有办法继续从这儿出发来分析。
因为实在想不到别的方法来从二叉树出发定位了，所以在完整的逆向TA二叉树的代码前，决定先把weight函数的错误给处理掉。
因为weight函数是在二叉树处的后面执行的，因此把二叉树处的代码又给注释掉。
这一次却在一个全新的地方非法了，本来的想法是简单分析下这一块的代码，接着处理好weight的再回来处理这个新的非法，此时的猜测是它可能又是因为内存管理而出的新错。
但是四处折腾非法了几次后，我决定一个个处理，于是把这块的代码详细的分析了下，确定了是以前研究TA编队时碰过的category，这时灵机一动，想到了TA操作category时申请给它用的缓冲只有0x40字节，同时这个缓冲中保存了所有的单位种类在这个category缓冲中是否达标，接着在调试这儿的非法时确定了它会在把缓冲扩充到0x200时执行出错。于是在这儿思考了一会儿，对照category缓冲的使用方法，知道0x40的大小里可以操作的正是0x200个单位ID。
当然最后确定是这儿的问题还经过了一些测试。
现在找到了问题所在，回头思考一番，很多地方的疑云就像拨云见日般顺手散开了。
前面以1为操作数的操作，很明显就是category缓冲中按照一bit一bit操作时的结果，而那一次能够注意到，也是因为运气好，刚好是操作的经常为0的内存地址的最后一位，这是第一个运气
而最早时候找非法位置时没有找到这一个非法，回来一次才遇得到，是因为最早时的单位种类的数量不够，不能让这儿申请的内存其后的一点点保留内存不够用，所以会覆盖到其他的内存块，也就是二叉树的。
思考之后，就得到了一个寻找这种内存操作出了错时的定位技巧，让溢出的内存操作溢出到引起非法，而不只是误操作到其他地方的数据。