バグフィクス版をアップロード
2015年に公開された Windows PC 用エクステンションのバグフィクス版です。動作検証及びバグ報告をしてくださったユーザ様へ、感謝申し上げます。
rev 1.0.4 を 1.0.5 へアップしました(03.Nov.2018)
参考:バグ報告とタブ区切り方式
仕様など:エスケープ処理
入れるのを忘れていたため、CSV(カンマセパレート形式) 形式あるいは TSV(タブセバレート形式)でも指定されたデリミタに対するエスケープ処理ができません。
このエクステは当初、ペンタくん専用のエクステとしてマップデータをネット経由でやり取りする用途などを想定して作られました。マップデータをやりとりする用途だと「A10,B10,C24,D01,,,
」こんな形式のデータしか扱わないため日本語も英語も「文章」を含めて送信する可能性についてはすっかり頭から抜け落ちていました。
rev1.0.5 にエスケープ処理を入れるかどうか検討もされましたが、時間的に余裕が無いためエスケープ処理については未実装のままとしました。
仕様など:エクスプレッションの制限
バグではないのですが rev1.0.5 で未実装の部分として、エクスプレッションエディタからの利用にも制限があります。以下のような使い方は GArR rev1.0.5 でもご利用いただけません。
二次元配列化したデータにアクセスするためには一般的にループ処理を使うのですが、ループ処理を使わないでエクスプレッションエディタから直接配列要素を複数指定して値を取得する方法があります。これができません。
この部分は意外と高度なループ処理がエクステ内部で実行されているため、サンプルのソースコードをいくつか見たけれど実装が面倒くさかった。そして厄介なデバッグもある。
Element2D$("GArR", 0 ,1)+Element2D$("GArR", 0, 2)
例えばこう書いた場合現在の GArR だと最初のElement2D$("GArR", 0 ,1)
は無視されてElement2D$("GArR", 0, 2)
こっちだけ値が二回取得されます。
Conditions の二値比較条件からは
Element2D$("GArR", 0 ,1)+Element2D$("GArR", 0, 2)
このように書いても大丈夫なのですが、アクションから実行される場合はアクションループを考慮したエクステの作り方というものがあります。しかし申し訳ないのですが労力的にこの部分はこれ以上時間かけて作りたくなかったので処理を省きました。
その他
デバッグを兼ねて GArR を使った自分用ツールの .mfa ソースをサンプルとして配布ファイルの中に入れてあります。
GArR を使わなくても作れるのですが、今回バグ報告を受けた際に人それぞれ使い方というものがあるのだなと思い知らされた部分があって、それに影響を受けた作り方になってます。具体的には以下
こういう発想が自分には無かった。
もともとネット経由でデータを取ってくることしか考えてなかったので、エクスプレッションエディタを活用してデータソースを入力するというやり方はあまり試してませんでした。
ツールとしての使い方は今回特に説明しませんが、自作ゲームのメッセージシステムを補助する目的で作られたツールです。クリップボードにスクリプトソースをコピーしてそれを Python でCSV にパースしてから GMS で読み込んで使う、そんなツール。
GMS ではこういうツールは作れないからやっぱ CF25 なんだな。
GArR rev 1.0.5 ダウンロードはこちら
ダウンロード:GArR rev 1.0.5
不具合報告などありましたらブログのコメント欄をご利用ください。メールも受け付けていますがたまにチェックサボったり忘れたりスパム判定されてゴミ箱に入っていたりします。
ご無沙汰しております。
いつも不具合報告で申し訳ないのですが、また偶然見つけてしまいましたので報告します!
正確な発動条件はわかりませんが、「服」というワードと特定の文字の組み合わせで先頭の1文字が掻き消えてしまいます。
例)服からか→からか
なんとも不思議な現象ですが、とにかく「服」という文字と一定の文字が複合すると発生するようです。
今のところ、他の文字では発生していません。お時間のある時に調べて頂ければ幸いです。よろしくお願いします。
こちらこそいつも報告をありがとうございます(そして毎度返信が遅れて申し訳有りません)。
バグについてはこちらでも再現性を確認しました。ソースコードにまだ手を入れることができないため修正できないのですが、UTF-16の文字コード中に含まれるバイナリパターンをキャリッジ・リターン(復帰)として解釈してしまっているようです。キャリッジ・リターンは三種類ある改行コードの一つで、古いMacOSで利用されていた形式。プログラムでは「CR」とか「\r」で表現されます。
>「服」という文字と一定の文字が複合すると発生
ではなく、文頭に「服」あるいはUTF-16バイナリで見ると「服=670D」の「OD」が改行(CR=0x0d)として誤認されます(だから「服」という文字一つでもバグを再現できます)。まだ全部は確認していませんが末尾「0D」のバイナリは文頭に置けば全てバグを起こすはずなので現在ダメ文字として認定できるものは以下にまとめられるだろうと考えています。
服
」
鰍
伍
植
損
鈍
納
倍
不
名
エクステの修正版は8月か9月のアップロードとなってしまいます(七月は少なくとも無理)。申し訳ありません。GArR 1.0.5 における暫定的なバグ回避策としては文頭に上記リスト中の文字列を配置しない等で、対応をお願い申し上げます。
お手数おかけします。
prester
お忙しいところ、お手間掛けます。
バグについて、再現できたようで安心?しました
(こちらでも、具体的にハッキリとこうだ!という例を挙げられなかったので)
原因も推測できているとのことなので、心強い限りです!
速度の面において、GArRは頭ひとつ抜きん出ているので大変重宝しております。
修正作業はpresterさんのお手隙の際に進めて頂ければ幸いです。
それでは、よろしくお願いします!
バグフィックス版を rev1.0.6T としてアップロード
http://prester.org/cf2.5/?p=5879
大変おまたせしました。