[功能改进]:操作逻辑、界面改进方案

[Mifan-T]

描述

前言

目前SlopeCraft的操作逻辑并不清晰，界面混乱的设计更是雪上加霜。
要想进行改进，就要先将基础逻辑梳理好，再用经过刻意设计的界面进行引导，而这肯定不是一个小工程。不过幸运的是，现有的界面虽然分类混乱，但大部分该有的功能都有，这让我们可以节省一些功夫，不需要100%重写界面。这个issue就会尽可能的利用已有功能，通过重新排布元素使逻辑更清晰明了

整个改进流程：

1）我会先提交改进方案的设计图，进行可行性讨论，并不断改进。
2）改出满意的版本后，我会用这版的设计图画出界面的各版本概念图（因为实际的界面是立体的，同一个功能在界面上有多种实现方式，我们需要找到最适合的方式）。
3）概念图通过后再对代码进行更改。

注意：我并不会编程，以下仅为我通过经验整理出的方案，请仔细甄别，并指出错误

目前方案的整理和“批判”

这一步是为了充分了解当前的所有功能，并找出缺陷所在，方便后续的改进。
↓（画的比较潦草，请谅解）

第一版操作逻辑改进设计图

这张图是重点。目前并不完善，欢迎提出各种意见，我会不断进行改进
另外，因为我不会编程，所以可行性的分析就交给你们了

补充

↓“改进设计图”中提到的批量操作改进概念图 （仅作为批量操作概念演示，不包含其它功能）

↑最左侧的为“项目池”

[ToKiNoBug]

谢谢，图我已经看到了，不过确实有点复杂，我慢慢看

[ToKiNoBug]

我觉得把各自导出合并到一个页面是有一定道理的，但最早的时候没这么设计，是因为输出三种原理图需要额外构建三维结构，地图画很可能超过限高，用户需要知道到底有没有超限高，以及地图画的实际尺寸；但输出纯文件地图画不需要构建三维结构

[Mifan-T]

我觉得把各自导出合并到一个页面是有一定道理的，但最早的时候没这么设计，是因为输出三种原理图需要额外构建三维结构，地图画很可能超过限高，用户需要知道到底有没有超限高，以及地图画的实际尺寸；但输出纯文件地图画不需要构建三维结构

是这样的，设计中也考虑了这一点，所以不同格式使用的是不同的子页面，只不过三种原理图的页面元素有部分重合。
这种设计在概念图上可能更好理解，我之后会发几张

[ToKiNoBug]

我觉得把各自导出合并到一个页面是有一定道理的，但最早的时候没这么设计，是因为输出三种原理图需要额外构建三维结构，地图画很可能超过限高，用户需要知道到底有没有超限高，以及地图画的实际尺寸；但输出纯文件地图画不需要构建三维结构

是这样的，设计中也考虑了这一点，所以不同格式使用的是不同的子页面，只不过三种原理图的页面元素有部分重合。 这种设计在概念图上可能更好理解，我之后会发几张

谢谢，我很期待后面的概念图。不过我在仔细看了你的第一版图之后，发现一个比较难实现的要求：全部转化、全部构建（三维结构）。SlopeCraft内核的设计逻辑不适合同时持有多个图片或者多个三维结构，而只能逐个处理每个图片，真正存储了多个图片的是界面。

不过我感觉界面逻辑三大步的划分还是相当合理的，非常适合内核运行的逻辑。

内核运行的基本逻辑也确实分几步：

1. 设置游戏版本、方块表和地图画类型（决定了有哪些颜色）
2. 输入图片
3. 转化图片
4. 构建三维结构

只要完成第三步，就都可以输出转化后图片和纯文件地图画；只要完成第四步，就可以输出所有类型的地图画。

---

另外我自认为VisualCraft的界面逻辑还是很适合批量处理的，也许可以参考一下。不过它表格的形式确实不够方便，只是刚好能显示和修改所有信息。

[Mifan-T]

不过我在仔细看了你的第一版图之后，发现一个比较难实现的要求：全部转化、全部构建（三维结构）。SlopeCraft内核的设计逻辑不适合同时持有多个图片或者多个三维结构，而只能逐个处理每个图片，真正存储了多个图片的是界面。

另外我自认为VisualCraft的界面逻辑还是很适合批量处理的，也许可以参考一下。不过它表格的形式确实不够方便，只是刚好能显示和修改所有信息。

ok，这一部分的设计其实旨在让批量处理和单件处理操作无缝融合，和VisualCraft（以下简称VC）的设计理念相近，但我希望优化一些细节，提升可视性，让操作更加直观。

按我的理解，目前SlopeCraft（以下简称SC）的内核无法暂存多张图片或三维结构，而VC批量导出时实际是将颜色转换、结构构建单线程地做了一遍，界面中转换的图片仅用于预览。
如果我的理解正确的话，这也是一个设计思路，因为手动构建结构的主要目的其实是预览材料表和压缩后的地图画，并没有大量暂存的需求，这种方案就可以砍掉“全部构建"和“全部*转换”按钮（但是可以思考下批量操作的材料表如何实现）。不过这算是一个阉割版的方案，实际效果还是比较畸形
*转换（设计图里打错字了）

我之所以想增加项目池的概念，是因为这非常便于表现SC的转换逻辑，用户一层一层转化图像的动作同时也是一种引导。
我认为，这种轻量级的工具软件应该朝即用即会设计，而不该给用户发一本晦涩的手册。也就是说，界面作为交互的手段，同时也要具有引导的功能，而项目池就是一个很好的引导手段。

[Mifan-T]

概念图的命名规则：

第一个英文字母指定某个页面。小写代表早期概念图，是无序的；大写代表正式概念图，会按页面顺序标定
字母后的数字代表某种方案，而这种方案的改进型会用“-”后的数字表示
例如：早期a页面方案一第一版改进型（a1-1）

正文

↓阉割版方案的概念图

我实在没想出如何改进，如果有想法可以告诉我

↓理想方案的概念图

导出页面的概念图还要再完善，摸了

[Mifan-T]

a2-1引入的新问题：

项目池中的不同图片可以使用不同算法
由于可以使用不同的算法，可能会有用户搞错不同图片的算法，致使导出的地图画出现问题？

补充

制作概念图的过程中，我发现“项目池”的设计并不是最好的，因为这会引入一大堆新问题
如果有更好的建议，可以提出来

[Mifan-T]

SlopeCraft内核的设计逻辑不适合同时持有多个图片或者多个三维结构，而只能逐个处理每个图片，真正存储了多个图片的是界面。

我在想，有没有可能把处理后的缓存转化为文件，暂存在软件目录下，方便后续步骤调取。blender应该就是用这种方法储存流体模拟数据的

[ToKiNoBug]

a2-1引入的新问题：

项目池中的不同图片可以使用不同算法 由于可以使用不同的算法，可能会有用户搞错不同图片的算法，致使导出的地图画出现问题？

补充

制作概念图的过程中，我发现“项目池”的设计并不是最好的，因为这会引入一大堆新问题 如果有更好的建议，可以提出来

我觉得，没有必要允许不同图片使用不同算法，批量处理通常是多个相似的图片经过几乎一样的方法生成地图画。如果要用不同的算法，那用户完全可以分成不同批次，没必要把不同算法挤进同一批次里。

[ToKiNoBug]

不过我在仔细看了你的第一版图之后，发现一个比较难实现的要求：全部转化、全部构建（三维结构）。SlopeCraft内核的设计逻辑不适合同时持有多个图片或者多个三维结构，而只能逐个处理每个图片，真正存储了多个图片的是界面。

另外我自认为VisualCraft的界面逻辑还是很适合批量处理的，也许可以参考一下。不过它表格的形式确实不够方便，只是刚好能显示和修改所有信息。

ok，这一部分的设计其实旨在让批量处理和单件处理操作无缝融合，和VisualCraft（以下简称VC）的设计理念相近，但我希望优化一些细节，提升可视性，让操作更加直观。

按我的理解，目前SlopeCraft（以下简称SC）的内核无法暂存多张图片或三维结构，而VC批量导出时实际是将颜色转换、结构构建单线程地做了一遍，界面中转换的图片仅用于预览。 如果我的理解正确的话，这也是一个设计思路，因为手动构建结构的主要目的其实是预览材料表和压缩后的地图画，并没有大量暂存的需求，这种方案就可以砍掉“全部构建"和“全部*转换”按钮（但是可以思考下批量操作的材料表如何实现）。不过这算是一个阉割版的方案，实际效果还是比较畸形 *转换（设计图里打错字了）

我之所以想增加项目池的概念，是因为这非常便于表现SC的转换逻辑，用户一层一层转化图像的动作同时也是一种引导。 我认为，这种轻量级的工具软件应该朝即用即会设计，而不该给用户发一本晦涩的手册。也就是说，界面作为交互的手段，同时也要具有引导的功能，而项目池就是一个很好的引导手段。

是的，你的理解完全正确。

[ToKiNoBug]

SlopeCraft内核的设计逻辑不适合同时持有多个图片或者多个三维结构，而只能逐个处理每个图片，真正存储了多个图片的是界面。

我在想，有没有可能把处理后的缓存转化为文件，暂存在软件目录下，方便后续步骤调取。blender应该就是用这种方法储存流体模拟数据的

确实可以设计一种缓存格式，并且让内核可以加载缓存

[Mifan-T]

我觉得，没有必要允许不同图片使用不同算法，批量处理通常是多个相似的图片经过几乎一样的方法生成地图画。如果要用不同的算法，那用户完全可以分成不同批次，没必要把不同算法挤进同一批次里。

我想到了一个解决方案：

用户每对算法做出一次改动，就清空一次缓存区，这样就能保证缓存区内所有图片都使用相同的算法

顺带对a1-1的设计做出详细说明：

将缓存区的状态做了可视化，并且整合到项目池中（就是图片右下角的小箭头）。绿色箭头表示图片已被转换到缓存区，红色箭头表示还未转换

[Mifan-T]

既然我们现在是在纸上谈兵，那想法不妨就大胆一点。就算目前无法实现也没关系，至少还可以留个空位，方便后续改进

我现在就有个大胆的想法
既然SC可以导出转换后的图片，那能不能将导出的图片再导入SC呢？如果可以做到，那理论上用相应色表对图片精修后也可以再导入，甚至还能自由绘图，相当于变相实现了手动精修的大饼

[ToKiNoBug]

既然我们现在是在纸上谈兵，那想法不妨就大胆一点。就算目前无法实现也没关系，至少还可以留个空位，方便后续改进

我现在就有个大胆的想法 既然SC可以导出转换后的图片，那能不能将导出的图片再导入SC呢？如果可以做到，那理论上用相应色表对图片精修后也可以再导入，甚至还能自由绘图，相当于变相实现了手动精修的大饼

是这样，但用户本来就可以手动导出再导入，所以我就没有显式的加入手动精修的按钮，而只是加了导出颜色表的功能。我没能力造一个图像编辑器的轮子

[Mifan-T]

是这样，但用户本来就可以手动导出再导入，所以我就没有显式的加入手动精修的按钮，而只是加了导出颜色表的功能。我没能力造一个图像编辑器的轮子

但目前的操作有个问题，导出的图像再导入时会进行二次颜色转换，如果这时勾选了抖动仿色就有可能会使图像发生一些变化，尤其是HSV+抖动仿色特别明显（点名批评HSV）

↓RGB+&抖动仿色一次转换

↓HSV&抖动仿色二次转换

所以不如单独加一个按钮用于导入已处理过的图片，二次处理时限制算法，避免出现问题。将这个流程直接展示出来也利于用户使用

[ToKiNoBug]

是这样，但用户本来就可以手动导出再导入，所以我就没有显式的加入手动精修的按钮，而只是加了导出颜色表的功能。我没能力造一个图像编辑器的轮子

但目前的操作有个问题，导出的图像再导入时会进行二次颜色转换，如果这时勾选了抖动仿色就有可能会使图像发生一些变化，尤其是HSV+抖动仿色特别明显（点名批评HSV）

↓RGB+&抖动仿色一次转换

↓HSV&抖动仿色二次转换

所以不如单独加一个按钮用于导入已处理过的图片，二次处理时限制算法，避免出现问题。将这个流程直接展示出来也利于用户使用

按理来说，二次颜色转换应该是没有任何变化的，因为输出的图片只包含了地图画可用色，二次导入的话，每个像素都必定能找到完全一样的颜色。

[ToKiNoBug]

是这样，但用户本来就可以手动导出再导入，所以我就没有显式的加入手动精修的按钮，而只是加了导出颜色表的功能。我没能力造一个图像编辑器的轮子

但目前的操作有个问题，导出的图像再导入时会进行二次颜色转换，如果这时勾选了抖动仿色就有可能会使图像发生一些变化，尤其是HSV+抖动仿色特别明显（点名批评HSV）
↓RGB+&抖动仿色一次转换
↓HSV&抖动仿色二次转换
所以不如单独加一个按钮用于导入已处理过的图片，二次处理时限制算法，避免出现问题。将这个流程直接展示出来也利于用户使用

按理来说，二次颜色转换应该是没有任何变化的，因为输出的图片只包含了地图画可用色，二次导入的话，每个像素都必定能找到完全一样的颜色。

至于HSV嘛……我现在想通了，它就是这样，这就是正常效果，不是bug。

[Mifan-T]

按理来说，二次颜色转换应该是没有任何变化的，因为输出的图片只包含了地图画可用色，二次导入的话，每个像素都必定能找到完全一样的颜色。

但实际启用抖动仿色就可能出现各种奇怪的变化。二次导入应该作为一种正常操作，而不是野路子，所以优化流程是必要的，要避免潜在的问题

[Mifan-T]

至于HSV嘛……我现在想通了，它就是这样，这就是正常效果，不是bug。

只要启用抖动仿色，用其它算法其实也会有部分像素出现变化，只不过HSV是最明显的（不启用抖动仿色就和原图一样）
我不太清楚这是不是一个bug

[ToKiNoBug]

按理来说，二次颜色转换应该是没有任何变化的，因为输出的图片只包含了地图画可用色，二次导入的话，每个像素都必定能找到完全一样的颜色。

但实际启用抖动仿色就可能出现各种奇怪的变化。二次导入应该作为一种正常操作，而不是野路子，所以优化流程是必要的，要避免潜在的问题

但是技术上，二次导入也不可以绕过转化图像这一步，因为每个颜色都必须换成地图画可用的颜色，这是地图画的死要求。我刚才试过了，抖动+二次导入的图片，在其他算法的效果下都几乎没有变化，除了HSV。

[ToKiNoBug]

至于HSV嘛……我现在想通了，它就是这样，这就是正常效果，不是bug。

只要启用抖动仿色，用其它算法其实也会有部分像素出现变化，只不过HSV是最明显的（不启用抖动仿色就和原图一样） 我不太清楚这是不是一个bug

emmmmm，我要不干脆隐藏掉HSV吧

[ToKiNoBug]

另外我觉得SlopeCraft采用一步一步的操作逻辑也不是很好，我现在更倾向于多个选项卡的模式，不限制用户翻页，只禁用不能点的按钮，就像VisualCraft那样。（分步操作的逻辑仍然存在于代码里，但是在界面上，不根据步骤限制用户翻页，只根据步骤限制用户按按钮）

[Mifan-T]

但是技术上，二次导入也不可以绕过转化图像这一步，因为每个颜色都必须换成地图画可用的颜色，这是地图画的死要求。我刚才试过了，抖动+二次导入的图片，在其他算法的效果下都几乎没有变化，除了HSV。

其它算法还是会有部分像素发生变化，这肯定还是违背了精修的原则（我经常用光追渲染引擎，所以对噪点确实比较敏感）
我的想法是：增加二次导入按钮，选择图像后，自动使用RGB+（不启用抖动仿色）算法转换，并将转换后的结果添加到缓存区
（当然我这种假设是建立在缓存区的数据能被后续操作调用的前提下）

[Mifan-T]

另外我觉得SlopeCraft采用一步一步的操作逻辑也不是很好，我现在更倾向于多个选项卡的模式，不限制用户翻页，只禁用不能点的按钮，就像VisualCraft那样

我也有相同的想法，用户自己翻页的同时也能了解整个过程

[ToKiNoBug]

这样就相当于修改了调色算法，二次导入无疑就覆盖了原始图像

[Mifan-T]

为了方便理解，我还是尽快把新版设计图发出来
导出时的逻辑为：调取转换颜色后的缓存-构建三维结构-导出相应格式的文件

当然，这些只是假设，如果目前无法实现，留空就好，我能做出备用方案

[ToKiNoBug]

为了方便理解，我还是尽快把新版设计图发出来 导出时的逻辑为：调取转换颜色后的缓存-构建三维结构-导出相应格式的文件

当然，这些只是假设，如果目前无法实现，留空就好，我能做出备用方案

我看到这个图了，不过可能有个地方我没有说清：内核是可以暂存三维结构的，但因为内核只能暂存一个图，所以只能暂存一个三维结构。
不过只要设计了缓存，那就完全可以用缓存来存储转化后的图像和三维结构，持有多个图片、多个三维结构的问题反而解决了

[Mifan-T]

这样就相当于修改了调色算法，二次导入无疑就覆盖了原始图像

我觉得这不会是一个问题，在有项目池的情况下，除非有重名，否则是可以允许导入的图像和原始图像同时存在的。而如果没有项目池，目前的主操作面板也只能进行单件操作，导入图像必定覆盖原图像
而且新增“二次导入”按钮只是让内核自动转换，自动转换后锁死转换按钮，防止用户搞出问题，并没有修改算法

我看到这个图了，不过可能有个地方我没有说清：内核是可以暂存三维结构的，但因为内核只能暂存一个图，所以只能暂存一个三维结构。 不过只要设计了缓存，那就完全可以用缓存来存储转化后的图像和三维结构，持有多个图片、多个三维结构的问题反而解决了

那这样也挺好，理论上可以统计队列中的总材料表了。而且我在V1.1中有个疏忽的点：需要构建三维结构查看结构尺寸。我会想办法优化的

[ToKiNoBug]

我觉得这不会是一个问题，在有项目池的情况下，除非有重名，否则是可以允许导入的图像和原始图像同时存在的。而如果没有项目池，目前的主操作面板也只能进行单件操作，导入图像必定覆盖原图像 而且新增“二次导入”按钮只是让内核自动转换，自动转换后锁死转换按钮，防止用户搞出问题，并没有修改算法

这样会不会让用户觉得费解，或者误以为是bug？

我倒是觉得，可以把逻辑设计的简单点，让“二次导入”仅仅只覆盖原图、修改调色算法，不禁用任何控件（这样界面代码写起来容易很多很多）。甚至再简单点，把二次导入改名叫重新导入，让它根本不关心一个图被按了多少次，只是机械的覆盖原图、调色算法改为RGB、禁用抖动。

至于用户在二次抖动之后修改调色算法的操作，可以弹一个警告的窗口，其他像普通的图片一样。

我认为这样写，界面逻辑简单些，更不容易出错

[Mifan-T]

这样会不会让用户觉得费解，或者误以为是bug？

我觉得倒不一定会让用户费解，只要有充足的设计，引导就不成问题（例如在项目池中相应的图片上加一个特别的标志）

我倒是觉得，可以把逻辑设计的简单点，让“二次导入”仅仅只覆盖原图、修改调色算法，不禁用任何控件（这样界面代码写起来容易很多很多）。甚至再简单点，把二次导入改名叫重新导入，让它根本不关心一个图被按了多少次，只是机械的覆盖原图、调色算法改为RGB、禁用抖动。

至于用户在二次抖动之后修改调色算法的操作，可以弹一个警告的窗口，其他像普通的图片一样。

我认为这样写，界面逻辑简单些，更不容易出错

至于“二次导入”的最终名称先待定吧，毕竟也可以导入用色板从零画出的图像，“重新导入”也不太贴切

虽然二次导入的图片没有再手动转换的必要，但你的方案在代码上更容易实现，也确实可以作为其中一个选项

[ToKiNoBug]

我觉得项目池图像中的标志可以借鉴一下emoji 下图就是用emoji拼凑出的几个方案，可以挑一个组合

我觉得组合4比较好，你觉得呢？ 最后选出的方案会用在正式版概念图中

另外，能告诉我标志需要的图像尺寸吗？这些emoji肯定是要转换成图像的

我不太理解“手动涂色版”是什么意思。另外我觉得1和4的已转换标识都不错，但未转换标志不应该用红叉，这容易被理解为错误。可以用无图标表示未转换。

如果出图像的话，用32*32的图像就可以了，不用太大

[Mifan-T]

我不太理解“手动涂色版”是什么意思

因为emoji的减号只有灰色，手动改色后就失去了文字信息（不过反正都要转图像也无所谓）

另外我觉得1和4的已转换标识都不错，但未转换标志不应该用红叉，这容易被理解为错误。可以用无图标表示未转换。

我觉得依然需要个标志来提醒用户有图像未转换（甚至应该在项目池下注明未转换的数量？不过可以先不搞，太复杂了bug会满天飞）
我再找找看有没有图标能表示“等待转换”

[ToKiNoBug]

我觉得依然需要个标志来提醒用户有图像未转换（甚至应该在项目池下注明未转换的数量？不过可以先不搞，太复杂了bug会满天飞） 我再找找看有没有图标能表示“等待转换”

找不到就算了吧

[Mifan-T]

这可能是最后一版设计图

最后进行了一波梳理和修正，你再检查一下，如果没有问题就定稿了
大多数需要注意的点都标在图上了

顺便附上xmind文件，以便今后使用
操作逻辑改进V1.3.5.xmind.zip

[Mifan-T]

地图图片是加上阴影的版本 可以自行缩放（缩放时别用差值）

tips则是纯文本，前面加了个emoji“💡”

我有点失误，这些素材还需改进，最终版会和正式版概念图一起放出

[ToKiNoBug]

这可能是最后一版设计图

最后进行了一波梳理和修正，你再检查一下，如果没有问题就定稿了 大多数需要注意的点都标在图上了

顺便附上xmind文件，以便今后使用 操作逻辑改进V1.3.5.xmind.zip

谢谢，我已经按照设计图开始写新的界面了，你可以在github actions上找到最新的预览版，这里面的SlopeCraft就是正在开发的预览版

[Mifan-T]

我概念图好像更得太慢了，有些改动并没有同步上来＞﹏＜

为了去除冗杂功能，导出界面中不再进行图片预览（b2-3中的预览框只是为了占位），所有对图像的操作都在“颜色转换”界面进行。导出界面空余的部分会加上点装饰

我目前在进行素材的修饰和规格化处理，正式版概念图应该快了

[ToKiNoBug]

我目前在进行素材的修饰和规格化处理，正式版概念图应该快了

我现在已经搞定了转化缓存的写入和读取，不过因为没有图标的图片，还不能在任务池里显示标志

[Mifan-T]

正式版概念图

概念图的排版不一定是最优，仅做参考
如果有问题也可以指出来







可算是赶出来了（/TДT)/

素材包：

如果可以，还是尽量注意一下图片的缩放策略
素材包1.0.zip

[ToKiNoBug]

可算是赶出来了（/TДT)/

辛苦了，用ps拼出来这么多图，不容易啊

[ToKiNoBug]

如果可以，还是尽量注意一下图片的缩放策略

不用太担心，qt给了平滑插值（疑似双立方）和快速插值（疑似双线性）两种方式，如果都不好，我还可以手写一个最近邻插值，这反而是最简单的

[Mifan-T]

不用太担心，qt给了平滑插值（疑似双立方）和快速插值（疑似双线性）两种方式，如果都不好，我还可以手写一个最近邻插值，这反而是最简单的

我其实指的是窗口缩放时图像的填充策略，可能会比较麻烦。不过其实也可以不缩放装饰物（毕竟大多数软件就是这么做的）
至于插值，我觉得对于像素画装饰物和预览窗口来说，最近插值是最好的。因为这可以保证像素边缘的锐度，并且让低像素图像也能正常显示

[ToKiNoBug]

我其实指的是窗口缩放时图像的填充策略，可能会比较麻烦。不过其实也可以不缩放装饰物（毕竟大多数软件就是这么做的） 至于插值，我觉得对于像素画装饰物和预览窗口来说，最近插值是最好的。因为这可以保证像素边缘的锐度，并且让低像素图像也能正常显示

我已经实现了。我发现实际显示的时候完全可以不用缩放图标，我只需要把原图缩小到符合任务池的宽度，然后把图标画右下角就完事了。

[Mifan-T]

我已经实现了。我发现实际显示的时候完全可以不用缩放图标，我只需要把原图缩小到符合任务池的宽度，然后把图标画右下角就完事了。

看起来不错，期待最终的效果

↑图中其实有个很明显的问题(^・ω・^)

[ToKiNoBug]

看起来不错，期待最终的效果 ↑图中其实有个很明显的问题(^・ω・^)

这是怎么出现的？我复现不出来

[Mifan-T]

这是怎么出现的？我复现不出来

切换到未转换的算法时，项目池中的图标依然显示已转换
这难道不是功能不完善导致的问题吗，不像是bug

[Mifan-T]

目前的设计是：切换到相应的算法时，两个项目池显示相应算法缓存的状态

[ToKiNoBug]

目前的设计是：切换到相应的算法时，两个项目池显示相应算法缓存的状态

太复杂了，怕无限递归，就偷懒了。现在试着修了一下

[Mifan-T]

但现在又出现了一堆新的问题，图标切换并不符合逻辑，有些操作甚至还会导致崩溃
我觉得现在并不是反馈bug的好时候，因为我随手就能找出一被窝的bug，你先继续完善吧(´･_･`)

[Mifan-T]

虽然我不知道算法切换在代码上怎么实现，但逻辑上应该是这样的

各种算法能够来回切换，而且每次转换都是在往缓冲区内填内容，未转换的算法会越来越少

不过要注意前置选项（地图画配置）有更改时，原有的缓冲区内容可能无法再使用，需重新转换

[ToKiNoBug]

不过要注意前置选项（地图画配置）有更改时，原有的缓冲区内容可能无法再使用，需重新转换

目前能做到这个，因为缓存的路径包含了颜色表+地图画类型+游戏版本的哈希，哈希不一样路径就对不上，没有缓存就认为没有转化过

[Mifan-T]

我试了下正式版，bug确实少了很多，感谢大佬的付出

.

.

.

.

但还是有些地方不太对劲：
1.切换算法后，项目池并不会自动刷新状态，必须一个一个选中才能刷新图标，这也会导致已转换项目池中显示的图像不同步

2.如果原先选择的是非纯文件地图画、并且导出界面选中的是非地图文件，则地图画配置中更换为纯文件地图画后，导出界面按钮会自动切换到地图文件，但界面并不会刷新，需要再点下按钮才能切换界面

3.“预览压缩效果”窗口只能放大，无法缩小

4.“预览材料表”只会显示最后转换的图像，和选中的图像无关
“预览压缩效果”也有类似的问题，唯一的区别是选中未构建的图像会弹提示

这些是目前发现的bug，可能还有些没被发现，我也不知道为啥这么多X﹏X

[ToKiNoBug]

这些是目前发现的bug，可能还有些没被发现，我也不知道为啥这么多X﹏X

就是因为逻辑太复杂了，所以先少写点，避免出现死循环崩溃，我慢慢完善吧……

[Mifan-T]

就是因为逻辑太复杂了，所以先少写点，避免出现死循环崩溃，我慢慢完善吧……

确实有些道理，我今天就玩崩了一次
不过这意味着这个正式版非常尴尬，我猜有很多人会对这个项目池一脸懵逼😂

[ToKiNoBug]

最近列出的4个bug均已修复（https://github.com/SlopeCraft/SlopeCraft/release/latest

[VinsonFather]

我个人觉得可以增加一个功能，就是增加方块可选，有一些颜色比如白色，他是强制选择的，可是可以选择的只有蜘蛛网或蘑菇柄等一些很难获得的东西，如果有这个功能，那请忽略。

[VinsonFather]

同时Windows版本建议适配arm的版本，之前Mac版本不可用，所以只能用虚拟机，但是程序在构建3D时崩溃了，可能是因为转译的原因，要解决这个问题，只能选择原生适配arm，但现在也许不用适配，因为bug解决了

[Mifan-T]

我个人觉得可以增加一个功能，就是增加方块可选，有一些颜色比如白色，他是强制选择的，可是可以选择的只有蜘蛛网或蘑菇柄等一些很难获得的东西，如果有这个功能，那请忽略。

@VinsonFather
你应该是指禁用颜色吧？
除了透明色，所有颜色都是可选的，取消勾选这个启用就可以禁用颜色了

[VinsonFather]

oh，那就把arm虚拟机崩溃的问题就一下吧

[Mifan-T]

oh，那就把arm虚拟机崩溃的问题就一下吧

@VinsonFather
这个问题其实建议另开一个Issue（毕竟不属于界面问题），把详细的崩溃过程发出来，以帮助解决问题