【随手写写】一些乱七八糟的东西和坑.

z没有控制台.
z的编码需要使用Unicode否则无法使用中文.这一点比较麻烦.
z使用的tjsvm依然没有处理tjs上各种闭包问题.
例如如果你类内某个参数跟全局某个类同名.那么可能会使用这个参数和那个类执行两次.
又比如你在类内写了个类.你会发现这东西简直GG.所有的继承都需要写完成路径才能正确继承
z的rect坐标就是拿来反人类的.你会发现那东西是x,y,x+w,y+h
z的ImageFunction使用的就是这套rect的坐标...并且这东西总会出现一些莫名其妙的BUG
tjs对Layer和Bitmap的asgin基本就是个坑.你会发现这东西解锁总会存在各种BUG
ImageFunction依然没办法对单个Bitmap直接进行运算并将处理结果赋值到该Bitmap
z的解析器支持变更上下文.而2不可以.这让z可以更灵活的让你利用tjs来创造自己的解析器.或者更灵活的读取一些数据/成员属性.挂载脚本等等.
但这毫无疑问会让脚本变得混乱.另外需要导入一大堆概念.我后面会说.谨慎使用.
z的Font与2有一些细微不同.不过没什么卵用.
z的路径与2并没什么区别.所以手动管理路径就需要对应的一套东西.例如引入相对路径的概念.("../Data/System/Initialize.tjs");
这样即使变更了游戏的文件夹路径.存档文件也不会失效.
同时需要对路径进行处理.这需要拆分每一级路径并且检测其各自是否存在xp3包.如果有需要将其替换.因为/和.xp3>无法通用.但保存时需要存上面那个格式.
z依然没有修复Sound和Video的某些BUG.例如Sound的长度依然需要先play().而这两个的某些事件都是作废的.属于过时API.....
匿名函数是个好东西.但是有的时候需要搞清楚返回的结果到底需不需要保存.有的情况下直接作为参数会使返回的结果丢失
z1依然是TVP.z2还没有能运行的稳定版本.

先说一些对于之前那个简单tjs的补充.
上下文的概念懒得解释.kr的默认上下文是global.在读取文件或解析字符串脚本时可以变成上下文.
在读取文件时.可以先写一个列表文件.因为读取逻辑基本是不会变的.但有时候需要先制定列表文件的规则.
tjs中存在一大片的运算子.但是有一些反正我是从来没用过.但是需要注意的依然还是==和===的关系.如果是数字的0的话.直接==是会被判定为void的
对于一个步骤的多个判定.并且只需要完成一个就可以返回或者结束本次动作来讲.可以使用while(1){}.通过break来跳过后续的判定动作.
kr的Timer是个好东西.反正Tigger是没有Timer好用的....并且例如闲时执行.解析器wait.粒子.移动.渲染循环等等乱七八糟的东西全是Timer.所以对Timer进行一定的封装是最好的.
tjs来讲的话.各种调用的时候出现问题可能行数或者文件位置都不会特别准确.需要特别注意.并且猜测到底是哪里出现问题.最简单的话就是注释一部分刚写的代码.并且debug来查找问题.
在继承无法new的类时.你就拥有了一个无法new的类.但你仍然可以对它进行各种操作.因为要的其实还是它的构造函数...
这里解释一下TJS2到底是个什么东西...tjs2实际上是由数个类型合并在一起的tjsVariant.并且在C++代码中写了一大堆转换逻辑.一个tjsVariant当中包含所有tjs2所支持的类型.因此你给它赋值什么它就是什么.....但一个tjsVariant同时所保持的值只有一个.
而负责解析tjs脚本.我没记错的话是tjsScriptBlock和tjsScriptsVache吧...而tjs的实际运行环境就是TJSVM.一个虚拟机.因此在tjs中并不需要include来注册.因为他们使用的是一个共同的域.
tjsz对tjs2的变更上并不算太大.就不多说了..

😂冰儿的领域

虽然Layer直接来做按钮是比较方便的情况.但是实际上在kr里效果比较好的按钮.例如ex2之前的asd按钮.平滑滚动的按钮.UI进场乱七八糟的按钮……基本上都是透明的……因为方便切逻辑.不干扰画面.同时会降低出错概率
所以透明按钮只用到了层的很小一部分功能.并且有些时候是真的烦人……解决方案比较麻烦.看看就好
首先说明的是……在z里如果不是一定要用Layer显示.粒子的渲染效率不够.还有Video之类的问题……我都要扔了这个Layer了……
那么基本思路还是改变Window的设置.重写Window的事件.利用自己写的循环来进行检测.同时对高度一类的东西进行处理.顺带也可以把鼠标坐标.keymap一类乱七八糟的东西都写了……
具体的结构不多说……反正没什么用.总之要么从win获取热区要么向win注册热区.看个人
另外一些比较麻烦的问题.例如缩放的话.在win直接丢一个比例.然后把窗口大小改变的那个事件改了.渲染的时候直接乘算就好
当然我这里是直接对渲染结果放大……你愿意用layer各种算坐标我也没意见……
另外对于无边框等等一类操作.直接挂一个属性然后在win内封装还是比较舒服的……但是的确比较麻烦就是了…………

关于存档以及逐条跳转.需场景支持.需要标准规则支持.需要场景物件列表支持.
虽然要一大片的支持.但是实际上这东西的结构很简单.
需要场景支持主要是需要将每个场景根据Scene将存档数据内容错开..同时使每个Scene的存档数据在运行该场景时成为该场景的数据包.也就是删除了tf的概念(同tjs默认).把原本的tf和f合并为一个Scene数据包.
在场景内可以通过根访问全局数据和其他场景的数据包做引用或修改等等.这样就将全场景的数据相对独立化了.
那么存档也是依据此来的...
该存档的结构是[ StartSave , ChangeData , EndSave ]，之前提到的需要标准规则和物件列表也就是这个原因.这需要对场景中变化或需要进行存档的数据进行集中编集.并且将其合并为一个包.
而后通过StartSave或EndSave直接向下或向上合并.直接取代而不是通过改变的操作去变更数据.会更加的稳定.也不需要太多其他的设置.就几个事件接口的事...
目的就是能够让历史记录能运用的同时.实现逐行跳转的功能.并实现存档数据的最小化.但是具体如何处理这些数据进行还原.需要存档什么数据.什么时候存档这些数据.那就不关我事了..

在kr中导入预制体.并通过tjs特性来折中Prefab和Actor的一些东西.但是实际上也就是通过函数进行class封装.这个东西在纯tjs上用处不大
对于kr来讲.由于没有IDE.对于预制体的调试会变得特别麻烦.尤其对于打包预制体.和细微数值调节一些乱七八糟的东西...
但所幸的是kr上使用预制体的情况.可以在继承后直接将某个预制体内的方法进行直接替换.如果需要的话.再通过Parent来调用父预制体的动作.
那么如果对父预制体进行改动的话.会变更所有的子预制体动作.这一点的应用会变得特别广泛.因为在kr中tjs不会对你的预制体进行类型限定.你可以拿它来做任何东西.只要你不担心可读性归零.
预制体打包最麻烦的就是需要进行一次解析.来区分普通数值和函数动作.以及最终解析合并.并单独处理构造函数.而区分数值则需要标记.
【说句题外话.如果是渲染循环挂组件的那种方式.对数值标记的话.如果有IDE理论上也是可以进行快捷调整的.但是就算标记处理完也需要对应的东西来处理后续的结果和显示...这就很烦人了- -】
在打包后.预制体内会自动调用所有需要的东西.并最终返回一个结果.但是上面也说了.这东西在纯tjs上用处并不大.
主要还是针对我之前说过的.自定义解析器所使用的脚本.这些脚本组合起来的预制体需要经过一大片的解析.替换.才能返回一个最终结果.而这东西是无法被eval和exec所直接执行的.但直接写起来来讲会节省一大片的东西.毕竟z给了你条件.引擎支持.不用白不用- -

但是前提上来讲，实现这个该死的解析器并且让他能够切换解析器来应对一些资源脚本..需要大量的基本代码.不多.也就那么几百kb.kag那种简单一些的语法另算...
因为是利用tjs写自定解析器.所以你可以自己规定他的语法.用途.逻辑等等一些乱七八糟的东西.并最终通过解析进行执行.
KAG的语法来讲基本就是[maintag tag=xxx]相对于功能.这个东西更多只是调用一些已经封装好的东西而已.
我这个**到死的OFS从一开始就是打算嵌入到tjs去用的.然后写着写着发现资源脚本和执行脚本还是应该分开...所以又加了一部分东西上去...
所以基本语法就变成了.
资源代码片段:这种东西会根据fragment把中间的scripts代入到指定命名空间(一个dic)中的代码片段那个值.供后续的包含或解析调用等等.
当然.除了保存资源片段以外.还有屏蔽一些底层API的作用....比如那个该死的ImageFunction
在解析资源片段时.会对scripts进行简单的区间闭合检测.但不会对其进行具体的解析执行.
namespace<<< fragment<< scripts >> >>>
执行代码片段:这种片段不会对命名空间和片段进行解析.换句话说就是.命名空间无法作为上下文进行使用.没什么用
执行代码片段可以直接嵌入tjs使用.也可以完全使用执行片段来调用功能.另外通过各个解析器间的不同规则.可以灵活的挂载各种资源.代价是让复杂度增加.
另外因为嵌入的原因.OFS的脚本是直接插在TJS脚本中使用.因此OFS的检测逻辑必须要依靠区间.因此语法要比KAG麻烦...但好处是可以进行嵌套.
<#maintag tag<> >
<#maintag tag< tjs + <#maintag tag< $( input ? Object : AnyObject ) > > + tjs > >
前面也提到过.fragment会把执行片段封装起来..而在执行时则会通过具体的解析函数进行拆分.
这种片段是可以进行传值的.在<>区间中的%()区块中那三个参数.也可以直接用input : AnyObject或者input?Object
input就是向传值字典中查找一个值来进行替换.?表示对input进行类型检测.如果通过才会进行替换.而:后面则是input的默认值.
在只存在一个input的情况下.报错参数错误.换句话说就是.一个执行片段被当做一个函数使用了
我承认这一堆尖括号看的眼花...谁让%[]和[].....虽然检测逻辑是支持自定义符号的....但是有时候对上%[]和[]之类的还是容易爆炸.....所以干脆就不支持方括号了.....大中括号同理......
具体的处理调用关系我就不说了...太麻烦.但是这玩应无非还是拆标签.而不是对tjs语法直接进行拓展.直接拓展虽然不是不可以.但是要判定哪些是自己的逻辑哪些是tjs自带的逻辑，还要分辨再拆出来再解析替换再交给tjs执行....想想那个区分的逻辑我就头疼- -
这玩应反正就是.如果不是自己写的要了解很长时间.了解差不多了写写模板然后就不用动弹了.....反正我就拿来做做demo..........
OFS片段解析的占用...基本没有，至少在我测试的时候比我那个win热区的消耗低得多.我测这玩应永远是1ms，测热区还给我出过3ms.........
最后补充一点就是.注意各个OFS之间的引用逻辑........如果没有资源引用表(类似U的ab包那样的.但是kr的话会简洁挺多的...).还是挺麻烦的....

这个辣鸡命令行...
首先....System.readRegValue( key ).....这玩应丢进去它直接就是吃转义的，我还以为不转......所以如果要在这里面丢一个\需要写\\....
"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Nls\\Language\\Default"
不知道在其他电脑什么情况...反正可以自己试试...
关于命令行...对kr本身进行设置那个cf和cuf...一个是在根目录，一个是在datapath下面...
这里面的所有命令值...在tjs层都无法获取...........但需要注意的是.它那玩应的格式是
startup="startup.tjs"..........
不用写-因为换行它会给你自动添加...值必须要用""扩上不然它给你到下一个命令头结尾.但是这会让你之前那个命令的值多了一个\n导致爆炸...........................
并且这些值......有一些是在tjs层可以动态变更.但是有一些并不能.............
这些命令行，都可以在启动kr那个exe的时候作为命令参数输入.效果是一样的......
但是...通过启动输入的命令参数是可以被System.getArgument( name )获取到值的...虽然这些符号也会被转义，但是还是可以用\"之类的来达到输入一个字典的效果【.
不过这些的玩法相对来讲比较有限了...