[T][光环]转生领域

紫水晶之瞳

引用第21楼麦德三世于2009-09-24 15:21发表的 :正确的做法是这样。农民先说了声“反对独裁！”，然后被雷劈而死。然后边上的朋友们纷纷喊道：“快信飞雪大人！”“快信飞雪大人！”然后此人满血满BUFF活转回来：“状态满了。”

　一处华丽的重复或者是错别字……

血戮魔动冰

……………………cccty1l………………
首先……我刚刚的话只是给新手一个提示，也没必要必须按我说的做。
确实创建单位很简单，也很容易。我没有要否认他的意思。
我只是站在一个……恩……“高手”的高度上吧……说的我的一些想法而已。
那个…………单位自定义值是非常宝贵的
一张成品图里可能有无数系统混杂在里面。而如果全部使用userdata作为数据索引。那么任何一个系统都不可能正常工作。
而如果要把所有的数据全部绑定在一个单位的userdata上，除非系统的使用者编写一些代码。
如果使用userdata很好的话，那么我下面的话可以WS掉了。
如果不能使用userdata，绑定单位的数据，基本只剩下handle+hashtable。
war3的hashtable到底用什么作为index我不知道，所以我就只说数据编写的hastable。
那么单位只能通过handle+hash来存储数据。
如果创建新的单位。很显然有可能不能继承原单位的handle。
而如果要移植单位的数据，那么需要把hashtable的数据内容全部移植（如果hashtable只是存储了一个指针，那好办，直接把指针copy过去）。
先不说指针指向的内容可能还有指向原来单位的变量。光是移植数据的话，就必须知道所有的hashtable的借口函数……
那么，这个光环是不可能被移植的，因为只有移植使用者才知道所有的hashtable的借口函数……（甚至可能他也不知道）
好吧越说越绕了…………

只说一句吧：
一个东西如果还要用，为什么要删除并且弄一个新的（还不一定是完全一样的）替代品呢？

灼眼の熊猫王

LSS观察好仔细哦
还有糖吗,我要吃
LS是坏人,为什么就要抢在我前面,害我还要编辑帖子
努力磨刀中...

血戮魔动冰

貌似LS穿越了。

alexries

原来头目也看过那个寂寞的图片。

血戮魔动冰

补充：
如果使用userdata，那么就必须将设置指针的接口交出来，然后由使用者写这个接口…………
那个…………这样岂不是很囧吗？…………

疯人￠衰人

引用第35楼cccty1l于2009-09-24 19:22发表的  :
[code]
那么我们来看用存储系统的问题，如果我记的没错，单位是当尸体消失之后数据才会被清除的，这也就是为什么unit类型变量在连接数为0后运行 TriggerSleepAction（0）不会被释放的原因。那么就是说，如果用创建单位的方法的话，对应的handle是必然要变化的。而是用复活则不会变化。

在演示中替换记录的handle值，很容易就解决绑定的问题，但是如果在一张地图上，需要绑定的数据很多的话，那么调整handle值的记录明显是一项很麻烦的工作。
至于你说死亡就清除数据，复活后出现问题，这个很容易被解决的，尸体消失后再清除就行了。甚至我们不需要知道确切的消失时间，只要大于这个时间就行
.......

实际上一边回帖一边聊QQ半路写乱了

本来我是想为小血争辩来着……
因为复活单位时不必考虑这些问题的
被释放的单位肯定无法复活
那么于是问题就解决了

如你所说单位死亡之外，其他时间的绑定都是不准确的
那么为什么还要用创建单位的方法？主要的问题在于除非我们注册单位的死亡时间，否则我们是无法精确到单位消失（释放handle）的。这个事件不存在。

也许是当时混乱解释错了。是指在一张图上的绑定很麻烦
我们需要把所有绑定了单位的系统一个个找出来，重新绑定
如果使用复活单位的话，就不会有这个问题了。

我所说的方法实际上也很混乱，我的目的本来是说用单位来传递参数代替存储系统的方法。如果在一个复杂的地图中我要绑定很多东西到这个单位上就可以用这样的传递方法。

关于那个消失了尸体还复活的bug，判断类别注册单位的尸体消失时间就行了，根据类别判断。不过这样做还有其他问题……比如背召唤骷髅了……

最后多说一句……
我一直没有装1.24……
所以关于这个方面没有发言权……

cccty1l

2. 如果hashtable只是存储了一个指针，那好办，直接把指针copy过去。

复制代码

这不就是正解么，我在第三里面说的也就是这样意思呀，尽管不能称之为指针，就算是一个整数吧。

疯人兄你说的我完全没有看懂啊，不过这个讨论的两个方法不是非此即彼的关系，相互说服对方无异于要改变对方编图习惯，我无此打算更无此能力。讨论的重点是数据的存储和转移，貌似咱们仨都还没有装1.24b对吧，虽说和缓存相比更是简单了不少，但是还是会有新的技巧存在的吧，所以，与其空谈，不如动手做点演示吧。

  
近期太忙啦，说这几句话花了一天的时间呀，唉。

血戮魔动冰

…………可能是我没说清楚哦…………
现在假设有3个人。
一个活宝，一个某系统制作者，一个成品图制作者。
系统制作者使用了hashtable（数组），用handle值作为索引。
活宝是Recreateunit的光环制作者。
成品图制作者把系统和光环全部copy到自己的图上。
那么问题出来了。系统肯定有个单位进入全图区域事件并且为这个单位初始化所有数据。
Recreate的Unit会被直接初始化所有数据。
要复制索引肯定要先把新的初始化数据删掉再覆盖索引。
但是活宝根本不知道成品图制作者使用的哪个系统，该用哪个函数进行copy单位数据/索引。
那么如果必须要继承数据，除非成品图使用者把系统和光环全部都看一遍，再自己写代码…………

疯人￠衰人

引用第47楼cccty1l于2009-09-25 00:21发表的  :

2. 如果hashtable只是存储了一个指针，那好办，直接把指针copy过去。

复制代码

这不就是正解么，我在第三里面说的也就是这样意思呀，尽管不能称之为指针，就算是一个整数吧。
.......

最近某个系统忙的焦头烂额呢……
懒得做哦……
1.24？
抵制……

你看不懂也无所谓，我只是支持小血……
支持在实际移植到地图中，重新绑定很麻烦
反正我的理念是：能用自带技能或者其他等实现就不模拟，能够不用自定义值就不用自定义值，能不用存储系统就不用存储系统，能用T就不用J，能做演示就不给人修改。能偷懒就偷懒……

cccty1l

好吧，原来大家还想继续呢。

…………可能是我没说清楚哦…………
现在假设有3个人。
一个活宝，一个某系统制作者，一个成品图制作者。
系统制作者使用了hashtable（数组），用handle值作为索引。
活宝是Recreateunit的光环制作者。
成品图制作者把系统和光环全部copy到自己的图上。
那么问题出来了。系统肯定有个单位进入全图区域事件并且为这个单位初始化所有数据。
Recreate的Unit会被直接初始化所有数据。
要复制索引肯定要先把新的初始化数据删掉再覆盖索引。
但是活宝根本不知道成品图制作者使用的哪个系统，该用哪个函数进行copy单位数据/索引。
那么如果必须要继承数据，除非成品图使用者把系统和光环全部都看一遍，再自己写代码…………

小血你这段话完全是想当然的情况，那我就给你对应下3个人的关系吧，活宝不用说了就是LZ啦；成品图制作者可能是任何人，但必须满足的条件是此人一定会是一个无脑的移植者，他基本上是无选择无分辨的看见好的技能或者系统就拉进自己的地图这样子；最后是某系统制作者，这个系统制作者的系统是什么我们还不知道，但是知道的是：1，这个系统负责了“单位进入地图区域”的事件注册；2，在触发事件是会为单位“初始化数据”；3，没有删除数据的功能，或者小血你没有指出。

那么现在看上面的第3点。
第一，系统没有排泄的话是不行的，那么我们默认有排泄；
第二，排泄的时机不是在单位死亡时，因为存在小血说的“要先把新的初始化数据删掉再覆盖索引”的步骤，这有可能说明一个单位在其死亡后其携带的数据依然是有用的，也就是说一个尸体携带“有用数据”，但是尸体的话除了被复活之外将不会再直接参与到与其他单位的交互中，有什么理由要携带“有用数据”呢？
好了，你可能会说，这些尸体都会被回收的，它们都会被复活，然后继续投入战斗。那么我接着问，是原地复活呢还是从刷新点复活，如果是前者的话，我且按住想问为什么的好奇心，我承认它确实可能需要些“生前”的数据，但是我想说这是一个奇怪的地图和奇怪的系统，我未见过，请给出实例或者链接；如果是后者的话，类似存在的有“刷兵”系统吧，那么我认为，“新刷”出来的兵不论你是重新创建的还是复活得来的，它都需要一个“初始化的数据”，而不是继承一个除了系统制作者没有人关心的某个已经死亡后连尸体都找不到的兵的数据，为什么要继承呢，你想知道它一共要死多少次才能杀掉一个英雄吗，或者为系统确实是依靠复活而不是创建单位来运行来提供一个证据么？真是恶趣味呢。
第三，下一个假设是系统有排泄不依靠复活运作，只不过排泄的时机不是“单位死亡”时，好了，那么是什么时候呢，这个问题昨天和疯人兄讨论了下，只不过疯人兄第二贴说他的第一帖没说清楚，而我没看懂第二贴，疯人兄的第三贴又说了我不懂第二贴也没关系，所以讨论目前是没有进展的，但是我看到了一句“如你所说单位死亡之外，其他时间的绑定都是不准确的”，可能有断章取义之嫌，疯人兄还想说的话请继续。

最近某个系统忙的焦头烂额呢……
懒得做哦……
1.24？
抵制……

你看不懂也无所谓，我只是支持小血……
支持在实际移植到地图中，重新绑定很麻烦
反正我的理念是：能用自带技能或者其他等实现就不模拟，能够不用自定义值就不用自定义值，能不用存储系统就不用存储系统，能用T就不用J，能做演示就不给人修改。能偷懒就偷懒……

我无力改变你的理念，但是你也应该经常审视一下你的理念是不是过时了呢，怎么看你的理念都是为偷懒而存在呢，哦，这个你也说了。



最后再补充下我所认为的小血说的3个人关系吧。我简单称他们为“演示、系统、成品图”，小血认为“成品图”可以把“系统”拿来直接用，我表示理解但不认同，鉴于“系统”的复杂性没多少人想要改动它，但是“系统”不可能考虑到所有的情况，也不可能完全满足“成品图”所有的要求，所以改动是必须的，从最简单的可能出现函数、变量名的冲突，到功能上的重复，这些都需要“成品图”对此采取相应的措施，也就是说“成品图”不能无脑移植，至少要充分了解“系统”才行；然后，“演示”是否要满足“系统”的要求，我认为，“演示”展示的可能是技能制作方法、理念与效果，可能是一个系统，也可能是娱乐用，但是“成品图”的环境纷杂无序，“演示”要考虑这些的话只会分散人们的注意力而已，也有一些“演示”是为了移植而存在的，但是也很难做到满足所有的“系统”，尤其是两个彼此原本就冲突的“系统”，所以满足主流才是合理的。

具体在现在的“演示”，“改变所属+复活书”和“删除+创建”两者实现方法上相差无几，前者还更麻烦一些，具体我前面已经说过了。小血你要求LZ的技能满足你假想的一个“系统”，这个“系统”思路古怪用途不明，这个必要性我觉得值得再商议一下，然后你还将以“系统”需要、移植困难这些莫须有的理由来提出的“建议”冠以“‘高手’的高度”的称谓，而实际情况是即使LZ做出了修改，我想你也不会移植此技能的，因为所谓的“系统”需求和移植难度都不存在，而这个“建议”在我看来只是你以“高手”的姿态对“新手”的强迫。你的想法可能很简单，只是

说的我的一些想法而已

，但是实际上起到的效果完全不止于此，看看第一页的回复吧，你这么做完全会让大家认为“哦，我必须这么做”而不是“唔，这是一个可以选择的方法”，你认为呢？

疯人￠衰人

恩恩，或许是我想的角度窄了些吧……
首先说“演示、系统、成品图”这个问题……
且先不考虑移植，你认为一个地图中的每个系统、技能是相对独立的好，还是互相牵连的好？也许从运行的角度上没有差异，但是如果相对独立的话，那么Debug更加方便了吧。我不是学软件的，我不清楚模块化的设计是否是最好的，但是我知道它是有好处的，设计系统、地图也应该使用这种方法，让每个系统、技能尽可能的独立，有较好的封闭性，当然这种模块之间的链接是不可能没有的，只是我们应该不希望一个数据会被多个系统、技能更改，这会加大我们制做时的复杂度、也更会出错。
上面所说似乎跟讨论的问题没有任何关系，实际上并非如此。先不讨论实际做图中用不用复活单位的方法，假设我们需要。那么用创建新的单位还是复活的方法好呢？如果用创建单位的方法，那么首要的问题是将旧的、死亡的单位的绑定数据保存到新的单位上去，这样是不是很复杂，我们需要编写更多的代码来善后。而用复活就不会。因为复活的单位就是死亡单位自身。
既然 cccty1l 兄提到了实际很少应用。那么我就继续来说吧，当然正常的刷兵不需要复活这样的办法。那么如果我要做一些特别的技能呢，当然技能也可以说是特别的，那么如果我们要做剧情呢？我来举具体例子也没有意义。因为我们只能说它很少用到，但是谁敢说绝对不会有人用这方面的东西？
好吧，关于“排泄时机”我认为排泄单位是在尸体消失后。也就是尸体消失后，单位的数据才会被销毁。我之前说unit变量的handle释放那个例子，就是证明这一点。你可以自己做测试，当一个变量（Location、timer都行）在一个function的某一步之后连接数变为0，并且对象也被清除了（比如RemoveLocation）那么它的handle值是不能立即被使用的，只有运行到等待或者整个触发结束才行（return也不行）。而unit变量在等待时也不会被释放，只有在触发结束才释放。它的这种特殊性也许跟死亡单位的排泄有关具体没有再测试。

高手新手的问题，或者我的理念的问题，都是一样的。我尽量不用J做演示是因为很多新手看不懂。不模拟是因为模拟很麻烦 ，对新手很难，自定义值的问题说了，怕移植难，或者如果新手在自己的图里用了自定义值呢，你给他个用自定义值的演示，他不是也白看么，小白一点的新手也许会直接用了，出现诡异bug后再来找你……
我一般情况都把提问者当小白的（除非我知道对方水平）当然不是看不起对方，只是为了让对方不会因为种种原因再找你，一次就明白，有水平的话他可以自己改。

“具体在现在的“演示”，“改变所属+复活书”和“删除+创建”两者实现方法上相差无几，前者还更麻烦一些，具体我前面已经说过了。”也许对于活宝的技能来说确实如此，但是对于很多东西来说，不用存储系统或许会更简单一些。比如需要模拟投射物时，我都是用远程马甲释放单体技能或者普通攻击一次的。这样会很容易的实现追踪等效果。

最后你说的那些恐怕过了。无论我们怎么说，都不会是强迫的。因为我们没法强迫。难道你还能去现实世界找对方拿刀逼着活宝这样做，或者派个贞子过去？当然不可能，无论我们用什么语气，都是一种描述、建议性质的。我说你新手的方法不好，用我的方法好，我不是强迫你用我的方法，只是告诉你可以这样做，可以这样改。具体新手自己想去。

我也是说的我的一些想法而已

cccty1l

疯人兄，我很欣赏你很谦虚对事认真的态度，但是讨论是对事不对人，也请原谅我出言不逊吧。

好了，现在我摘抄你的出回复，继续讨论吧。

先不讨论实际做图中用不用复活单位的方法，假设我们需要。那么用创建新的单位还是复活的方法好呢？如果用创建单位的方法，那么首要的问题是将旧的、死亡的单位的绑定数据保存到新的单位上去，这样是不是很复杂，我们需要编写更多的代码来善后。而用复活就不会。因为复活的单位就是死亡单位自身。

我在意的是“将旧的、死亡的单位的绑定数据保存到新的单位上去”，我认为，一个单位死亡就意味着其功能的终止，但是你仍然将“有用的数据”绑定在该单位上，并且执意要将其复活，请问，该单位为什么要“不死”？这些“数据”是什么？
你可能说，复活只是避免转移“数据”的方法，而不是这个“系统”的目的，那么我接着问，如果复活仅仅只是手段的话，意味着这些“数据”的重要性是大于复活单位的举动的。那么你这么做也就是告诉大家：这些“数据”很多且很重要，我把它绑定在这个单位“身上”了，单位死了但“数据”不能丢，你要创建新的单位那么我就必须得将这个“尸体”剥光了，再把“数据”绑定到新的单位上，这样很麻烦，我直接用复活就可以了，是这个意思么？那么既然“数据”这么重要的话你为什么要把它绑定在一个随时面临生命危险的家伙“身上”呢？真的不能绑定在别处么？

既然 cccty1l 兄提到了实际很少应用。那么我就继续来说吧，当然正常的刷兵不需要复活这样的办法。那么如果我要做一些特别的技能呢，当然技能也可以说是特别的，那么如果我们要做剧情呢？我来举具体例子也没有意义。因为我们只能说它很少用到，但是谁敢说绝对不会有人用这方面的东西？

或许你又在聊QQ了，那么我基本上可以认为你是在说“它很少用到”，对吧？我也说了，“演示”可以迎合一些“系统”的要求，但是当两类“系统”相互冲突的话，应该满足主流的，所以呢，将一个本来适合主流“系统”的“演示”变成不再适合的，这是你在论坛为人的方法还是目的呢？

好吧，关于“排泄时机”我认为排泄单位是在尸体消失后。也就是尸体消失后，单位的数据才会被销毁。我之前说unit变量的handle释放那个例子，就是证明这一点。你可以自己做测试，当一个变量（Location、timer都行）在一个function的某一步之后连接数变为0，并且对象也被清除了（比如RemoveLocation）那么它的handle值是不能立即被使用的，只有运行到等待或者整个触发结束才行（return也不行）。而 unit变量在等待时也不会被释放，只有在触发结束才释放。它的这种特殊性也许跟死亡单位的排泄有关具体没有再测试。

这个我也说了，只要是在尸体消失“后”而不是在尸体消失“时”清空数据，都是有可能造成Bug的，只是几率大小与时间差成正性相关，为了想使用复活，你愿意容忍这样的Bug存在么？这是怎样的执念呢。

能用自带技能或者其他等实现就不模拟，能够不用自定义值就不用自定义值，能不用存储系统就不用存储系统，能用T就不用J，能做演示就不给人修改。能偷懒就偷懒……

你的这个理念其实我只有部分比较认同，就是单位和物品的自定义值，我在之前发帖贴出了TimerDataSystem和UnitDataSystem的代码，但是后者我只在我做的“山寨钩肥”里面用过一次，那还是因为要展示DataSystem的用法，此后尽管有指出，却再也没有碰过，为什么，因为自定义值只能用一次，而这次机会是要交给“成品图”来使用的，疯人兄你如果不是作为“成品图”的角度来说的话，关于自定义值，我同意你的说法。关于技能的模拟，模拟自然是要达成更好的效果或者更高的可控性，存储系统的抵制我也觉得不可思意，或者你只是说之前的Hash系统么？T或J我不论，不过我确实对T无爱，因为之前编图时输入公式是那无限的鼠标点击已经让我崩溃了。能偷懒就偷懒，嗯，我举双手。咳咳，这算是对你的

高手新手的问题，或者我的理念的问题，都是一样的。我尽量不用J做演示是因为很多新手看不懂。不模拟是因为模拟很麻烦，对新手很难，自定义值的问题说了，怕移植难，或者如果新手在自己的图里用了自定义值呢，你给他个用自定义值的演示，他不是也白看么，小白一点的新手也许会直接用了，出现诡异bug后再来找你……
我一般情况都把提问者当小白的（除非我知道对方水平）当然不是看不起对方，只是为了让对方不会因为种种原因再找你，一次就明白，有水平的话他可以自己改。

的回应吧。

最后你说的那些恐怕过了。无论我们怎么说，都不会是强迫的。因为我们没法强迫。难道你还能去现实世界找对方拿刀逼着活宝这样做，或者派个贞子过去？当然不可能，无论我们用什么语气，都是一种描述、建议性质的。我说你新手的方法不好，用我的方法好，我不是强迫你用我的方法，只是告诉你可以这样做，可以这样改。具体新手自己想去。

这个我不想再重复了，我知道大家的本意是好的，不然也不会为了这么一个问题讨论这么长的时间。但是想的是一回事，做出来的效果就不一定能100%的传达出本意了，如此容易引起误会的“建议”应当是我在此发起讨论的动因吧。可能我说的也有些过了，还希望大家不要看我的笑话，认为我这个半瓶水在这里唬人。

血戮魔动冰

…………………………我认为此贴内容完全可以变成综合区讨论系统/演示的封装性教程。

风纪委员

对地图没什么用处，大部分玩家不会去理会。

血戮魔动冰

…………实际上如果不搞明白会有可能引发无数Bug。

疯人￠衰人

引用第52楼cccty1l于2009-09-25 16:37发表的 :
疯人兄，我很欣赏你很谦虚对事认真的态度，但是讨论是对事不对人，也请原谅我出言不逊吧。

好了，现在我摘抄你的出回复，继续讨论吧。

这个我不想再重复了，我知道大家的本意是好的，不然也不会为了这么一个问题讨论这么长的时间。但是想的是一回事，做出来的效果就不一定能100%的传达出本意了，如此容易引起误会的“建议”应当是我在此发起讨论的动因吧。可能我说的也有些过了，还希望大家不要看我的笑话，认为我这个半瓶水在这里唬人。

好吧……
因为跟言灵聊QQ
写的一大堆东西丢失了……
我很郁闷……

疯人￠衰人

重新写……

我在意的是“将旧的、死亡的单位的绑定数据保存到新的单位上去”，我认为，一个单位死亡就意味着其功能的终止，但是你仍然将“有用的数据”绑定在该单位上，并且执意要将其复活，请问，该单位为什么要“不死”？这些“数据”是什么？
你可能说，复活只是避免转移“数据”的方法，而不是这个“系统”的目的，那么我接着问，如果复活仅仅只是手段的话，意味着这些“数据”的重要性是大于复活单位的举动的。那么你这么做也就是告诉大家：这些“数据”很多且很重要，我把它绑定在这个单位“身上”了，单位死了但“数据”不能丢，你要创建新的单位那么我就必须得将这个“尸体”剥光了，再把“数据”绑定到新的单位上，这样很麻烦，我直接用复活就可以了，是这个意思么？那么既然“数据”这么重要的话你为什么要把它绑定在一个随时面临生命危险的家伙“身上”呢？真的不能绑定在别处么？

或许你又在聊QQ了，那么我基本上可以认为你是在说“它很少用到”，对吧？我也说了，“演示”可以迎合一些“系统”的要求，但是当两类“系统”相互冲突的话，应该满足主流的，所以呢，将一个本来适合主流“系统”的“演示”变成不再适合的，这是你在论坛为人的方法还是目的呢？

当时是突然忘记自己要举的例子了……我常这样……
实际上你说的，都不是绑定数据的问题，而是复活（不是复活技能）的问题。实际上很少应用的是复活单位，就像你说的，都是刷兵，创建兵，没有让死了的兵复活当做新的兵的。于是我说应用的少。但是不是没有。如果我真的要在地图上加入这样一个技能呢？（制图时）
我要讨论的不是是不是改由复活的效果，而是如果我们用了复合这个效果，我们应该怎么达到这个效果，是用复活技能还是创建新单位，哪个方法更简单方便。
举个例子：比如我要做个范围内持续效果的群体的技能。首先这个技能是持续的，它还有一些效果，比如要调整单位的高度与击退，所以我们需要绑定数据到这个范围内可伤害的单位身上。如果在效果发动的过程中，某个受到伤害的单位死了，然后它有可能被其他系统或者技能复活。我们能不保留绑定的数据么，如果没有绑定，那么我们怎么来获得调整高度的变化击退方向的变化这些数据？
于是我们就需要在单位死亡后保留下来，直到不可能被复活为止（清除尸体）。如果使用创建单位的方法，这样的参数传递时不可避免的。而使用复活的方法，完全可以无视这个问题（除了buff丢失）。
还理解不了么？这个说的不混乱吧。

这个我也说了，只要是在尸体消失“后”而不是在尸体消失“时”清空数据，都是有可能造成Bug的，只是几率大小与时间差成正性相关，为了想使用复活，你愿意容忍这样的Bug存在么？这是怎样的执念呢。

这个bug是不可能存在的。首先玻璃渣应该会保证在尸体消失后立即清空数据的，这个实现起来一点也不难，而且也应该这样做。然后，即使没有立即清除，复活也不会出问题，那是因为复活的释放目标（就是影响范围）是尸体，尸体没了自然也就不复活了，也不会出现bug。
会出bug的是绑定，也就是对尸体消失单位的H2I，不过我很怀疑是否会得到正确的结果。而且这个问题也不是复活才有的，如果你删除了单位，然后再对没有清空的unit变量H2I，自然会有问题。这个主意点就好了。
这也证明了复活技能的方法比较好。

你的这个理念其实我只有部分比较认同，就是单位和物品的自定义值，我在之前发帖贴出了TimerDataSystem和UnitDataSystem的代码，但是后者我只在我做的“山寨钩肥”里面用过一次，那还是因为要展示DataSystem的用法，此后尽管有指出，却再也没有碰过，为什么，因为自定义值只能用一次，而这次机会是要交给“成品图”来使用的，疯人兄你如果不是作为“成品图”的角度来说的话，关于自定义值，我同意你的说法。关于技能的模拟，模拟自然是要达成更好的效果或者更高的可控性，存储系统的抵制我也觉得不可思意，或者你只是说之前的Hash系统么？T或J我不论，不过我确实对T无爱，因为之前编图时输入公式是那无限的鼠标点击已经让我崩溃了。能偷懒就偷懒，嗯，我举双手。咳咳，这算是对你的的回应吧。

我说的自然不是做成品图时，不过即使是成品图，也要尽量不用自定义值，以为你没法保证下一个系统不用。如过你肯先放下这个系统、技能到最后做的话，就没问题了。

这个我不想再重复了，我知道大家的本意是好的，不然也不会为了这么一个问题讨论这么长的时间。但是想的是一回事，做出来的效果就不一定能100%的传达出本意了，如此容易引起误会的“建议”应当是我在此发起讨论的动因吧。可能我说的也有些过了，还希望大家不要看我的笑话，认为我这个半瓶水在这里唬人。

跟你不是很熟，不清楚你带没带过新手，也不知道你是怎么给演示的。对于新手来说，只要能做出来，我才不去考虑其他方法呢……至少我只看到一个人不是这样，而且她还很可能是个老手。多说的那些，都是给翻帖子的人看的。这些人往往不是新手，也只有有些水平的人才会关心哪种方法好。
或许说的那么绝对是个错误，不过这个还是个人看法。相信无论cccty1l 你，小血还是我，以及GA上的所有非新手都不会有看不起新手的想法。只是我们习惯于自己的思路，自己的感觉而已。无论怎么说，决定权都是在提问的LZ身上（不是单指活宝）。你说的再绝对，他无视你也是白搭。

可能我说的也有些过了，还希望大家不要看我的笑话，认为我这个半瓶水在这里唬人。

至于这个，没有什么问题。大家也没说出火气来，不过是阐述观点而已。说起来我的水平还不如cccty1|你，我学J也没多久，才几个月，也没用J做过什么东西。我只是对T更熟悉些
更了解新手的想法而已

cccty1l

呵呵，其实我的观点表述完毕了。

看到这里的童鞋查看这个欢乐物吧
http://220.170.79.48/html/ent/20090925/49315.html