Skip to content

Scripting

Jim Chen edited this page Jul 10, 2014 · 1 revision

Scripting 代码架设

The scripting module is somewhat independant of the CommentManager even though both share data in between and (likely) share the same stage (this is not required, for some cases separating the stage objects may be a better design).

代码引擎是相对独立于弹幕管理器的,虽然二者互相共享信息,和(有些情况下)共享同一个舞台对象。此维基页面將介绍如何正确架设scripting部分。

Terminology 词汇

  • Scripting Sandbox (代码沙箱):

    The scripting sandbox is an instance of the CCL Scripter. It provides methods to push code in to evaluate and methods of communicating messages into the scripting worker sandbox. Every new sandbox is independant though you can hook multiple sandboxes on the same stage.

    代码沙箱是一个CCL代码库的实例。它提供了最基础的“运行代码弹幕”和“与代码弹幕通讯”的功能。每一个沙箱都相互独立,并且有自己的Worker。一个沙箱一般只有一个Worker,虽然这个Worker有可能死亡而重置。你可以在同一个舞台上绑定多个沙箱。

  • Scripting Context (代码环境):

    The scripting context is a replica of the internal playground within the workers. This is where the shadow objects reside. Generally a sandbox will have only one context, although contexts may be serialized, possibly saved, halted or modified.

    “代码环境”是一个Worker内部环境的镜像体。这是所有的代码弹幕元件受控制的地方。一般来说一个沙箱只会有一个代码环境,不过理论上这些代码环境可以被压制,保存,冻结或者替换。

  • Kagerou Engine(陽炎引擎):

    The Kagerou Engine refers to the basic API running by default INSIDE the worker. It - paired with the recieving end Unpackers - controls the actual implementation of the API. In contrast to the Scripting Context as being just a runtime management circulatory system, the Kagerou Engine is the actual brains and motors of the Scripting Module.

    陽炎引擎是指运行于沙箱内的API实现。它和在沙箱外的解包器一起,组成了API的实际事项。和代码环境相区别的是,代码环境仅仅管理对象的创建与同步(一个循环系统),而陽炎引擎则是真正控制绘图和布置代码弹幕,联通API的大脑和肌肉。

Deployment 架设

Similar to how you can instantiate multiple CommentManagers. You may also instantiate multiple scripting sandboxes. This is done as follows:

类似于弹幕管理器,你也可以实例化多个代码沙箱。如下是方式:

var bscripter = new CCLScripting("__PATH__TO__WORKER.JS__FILE__", optional_unpacker);
cm.scripting = bscripter.getSandbox($canvas_dom_object);

Creating a CCLScripting instance is like initializing an API Set. The default Worker.js and Unpacker (Kagerou Engine) implement the BiliScriptEngine API. You may also start scripting contexts with different APIs and different Unpackers.

制造一个CCLScripting实例就比较像初始化了一个API集。默认的Worker.js和Unpacker们(也就是陽炎引擎)实现了BiliScriptEngine (BSE)的API接口。你也可以使用不同的Worker和不同的Unpacker创造同样基于“影子沙箱”的API接口(大部分应该都会是类似的接口)。

After instantiating the scripter, you can create new sandboxes that will run under this API set. This is done by calling the factory function getSandbox and passing in the stage DOM object you wish to bind to. You can bind multiple sandboxes to one stage. You cannot bind multiple stages to one sandbox.

在实例化了代码运行时实例后,你就可以对通过这个运行时获取新的沙箱。这通过调用getSandbox方法,并提供stage参数来告之沙箱它操控的舞台信息。你可以把多个沙箱绑定到一个舞台上,但是一般来说你不能绑定多个舞台给一个沙箱。

To make it work well with the CommentManager, we can simply set the scripting sandbox to the scripting property of the CommentManager.

让以上部分都能和弹幕管理器一起工作,我们只需把弹幕管理器的 scripting 属性设置成沙箱即可。当然根据情况还可能需要发送一些状态信息/回调函数。

Clone this wiki locally