Zhang C

And I wonder why it need 7.23GiB memory? Can anyone explain it?

@fujimotomh Thank you for your reply. But I wonder how can I modify the code as I'm just new to tensorflow? I just tried to use `outputs, last_state = tf.nn.rnn(cell,...

@fujimotomh Oh, it works! Only 1.1G usage of GPU memory! Thanks for your advice!

1. 首先我并不反对3.0开发，我的原话是“可以尝试，但不期待”，即能有更好，实在没有也不会影响什么。 我不看好的原因是，运行时和编辑器不同，从各个意义上来说都是一个非常精密的系统（包括且不仅限于事件流、录像回调链等等）；推翻再重新搞一套新的也许会导致把坑全踩一遍。 另一个是用于操作性问题。网站绝大多数用户都是玩塔的，尤其是手机玩塔，对很多东西都容忍度更低；造塔者其实没多少，他们对于变化的容忍度更高，所以对编辑器动刀子无所谓，但是对运行时动刀子需要谨慎。 与之替代的，我更建议直接当前v2.x运行时逐步推进，包括大地图、Sprite化等的开发。终究是会找到方法解决的，你看当前发展到v2.7解决了多少问题。 2. 你所担心的这种竞争本身毫无意义，因为它们的“产出”是同一个东西，同一套运行时。换句话说，玩家在网站上玩的时候，是无法分辨到底是哪个编辑器做的，何谈竞争之说？因为运行时和产出一致，造塔者随意在两个编辑器间切换也毫无问题，更多的选择，完全的兼容性，何谈矛盾来源？ 3. "2.x很可能是仅有一个最佳实践的，所以，只要一个编辑器就足够了" 未必。事实上，对作者来说，样板的本质仅在于`project`文件夹；换句话说，只要产出是一致的，不管你使用v2.x的当前编辑器，新编辑器，还是VSCode，甚至是写个python编辑器，都是等价的。 我仍然认为，编辑器和运行时不应该嵌入太深，不能出现某个插件写崩了导致整个编辑器都打不开的情况（这也是v2.x编辑器遗憾的地方之一）。难道代码写的有问题就导致打不开VSCode了？最佳情况下，编辑器甚至完全都不应该读libs文件夹（最坏情况也是以``内置引入），即使是脚本编辑和插件编写也应该是只读而不执行的。 所以我很遗憾，如果之前的pre-alpha是基于v2.x的运行时，其产出是能被当前运行时所接受的，那现在也许beta都出来了。

补充一个很简单的例子： 只要用户随便写错了什么东西，哪怕是打错了怪物ID：  保存再刷新，编辑器就崩了，此时就必须开文件处理，别无他法。  这很合理么？非常不合理。你见过哪个程序的源代码写错了导致整个VSCode打不开的？这也是v2.x编辑器当前最大的问题和遗憾，没有之一。这也是我为什么想要一个新的，独立的，不依赖于运行时的，不执行脚本编辑和插件编写的编辑器。 事实上，编辑器的产出目的只有一个，project目录；这些东西真的都是JSON格式的纯数据（唯一区别可能就是getSpecials）；所以完整执行一遍全部的脚本和插件本身就是非常非常不合理的行为；哪怕开VSCode手动编写可能都不会出现这种情况。 我想说的，与相对已经完善的运行时不同，当前编辑器确实不是最优解，问题很大，限制很多。但是它已经定型了，没办法修改了，所以最佳的实践应当是跳出现在的编辑器框架，在考虑如何保证project兼容性的情况下，弄一套全新的出来。

暂时不再考虑这个问题，未来有需要再重启。