sunyink

Results 13 comments of sunyink

私下觉得,假设程序都能实现情况下,为符合条件的圣遗物上锁方案更好。这是程序以外的问题,因为无法确保融掉的圣遗物“真的”是使用者想融掉的,我担心引来不必要的问题。(带锁的不要动,不带锁的可以比较放心的手动去融如此可以?)

晚上好,感谢您回复了我的建议,我也花了些时间思考。 首先从回复中第一段【存档】开始表述: 我认为存档这个功能,很有实际操作性。不过留心,若是直接切换,觉得各存档之间可能发生,库存数难以同步、各存档的需求数缺乏联动互相抢夺另一个存档的资源。感觉这个功能,非常适合有多个账号或者共用电脑。 其实我原来的想法来源....您也许听说过会计,会计有个概念叫“会计科目”的:"一级科目"和他的“子科目”。二者其实是集合概念,"一级科目"一定包含全部n个“子科目”。 请允许我啰嗦地用“银行存款”举例(左边部分): 可以看出,在只有2个层级情况下,所有2层级必定被包含在层级1中;他们同时存在与同一个数据库中,层级2嗯....其实只是把100颗豆子进行了,一份80个、加一份30个的摆放。 然后转译到我们的系统中(右边部分),如右图中。因为1层级的“需求数”含义是各个计划的汇总,请玩家编辑好各自子计划数量后由公式带出即可,故不应该被编辑。而1层级“库存数”含义指玩家的全部库存,库存我觉得无法人为作划分,故应只在此一处可编辑。如此即可解决前文的“觉得各存档之间可能发生,库存数难以同步、个存档的需求数缺乏联动互相抢夺另一个存档的资源”问题。 我开始所设想的“标签页”其实就是“层级1:合集”、“层级2:计划1”、“层级2:计划2”...等等(标签页体验起来确实和chrome的同窗口多标签差不多)。 然后,我就能回复第二段,关于 另外,若需要「将多个项目中的材料重复情况也纳入最优方案的考虑」的话,可能会引入一个问题:区分「是项目A还是项目B需要多少资源」变得比较困难。 物流统计的优势,是建立在统括数量后计算上才有意义的,所以应该也必须只对层级1的需求合计数为目标去计算,不过关于计算结果的分计划表示,我觉得按“关卡次”为单位会很钻牛角尖,如果我们只是提示他个数呢?在复杂点的例子中:我们给出的结果中会有好几处关卡刷“研磨石”,有3-3,也有7-17;我们分别给出了总括需要打的次数,然后只需要提示一下’你的计划A,要用研磨石9个‘(旁白:我现在信息都告诉你了,具体怎么刷,你自己决定,反正我认为刷完两种关卡到规定数量,你的全部计划都大功告成)。 实操继续下去的话,按我的习惯,我会每次结算截图,然后用数据统计“截图识别”帮我汇总都刷出些什么材料,以此去更新层级1的“库存数”(狂点“+”号环节)。此环节后,若时候切换到“计划1”的标签页,当[“需求数”

> 楼主找到解决没?我没编译turbo acc,但在启动日志里也发现有关于offload的信息,且也发现samba在10M以下。 换了个官方源。但NSS对高通路由很重要,不然外网转发只有300M。

> 外网访问 lede 是 IPv6?还是 IPv4,有相似的问题 ipv4的,很离奇。

我暂时换成官方源了,然后官方源转发好像有问题,500M下行经常卡成只有300M。

还在排查。我发现openclash的内核报错也会计入 系统的内核报错。现在换了老内核,持续观察一段时间。clash真的是反人类。

R7800,+1,编译了无数次原来是这个原因.....

[re2_framework_log.zip](https://github.com/user-attachments/files/15617700/re2_framework_log.zip) [re2_fw_config.zip](https://github.com/user-attachments/files/15617708/re2_fw_config.zip) If I can help, that would be great.