这是第几次从头开始做口上了呢...但是技术储备和灵感是不会消失的。
重新做是因为想到了更加美味的写法、但哪怕不是因为更美味的想法也会在之后开始继续按照旧的写法做下去吧
我不死！

顺带现在update里的作者的bb理所当然地比初见口上还多...但是初见还没写多少呢。
这次初见就不根据地点什么的做太多差分了，没必要，写得越多割裂感越大、我要配套做的东西也越多。
上次文本停止更新，就是因为我发现“为了做初见、需要给帕露西做一套行动系统”。多亏了这个有了一套能自定义的行动系统，但是为了那么点东西做出这么些玩意、回过头来看看真是有点...
再者，意识到了tw的底层缺陷——记忆不好做。这样我就干脆不那么做了、那样做的话估计会累死。
虽然我有毅力去耗到累死之累不死，但是如今有了更好的想法那样就实在不值得了。
新的角度，新的解法，甚至有新的口上名（原定口上名是仿照xx之x格式的“嫉妒之毒”但是其实相当不合适，现在嘛...暂且保密）

说记忆不好做...此乃谎言。
我突然想起来、我自己的era企划里面的地图类，好像稍微改一改就是一套便利的字符串操作工具？
决定就是你了！

目前单对话这方面的期望，就是做成“因为触发了某些事情、所以有某些话题可以聊”。分为临时话题和非临时话题、临时话题的话睡觉就消除了，非临时话题则是推进剧情的内容之类的。
之前不这么做是因为原版的firsttime和once实在是太太太太太不好用了，但是我既然有了便利的不用我人为穷举的工具，whynot？

计画是做成“没有话题就不能尬聊”的模式。但是预定模式有“熟了以后会根据话术等级随机出现临时话题所以不用担心无话可说”。每次聊什么都是手动点选、帕露西想要和你聊天的话预计会用自由行动作出提示（有什么话想说、然后会话加入“听帕露西说”这样的选项）
话题就像上一层提“记忆”提到的、由事件和日常活动产生，或许还有每日刷新的部分？

初见干了20KB，配合的对话也整了6kb，然后发现“随着对自制工具的熟练使用、产生了新的想法”
虽然大纲不变但让我修细节不如杀了我，所以重写、重新打磨，从头开始再一气呵成就不容易有割裂感了
顺便目前最大的困难在于按心意仔细调整差分图片。写两千字的难度远小于调二十张。虽然调整好辛苦但是用起来（无论是写的角度还是看的角度都）是真香，难以割舍呀
目前写出来的东西最喜欢的是这一段

一寸之虫五分魂的neta一定会保留，大概，因为将会放在什么位置完全不好说

稍微整理了一下每日遭遇的情况。感觉以前被问过很多遍“部屋遭遇/EVENT1的XXX是干什么的”，当时是回答了还是没回答呢？但是以后要是再有人问我，我就把这张图甩过去好了
至于为什么初见还没写多少就整理这个？
——因为初见的触发，不能实现我想象中的一些东西。去设计情况判断“这里该不该触发二次初见”什么的太麻烦了、不如从“遭遇”去做，省时省力
初见了、就认识了吗？帕露西为什么要记住“自己已经见过玩家”呢？如果不在意的话、即使初见了也跟没有初见没什么区别吧？抱着这种想法、我必然会把一部分传统上属于“初见”的内容分出来、放到“每日遭遇”上——
既然做了就一气贯通，整理、整！

-放下了“我得先做初见”的想法、写想写的事件（得益于记忆系统、我不必按照传统方式先做初见然后设计CFLAG了）
-纯汉字1450字却有9KB大，选择支如多（因为是互动的差分而非正文），字数不多写起来相当费劲（要构思的同时还要打磨差分）
-因为帕露西的谈及一些东西的表现太正经了、可能有点可怕，所以加入了额外的小互动环节来安抚可能被吓到了的玩家的情绪（如果是帕露西的话也会这么做的、设计与人物塑造两全，win~win~）
-“（我很可爱、）原谅我嘛”环节，设置了一个循环，内置6次拒绝（算上最开始的拒绝一共是七次）
-每一次文本都不同，选项虽然是一个同意一个拒绝、但也加入了大量的neta
-虽然说有6次拒绝，但是我做到CASE 3（循环中的第四次）的时候就被萌杀了

↑这小眼神，这小表情，这谁顶得住啊

每日见面口上，接口内部ARG==8的情况，只要是每日初次见面就一定会触发，不管此前是否触发过其他内容（如初见、ARG==7、ARG==6、ARG==9）。ARG==0的情况差不多，但模板没给ARG==0所以大家都不晓得。
模板里说ARG==8是主地图每日初见，但实际上非主地图的情况也完全可以触发。所以说模板注释有时候真是瞎糊比写。此所以口上作者不可以不深思而慎取之也。

我的字符串操作工具！比原版的ONCE啊FIRSTMEET啊这些！更好用！
-
分为临时记忆（CSTR:60:1）和非临时记忆（CSTR:60:0）两种，临时的是每日刷新（因为和K60的ONCE本质用的是一个字符串）。
它的优点在于，可以以“记忆（组）名:记忆内容/记忆（组）名:记忆内容/记忆（组）名:记忆内容/”的形式，大规模地精确地存储内容、并进行检索。
例如，我写入一个"EVENT:AAA"，再写入一个"EVENT:BBB"，以FIRSTTIME的形式查找的话需要知道写入的东西可能有"EVENT:AAA"才能读出"EVENT:AAA"，"EVENT:BBB"同理。
但按我这么设计，我只需要知道我有"EVNET:"这么一个组，就可以通过检索这个组来获取一个"EVENT:AAA/EVENT:BBB/"的串，包含这个组下的所有元素（带组名是为了后续可能的操作），而不需要打一个表去"AAA""BBB""CCC"这么一个一个对、一个一个找。以及原版的工具不能有重复的元素，但我这个可以。
正如这个工具的名称，“MEMORY_STR”，它被设计出来的初衷是更方便地存储一些事件的记忆。这样的话，就不需要费心费力去记住那些用于控制事件的CFLAG、也不怕搞混一大堆用FIRSTMEET存储的元素了。
基于这个工具，【图1】是以记忆用字符串存储数值的工具。无论是隐藏的好感、隐藏的信赖，还是每日会面次数的计数器，都可以超级方便地读写。CALLF控制对应数值的函数，变量仅仅只有一个增量（负数的情况就是减少量、0的时候就只是获取当前数值）！实在是太好用了！
顺便，发这个东西，是因为几个小时前发现了这个东西的一个BUG而连忙修补（最后直接造了个模板类出来，省得每开一个新变量就要复制粘贴一轮）

为了更方便地实现我的TALK_TOPIC...史上最强大的DOKU_XX_ASK_M要诞生了吗？

设计的初衷是用一个函数打印巨量的选项（而且字符串这个东西更方便模式化操作，可以很方便地增减）。目前在ULTRA和PLENTY还有INFI之间纠结函数的命名。

我可以！在选项不可选的时候！写出为什么不可选！

测试偶遇**更新，字符串乘负数强如魔鬼，拼尽全力无法战胜。
要是想固定长度的话，为什么不给LOCAL加MAX呢？为什么呢为什么呢？
不加MAX，改BASE理性BASE情绪的人，不就只能非常痛苦地手动改回最大值了吗？
没有防范意识的东西！

想玩这种选项式对话，代价就是一个半小时的测试排查。做到昏天黑地，总算能跑。之前做的版本也能跑、但是现在我用上了无敌的DOKU_ULTRA_ASK_M！
这样的话查表只需要单独列两个函数就好了。这么辛苦了半天，第二重要的就是这件事了。

大危机！自制指令管理，时点太靠前，无法利用NOWEX！
大智慧！轻轻加时点，就可以利用了！虽然加的很丑陋！

顺带，发现这个问题的原因，是性欲。圣诞短文那边写到色卡文了，但绷不住了。