isee
isee
public class AutoAttacksVO{ private List attacks; } public class AttackResultVO { ``` private long attackId; private List bombs; ``` } public class BombVO { private int hurt; } like this
you can use this class take a test
Although simple point would be better, but some of the hierarchy is a must
your java-proto-generator is very helpful,I do not know that there is no official solution.
无法100%复现,可能跟服务端有关,但是也是因为更新了客户端代码为最新的出现的,什么都没改.
连官网也会有这种偶发提示 I (62491) Application: STATE: connecting I (62541) MQTT: Session ID: a9b4f644 I (62541) wifi:Set ps type: 0, coexist: 0 I (62541) Application: STATE: listening I (65571) Application: STATE: speaking...
我发现 在一些情况下 播放声音就会错 然后客户端卡死PlaySound(Lang::Sounds::P3_SUCCESS); 这个应该算是bug吧 void Application::ToggleChatState() { Schedule([this]() { PlaySound(Lang::Sounds::P3_SUCCESS); }); }例如在ToggleChatState 方法里面加上一个提示音的功能 W (195131) Application: Too many audio packets in queue, drop the oldest packet W (195201) Application:...
随便一个开发板 都能复现,void Application::ToggleChatState() { Schedule([this] { PlaySound(Lang::Sounds::P3_SUCCESS); }); 像这样在ToggleChatState 方法里面加上一个播放声音方法就复现了
很难复现,但是有另外两种情况. ToggleChatState方法里面 要是这样播放声音 100%卡机 1. PlaySound(Lang::Sounds::P3_SUCCESS); 2. Schedule([this]() { PlaySound(Lang::Sounds::P3_SUCCESS); }); 这样播放声音 不会卡死 但是声音不会被完整播放, 应该是切换状态清理掉了音频播放,这里有个问题是 这种本地声音 是否应该独立出来不受状态切换和对话影响?
服务端自定义唤醒词本质就是服务端一直解析 效果是能达到但是变味了.不是离线唤醒词.外挂的话应该也没问题, 乐鑫官方内置了那么多的唤醒 为什么不搞几个中性词