是否可以用于游戏引擎

• 我已确认 Echo-Live 近期没有类似更新。
• 我已确认近期没有其他人提出类似提议。

提议描述

试试霞鹭https://github.com/lxgw/LxgwNeoXiHei-Screen

参见： https://github.com/users/sheep-realms/projects/3

问题描述

有对话框处于不可见状态但已被加载过（尤其注意为不同场景分别添加的对话框），可能导致计时器阻塞。当开启打印音效时，表现如下：

1. 打印音效有时会在播放完成后一段时间内再播放一次，长度和上次发送的消息一致。
2. 极端情况下，打印消息会持续播放。

问题原因

页面不可见时计时器可能会失效。

解决方案

增加休眠机制。

备用解决方案

1. 在 OBS 中为对话框浏览器源勾选 “不可见时关闭源”。
2. 不要在不可见状态下发送消息。

• 我已确认 Echo-Live 近期没有类似更新。
• 我已确认近期没有其他人提出类似提议。

有关 #3

首先, #3 中并没有提到跨设备使用editor

#3 中有提到开发后端的缺点, 其一是用户使用难度高, 鉴于nodejs也可以打包发布, 应该不会导致用户使用困难

引入后端还可以让其他开发者直接使用暴露的API, 甚至不用阅读Echo-Live的任何代码, 这会给开发灵活性带来提升

提议描述

目前live和editor必须在同一个设备上使用, 这对没有多显示器、或者游戏强制全屏的用户来说体验比较糟糕

如果可以在其他设备（例如手机）上使用editor, 可以大幅提升用户体验

实现方法

使用node,js搭建简单的后端, 将消息经由后端进行处理
局域网内的设备即可使用浏览器直接访问前端页面, 调用API发送信息

问题描述

Unicode 辅助平面字符（例如 emoji）在打印时会被拆分为 2 个打印循环，在完整打印前字符会显示为问号占位符。

问题原因

Unicode 辅助平面字符占用两个字符空间，而 Echo 会将每一个字符拆分打印。

解决方案

使用 Spread 操作符分割字符，而不是 String.split 方法。

备用解决方案

1. 也不是不能接受。
2. 不使用 emoji。

• 我已确认 Echo-Live 的最新发行版本中依然存在此问题。
• 我已确认近期没有其他人提出类似问题。

问题描述

我在输入时试图在一行文本中间通过一串空格（tab也试过）来将一行文本分隔为两小段，但是在插件中实际只会输出一个空格（如下文截图所示

这是我的start.js文件内容：

const data = {
    "username": ".", 
    "messages": [
        {
            "message": "「测试文本                  测试文本」",
            "data": {
                "printSpeed": "30"
            }
        }
    ]
}

我期望输出的：

「测试文本 测试文本」

实际输出的：

「测试文本 测试文本」

期望效果

可以正常输出一长串空格

截图

解决方案

我不知道.jpg（
无论往里面输多————长的空格（或者tab），它都只会显示一个（

富文本编辑器没做完，所以隐藏了富文本编辑器。但是我突然意识到哪怕是纯手敲的代码也发送不出去，所以这个问题必须要解决。

如果您有发送富文本的需求，请改用轮询模式。

前端的能力是有极限的，我从短暂的前端开发生涯中学到一件事...... 越是整花活，就越会发现前端的能力是有极限的...... 除非超越前端。

咳咳，如题，Echo Live 在操作优化方面已经遇到了瓶颈，仅靠前端已经无法提供更友好的交互体验。为此，我设想了几种应对方案，但这些方案以我目前的能力是无法实现的。为此，我需要征集意见和寻求帮助。

这样做有什么好处？

Echo Live 有很多有意思的功能受限于纯前端网页无法实现，不过一旦有了后端或者直接开发成应用程序，这些功能都有可能实现：

• 消息与上一条消息之间的过渡效果。
• 联动 Live2D 动作。
• 模块化设计，让用户根据自己的需求只需动动鼠标就能选择所需的模块。
• 更丰富且更规范的扩展包功能。
• 如有需要，可自动获取更新。

方案列表

先让我们来看一下现有的方案吧。

方案 A：开发后端

通过架设本地服务器来实现跨浏览器的网页通信，用户只需在浏览器网页中点击发送按钮，数据就会通过服务器向 OBS 内置浏览器中的网页传递数据，以此更新对话框内容。基于我的知识储备，优先考虑 Node.js 或 ThinkPHP 编写后端程序。

优点：

• 不需要大幅度改动，甚至还能优化现有的前端架构。
• 对我而言已有积累一些的开发经验，开发效率不会受到太大的影响。

缺点：

• 可能会对不熟悉本地服务器的用户造成困扰。
• 如果使用了框架，可能会产生大量文件，甚至存在冗余文件，增加了客制化难度。

方案 A.2：开发网站并上线运营

直接将后端程序部署到云端服务器，供用户使用。

优点：

• 对于直播用户而言是最优秀的解决方案（总不能断网开直播吧？），并且有成熟案例可供参考。

缺点：

• 容易受到外部因素影响正常使用。
• 客制化变得特别困难，这将彻底改变客制化的发展方向。
• 费钱。

方案 B：开发浏览器套壳应用程序

基于 Electron 或 NW.js 开发应用程序。

优点：

• 用户学习成本更低。
• 能整更花的活。

缺点：

• 可能需要大幅度改动现有前端架构。
• 可能需要改变被 OBS 捕获的方式，这可能会造成一些特性的丢失。（这个问题可以解决）
• 如果没有为客制化铺好路，将会严重阻碍客制化。
• 对我而言是从零开始，开发效率会受到很大影响。

方案 C：使用别的渲染引擎

目前来讲，这个方案全是缺点，没有这个方案。

以上就是我目前能想出的所有方案，欢迎大家提出宝贵的意见，如果能直接提供技术支持那是对我最大的鼓励，谢谢大家！

其他问题

在确定某一方案后，旧版的 Echo Live 会怎么样？

如果整体架构没有产生过大的变化，旧架构将会与新架构共存，供用户自由选择。反之，新架构成为新的分支，创建新的独立项目。