Kagamia

Because this cash weapon can be used on all weapons, different back weapons have different sets of actions. Obviously, the attack actions for 1H, 2H, spears, and bows are not...

请问完整节点名称和客户端版本是什么....

Added in https://github.com/Kagamia/WzComparerR2/commit/75420f810265a02516cb85c0de2ebe2b5d8bed93

@HikariCalyx 并非相关问题。

添加了Video的预览。 现在wcR2对于video的解析、播放、保存、导出均已完整支持，对文件格式感兴趣的可以参考源代码。

@seotbeo Fixed mcv file loading on flag=7(1|2|4), please try again.

尝试做了一些性能分析，发现了几个内存泄漏点： 1. UI框架内存泄漏，在AdvTree清空节点以后，node和cell会因为一些私有字段持有被删除的节点的引用，导致无法被GC回收。 2. 随着MapRender2读取地图，会有大量img被解压读取导致内存占用提高。 3. MapRender2中，如果在刚刚进入或退出地图的时候关闭窗口，控制bgm音量的Task会一直处于active状态导致无法回收。 4. Monogame内部的VertexDeclaration有静态缓存，会导致GraphicsDevice被引用导致无法回收。 5. MainForm上的GraphicsControl在清空绘图资源后，已加载的Texture2D不会自动释放导致内存泄漏。 如上很多问题都不是调用GC.Collect强制回收可以解决的，目前对64位运行时下的内存占用也确实没有太好的优化手段。后面等到issue列表主要的bug修理完后可以考虑做做内存优化，但也不要抱太大期望。

初步结论：新的客户端中使用了非标准大小的BC7纹理，以及自定义的像素数据编码。 我们拿第二张图举例，它的原始尺寸为2043x2035，**宽高都不是4的倍数**，而BC纹理格式是按照4x4大小的块进行编码，并且按行列顺序存储到文件的。 那么4151376是怎么来的呢？事实上4151376=2043x2032，也就是说，图片切掉了底部3个像素行，并且在每行添加了一些padding，实际有效数据大小只有2040*2032。 如图所示，蓝色阴影的部分是NX擅自添加的填充数据，黑色阴影部分数据被省略。 目前没有足够的样本证明NX对于所有BC格式纹理都使用了相同的处理方式，所以wc计划只修复BC7，其他格式以后碰到再说。 -------------------- 然而修复以后还会存在很多细节问题。 能正确地显示和保存只是第一步，我们还要思考游戏中是如何使用这张纹理的。如果这些纹理是被用于骨骼动画，还需要考虑擅自调平纹理大小会不会影响骨骼坐标计算。此外也要考虑保存到png时是否需要对齐尺寸或切掉无效数据，texture和canvas尺寸不一致时会不会产生副作用或无法预期的bug等等。

推送了一个更新。 目前方案：切除无效尺寸，无论对于预览还是保存，都仅解码有效数据。 理论上对于骨骼的uv计算会出现问题，理论上uv和纹理加载都是按照atlas文件中声明的大小去处理的，如果atlasPage定义的大小和实际加载后的大小不一致，后续绘制是一定会出现偏差的。 实际效果需要提供完整的spine声明才能验证，目前wc的TextureLoader和SpineRenderer都没处理这个差异。

感谢提交bug。 这确实是一个未定义操作。 在设计上，ms文件通常随着Base.wz自动打开，并且把所有读取到的Ms_Image目录合并到已有的结构树上。 对于单独打开的行为没有正确设计，所以产生了报错。 这个问题可能会在后续的更新里修复，优先级不是最高。