长按选不到实例变量
-
在怪物装备.装备名称=0时，也进行下面的否则程序
但后面的能识别怪物装备.位置，及后面没问题
改了一下代码这样也无法识别装备名称=0，
在装备名称=0时，还是会执行
-
这种情况就可以识别，
及为什么不能识别怪物装备.位置=0，实例的实例变量
但把实例变量的值作为一个参数时就可以识别
-
@maker发 没理解你想说的是什么意思，只看你的截图内容的话：
第一张图：如果长按的是装备名称不为0的怪物装备实例，那么会走否则的情况，如果长按的实例的装备名称等于数值型的0的实例，那么会走【[系统] 当怪物装备.装备名称=0时】的事件，也就是什么都没执行，但用“名称”给实例变量取名的话，一般该实例变量的类型应该是文字型的，所以猜测你的问题是出在数据类型不匹配却硬是做了比较。
第二张图：看似多做了一步筛选，实际跟第一张图的情况没有区别，所以结果跟第一张图是一样的才对。
第三张图：前面部分跟第一二张图的筛选情况是一样的，唯一的区别是【怪物装备库.at(怪物装备.位置)=0】这个条件，如果这个数组里对应的元素位置是空的，那么根据数组的at表达式，如果获取到的是元素的值是空的，会默认返回数值型的0，也就能打破第一张图中我所猜测的“数据类型不匹配却硬是做了比较”的情况，也就有效果了。
或者我猜测你是误以为：实例变量只要为空，那么用表达式去获取它的值，就会固定返回数值型的0。但实际上用表达式获取文字型变量的值时，如果实例变量空着没填，返回的其实是空字符串，跟数组中的空是不一样的（数组可视化界面中，什么都不填的空叫undefined，是未定义的意思，跟空字符串是有差别的，undefined可以看做是没有任何数据类型的，而空字符串是文字型的数据，但是内容中没有任何字符）
-
@maker发 你的说法自相矛盾啊，就如下图所说的，你这个长按如你所说，在第三张图有选中效果的话，说明实例是已经选中了，实例变量就一定能获取到的（而且我还特地去测试了一下，确实是能正常选中的），因此“长按选不到实例变量”的说法是不存在的，我觉得大概率是你的测试事件的设计和表现导致你下了这个错误的结论，原因的话，楼上那位朋友的说法我觉得可能性很大，其实你想要验证你这个说法也很简单，你只需要单独搞个全局变量，然后写一个“长按对象时，把这个对象的某个实例变量的值设置给全局变量”，然后预览看看这个全局变量的值有没有正常跟着变化就行了，不用写那么复杂的验证事件
-
这位老哥说的很对，我确实那名称那里用的是字符串，而且我的理解也是老哥说的那样应该是这里错了
只是我还想问一下如果我想判断其字符串是否为空怎么写这个判断呢？
-
@maker发 空字符串就是单纯一对英文双引号，你在输入框打 "" 就行了
-
@忠心耿耿汉弗莱 我一开始的猜想是可以识别选中实例，但某些特殊情况下无法识别实例变量判断
系统有可能认为是全部实例中都是装备名称=0的情况，这样只有一个不等于0就执行下面的否则，
所以我调了代码，选中确定实例下的子事件去识别
但我这种思想大错特错，动摇了基础的长按就可以选中的基本规则。
希望后面的人看到这类问题，不要直接动摇基本规则来排代码。
-
@maker发 其实保持怀疑也可以的啦，毕竟唤境现在还是会时不时发现bug，保持合理的怀疑才能帮官方找出bug来，我想那位仁兄只是想表达“根据自己的怀疑得到一个临时的结论后，最好用更简单的事件去验证这个临时的结论是否成立”，这样就能减少下错结论的情况了，就像他说的，你的临时结论既然是“长按的情况下能选到实例但使用不了它的实例变量”，那么验证这个临时结论是否正确，只需要长按后拿个全局变量去引用实例变量的值是否是正常的就行了，事件写多了就容易对结论的验证造成干扰。
总之保持合理的怀疑我觉得是没什么问题的，我会觉得学习过程中就是这样的，一步步用已知的知识去思考，已知的知识自然是有局限性的，会得出不完全正确的结论也是常见的事，通过自己验证也好或是他人告知也好，能进一步扩展新的知识，下错结论的情况自然也会随着知识丰富起来而慢慢变少的。
