回來吧王女士我最驕傲的信仰😭😭😭 @"n0099"#1

@"n0099"#p36514 您忠誠的四葉tg殘部

tg群是维也纳的地盘里1群是现充人的地盘早已解体的流亡四叶没有容得下我的地方

@"n0099"#p36516 四葉tg殘部是您永遠的家

我局的是您和维也纳的家邀请链接？

@"n0099"#p36518 https://t.me/+TFrGbh04kXRjMzE1

@"n0099"#p36520 已第114514次宣告退葉

@"PeterBarofsky"#p36521 什么时候

回來吧王女士

n0099

yangbowen
您又不知道我什么时候会播
所以mechjeb是必备的没人会像原版那样手动微操发射对接
不装可选的Principia就还是原版的2体模拟
太阳系本来就比kerbol星系大得多要是dv还是原版那样您觉得合理？

yangbowen

n0099 太阳系本来就比kerbol星系大得多要是dv还是原版那样您觉得合理？

我当然知道从 realism 来讲真实的太阳系需要更多 Δv 。但是从难度平衡来讲我比较担忧。
它能给原版那个Q弹Q弹的结构力学也改 real 了么？

n0099

yangbowen https://github.com/KSP-RO/Kerbal-Joint-Reinforcement-Continued
FYI https://github.com/KSP-RO/RealismOverhaul/wiki/False-KSP-Lessons

yangbowen

n0099 https://github.com/KSP-RO/Kerbal-Joint-Reinforcement-Continued

唉，Unity

n0099

yangbowen
https://github.com/KSP-RO/RP-1/wiki/Am-I-ready-for-RO-RP%E2%80%901%3F
https://deltavmap.github.io/?system=Solar

yangbowen

总之我只能认为在基本的物理引擎都这样毫无 real 可言的前提下，天体大小、delta-v 之类的 real 不 real 意义不大了……
KSP2 他们也继续沿用 Unity ，不肯换引擎重写。假如抛弃 Unity 彻底重写我肯定买爆

n0099

yangbowen 然而KSP2开发商早已跑路，您现在去买相当于给g胖送钱因为没人提现

yangbowen

n0099 因为我又企图去玩 KSP （不是 RO ）然后又被火箭在发射台上无端爆炸搞得很沮丧而已

所以说物理引擎（特别是碰撞模拟）至今仍是 unsolved problem 吗？

yangbowen

n0099 您现在去买相当于给g胖送钱因为没人提现

不是给 Take-Two 送钱？
不过我对 Take-Two 印象不怎么好

n0099

yangbowen 您1级捆了一大堆固推？

yangbowen

n0099 您怎么知道
但是我开满 autostrut 了啊

n0099

yangbowen 因为RO里也不能Q值（动压）太大
什么事autostrut

n0099

yangbowen 就算发行商 https://en.wikipedia.org/wiki/Fictions_(company) 取了钱业已解散的开发商也拿不到一分

yangbowen

n0099 行吧，不过我本来也没打算买。而且对 Take-Two 没啥好印象。
话说刻板印象感觉名字叫某某 Interactive 的游戏公司好像都挺怎样的

yangbowen

n0099 什么事autostrut

就是部件的右键菜单里可以启用然后相当于自动添加 strut 的按钮，原版的
不过无所谓，我安装 Kerbal Joint Reinforcement Next 了

n0099

对于>256 字节的文件，对全文和尾部 128 位字节分别进行 xxHash3-128 然后拼接得到 256bit 散列和 SHA256 一次得到的 256bit 哪个更抗碰撞？用于命名用户上传的文件，另外加盐用拼接还是 XOR 方式更好？ https://v2ex.com/t/1145673

yangbowen

n0099 肯定是 SHA256 ，因为 xxHash 是非密码学哈希
即便不考虑这点，全文和尾部分别哈希然后拼接也是达不到两倍的强度的
拼接跟 XOR 的话， HKDF > 拼接 > XOR 。或者说，设计良好的哈希自己会考虑到（你拼接所产生的）输入的不同部分之间采用何种方式压缩。

n0099

yangbowen 然而v2ex帖楼主并不会看到您的回复
而那帖里顶多有人提到hmac但没人提到hkdf

yangbowen

n0099 v2ex帖

那也没办法，我平常也不逛 v2ex
你既然转发提到了我刚好就内容评论一下罢了

啊我说错，我想说的就是 HMAC 而不是 HKDF 。这个场景还犯不着 HKDF 。
另外 HMAC 好过拼接的主要原因就是它能抵抗 SHA256 之类的（采用非截断 Merkle Damgard 构造的）的长度扩展攻击。对于不存在这个弱点的哈希（比方说 SHA3 或者 BLAKE 系）来说用 HKDF 还是拼接就差别不大了。

总之是我我就直接 BLAKE3 了。安全性好，没 Merkle Damgard 的坑，性能也挺快。

n0099

yangbowen 您可以让我再转发过去
那为什么不用sha3而是sha2-256
https://github.com/Cyan4973/xxHash/issues/450

yangbowen

yangbowen 总之是我我就直接 BLAKE3 了。安全性好，没 Merkle Damgard 的坑，性能也挺快

BLAKE3 采用先进的树状构造（ Merkle Tree ）而不是 Merkle Damgard （MD5、SHA1、SHA2）、 Sponge （SHA3）之类的链式构造，带来一些性能和使用上的好处，比如易于并行计算（每棵子树的计算是独立的）、流式哈希（通过附带上层树节点上的值，可以在接收到完整数据之前就验证已经接收到的部分的哈希）等等。这些优点我是很欣赏的。

yangbowen

n0099 您可以让我再转发过去

不署名（或者以其它方式指向）到我的前提下你要是愿意转发过去我也没意见。比方说以你自己或者“我认识的某个人”的身份。
别无端引流就好

n0099 那为什么不用sha3而是sha2-256

SHA3 的设计使得在没有硬件加速的软件实现上，比 SHA2 慢不少吧。等到 SHA3 硬件加速普及了的话我也推荐 SHA3 。