6月19日开始研究并完成游戏中队员在组间调度的Join机制，并有一些新的发现
group格式的数据，组内【最后一个队员】如果是通过deleteVehicle删除，那么这个group仍然会被保留；然而，如果【最后一个队员】通过join加入其他组，那么这个group会被销毁。
例如，某个组的变量记为g1，对应的组名是ALPHA BLACK，则{deleteVehicle _x} forEach (units g1)执行完毕后，g1仍然对应ALPHA BLACK这个组，[units array] join g1可以让单位加入ALPHA BLACK；然而(units g1) join g2（另一个组，或grpNull）执行完毕后，g1对应grpNull，[units array] join g1等价于[units array] join grpNull，是否会被系统分配到ALPHA BLACK基本随缘，大概率是不会的。g1变量也无法继续指向ALPHA BLACK组，而是指向grpNull。
选中某些队员后，通过脚本让这些队员Join到其他组后，对这些队员的【选中】效果仍然保留，需要按F1-F12取消选中。如果没有取消选中，后续对【选中】队员的脚本命令仍然会覆盖这些Join其他组的队员，有可能会对脚本效果造成干扰

成功得到ETON的许可
本次更新对CTI任务中的环境效果和载具单位进行了一次大范围的调整。之所以此前一直抱残守缺，外观上基本使用源自OFP原本的载具武器，是因为笔者重视CTI的游戏性和平衡性甚于其他。而TZK任务框架历经两个版本的更新后，除修复原XR任务的既有bug外，业已搭建颇为成熟的更为详全的指挥系统，因此可以稍微将精力放到外观设计上；此外，老外基于我的TZK任务，也制作并测试了他们的一个MOD，我对其中部分新载具的使用感觉不错，因此从他们的测试结果中直接摘了一些桃子（载具、参数）过来。
而既然要改头换面，那索性做得彻底一些。咱们这里有现成的优质ETON模组，虽然考虑到玩家电脑性能以及CTI联机中本就存在的大量数据交换对于模组中部分效果的制约，无法选用ECP而只能借鉴PLUS，并且也并非所有效果都有必要移植，但仍然能够给CTI提供一个全新的面貌——老外的模组选用的是SIG的M1A1和相对简陋的T90，而笔者参考ETON模组，另选INQ的M1A2和ICP的T90，样貌要更加美观。
关于ETON模组效果移植，以及其他相关内容，将陆续在下面补完

Join可能导致unit在AI队伍之间、AI到玩家队伍、玩家到AI队伍、玩家之间传输，为使得其所受命令脚本被正确、及时地添加、中止，需要对机制做出完善。新出生AI的聚集与等车也一并进行修改
为使得功能性EventHandler在Join后得到正确的调整，首先需要规范化CTI里EventHandler的使用方式。目前已将绝大部分仅与特定载具相关，以及与整体大环境相关的EH处理完毕，1.10版本新增的功能性EH留待之后处理
此外，发现ETON模组所使用的RHS_T72A无法被dedicated server所使用，故改用ICP_T72B

Join项目当真是牵一发而动全身，完整地分析Join的前后关联，并规范化CTI里EH的使用后，EH反而不是什么大工程了……有些时候都会想，不在Join时对被Join单位做调整，而是把Join单位当做全新的单位，彻底剔除原有脚本并重新初始化会不会好一点
需要处理的问题：单位离开玩家队伍后，玩家队伍的命令脚本中止、玩家client的附加脚本中止；单位加入玩家队伍后，会正常响应玩家队伍的脚本命令、能够被新玩家client启动附加脚本；单位离开AI队伍后，单位与原AI队伍的当前命令、设置脱钩，单位停止响应原AI队伍的命令变更；单位加入AI队伍后，开始执行新AI队伍的命令并服从新AI队伍的调度。
此外，CTI使用的Rearm机制是各client创建一个存放数据的数组，Rearm时由单位local的client读取数据并重新为单位注入武器弹夹，因此需要更新该数组的写入与存储方式，保证联机中各client的这个数组内数据相一致（原先的机制过于简陋，有数据不匹配的情况发生）。
仍然留待处理的是AI因为各种临时性需求而暂时从命令中脱钩的busy机制，以及笔者本次更新打算新增的，级别在原有的持续性Order之上、在功能性busy之下的临时性order设计，因为尚未着手临时性order的制作，所以这部分留待之后一并解决。
规范化CTI的EH使用，适合放到插件内的就丢给插件的config而不是在游戏内临时添加。xr的CTI广泛使用addAction和addEH来创造CTI环境，虽然泛用性很强，但受限于OFP里这两个函数的简陋功能，它们和插件config预先定义UA、EH是无法相提并论的。TZK使用大量插件UA、EH替代CTI任务内附的addAction和addEH，虽然泛用性减弱了（xr的设置，只需定义单位即可，CTI功能主要在CTI任务内部创建，而TZK这种模式导致往CTI里新增单位必须要连插件一并编辑），但功能性得到强化。反正可预见的未来里只有不多于笔者一人会继续做CTI的更新，这个取舍的意义也没什么讨论的必要了。
规范化EH之后，发现只需根据EH的作用范围，在EH内部编辑效果即可，无需针对Join做EH的移除和重添加。

漏了RearmData的机制编辑了……Equip系列脚本对CTI中新出厂的单位武器进行重定义，然而变更某单位的武器弹夹，其效果虽然是global的，但是broadcast到各client的时间并不一定是即时的效果。由于各client存储单位的武器弹夹数据是各自为政的local效果，因此寄希望于它们能够在武器变更【之后】才往rearmdata里填写数据是不太现实的。
治本的方法是利用数组规范化Equip系列脚本的写法，并在equip系列脚本里直接让数组传参执行rearmdata的数据写入（实际上是校正），如此一来可以绕开广播机制

不是打击楼主，你写这些东西，是乱给OFP脚本下定义，胡乱理解，容易走入歧途。另外，你鼓捣的CTI，应该是CR那套吧，我记不清了，只记得那套脚本根本不适合他人后期开发和扩展功能。
言尽于此。玩的开心！

我还以为楼上那个装X犯不会再进我帖子了呢，被回复了还真是有点意外，然而风格仍然和一年半前如出一辙，居高临下，指点江山，B装得倒是大，干货半点没有。无怪乎此人和另一个ID臭味相投，两人均已成年已久，然则在心智不全和毫无长进上颇有共同之处，物以类聚，此之谓也。

TZK_1.01在原有命令的基础上增添了Reclaim、Occupy、Board、Land Helicopters的命令。但从机制上来说，原有的Order命令都是“持续性”的，例如守卫某个路点、执行城镇防御等，而新增的4个命令则是“临时性”的，命令的内容很明显会在一定时间内“完结”，此外，从目的上，希望执行上述新增命令的单位也是符合一定条件的，会去执行Reclaim的显然只应该是士兵和不满员的载具，而执行Land Helicopters的应该是直升机。
因此打算在原有Order的框架之上，新增“临时性命令”的机制，并在其中增设“响应类型”/“响应单位UID”和“持续时长”参数，使得该机制既能包含“临时性”命令，又能囊括“触发式”命令，如此一来，在原有Order的基础上，可以对一支队伍进行命令的分化，使得AI队伍的功能更加多样化。
例如，装甲队伍内混编的防空单位，可以针对性地下达“移动到某坐标”，使得防空单位独立于装甲单位运动、自律补给，同时由于队伍雷达共享，该防空单位可以更加有效地保护射程范围内的同队装甲。
又例如，所有军队都远征前线，但发现敌人偷偷摸摸来基地搞事情，如果不希望投入过多的防御力量在基地里，那么可以对某只队伍里部分UID或者某种类型的单位下达“巡逻某区域”的命令
再例如，使用触发式命令，结合合适的阈值，可以让一支队伍里满足条件的单位主动向sup单位靠近并执行维修自检，从而更高效率地完成补给任务
已完成机制和界面的设计，待进一步完善命令种类和制作各命令的脚本

你会在ofp的历史上留下大名的。666.另外能否在tgha中加入8K AA，升级8.5w对空防御反而比1.5w弱了，这不科学。

初步设计了Temporary机制，优先级在Order之上，Busy之下，Temporary之间互不干涉，先来后到。具体的机制仍然依赖于Temporary命令的细则，事实上Temporary命令的分类仍然不够细致，不过做得太细或许有点违背CTI的初中了，虽说是RTS内核，但指挥官终究也是以第一人称参与战斗的人之一，关于这点还是之后看反馈吧。
已完成第一个具体的Temporary任务，本项目暂时挂起，和其他主体内容初步完成框架后做一次测试，找寻问题后再展开后续工作

AI自动购买的设定是只在“空闲”工厂下单，AI小队长的脚本主循环时长5秒，而步兵的建造时间是10秒。换言之，只让1支队伍执行自动购买，则对于生产效率的浪费可以达到平均25%的程度。多支队伍同时自动购买可以减少浪费，但问题仍然存在。
治本的方法是修改“空闲”的判定，将原先的Q0提升为Q1。虽然对于制造时间较长的载具而言，这个思路仍然不够完全，但目前任务的定价收入数值设置使得自动购买仍然是以步兵为绝对主体，故而暂时不去考虑载具的情形。
顺带对Cancel附加了一个队伍规模计算的修正项，发讯CancelBuy时一并做一个减法，使得cancel购买不再无法及时削减队伍的待建造单位总数。由于并未对排队机制做优化，仅仅只是附加一个数组，因此简单粗暴地增大计数变量的归零阈值，使得可能出bug的情形被排除在游戏的“常规操作”之外。

鸽了6天StrangeLove总算回复我了，不过结果不甚理想。他希望TZK保持“经典”的设计，所做的改动以“保守”为宜。虽然我在受启发于他们的SE改编、借用ETON模组提升CTI的任务环境的同时，对单位模型的替换仍然保持在【换皮】的程度，但终究是从他们的改编里借鉴了榴弹炮、大型运输机和AA干扰。
看来有必要在更新完成后，预先写一个更新内容，着重突出一下基础功能性的提升与【换皮】工程中希望他们重点留意的部分，然后和他们做几场测试，争取说服他们接受我所做的改良中借鉴他们idea的部分。
嘛，听天命尽人事，希望能如愿罢

和StrangeLove讨论了一天的结果是比较糟糕的那一个。从他们的模组里借鉴单位和机制虽然没有被拒绝，但似乎外国的玩家们并不像国内部分玩家对载具换皮那么热衷，换言之我或许需要再多花2-3天把2.00拆分成2个版本，其一为保持原汁原味的基础版，其二为添加要素的mod形式。
话说我累不累啊，本来TZK就是我的手笔，结果我自己反而做起我自己制作模组的模组了

发现OFP游戏bug一枚。联机利用手段封锁√