タイトル絵描いてからにしようかと
おもったけど正月からこっちたまりすぎてるのでとりあえず公開……。
いいかげんシステムかえないとなってことで、GNS にしてみました。
CSS 考えるのもめどいのぅ。
_ すみませんテスト不足です……。 このへんは素材とかと関係ないので、ちゃんと試験できる時間がとれるはずなのですが以下略。うちの責任 orz
ブロックかかったときはタイムアウトまちになってるのかな？ 要検証^^;
_ ちなみにアップデートは近いうちに全部再配信があるとの噂。 詩子たんわりと活躍でふ
コンタクト完了で打ち合わせセッティングちう
_ 同期は ボイス先頭からの絶対時間で待つ処理をしてます。 Overture では似たようなことを wait 処理をつかってやらかしてまして、 それクリックが超うざいんで次はやめてー(´д｀;) ってことで、 ボイスに同期、かつ、単発クリックで全てキャンセルがかかる仕組みを 組んだのでした。
_ 指定方法は、テキスト＋演出コードをあらかじめ文節分割した上で、 手動と直感のキーボード連打によるタイミング値入力による切り出し、という、 超原始的で死ぬほどめんどくさい……せめて波形とバーがほしいところです。 ええ、時間のかかる原因になりましたよ（号泣）
_ あ、ちなみに、サウンドデータの特定個所で event が投げれるフォーマットは、 吉里吉里が外部データファイルをつかって実現してますね。ループチューナの新しいのだと つくれるはずです。BGM の同期待ちとかで効果的に使えるはずだけど、使ってる例は知らない^^; RIFF や OGG のコンテナにオリジナルタグつくってうめれるとかっこいいよね。
_ しかし、結局、要所要所に、やっぱり wait 命令が使われてる罠。 そもそも使えてしまうのが問題だということで、個別の wait 命令は全削除予定。 行間に演出としての待ちを入れたい場合は、行単位での自動待ち加算指定をつかえばOKってことで。
_ 最近のこのあたりのあるべき姿の個人的結論は以下のようなかんじ。
l快適にプレイできるメッセージウインドウタイプのシステムは次の動作仕様であるべき。
_ これ以外は確実に速読できる高速プレイヤーのリズムを崩してプレイに不快感がでます ^^; で、実現するには、以下のようなシステム対応＋スクリプト原則が必要。
_
あと、強制同期演出は、音楽またはムービーが伴う場合に限りしぶしぶ許可(ぉ
これは、↑とはあきらかにスクリプト思想が違うので、独立した
専用の再生系を準備したほうがいいでしょうね。一種の単発ムービー扱い。
_ シーケンスを飛ばす、 はい。そういうことでして、「行 = クリックで処理がとばされる範囲」と定義しなおすわけです。
_ 従来定義は 行: 会話文一つ、または、適当なコマンドの固まり（単に見た目上の区別）でした。 会話文の処理ロジックには、ボイス同期をいれたときにあわせて、WAIT 含めた処理の一括キャンセルの機能を入れ込んだけど、 コマンド行のほうには入れて無いので、いちいち「待ち」で待ってしまったのが敗北。
_ ああ、そうすると、記述上は「待ち」は残してもいいのか……。 そうすると、今の沢村さんの記法そのままでOKということに……ダメでした。 沢村さん、コマンド記述でひたすら行わけちゃってます。ex：お嬢様登場。 一連の処理は必ず「１行」におさめてもらうのが前提。範囲の自動判定むりぽ。 たぶん動作確認しながら作業しやすいように分けて作業して、そのままなんですね。
_ うーん、一連のコマンド行をまとめる概念の導入もなぁ……。 そういったところは作業おわった段階で行をまとめてもらうような習慣をつけてもらうか。 でも習慣でカバーは敗北の要因。入力用パネルは要改善。あと、コマンドの連続を警告する検証ツールも。 スクリプト記述上ももちっと考えないとダメな予感。空行で対応か範囲記述の記法を準備するか。
でも開始時間を指定するようにするのが、会話文処理との記述概念整合はとれるんだな。 いっそ、個別のコマンドに at (コマンド列先頭からの絶対開始時間指定) と delay (カレントからの相対開始時間指定) と wait (次のコマンドに対する開始遅延)のパラメータを全部つけるか。 問題は記述法。操作パネルのほうではコマンドも全部専用のフォーム化するのが大前提ですな。 スクリプト記述的には、名前つき引数が必要だな。その点 KAG は偉い（苦笑）
_ 目ぱちの件は、コマンド行で処理するなら↑の仕様変更で１クリックになるから、 まあ、問題軽減されるとして、会話と同じ行にいれこむなら、行の最初の文節を 空テキストにしてしまえばいいんじゃないかな……ってボイスが開始されるから困るのか。 ボイス前に実行するコマンド、という専用構造「会話行」にいれこむのが妥当かな。 考えよう。
_ テンプレートはまた別の話ってことで。あったほうが良いのは確かです。
_ あとバックグランドでの処理は、ありますよ？ ^^; スクリプトを低レベルでかかないといけないのがアレなので、 これは専用の記入しやすい新体系で対応ってことで。 「やえさえラジオ」が十分記述できるようなものを（これも低レベルでべた書きしてる）。 これの管理、今「環境」の機能として持ってるものなので、 機能分離的に正しくなさそうなので、シーンプレイヤー側に 管理を移動したほうがいいかも。
_ なんやかやで出先のネットがなにも無いところで、ＰＣからネットワークに つなぐことが必要な場合がちょくちょくある、ってことで、えあえぢを ネット25 で復活することに。
| 環境 | サービス | 費用 | 主な用途 |
|---|---|---|---|
| Zaurus | bitwarpPDA | ￥2,100 | IRC, WEB |
| PC | ネット25 | ￥3,402 | 出先での接続全般 |
| HotSpot | ￥1,680 | 外でお仕事, 大量ダウンロード＠駅 | |
| 合計 | ￥7,182 |
HotSpot は、6月からは WILLCOM の無線サービスに切り替えれば費用削減できるかな。 ただ、結局、事務所にこもって仕事ばかりになってて （最寄り接続ポイントだったリコッタがつぶれちゃったので……） 月にせいぜい 2,3回ぐらいしか使ってないので、1day でもいいのかもしれない。
一応今月後半＋来月ぐらいのネット25の使った量をみてみて、
17時間を越えないようなら、Willcom は全解約して、
b-mobile
への乗り換えも検討してもいいかも。1時間あたり200円換算です。
これ、無線との換算が、3時間、とかならホットスポット代替でも
いいんだけどな。HotSpot の 1Day チケットより高いのはちょっと悲しい。
b-mobile ONE の２年コースだとかなり割引だけど、 ２年先までには
なんか新しいのでてそうだから恐くてかえないね（笑）
_ RSS全文か要約かのバトルはぐぐるとたくさん見つかりますね（挨拶）。 セマンティックの夢やぶれた HTML の代替物扱いなんだろなー。
_ そうだ！ RSS で CSS とかが使えるようになればいいんだ! 俺頭いいな。
_ とかアホなこといってなくても Content-type が text/xml なら、昨今のブラウザなら普通に通るよね。たぶん ＜さっぱり試さずに言う。それオンリーにすればそれはそれでかっこいいかもしれない。 あ、でも RSS の description の中ってタグはダメなんだっけ？←わりと無知。 あー、たしか Atom なら summary に要約書いて、content に本文で XHTML 記述してOKだよね。
_ ということで「Atom ＋スタイルシートで日記本体を公開するので、 素の XHTML や RSS が欲しい人は XSLT かましておくれ」ってのがわりと 技術としては美しいのではなかろうかとつぶやいておく。人のつくったツールに 頼っている俺は自分では作業はしない（ぉ
_ 追記。ぐぐってて見つけた、「Atomが必要な理由」。 ま、「RSS に全文本文をうめこむ」≒「HTML 2.0 で日本語つかう」、ってことですな。つまるところ美しくない。 GNS も Atom も採用希望（笑）
_
まあ、
「正常な進化」・「正しい姿」をまじめに実践しようとしてるのは、Atom のほうだねってことで。
全文派とそれに異義申し立ててる派、両方が満足する状態って
「（現行の）RSS と RSSリーダが滅亡」した先にあると思います。
統合の話はどのくらいすすんでるんだろう。だれか良いポインタあったらおしえて^^;
_ おお、 GNS で Atom が。 でも content が type=html で CDATA なので、うれしくないです（苦笑）。 やはりここは XHTML なコンテンツのうめこみにするしか……ってXML整形式化がめどかったりするのかしら？
_
RSS への明示的リンクはなくして link alternate に置き換え。
_
HTML 混在の問題。
本体側は地道に XHTML 化するとして、
ユーザ入力部分は一旦 Tidy をパイプで呼んでフィルタ処理かけてしまうってのは
そこそこ実用ラインになるんじゃないですかね（想像）
メールはこちらへ...[わたなべごう (go @(at) denpa .(dot) org)]
この日記は、GNSを使用して作成されています。