关于 行为 装备 两个数据之间的漏洞,希望注意!

东方油瓶

如果一个装备的携带或者装备行为中填写了某个行为，那么SC2会如此去在携带者身上运算：

单位携带装备→ 为单位添加行为
单位失去装备→ 为单位移除行为

添加与移除的行为就是填写在装备栏中的行为，那么这样会有一个什么样可怕的BUG呢!

假如我们制作了某个BUFF ，叫做魔法免疫，假如某个单位天生拥有该BUFF(魔法免疫)

此时，给予该单位一个装备，这个装备能够使其魔法免疫，使用的BUFF也是同样的"魔法免疫"BUFF。

那么当单位卸掉这个装备时，他就不再是魔法免疫的了！这个BUFF将会消失！

同理的BUG还有另外一种，关于属性的：
该属性最大叠加层数设为40，假设这个属性的名字为：冷却缩减

此时给予单位两个装备，装备1：提升30冷却缩减  装备2：提升20冷却缩减

那么，当同时装备两个装备时，单位的冷却缩减属性将是40。

此时，我们使单位失去装备2，也就是失去20的冷却缩减。装备1原封不动。此时，按照正常的逻辑，单位的该属性应该变化为30（因为有装备1的存在）
但是实际上，单位的冷却缩减属性将会变为20！！！！是的！！变为20！！！卧槽我真是醉了，暴雪爸爸你这跟dota的严谨比起来不知道被甩了几百条街啊FUCK!

东方油瓶

这个坑爹的系统我可以这么说，如果暴雪敢放多一点东西，让我自己能够制作单位使用技能的界面。

同时单位的技能数量不止限制为64个，我绝对会自己撸一个装备系统而不是用他这个SB东西，气人。

yxxiaobin

确实，如果不注意的话，真的有可能掉进buff上限的陷阱。
其实这本质上是一个问题：buff有上限，当提供buff时，受上限影响可能会少添加，但是移除buff时却忘记了少添加的层数。
这个目前想来，还真的没有什么太好的方案去解决。

东方油瓶

yxxiaobin 发表于 2016-8-29 10:00
确实，如果不注意的话，真的有可能掉进buff上限的陷阱。
其实这本质上是一个问题：buff有上限，当提供buff ...

我现在的做法是，通过一个隐藏buff来调整buff的数量。

上限我调整为一个永远不会超过的数目，然后用属性变化事件去捕获变化

在超过的时候用隐藏buff去削减超过的部分。

这个实际上是一个月前发现的事情了，这个真的还好（因为做法并不是很耗资源）

但是新的这个实在是太恶心了，这代表着所有通用buff都不能在装备里面直接给予，而要通过一些特殊的处理来尽量规避这种buff出现在装备的携带数据中。

这个工作量就有点恶心了。。。。

东方油瓶

yxxiaobin 发表于 2016-8-29 10:00
确实，如果不注意的话，真的有可能掉进buff上限的陷阱。
其实这本质上是一个问题：buff有上限，当提供buff ...

叠加层数即使再怎么变化，我也有这个属性在单位身上，就可以捕获

但是另外一种这个行为直接没了！没了我怎么捕获???

如果不能通过内部捕获，自己强行捕获，那么效率自然是不好的.

属性只是控制数目，但是行为是控制有无啊~

疯人￠衰人

东方油瓶 发表于 2016-8-29 11:23
叠加层数即使再怎么变化，我也有这个属性在单位身上，就可以捕获

但是另外一种这个行为直接没了！没了 ...

其实我感觉这是你制作的问题不是编辑器自身的问题。
这个可以采用添加同效果不同行为来制作，比如每层buff A降低5%速度
那么可以做个buff B也是降低5的速度来达到期盼的效果，然后在添加和删除buff B的时候来限制上限

本身添加和移除行为就不是对应的。单位的行为列表应该是一个队里，先入先出。删除时删除最早获得的行为（因为每层（一个效果添加的多层视为一层）行为的源单位等信息是独立的，这点可以很容易的测试出来）

东方油瓶

疯人￠衰人 发表于 2016-8-29 11:54
其实我感觉这是你制作的问题不是编辑器自身的问题。
这个可以采用添加同效果不同行为来制作，比如每层bu ...

我只是说麻烦....不是说不行...

成本问题.

royugo

最近在弄装备系统也是深感SE的物品系统简陋的不行，各种BUG花样百出，只能说这编辑器毕竟是为RTS服务的，连衍生的MOBA游戏都不太适合

疯人￠衰人

royugo 发表于 2016-8-29 15:19
最近在弄装备系统也是深感SE的物品系统简陋的不行，各种BUG花样百出，只能说这编辑器毕竟是为RTS服务的，连 ...

不是简陋，而是开放了更底层的定制功能，然而并没有很好用的官方应用作为例子罢了

priceles

每次丢去捡起装备的时候把BUFF用触发器算一遍呗。单位组里面有个函数叫单位携带的物品

yxxiaobin

priceles 发表于 2016-8-29 22:10
每次丢去捡起装备的时候把BUFF用触发器算一遍呗。单位组里面有个函数叫单位携带的物品

如果存在多种buff冲突，这种做法就不太妙了。主要是因为玩家自定的东西实际上很难保证良好的兼容性，所以通用代码实现困难。而单独做的话，可能比孔明的方案写起来方便，但是出错风险更大。
如果能保证自己有清晰的头脑，并且编程习惯良好，则推荐这种做法，否则还是用孔明的方案更保险一点。

疯人￠衰人

yxxiaobin 发表于 2016-8-29 23:21
如果存在多种buff冲突，这种做法就不太妙了。主要是因为玩家自定的东西实际上很难保证良好的兼容性，所以 ...

不同的技能共享相同的buff本来就是一个错误的选择，排除制作难度本身，设计起来坑就不少。而实现方法本身就是依赖于设计的。
如果非要采用这种不同的装备产生一个公共的效果时，那么最好的方法是制作一个维护的系统，独立效果通过行为实现，但是添加删除效果层数时通过脚本来控制总数

东方油瓶

疯人￠衰人 发表于 2016-8-30 11:43
不同的技能共享相同的buff本来就是一个错误的选择，排除制作难度本身，设计起来坑就不少。而实现方法本身 ...

嗯嗯嗯嗯嗯，很机智

东方油瓶

疯人￠衰人 发表于 2016-8-30 11:43
不同的技能共享相同的buff本来就是一个错误的选择，排除制作难度本身，设计起来坑就不少。而实现方法本身 ...

脚本控制其实可以延展为数据层的

使用验证器完成：单位拥有装备1 2 3的独立buff（or）

禁用/启用 公用行为

在装备给予时装备的独立行为初始效果：应用公共行为

这个做法应该没什么毛病吧？我尽量不想用触层去做这种，因为效率比起数据低很多（或者说数据的效率太好了）

疯人￠衰人

东方油瓶 发表于 2016-8-31 09:07
脚本控制其实可以延展为数据层的

使用验证器完成：单位拥有装备1 2 3的独立buff（or）

问题是如果你希望实现公共行为层数等于123的行为，是没法纯数据实现（简单的）的

疯人￠衰人

东方油瓶 发表于 2016-8-31 09:07
脚本控制其实可以延展为数据层的

使用验证器完成：单位拥有装备1 2 3的独立buff（or）

问题是如果你希望实现公共行为层数等于123的行为，是没法纯数据实现（简单的）的

东方油瓶

疯人￠衰人 发表于 2016-8-31 09:38
问题是如果你希望实现公共行为层数等于123的行为，是没法纯数据实现（简单的）的

为何？行为有禁用的验证器，用或的条件启用/禁用公用行为不行么？

东方油瓶

疯人￠衰人 发表于 2016-8-31 09:38
问题是如果你希望实现公共行为层数等于123的行为，是没法纯数据实现（简单的）的

哦，是说层数啊，那个倒是不敢想啦~~哈哈哈

yxxiaobin

疯人￠衰人 发表于 2016-8-30 11:43
不同的技能共享相同的buff本来就是一个错误的选择，排除制作难度本身，设计起来坑就不少。而实现方法本身 ...

我突然发现我错误的理解你的回复了。
其实我是这么理解的：
做一个buffA，拥有实际的作用，并拥有合适的层数的上限。
做一个buffB，没有实际作用，拥有极高上限，以至于游戏中总是达不到。
装备行为带的是buffB，buffB初始行为会应用一层buffA。但是buffB移除时并不移除buffA。
接下去最好交给触发器，响应buffB减少事件，把buffA层数设置的和buffB一样。当然，纯数据的话也可以，但是考虑到并没有直接比对两个buff层数的触发器，实现起来稍微有点费劲（但是可以实现，因为还有所需条件这东西）。

这样做的好处是不必详细记录少加了多少层，该加多少层等等。因为当buffB的层数始终高于buffA上限时，buffA自然会维持自己的上限，此时无论buffB增加还是减少，都不会受影响。但是一旦buffB的层数下降到低于buffA的上限，则buffA会保持和buffB同样的增减。

a684258

yxxiaobin 发表于 2016-8-31 11:05
我突然发现我错误的理解你的回复了。
其实我是这么理解的：
做一个buffA，拥有实际的作用，并拥有合 ...

物品本身的行为中,效果初始和最终设置一个 "伤害" 来捕捉作为事件,此时计算"无上限的马甲冷却"行为的层数
然后用触发添加/移除 "实际起作用的冷却" 的行为