お節介。
要らぬ世話かなと思っていたけどPython最新版が積んでいたので倣った。
ずっと前に積んでいたstring.closest()関数が役に立った。

こいつ。

NScripter開発者なら一度や二度は苦しめられた経験があるはずだ。
うっかりデスクトップを覆い尽くしてイラっと来たことがあるのではないか。
多重起動できないのはそういう仕様として、どうにかこいつだけでも抑制できないか？と願った末に
「無事に起動しているNScripterからこいつの出現を監視して閉じ続ければいいんじゃね？」
という結論に達した。

分離したスレッドが「起動エラー」と題されたダイアログを100msに一回検索し、
見つけ次第タスクキル。
現代的な挙動は「既に起動しているならそちらの窓にフォーカスする」であるため、
不格好ながらそのようにもした。

closedoublewindow命令としてNSMirageに乗っけた。
さらばこいつ。

NSGetFileInfo()とns2アーカイブについて。

NScripter、ns2アーカイブのファイル構造は以下のようになっている。


生のファイルとアーカイブ、両対応の読み込みは以下のように行う。

--開く
local file="hoge.png"
local name,off,len=NSGetFileInfo(file)
local a,err=io.open(name,"rb")
--開けないなら中断。原因はerrに文字列で入る
if(not a)then
	return a,err
end
--生のファイルだった場合は長さ＝ファイル容量
if(off==0)then
	len=a:seek("end")
	a:seek("set")
end

--�@ファイル先頭に位置を合わせる
a:seek("set",off)
--�Aファイル末尾まで位置を進める
a:seek("set",off+len)
--�Bファイルを先頭から丸ごと読み込む(*a)
a:seek(off)
local str=a:read(len)

今は昔……
「NScripterでいう通常変数は一般的なプログラミング言語でいうと全てグローバル(広域)変数である」
というような話を今はなき先人の誰かが書いていた。
NScripterがLuaと連携したのはバージョンアップ終盤であり、長い間ローカル変数の概念が無かった。
「グローバル変数／通常変数」という名称は、Luaや他言語の事を考えない限り大した問題ではない。

NScripter
NSLa
全データで共有
グローバル変数
グローバル変数
セーブデータ毎
通常変数
通常変数
ブロック内のみ
　
ローカル変数

ローカル変数を積んだNSLa環境下では「通常変数」の意味するところがとても分かりにくい。

後発であるティラノスクリプトでは「システム変数」「ゲーム変数」と呼び分けているらしく、
これはなかなか直感的で上手い名称であると思う。

NScripter
NSLa
全データで共有
システム変数
システム変数
セーブデータ毎
ゲーム変数
ゲーム変数
ブロック内のみ
　
ローカル変数

界隈が界隈として残っていれば
「NScripter界隈でもこの呼び分け使うと分かりやすくない？」
と提案したかったけど、2020年現在NScripterコミュニティはTwitter上にしかおらへん。

NSMirage.dllの「ボーダーレス化」というのは



こんな感じでデスクトップいっぱいにダミー窓を拡大する機能。
(擬似フルスクリーン化)
Nスクデフォの「フルスクリーン化」はデスクトップ解像度の一時変更であるため、
現代の環境ではフォルダやアイコンの位置が崩れたりしてちょっと不便だった。

左右の余白は黒で塗り潰すべきかもしれない(視野の端にデスクトップが映って没入感を殺ぎそうなので)

deffontd.dllのルビは、本文に対して極端に少量だった場合の割り振りが妙な見た目になる。
そこでルビ文字の左右に適切な量のスペースを足し、それからあらためて渡してあげる。

いい感じの見た目になる。

ルビサイズは一定であるべきか？

それとも本文サイズに応じて可変であるべきか？
可変にした場合、大きくなり過ぎたルビは他の行の本文と見分けが付きにくい、紛らわしい。
一定にしておいた方が良さげ？

*define
	game
*start
	lsp 801,">180,120,#ffff00",0,0
	print 1
	click
	end
このコードは正常に動かない。
「NScripterのスプライトは本来なら必ず透過方式の指定を付けねばならない」
「にもかかわらず普段はそんなことをぜーんぜんしない」
「それは【transmode alpha】等と指定しているがゆえ」
完全に忘れていた。
わけあって最小環境で動かしていたら塗り潰せない、表示されない、なんでやねんと数時間悩んでいた。
	lsp 801,":c;>180,12,#aaffaa",300,140
したがって正しくはこう。公式マニュアルにもそう書いてある。また忘れそう。

Lua5.1のメタテーブルとは何ぞやという話
結論から書くと、NSLuaとして使う限りではテーブルを複雑にいじらない限り関係してこない。
つまり「NScripterで使うためのLua習得」においては当面の間存在を無視しても一切問題ない。

hoge="〜"
hoge:find("〜")

がどういう理屈で通るのか？　という疑問を無視出来なくなった段階(つまり今朝の僕だ)で調べれば十分だし、
そんなもんかと納得しても劇的にサウンドノベル用途におけるテクニックが広がるわけではない。
NScripter視点では理解を試みる優先順位を相当下げて構わないと思う。

--■たとえばこんなテーブルがあったとする
local hoge={
	"a", --hoge[1]="a"
	"b", --hoge[2]="b"
	"c", --hoge[3]="c"
}
--■本来の動作
alert(hoge:concat("/")) -->エラー！

　hoge:concat("/")と書いた場合、Luaは
　　→hoge.concat(hoge,"/")
　　　→hoge["concat"](hoge,"/")
　　　　と解釈する。
　　　　その結果
　　　　　hoge["concat"]の値を参照(index)するが、
　　　　　何も値が入っていない(nil)ので、
　　　　　★
　　　　　「nilを関数呼び(call)しようとした」としてエラー
　　　　という動作になる。

--■メタテーブルを設定した場合の動作
setmetatable(hoge,{__index=table,})
alert(hoge:concat("/")) -->"a/b/c" alertは文字表示関数というかNSOkBoxだと思うべし

　__index=table(※このtableはLua標準のグローバル変数(テーブル))

　とメタテーブルを設定した。
　これにより、、
　「キーの参照(index)時にhoge自身から値が見つからなければ(★のタイミング)、
　　【tableというテーブルからも同様に探す】」
　という動作が追加される。

　この例では
　�@hoge["concat"]に値が入っていればそれを返す
　�Atable["concat"]に値が入っていればそれを返す
　と動くようになる。
　そしてtable.concatには関数(渡したテーブルの数値インデックスの中身を結合する)が入っている。

　したがって
　hoge:concat("/")　　　　は
　table.concat(hoge,"/")　と読み替えられる。

--■そんでつまり何なのか

　根本的には普通ならエラー吐く演算に追加の挙動を紐付ける事ができる、という仕組み。

　hoge="〜"
　hoge:find("〜")
　と書いて通っている理由は
　「Luaが標準でstring(文字)型のメタテーブルに__index=stringを持たせている」ため、
　となる。

　hoge:find("〜") が
　hoge["find"](hoge,"〜")と読み替えられ、
　　�@hoge(文字列)自身にキー参照(index)時の動作は定義されていない
　　�Aメタテーブル見に行ったらstringから探すように言われた
　　�B探したらstring["find"]が定義されていた
　　�Cつまりstring["find"](hoge,"〜")だな！
　という順で処理される。

　※hoge:find("〜")とstring.find(hoge,"〜")は厳密にはちょっと違う、という話は今回重要ではない

　前々段落で「string(文字)型のメタテーブルに」と書いたが、
　「ユーザーデータ(は今回重要でない)とテーブル以外の型」
　　数値、文字、真偽、関数、コルーチン等…　は
　それぞれで単一のメタテーブルを使い回す仕様になっている。
　これらはCから操作しないといけない(＝Nscripter視点ではdll自作が必須＝無いも同然)。

　逆に言うとテーブルのメタテーブルだけはいちいち個別に設定する必要がある。
　そしてLua内から直接setmetatable関数で操作出来るのもテーブル型のみとなっている。

　「いちいち設定する必要がある」のは本来、
　オブジェクト指向やらクラスの継承やらその辺の再現に関わる仕様(だが今回は重要ではない)。
　個別に設定するまでもなく使い回せば十分な場合
-------------------------
local meta={__index=table}
function newtable(tab)
	setmetatable(tab,meta)
	return tab
end
newtable({〜})
-------------------------
　のような事をやれば多少手間は減る(が面倒には変わりない)。


長年分からなくなっていたWeb拍手のログインパスワードをサルベージすることが出来た。
使っていた携帯サイトはとっくにサービスごと終了している。

�@速度をステージ内の要所で変えつつ背景を多重スクロールさせる仕様
�A低負荷モード時は背景の多重スクロールエフェクトを切る仕様
　→何かの拍子に変数自体操作しないコードに(意図しない省略)
�B常に低負荷モードでテストプレイ
�C多重スクロール背景のスクロール状態を参照する敵(バグ)
�D本来出現するザコ敵が非・低負荷モード時に出現しない(バグ発現)
　→しかし気付かない
�E当然リプレイがずれる
　→内部の数字をああでもないこうでもないと探索、
　　敵が出ていないという最大のヒントに一晩気付かない
----------------------------
バグの原因一晩探して結局誤字由来だった７年くらい前を思い出した。

たぶん「NSExecで呼んだluasub命令内NSExec(0行戻りが発生する仕様違反)の多用」が
発生するための最低条件ではないかと思っているけれど、
NSExec("bexec $0,%0")
で異常な動作(%0に値が入らない、引数が変エラーで落ちるなど)を起こし、
NSExec("bexec        $0        ,        %0")
と書いたら正常動作するケースがある。
どうもbexec固有の現象らしい。
原因も対処できる理由もさっぱり分からない。

とりあえずNSLaはその環境下にある。
(拡張スクリプトに直接記述した場合は勝手に空白を足している、
NSExecから呼ぶ場合は自前で空白を足す必要がある)。
謎。


「JPEGがロード出来ません。OLEが使えません」というものすごく珍しいエラーについて。
確認している限り、発生条件は
「使っているドライブの空き容量が0バイトである場合に」
「NScripterが(bg命令等で)画像をロードしようとする」
というもの。
昨今のPCではまず遭遇し得ない条件だが、
低価格タブレットにゲーム詰め込んでいる場合はうっかりするとうっかりするかもしれない。
ググって6件しか引っ掛からないし、見た事がある人はほとんどいないのではないか。

うっかり
NSExec("bexec %0,$0")
と書いてしまい、なんか一回目のクリック反応しねえなあ？と悩んでいた。
NSExec("bexec $0,%0")
これが正しい記述。
エラーは出ないためうっかりするとハマる。
手打ちせずにコピペすれば防げたものを……

--Lua
--原始的なエラトステネスのふるい
local sosu={3,5,7,11,13,17,19} --2は判定しない(最後に足す)
for now=23,100000,2 do		--奇数のみ判定、とりあえず100000まで
	local issosu=true
	local limit=now^0.5
	for i,v in ipairs(sosu) do
		if(now % v==0)then
			issosu=false
			break
		elseif(v>limit)then
			break
		end
	end
	if(issosu)then
		sosu[#sosu+1]=now
	end
end
table.insert(sosu,1,2)
--sosuに素数が入っている

--10進数を16進数に変換するにはstring.formatを使う(知らなんだ)
local hex=string.format("%x",[10進数])

なんか半年に一回日記ページを更新するみたいな謎風習が付きかけている気がする

書きたいことが割といっぱいある。
「englishを使ったとしても偶数バイト目に全角文字の先頭を書けるわけではないのでこいつは実質ルビとの二択を産む命令である」みたいな話とか
「“テキスト”やボタン待ちは命令実行中に(アニメーションコールバックから)他の命令で割り込めるきわめて特殊な命令である」みたいな話とか
「そもそもアニメーションコールバックから何が出来るのか(NScripterはスクリプトの並列実行に対応している！！コルーチンと組み合わせればリアルタイムに思考するAIとかも理論上作れる！)」とか
「クローンゲームのようなごちゃっとした(あやしげな)ゲームがネット普及期のフリーゲーム畑で一定の役割を担ってきたことについて」とか
ひぐらし(このサイトでひぐらしについて何か書いたことが無かった気がする)とか

NSLaのマニュアルも最新版準拠に書き直す必要がある(出来ないと書いたことの多くが出来るようになっている)。
というかNSLisichkaの更新もしたい。

しかし「最終版」が出ていたNScripterが2.96→3.03と更新された話、
つまり「NScripterに脆弱性」という話について思うことを書く。

正確には
「NScripter2.96以前のバージョン(＝世にある既存のＮスク製ゲームほとんど)において」
「悪意ある第三者のセーブデータを読み込んだ際に」
「任意のコードを実行される可能性がある」
という内容。現在のバージョンでは修正済み。
「リビルドを」と呼びかける記事も出ているが、Ｎスクの仕様上大抵のケースではexe置き換えで済む。
というか個々のプレイヤーが普通の遊び方で普通に遊ぶ分にはその必要すらない。

前提�A
各記事は公式の修正版リリースに伴って出た。
この脆弱性による実際の被害が出たわけではない(理論上の脆弱性)

前提�B
そもそも、「他人のデータを読み込む」機会は限られている。

で、どういうケースが想定され得るのか。

■「他人とファイルをやり取りする前提で作られたジャンルである」

そうした作りのNScripter製ゲームが現実にほとんど存在しない。
NScripterはサウンドノベル以外のジャンルでも使われてきたゲームエンジンであるけれど、
「“他人のセーブデータを利用する”という仕掛けが用意されたゲーム」となると
僕は『晴れたり曇ったりＮ』くらいしか思いつかない。
あれにはたしか「セーブデータを用いて疑似的に対戦する」といった機能があったように思う。
一旦グローバル変数にデータを格納して使う仕組み？とか想像して確かめなかった記憶がある。

近代的なNScripterにおいて「他人とデータをやり取りするゲーム」を新規に作るならば、
「ロード」を挟まなければ読み込めない＝内部を気軽に確認/操作できない標準セーブデータを用いるより、
何らかの独自ファイルを自前で吐き、それを読み込む方が簡単だ。
(Lua・csvwrite/read命令)
とりあえずLuaのファイル出入力は空テーブルにseffenvして読み込めば変なデータにおかしな挙動をされる心配もほとんどない。

■「バグ報告用データ、やりこみ自慢、リプレイファイル等他者のデータを覗くためのデータやり取り」

「サウンドノベル以外のジャンル」において問題になり得るかもしれない。
想定される悪意として「バグ報告と称して作者狙い撃ち」というケースは(ピンポイントに狙うやり方として微妙に効率が悪い気もするけど)あり得る。
ただ、Ｎスクのセーブデータがなんか暗号化されている(＝セーブデータの状態を覗きにくい)こともあってか、
「バグ報告時にセーブデータを添付してもらう」という慣習はあまり行われていない(よね？)。
保持するデータ量が多いゲームでない限り、セーブデータを解析するよりも報告された症状から類推した方が原因特定もおそらく早い。

やりこみ自慢の類は現代においてスクリーンショットや動画主体だし、
Ｎスクの場合はスクリプトを手軽にかっ捌けるので他人のデータの信憑性的な意味ではあまり意味がない。
リプレイファイルに関してはすぐ上に書いた通り、標準セーブデータを使う意義が薄い。

■「ネットに転がった全クリデータ(要素開放済みのデータ)をプレイヤーが勝手に拾ってくる」

「脆弱性」として想定されているのはおそらくこのケース。
Ｎスクを触った経験がある人なら
「わからんセーブデータを落としてくるよりスクリプトを捌いて書き換える方が100倍早い」
ことを知っている。そうではないユーザーは大勢いる。
高橋直樹さんが書いていたけれど、セーブデータはたしかに警戒の盲点になりやすい。
そうしたユーザーが出自の怪しいアンロック済みデータを引っ張ってきて……という可能性は考えられなくもない。
そのようなユーザーを個々の開発者が想定すべきか否かは微妙だけれど、エンジンとして対策したのはユーザー保護として理に適っている。

ほかに、
●悪意ある開発者が悪意あるスクリプトを仕込む
fileremove命令を知った瞬間に誰でも一度は想像したことがあると思う。したよね？
当然今回の脆弱性とはあまり関係ない。
-----------------------------------
フリーゲームにせよ同人ゲームにせよ開発者とプレイヤーの信頼関係で成り立っている側面が大なり小なりある。
こいつウイルス仕込むんじゃね？という次元で信頼されていない開発者／サークルはおそらくインターネット上に生存できない。
商業ゲームがうっかりHDD吹っ飛ばす事件は何なんだろうね

●悪意なき開発者が悪意あるゲームをリリースしてしまう
ウイルススキャンしましょう。
NScripter製ゲームでウイルスが悪さをする余地はあまりない気もする。


なんか脆弱性という言葉だけ一人歩きしてね？と思っている。
いい加減な記事だと「旧バージョンに」が欠落していたりする。
(今回この日記を書いた主な理由�@……軽微な憤り)

僕自身は同人ゲーム板で作られていたひぐロワ私家改造版(二次創作の無断改造版、三次創作)を見てNScripterに入門した人間なので、
娯楽作品のスクリプトはオープンであってほしいと考える立場にいる。
したがって、「セキュリティ面を考えながら一人用ゲームを遊ぶ」というスタイルはちょっと息苦しく見えてしまう。
「サンドボックス環境で(仮想化された環境で)ゲームを提供する／遊ぶ」という安全性が開かれた環境／利便性と等価なトレードオフなのか僕には分からない。

NScripterコミュニティにおいて、あるいは他の制作ツール(ツクールとか)のそれにおいて、
復号化ツール(nsdecおよびその派生)の是非は積極的あるいは消極的に論争の火種となる。
ツクールＭＶ暗号化できねえじゃん！で世は燃えている(気がする、最近の流れは確認していない)。
NScripterコミュニティを発展させ支えてきた人たちは暗号化を好む考えの人が多いと思う。
難読化や独自暗号化の記事も複数ある。

でもブラウザ動作のノベルエンジンは色々可能性があると思う。
>私事 2010/09/01
でAIRNovelというエンジンに触れたけど、ああいうアプローチは次世代の環境を作り得ると思う(そりゃまあUEやUnityが全て飲み込んでいくかもしれないけど)。
そういやUnity用のサウンドノベルライブラリで宴ってのがあるらしいですよ

結局のところフォルダを開けば00.txtが転がっていて、exeを叩けば即座にゲームが起動する環境を愛している。
そしてアレックスの顔を叩けば立ち上がるツクール2000を愛している(でもマップが同じ階層にまとめて入っているのは気に入らない(当時のアスキーはパッケージ化(だっけ？)を想定していたんだろうけど、実際の用いられ方は知っての通り))。

(今回この日記を書いた主な理由�A……立場を明確にしておく)

雑記らしい雑記をひっさしぶりに書いた！これぞ個人サイトって感じですぜ本当！

NScripter2が正式公開されましたね！

というわけで割と実用的なレベルに弾幕STG動いちゃいました。
「NScripterを限界まで使った」と謳ったゲームは知る限り過去に数本存在していますが、
こいつをもって「NSD命令を限界まで使った」と宣言してもよいのではないだろうか

STG用ライブラリ(名前これから考える)としては
「普通の弾幕STGに用いる軌跡は全てコンパクトな記述で再現できるように」
および
「記述の省略(略記)を柔軟に認める」
がコンセプトです。

制作期間半年の内訳は
・土台作りの実作業が合計20日くらい
・二分間のステージ調整に40日くらい
・仕様(ゲームとしての)調整に四か月くらい〜継続中
・仕様(スマートな記述の)も平行してそのくらい
でした。「動かすだけなら簡単」を思い知る内訳。
STGにおいて「作れる」はほっとんど意味ねえと実感した次第。

--------------------------------------------
2014年から眺めます：弾幕STGにおいて、「2002年前後」はきわめて重大な時期でした。
2002年はらじおぞんでがリリースされ、
東方紅魔郷がリリースされ、
怒首領蜂大往生がリリースされた年でもあります。
1996年を弾幕STGの誕生とするならば、2002年は弾幕STGにおける重要な分化が概ね完了した年です。
で、それから12年経ちました。
商業STGはいよいよもって極限まで追い詰められたように見えます。
とうとうケイブが倒れ(たっぽい、たぶん)、k.h.d.n.が解散し、
グレフやガルチやモスは何やってるのかいまいち分からず、コナミは死んでいます。
これからどうなるでしょうか、分かりません。
しかしSTG文化は死なない。
まだ頑張っているメーカーもあります、同時に同人・インディー畑も激しくもがいています、
S.T.G CREATORや東方弾幕風のような制作環境だってインターネットに散らばっています。

もがこうと思いました。
もっと言えば：その12年前、BulletMLにおいて宣言された
>シューティングゲームが消えてなくなってしまう前に、
>この芸術的な弾幕の数々を保存しなくては、と。
に対する「ふざけんな終わってたまるか」の気持ちも込みで。
------

BulletMLが取ったアプローチも恐らくは、02年を取り巻く巨大なうねりの中にあったものでしょう。
ワールドカップやっていた裏でこんなに熱いうねりがあったとは驚きです。
私ももがきます。脳みそフルに使ってシンプルかつ高機能な記述体系を目指しました。
NScripterとメモ帳ガチ勢に向けた手打ち特化な弾幕STGライブラリです。
描画がNSLua、処理はほとんどピュアLuaです。
どうよ。

NSLuaメモ
　NSDSpAddは加算合成とされているが、最後の値(α値)に負の値を用いることができる。
　明るくするだけでなく、暗くも出来ることを意味する。
　一方、素のNScripterには「lspaddの減算ブレンディング版です。」と説明される「lsp2sub」が存在する。
　NSLuaに「NSDSpSub」が存在しない理由は需要のなさこの仕様にあるのだろう。

君影草工房さんのgetkey.dllに関して、ゲームパッドにおけるスティック入力周りを実験した

入力取得
・手持ちのPSもどきパッド(十字キーのみ)はなぜかニュートラル状態が32511だった。頭おかしい。
　"32511" "ゲームパッド"でググると同じ事例が出てくる。さすがの永字八法。
　頭おかしい手持ちのパッドも(何年も前の)ELECOM製だった。
　　→遊びを取っていればまず回避できるが、設定をユーザー側に委ねる場合が問題。
　　　「32511だけは決め打ちでニュートラル扱い」でもバレない気はする。
・有線360コンは標準ドライバだとスティック入力をまともに取得できなかった。頭おかしい。
　ひとたび入力すると値がニュートラルに戻りきらない。
　　→非公式ドライバ放り込めばちゃんと動く。放り込もう。
・Windows8.1で正常動作。まだ戦える。

入力取得後
・「どこから斜め入力扱いか」はプレイアビリティに直結してくる。
　8方向だからといって45度ずつ区切ればよいというものではない(と思う)。
　スクリプト側で斜め入力とみなす角度を増やせば360シューに近い操作感覚になって快適。
　アナログ入力そのままを用いて全方位STGでも作るならもちろん気にする必要はない。
　　「アナログ入力前提のPCゲー」自体、キーボードを切り捨てることにはなる。
　　NScriipter製ゲームに手を出す人の何割がゲームパッド常用勢かと考えると怪しいものもある。
・この辺りの設定もユーザーによっては自前でやっていそう。

身も蓋もない話
・同人ゲーやっており普段からゲームパッド使っている人間は(少なくとも今はまだ)
　動作しない事態に備えてJoyToKeyなどのキー入力変換ソフトを常用していそう。
　最悪そっちに丸投げする手もないではない。
　「ゲームパッド使ってるくらいだからお前自分で設定できるな、うん？」といった態度。
　結局中身次第か。
・手間は増えるので繋いですぐ動くにこしたことはない。

幸いUDP一本化版の動作確認をしてもらえたため、Sasanqua.zipとchecker.zipの中身を差し替えました。
機能増えてない割に互換性が無いので、Sasanqua.zipの旧版もしばらく置いておきます。

リリースするなり三ヶ月沈黙する変な人になった

【あらためて】
ヤギサザンカはNScripter用のネット通信ソフトです。DXライブラリを使用しています。
んでインターネットチェッカーはサンプルデモです。チェッカー面白いよ。
・通信は二人まで
・通信相手にIPアドレス伝え合う前提
　なので、ある程度身内向きです。
ローカル対戦付き(オンあったらいいのに系)ゲームのオン対応拡張には活用できると思います。
協力ゲー作るのもいいと思います(不正対策を考えずに済む分気楽です)。
オンラインマニュアルを改訂中。
サンプルもそのうち単純なやつを増やします。

ロード時間の配分を考えている。
文字スプライトを数百枚出したままセーブすると、読み込みに数秒かかってしまう。
何から何まで読み込むようにしたらプレイ中はそりゃもう快適なのですが、ロードが重い。
「セーブのたびに半分ほど消す」はプレイ中の無駄が多く、頻繁なオートセーブの問題も絡んでくる。
オートセーブと手動セーブで挙動を二種類用意してみたら、今度はロード時間のばらつきが気になる。
(ただし、絶対的なデータ量からしてばらつき不可避ではある。)
可能な限りロード画面なく読み込めた方がよいと思うけど、さてどうすべきか。

死んでません。

死んでません。

btntimeを使うと擬似的に並列処理に見えるものを作れる。
のだけど。
btnwait2からbtnwait2までの間、何をどう工夫しようと特に描画の瞬間だけはどうにもならない。
クリック抜けが起きる。描画の前後にisclickとか挟んで補うという手はあるかもしれない。
→それでも描画中にクリック押し込み・クリック離しをやられると入力抜けが起きる。
　描画にかかる時間を人間がクリックするのにかかる時間以内にまとめなきゃいけない。
　→うっかり複数行文字列スプライト(毎回忘れるけど(相対的に)死ぬほど重い)など使うと死ぬ。
　　死んだ。

ちくしょう処理重い！⇒strsp外したら問題なかった　のコンボを何回やったら気が済むのか。
たっぷり余裕のある時のstrsphくらいしか使わない方がいいレベルに毎度毎度……

本体の太字＋NSfont.dllの太字を組み合わせ(てしまっ)た潰れ文字はそれなりに味があって好きだ。
でもセル持ち(＝複数色持ち)文字スプライトと組み合わせると濃い色の表示が醜い。

上がセルなしのスプライト、下が醜くなったもの。これ薄い色の表示が残っちゃってるのか？
(というかこれcellの仕様なのか？)
↓
#000000#aaffaa#000000#8adf8a#000000#6abf6a#000000#4a9f4a#000000#2a7f2a
と、奇数番目(セル番号は0始まりの偶数だけど)に黒を挟んだもの。

セルなしのビューティフォーな表示と比べてまだ不自然さが残るけど、さっきよりはとても若干マシか。

・使うのはマウス＋矢印キー周辺のみ
・右クリックでメニュー表示
を外したくないので、全体マップ表示のショートカットをどうするか。
・ミニマップをクリックでも全体マップ表示
という案を思いついたけど、メニュー画面のMap項目可哀想なことになるか。
PC変わったらPageUp/Downが僻地に追いやられていて「矢印キー周辺」がなんだか分からなくなってる。

カテゴリによってこっちの色を変えるってのはどうだろう。

lsph 608,":s/18,18,1;#ffffff"+$SP1+"　　　　　　　　　　　　　　　　",280,88
みたいなものを400個ほど読み込ませる処理をやっていた。
で、これが信じられないくらい重い。
>+"　　　　　　　　　　　　　　　　"
ここを削ったら1/5くらいになった。信じられない。
この紫＋水色ってちょっと気持ち悪い。改善したいもんですね(たぶんやらない)。

どっちでも大して変わらないという結論に達した。
・全滅時の負担は重くしない
・けどリセットは認めない、
・セーブは特に制限付けない
あたりに落ち着けたい。脳内でシミュレートした結果。

表記これでいいんじゃないかと思う。日付先の方がわかりやすいよね。
あといい加減スタイルシート使う。

NScripterというカテゴリ分けをすべきだったねと今さら。
たとえば
lsp 10,hoge,0,0
みたいな感じで10番のスプライトに画像を読み込むとき、
lsph 10,hoge,0,0
とかが事前にある＝読み込むべきスプライトが既に同じ番号(同じ座標？)に存在している場合、
やたら体感速度が上がる気がする(検証してない)。
特に文字スプライトにおいて顕著な印象があるけど、内部処理としてどうなってるんだろう。
単に描画量が減るから(＝番号は関係ない、座標の問題)か？
原理はどうであれ、早くなってくれる分には構わないけど。
barとかprnum(非推奨命令だし非推奨だけど、変えるのが面倒でここまで引きずってる)が
速度に影響してるのかもしれないけど。
(追記)
なんと2010年延長戦をやっていた！　気付かなかった！

lenとmidをNSluaで作ったらどうなるのと思って試してみた。
midの方はちゃんと動いてるか試してない。
なんかstring.subは開始が0でなく1という記述を見た気もするので直さないと無意味かも。
2018/12/16追記：Luaは1オリジンなのでその通りです。
いや直したら意味があるかっていうとないんだけど。
--ちょっとだけ遅い。
2018/12/16追記：関数呼び出しのコストが影響していたのでしょうか？
NSExec("luasub len2")
function NSCOM_len2()
local num=NSPopIntRef()
NSPopComma()
local a=NSPopStrRef()
local str=NSGetStrValue(a)
local res=#str
NSSetIntValue(num,res)
end
--やはりちょっとだけ遅い。
NSExec("luasub mid2")
function NSCOM_mid2()
local rstr=NSPopStrRef()
NSPopComma()
local a=NSPopStrRef()
local str=NSGetStrValue(a)
NSPopComma()
local num1=NSPopInt()
NSPopComma()
local num2=NSPopInt()
local res=string.sub(str,num1,num2)
NSSetStrValue(rstr,res)
end
早いんならまだ救いようもあったけど。
2018/12/16追記：そもそもLuaにこんなしょうもない処理を投げても仕方ないのです。

usewheel対応に手を出したが最後地獄を見た。最初っからやっとくべきでした。
まだ終わらんのよ。あとそろそろページのレイアウトを整えたい。

メニュー画面作るとか言ってたのにもう年末だよ！

envdata消した後のglobalon読み込みでグローバル変数が初期化されちゃうのって、
fileexist %hoge,"global.sav" :if %hoge=0 globalon
で回避できるんじゃないかと思った。試してはいないし、何か問題が起きるかもしれないけど。
もちろんバージョンアップで定義部をいじっても変数の番号が変わらないという前提ありき。
あとenvdata削除も
何かしらのファイル(それこそ暗号化したcsvファイルとか)でバージョン判定
　→バージョン更新があったらfileremove→reset
みたいにやればユーザーの手間が明らかに減るんじゃないかと思う。たぶん。
やはり何か問題があるかもしれない。

私事制作修正更新というカテゴリ分けは失敗した気がする。

3Dダンジョンのオートマッピングというピンポイントにニヤニヤできる話題だったので、
ニヤニヤしていた。オートマッピングを無理やり実装した身としては見ていて楽しい。
こういう考えもしたっけなあ、みたいな。
Lua使うのが無難という意見には賛成だけど、Lua使わなくてもどうにかなる。
あくまで僕は「500階分(暫定)まで一つのダンジョンに詰め込める」という
アホな仕様にしてみたから無理やりやらなきゃいけなかったけど、
全7階くらいだったら別に「無理やり」じゃなくても大丈夫だと思うよ！
ちなみに今から作るならsplitよりmidの方が楽かと思うよ！

全然注目してなかったけど、draw系の命令群使えばたしかに描画におけるスプライトの制約は
気にならなくなるのかも。draw系の命令を実行してみたことが一度もないから推測だけど。
でも20*20なら普通にlsp使っても数は足りる。
20*20ってのはつまりそういうことなのかなあとかいろいろ考えを深読みすると楽しい。
でも、壁に厚みがないタイプのダンジョン(一般的なWIZライク)作る方がよほど大変だと思う。
個人的には。あとこの色気に入った。冬らしくてよい。

どこまでが私事でどこからが制作なのか、一度検討する必要性を感じる。
色々見やすい色を模索してみる。冬っぽい。むしろ先にフォント変えるべきかも。
Tipsさんで紹介されていたサイトが非常にありがたげなのでメモ。
NScripter覚え書き
そうそう、$0と%0の混同とかeffectcutとか、まさに僕はそういう所で引っ掛かったんだ。
今後同じようなミスをする人が出てこないためにもこういうページは必要だと思うので、
作った方はお疲れ様です。
というか順序としてはNスク本スレ→Tipsさんか。まあいいや。

普通待ち時間を作りたくない時はprint 0で済ますだろうなあとは思う。
ずっと前に作った描画周りが頭悪い処理だからこそ引っ掛かったってのも一つある。
とにかくeffectcut様様。

checkkeyの速さにまだ笑いが止まらない。
新ボタン命令全然使ってなかったけど、
もしかしたら処理も従来のbtnwaitより速かったりするんだろうか。
暇な時に試してみようかな。
今さらだけどpreタグの使い方を何か間違ってる気がする。
ブラウザによるのかもしれないけど、テーブルがこう横にみょーんと伸びるのはよろしくない。
br要らないとか超便利と思って使い始めたけど何か違う。
cssで横の長さを指定する方法をこの前知ったから、そのうち改革しよう。

右利きの人からしたらマウスと矢印キー前提の配置って死ぬほど使いづらいだろうなと思いつつ。
ZキーとXキーあたりを使って代替機能をできるだけ作ればいいんだろうけど、
僕が使うわけではないので後回し。当サイトは左利きゲーマーを応援します。
家庭用ゲーム機でもボタン連打とかキツいよね！
左利きの人がみんなマウスを左手で操作してるとは限らないのか？

btnwaitと併用するつもりでcheckkey命令を使ってみたら、
制御不能なレベルにダンジョン内移動が早くなって笑いが止まらない。
PCの性能に依存しそうだと思いつつ、btnwaitよりだいぶ処理が速いんだろうか。
あとこの色の組み合わせひどいですね。これはひどい。

最後にスクリプトいじってから33日が経過。
階段というか昇降用の記号が記号が。
別のところ先にやろうかな。
ctrl押しっぱなしのままダンジョン内で移動するとエラー落ちしていた。
スプライト描画のタイミングで落ちていたようなので、
エフェクトのウェイトを5ミリ秒から15ミリ秒にしてみたらあっさり直った。
ものすごく環境依存の予感がする。
あんまり無茶な時間にはしない方がいいのかもしれない。
→effectcutを使っていなかったのが原因と教えてもらい、解決しました。
　通りすがりの方に激しく感謝の意。

宿題が終わった。夏休みも終わった。
この夏休みの間何やってたんでしょう僕は。

straliasとnumaliasを対等に扱うのっておかしいと思う。
使用頻度的な意味で。
大学入ってまで宿題に苦しむとか世の中間違ってる。

Luaの何を理解できているか後でまとめてみる。
それから何をLuaに回すと楽になるか考える。
ラベル数的な意味で精神的によろしくない敵のAI設定なんかは候補筆頭。

静かなサイトと明るいサイト、どっちがいいんだろう。

---------
rgosubなんて便利なものがあったのか。シスカマする必要なくなるかも。
getbtntimerなんて面白いものが(ry
noloaderrorなんて(ry
lrclick(ry
えっ、fileremoveって非公式命令だったの？
lchkは便利そうだけど特殊文字列構文の方がもっと便利そうだ。参考:幻惑郷
確認。savegame2とgetsavestr、あとsavedir。サムネイルにはgetscreenshot。
本スレの質問はgettaglogとgetlogtextと[]を組み合わせればどうにかなるんじゃなかろうか
もちろんpretextgosubもか。
なんとzenkakkoが使う前に使えなくなっていた
<>で囲むとテキストボタン化できるんだ。ボタン番号は省略可能ってどういうことだろう。
と思ったらtextbtnstartで指定するのか。しないと1から順に。
って、テキストボタンは普通のボタンとは別物だったのか。
なぜか今まで文字スプライトと混同してた恥ずかしい。
---------
次々ボロが出る。
そういえば付属してたサンプルにテキストボタンなんちゃらというのがあった。
当時は意味分からなくてそれっきり忘れてた。
今見たらなかなか便利そうな機能じゃないですか。{}の使い道も納得した。
ただ{}内でエイリアスが使えないってのは不便だと思う。
---------
ついでにNSLuaのリファレンスに突入。
NScripter側に　luasub hoge　を書くと、
以後hogeを書いた時にdefsub的な感じで
Lua側の関数　NSCOM_hoge()　を呼び出す。
だからLua側には
function NSCOM_hoge(){
[命令の中身]
}
があればいい。
↑こいつが書かれたluaファイルってNL_dofileであらかじめ読み込んでおく必要があるのかな？
→system.luaは起動時に読み込んでくれる。
それ以外にファイルがある時はsystem.luaからNL_dofile("lib.lua")のように呼び出す。
NSCOM_mainは今のところ使うメリットがない。NSluaだけでってのはさすがに……
で、これがベースになってLua側であれこれ処理をする。
---
luacall text(とか)ってのはNScripterの基本的な動作に乗っ取りかます時に使う命令。
→例えば文字表示とか終了確認とかpretextgosubにあたる部分とか。

時々lua側で NSSleep(1)とか書いてCPUをお休みさせてあげる必要がある。

NSExec("NScripterの命令一個")　というものもある。
NSPopLabel(読みたいラベルの文字)というのもある。

NSD○○系はLua側で描画を行う命令。NScripterで描画すると消える。
誰得？　と思ったがテクスチャの概念があるみたい。
ってことは公式のSGEの迷路サンプルはこいつの親玉みたいな処理(というかluaそのもの？)をフル活用してるのかな？
SGEは3D対応するみたいだしきっとそうなんだろう。違っても今は困らない。
どうせこっちは中間画像もない止め絵の擬似3Dだし。自虐じゃない。本当だよ。

と、NSluaの基本はこんなもんなんだろう。たぶん。
---------
senzogawaさんのリファレンスにあったNSExecの
>※define時に行いたい処理はsystem.luaに裸で書いておけば読み込み時に実行されます。
という注の「裸で」の意味がいまいちよく分からないけど、
「NSExec("ふにゃ")みたいな形で」と読めばいいのかな。いいんだよね。たぶんそうだ。
起動時にsystem.lua読み込んでる時だからってさすがにNscripterの命令そのまま書けたら変だし。
公式のサンプルだと
function hoge()
ここに中身
end
ってなってるけど、
hoge(){
中身
}
でもどちらでもいいってことなのか？

ここで、ifとかについての言及がどこにもないことに気付いた。
けど普通に使われてる。どういうことなのか。lua自体の命令も使えるってことなのか。
→要するにまず根本的にNSLuaが結局何者なのか分かってなかったことになる。
そういう話題があったはずだとスレ読み返したらちゃんとあった。
これが間違ってたら知らない。けど突っ込みとかも入ってないしたぶん合ってるんだろうと思う。
	121 ：名前は開発中のものです。[sage]：2010/07/20(火) 21:04:17 ID:H/HgPWAc
	LuaはどこまでいってもLuaだがなあ。 
	NSLuaとLuaの違いは、 
	普通のLuaにNScripterとの連携用の命令をいくつか追加して、 
	現在あるほとんどのLuaライブラリ（特にC言語と連携してる奴）が 
	読み込めなくなった奴だから、まあ違うと言えば違うけど、 
	Luaでできることはたいがいできるんだがなあ。
要するにそういうことでよかったらしい。だからこそsenzogawaさんがlua講座を書いたわけだ。
どうやら何もわかってなかったっぽい。でももう理解した。
ここまで二時間ちょっと。現在午前二時四十三分。
これをNSLuaとはなんぞや？　みたいな記事にまとめたらコンテンツになりそうだけどたぶんやらないと思う。
ちゃんとわかってる人の誰かが作るのに任せよう。
とりあえず今日の結論として、
「NSLuaって実はそこまで敷居高くないんじゃない？
 深入りしたらわけわからない領域に突入しちゃうけど、
 使う部分だけ覚えれば無理やりシスカマするような部分とか配列変数とか連想配列って概念とか、
 NScripter単独でやるよりずっと楽になる予感がする」
という今まで色んな人が言っててFAMさんにもしてもらった説明の繰り返し。
でも具体像が見えたからあとは覚えるだけだ。
もうLuaは得体のしれない何かじゃなくて、NScripterとつながってくれた。
うん、なんかそれっぽい締めになった。

前々から分かっていなかった部分として、Lua側で使っている変数はそのままじゃ保存されないのかな？
→いい加減調べようとしてとりあえずググったらこれまたsenzogawaさんのtwitterアカウントが引っ掛かる。
　全然理解できないけど読む限りそうかな？　一応自分でも確かめる。
　でもたぶんそうなんだろうなあと思う。際限なく変数作れたりしてるし。
　サブルーチン内での汎用変数とかを気にせず使えるようにして、
　必要な数値はNScripter側に格納してねってことなんだろう。たぶん。
今さらだけどこの日記なんかすごく読みづらい。
フォントが悪いのかごちゃっと固まった文章配置が悪いのか。
要改善。

・これでやっとLuaを身につける準備ができた
(といっても解説のおかげでいくつかの概念は既に覚えてるはず。忘れてなきゃ)
・どこをluaに回すと楽になるのか考える
→とりあえずアイテムとか特技のデータベースかな。
　ラベル気にしなくていいわけだから、以前やめたアイテムID制を復活させるこ……
　入手時に全部格納するからいいやってことにしたんだった。
・rgosubなんて便利なものがあったしシスカマはやらなくていいと思う
(シスカマも無駄に敬遠してたけど見てみたらそんなにややこしい事はしてなさそう？
　ガチガチにいじってるスクリプト見たら感想は反転するかもしれないけど)
・まずはNScripterのスクリプトあれこれ修正してから
・せっかくだからNScripter2に備えてSGEも視野の片隅には入れておきたい。
　互換性優秀だといいなあ。サウンドノベルによく使う命令とRPGによく使う命令ってズレてそうだし、
　優先度的な意味でちょっと不安

精神的な壁になっていたのはsystem.luaの位置付けとNSLua-Luaの関係。あとセーブ時の情報。
これさえ明記しておけば、あとは要するに飛んだ先のルールがまるっきり違う、
defsubみたいなものだって事になる(Luaだけで組む時はともかく)。それで理解しやすくなる気がする。

【メモ】blt使わずにアニメーションさせるならcellとspwaitを組み合わせるといい感じかも。
ただ、そもそもアニメーションさせる素材(攻撃エフェクト)を揃えられないと思う。

>tablegoto %数字変数,*ラベル名（,*ラベル名...） 
>テーブルジャンプ命令です。
>数字変数の値が 0なら一つ目、1なら二つ目…… に指定したラベルへジャンプします。

AIRNovelというサウンドノベル作成ツールを何か月か前に偶然見つけたのですが、
全然話題になっていないのはどうしてなんだろうと思っています。
落としていないのであれですが、パッと見そこそこ使いやすそうなのに。
NScripterや吉里吉里の方が解説周りが充実していたり作品数(→実績)も多いからなのかなあ、
とか考えながら眺めています。

・目印代わりに安易に,や"を使わない
・次があればdefsub先で使う汎用変数と普段から使う汎用変数を分ける
・風呂で寝ない

気が付いたら生成されるセーブデータの容量が100KBくらい少なくなっていた。
いったい何があった。まさかOS依存なんてことはないだろうけど、気持ち悪い。

・timeはだいぶ遊べそうな命令。ユーザーを信じれば期間限定イベントやら
　最終起動から間が空いた時のあらすじ解説やら。←これいいかも。
・timertrapも面白そうな命令だけど、作中の演出に使うのは難しそう。特に後者。
・bltの原理をようやく理解した。使えるかどうかはまた別の話。
・今のPCがpageup/down最高に使いづらいのは最高に不幸。
以下未来の自分用メモ。小さい文字は読み飛ばす。
セーブデータとしての情報を外部ファイル、
おそらくはnsa内に格納されたcsvファイルにぶん投げるのは、
(→ってあれ？　NSAファイル内のcsvファイルは読み込めてもcsvwriteで書き込むことは
　できないのか。勘違いしてた。)
作っているときはとても便利だけど、セーブデータの管理、
具体的には紐付けとデータ削除時の処理)が面倒になる。
紐付けは簡単にできるけど、「指定した番号のセーブデータを初期化」するのが面倒。
GUIからホイとセーブファイル削除するんじゃだめで、初期化処理を作成しないといけない。
関連してマップ情報の初期化を行うのは非常に大変な気がする。
マップ情報はセーブデータごとに個別処理しなくてはいけなくなっているから
(→宝箱の取得状況も投げてしまっている)

また、csvに書き込む＝変更を確定してしまうわけで、
たとえばその回の探索途中でゲームを強制終了したときにどうするか。
階層移動するごとにオートセーブするようにしてしまうか、
あるいはダンジョンを出入りしたらオートセーブにして、
ダンジョン内でだけ通用する一時ファイル的なものを階層分用意するか。
読み込む時は階層別に読み込んで、
ある階層を離れた時に一時ファイルに保存。
同時にその探索内でどの階層に行ったかをどこかに記録して、
出た時に行った階層のマップ情報ファイルを上書き。
一時ファイルを再び真っさらにする必要は無い(最初に読み込む)。
→紐付け云々はともかく、これには「ユーザーがファイルをいじるとめちゃくちゃになる」
　という危険性がある。個々のファイルは暗号化したcsvだからいいにせよ、
　リネーム・上書きをされるとまずい。
NSAファイル内に放り込んでしまおうと考えていたけど、上記のとおり勘違いだった。
NSAファイル内から読み込む→csvwriteで書き込む→生のcsvファイルが放り出される
という残念な挙動。まあNSAファイルだし無理もない。こっちの要求が無茶だった。
つまり、紐付けをcsvファイルに頼って行おうという以前からの考えは無理がある。
グローバル変数で管理？　できそうだけど具体性がない。
マップ情報についてはどうしよう。ファイル名を無機質にしてしまえばいいのか。
あまりユーザーと喧嘩する意味はないから、その程度で十分か。
初期化処理についてだけは考えないと。
真っさらなcsvファイル
batファイルで上書き
さすがに強引過ぎるか？
→ゴチャゴチャ考えていたら、紐付けの方法を過去の自分が既に作っていた。
　開始時に固有番号(1〜999999999)をランダムに振る
　→マップ情報読み込み時に、マッピング情報先頭にある数値と一致するか判定
　→一致しなかったら(未踏破のマップは当然0を返す)情報を読み込まない
　→そうしたら、マッピング情報セーブ時に結果的に上書きされる。
　→万が一数値が被った時？　そんなものは知らない(後から何かやってもいいけど)！

マッピング情報が保存されるタイミングは、現状だと帰還時。
階層移動時のマッピング情報保存は、階層移動処理を作る時にまとめて。
考えてみればまだ階層移動処理を作っていない。別にすぐ作れるけど放置中。

>ダンジョン内でだけ通用する一時ファイル的なものを階層分用意する
>読み込む時は元のダンジョンのマッピング情報から読み込んで(つまり今と変わらない)、
>ある階層を離れた時に一時ファイルに保存。
>同時にその探索内でどの階層に行ったかをどこかに記録して、
>出た時に行った階層のマップ情報ファイルを上書き。
>一時ファイルを再び真っさらにする必要は無い(最初に読み込む)。
>同じ探索内でその階層を二度目に訪れた時(行った階層情報から判断)は、当然一時ファイルの方から読み込む。
こういう風に仕様変えよう。
temp的なダンジョン名を用意して、書き込み先変えるだけだし。
どの階層に行ったかを記録というより記憶しておく場所だけ考えるといいんじゃないかな。
万が一めったやたらに壮大なダンジョン作った時でも対応できる形が一応望ましいだろうし。

真ん中らへんの要約とまとめ
・初期化はセーブデータ消去時でもなく新規ストーリー開始時でもなく、
　マップ読み込み時(正確には初めてのマッピング状況保存時)に行われる
・マッピング状況保存のタイミングは帰還時になっているが、
　階層移動時に保存するようにすると色々セーブ関係でややこしいから、
　そのダンジョンを出るまでマッピング情報を一時保存する場所を作る。
　ダンジョンを出た時にオートセーブ＋一時ファイルから本来のマッピング保存箇所に保存。
　→一時用csv開く・読み込み・閉じる・マッピング情報保存csv開く・書き込み・閉じる
　　を階層数分行うか、batファイルを使って物理的に上書きするか。
　　見た目には前者がスマートだけど、ロード時間が長くなりすぎてしまうかもしれない。
　　csvファイル開く速度がどの程度環境に依存するやら。
・結局、csvファイルをめちゃくちゃにいじられたらマッピング情報は破滅する。
　マップ自体の書き換えは行えない(マッピング情報はあくまでマップ表示と宝箱用)が、
　現状では宝箱の無限入手が一応可能になってしまう。
　何か対策使用か。そもそもcsvファイルに投げた理由が
　「宝箱の情報保存しておく変数足りないよ、配列変数がメモリ破壊しやがるよ」
　だったから、NSluaの出番かもしれない。
　NSluaの方で定義した変数がどういう風に扱われるのかよく分かっていないので、
　一番最初に検証して覚えるのはその部分。
　あるいは、素のNスク(と愉快な仲間達)だけで有効な対策ができるかもしれない。
　ちょっと考えてみよう。
あまりにも長いダンジョンは、階層ごとにオートセーブってのもありだと思うよ。一応。
あんまり要約にならなかった。

そもそもセーブファイル数を１つにしてしまうという逃げもある。
たぶん歓迎されない。要熟考。

なんだかんだでこの一か月ほどろくに進んでいない。
春から延々メニュー画面作成中といいつつ未だ完成せず。
メニュー完成させたら連絡しようと思ったきり連絡を数か月取っていない高校の友人が一名。
そろそろ本気出さないと縁がぶっちぎれる。春休み中にはメニュー画面作る(笑)



なんたるこった。
いくらなんでもNスクの配列変数がここまで融通効かないとは思わなかった。
splitに指定するのさえ駄目だなんて……デメリットの方が圧倒的に多いじゃないですか。
「現在のところ」という事はいつか対応……今となってはされないだろうなあ。
SGEやらNSlua的な意味で。
とりあえずNscripter標準の配列変数をまともに扱うのはどうやっても難しい。
制約が多すぎる。これはもうNSlua使えという事なんだろう。早くluaの連想配列使おう。

そしてWIZライクでも作らない限り、
raceとsexは使われることのない死にステータスになる予感。
何しろ今の今まで忘れていた。
キャラエディットしてテキストオンリーの戦闘に突撃、
という頃のバージョンで使おうとしていたはず。

numaliasの仕様を理解してなかったその２。
*define
numalias a,1
numalias b,1
game
*start
mov %0,a
mov %1,b
%0と%1。\
同じ数値に複数名前を付けられたんですね、こいつ。

メニュー画面制作の状況
■アイテム使用処理
　→装備選択時にキャラごとの装備可不可・能力上下判定からの矢印アイコン表示を右に表示
　→そのまま装備させられるという処理を作りたい
□特技使用処理
　特技の仕様をいじった方がいい気がしてきた。
　特技を追加するタイミングであらかじめ必要MPと使用可能なタイミングを取得して、
　キャラごとに用意した変数にまとめてぶち込んでおく。参照する時はsplitで取りだす。
　いずれこうしないと読み込みが重くなる気がする。
■装備変更処理
■マップ表示
　→基礎は出来たから、もうちょい色々親切なアイコン表示を出してやりたい。
　　あと低スペックPCだと絶対表示重くなると思う。仕方ない。
□オプション画面
□ロード
■キャラごとのステータス表示(状態異常アイコン表示は未実装)
　→表示位置を考える。右側にアイコン。選択時には文字でも状態を表示したい。

もう五月ですよ？
A.現行のまま
→シンプル。
　ただし行き止まりと途中で引き返した道の区別が付かない。
B.自マスの上下左右の情報を取得
→行き止まりなのか未踏破なのかが分かる。
　角が埋まらないためなんだか気持ち悪い。
C.自マスの周り一マスを取得
→角が埋まる。
　視覚的に見えない部分まで情報を取得してしまう。
　これはミニマップも同じだけど…
D.視界に入った場所を記録
→さすがにこれはどうかと思う。
今さら周囲の壁の情報を取得するようにするのも面倒だし、
早いところどれかに決めちゃおう。
→Cで行きます。

ダンジョン内部でのマッピングしたマップ表示機能を一応作ってみた。
配色センスの問題等はあとで考えたい。
それと、宝箱の位置を表示する意義があるのかどうかも。
周辺一マスくらいは親切でマッピングするようにしてもいいかも。
どちらにしてももう少しいじる必要がある。
2010/03/13の分
メニュー画面作りかけ
HPやMPの現在値/最大値を視覚的に表示するバーの見た目がしょぼくなる。
スプライト使ってもbar命令使っても回避できそうにない。
barと組み合わせてメッセージウインドウで修飾するという強引な手段はあるがやらない。
こればっかりはセンスの問題だから諦めるしかなさそうか。
これは解決しましたが、移動中の特技使用処理において控えメンバーの概念を考えなくてはいけなくなった気がする。
いよいよ今までほったらかしにしてきたゲームデザインを考えなきゃいけないかなあ……
エディタとの兼ね合いから、とりあえずは先にマップ表示を作っちゃおうと思います。
それとキャラの顔は左一杯に詰めちゃった方がいいかもしれない

ごちゃごちゃ修正するモチベーションが足りないので、
先に全体マップ表示を作っちゃうことにした。
本当は早めにやるべき作業なんだけど、延々修正する気力が湧いてこない。
修正するのとしないのとじゃ処理の重さがだいぶ変わりそうだけど……
もういいや。後回し、いつかやる。作業日未定。

今日知った便利な命令、textoff。textclearしか知らなかった。
bgcopyは特定の状況下で有効利用できそう。というかする。
スプライト表示上限が1200くらいあれば必要ないし、
屋内型ダンジョンの5/6が何かしらの物体(道含む)で埋まることは考えにくい。
でも、一応保険は欲しい。仕方がないので
全体図を半分描画した後にbgcopy
↓
csp -1
↓
残りの半分を描画
という強引なやり方を取ろうと思う。
・遊ぶ側がマーカー置けた方がいいのか
・宝箱の位置を記憶≒宝箱の中身入手だが、宝箱の位置を記憶する意味はあるのか
・40×30のマップ内のどのあたりに居るのかが分かりやすくなるが、難易度低下しすぎないか
いっそ目的の座標をアイコンで表示するくらいの親切さをつけようか。
で、実際そこに行くにはやたらめったらグルグル回らなきゃいけないようにしたりして。
……ダンジョンの絵を確保できなければそれも無意味なんだけど。
ダンジョンの描画周りだけでもスプライト番号直そうかな、馬鹿みたいにキツキツだし。
毎回cspとlsp繰り返すくらいならlsphとvsp使った方がいいだろうし。
というかダンジョンのチップ判定自体を直したい。
ちゃんと変数とmid使えば160KBくらいあるスクリプトは10KBくらいに収められるし。
ああでもきりがない、妥協妥協。次があれば生かす。もうそれで妥協。

困った。
スプライト番号を修正しようと決めているのにモチベーションが足りない。
そうこうしているうちに本当に修正が必須なのかも分からなくなってくる始末。
本格的に困った。

当面の予定
作る方
・サイト改装
・罠のアイデアとエディタへの実装
・メニュー画面の残った部分
遊ぶ方
・どこまでゲームに時間を割けるやら現時点では不明。
・ロストプラネット2他数点を買う。

現時点で明確にわかる反省点。
・スプライトの番号管理
　一番痛い。番号が足りなくなっている箇所だらけ。
　今ならまだ直せるギリギリのラインかもしれない。
・戦闘時メニューの大きさとレイアウト
　要反省。大きすぎるしバランスも良くない。キャラの絵も無駄に大きいし。
・defsub命令と実質defsub命令にすべきサブルーチン
　曖昧になっているせいで結局defsubを有効活用できていない。
・汎用変数的に使う変数のまとめが無く、二重のものも
　同じような役割の変数があったり、あちこちで使いまわす変数があったり。
　どの変数が一時的なもので、どの範囲でなら自由に使っていいのかが部分的に曖昧。
　現在の行動を管理する変数において特に顕著。
こういう事態を回避するために最初は短編作れってことなんだろうなあ。
スプライトの番号管理だけでもなんとかした方がいいだろうと思う。
いつか直そう。できるだけ早い時期の夜中に。

もう三月中旬！？
当面の予定
作る方
・リンク追加と改装
・罠のアイデアとエディタへの実装
・メニュー画面の残った部分
・メモしておくページ
遊ぶ方
・現行据え置きを優先して、アサクリ２とEoEと他五本
・タイミングを見計らってロストプラネット他数点を買う

RPGにおける竜の定義を拡大したのはブレスオブファイアで間違いないと思う。
けど、ファンタジー全体として見た場合に定義を拡大したのはゲド戦記になるのかな。
などと思ったので書いておく。四巻までまとめて読んだのが小学生の時なので若干曖昧。

%%と$%は使えるけど$$や%$は使えないんだっけ。
考えてみればそりゃそうなんだけど書いておかないとまた忘れる。
このままオートマッピングを実装できれば同時に罠の仕様も決まるのでエディタが更新できる。
マップ内で使う文字変数とデータを保存するcsvファイルを併用することにしたので、
階層(エリア)を切り替えた時にマッピング状況が勝手にセーブされる。
階層１から階層２へ移動→階層２でゲームオーバー、となった場合、
１のマッピング状況は有無を言わさず保存。２の分は全滅時に保存させてもいいけど、
全滅上等でマッピングを保存しに突っ込むことが可能になってしまうのでどうだろう。

※この仕様だと「データを消して最初から」の処理がややこしくなる。解決手段。
A.csvファイルの末尾にランダムな数値をくっつけセーブデータに紐付けるか、
　あるいはそのマップを訪れたことがあるかどうかを変数に放り込んで判断させることで、
　初めて訪れるマップだった場合にマッピング状況を初期化するという方法がある。
　やるなら前者の方が楽か。
B.一度マッピングした地図はずっとそのまま。そのセーブ番号ごとにずっと共通。
　同人ゲームのマップ固定型ダンジョンRPGを複数周やりこむ人がいるのか疑問なことを考えると、
　これでもいいのかもしれない。ただ、投げやりすぎる仕様ではある。
C.全セーブデータで共通の地図を使う。
　何もしなくていいので一番楽ではあるけれど、さすがにこの仕様はどうかと思う。
ゲームにせよエディタにせよ広まるとも思えないのでBやCでいいと思うけれど、
意地があるので基本的にA、ただしBのようにもするという妥協案で。
csvファイルを一部だけ削除するような人が出てきても知らない。サポート外。

midさん格好いい。素敵。splitから乗り換えちゃうかもしれない。
いやどちらも便利だし共存させますが。そして配列変数、君には失望だ。

とりあえず全部終わりました。お疲れさまでした。以下今後の予定。
・サイトの軽い改装
・エディタに罠実装
・他のスクリプトいろいろ
・山と積まれたやりかけのゲーム消化(非現実的)
・借りていたゲームのクリア(期限アリ)
・やりかけのフリーゲーム数点

今さらですが明けました。
盲点繋がりという訳ではありませんが、
五日前にNScripterの基本的な仕様についての壮大な勘違いに気付きました。
200KBくらいなのでどうかちょっと落して、中身を見てください。■
自分一人の勘違いだったのかそれなりの人数が勘違いしているのかさっぱり見当が付きません。
そんなの当たり前だろという人は勘違いを笑って削除してください。
もしそうでなかった人は一緒に驚いて、それから削除してください。
文字変数0番と数字変数0番は別々の変数だと数年間気付かずにいた。

公式の要望、inputじゃなくてtextfieldなら空欄でも大丈夫だし、
感覚的にも見栄え的にもよろしい気がしなくもない。
splitとかtextfieldとか大好き。
※FAMさんにもらった助言に従ってダンジョンエディタへ追加した分は、
　もう少し暖かくなった頃にゲームと一緒にでもアップロードしようかと思います。
　今年の更新は本当にこれで最後です、あとは春まで我慢します。