【エミュレータ】Emueraスレ【＋α】 - 1290444111

1：Emueraの人：2010/11/23(火) 01:41:51 ID:mrlVhh/.0: このスレはEmuera（エミューラ）に関する話題を扱うスレです。
Emuera本体に関する要望・バグ報告などありましたらこのスレでどうぞ。
各ERBスクリプトに関する話題はそのバリアントのスレでお願いします。

なおeramakerの作者である佐藤敏様はEmueraの製作には関与していません。
Emueraへのサポート要求等をサークル獏様や佐藤様宛てに送らないで下さい。
197：191：2011/04/21(木) 18:42:55 ID:IbLOjg2M0: 遅レスすまん

>>193
そういった方法があるとは知りませんでした
代替方法でも実装できれば問題ないです
帰ったら色々試してみます
情報ありがとうございました
198：妊）|дﾟ)：2011/04/25(月) 00:09:41 ID:sEFy9Yks0: ttp://ux.getuploader.com/ninnohito/download/239/Emuera1756beta2%2B.zip

・beta2+v22
式中関数の再帰処理の問題修正
199：妊）|дﾟ)：2011/04/26(火) 20:44:32 ID:a3WFVMZE0: ttp://ux.getuploader.com/ninnohito/download/240/Emuera1756beta2%2B.zip

・beta2+v23
LINECOUNTの実装をCLEARLINEとの兼ね合いを考えてCLEARLINE型のカウントに変更
（内部処理中で分割された行も全部まとめて1行とカウントされます）
200：妊）|дﾟ)：2011/04/27(水) 20:07:01 ID:AYxcTOns0: ttp://ux.getuploader.com/ninnohito/download/241/Emuera1756beta2%2B.zip

・beta2+v24
CLEARLINEでLINECOUNTの値が更新されないのを修正
201：妊）|дﾟ)：2011/04/28(木) 07:11:30 ID:4seV2V2c0: ttp://ux.getuploader.com/ninnohito/download/242/Emuera1756beta2%2B.zip

・beta2+v25
コードの再読み込みが例外投げまくってくれる場合があるのを修正
202：193：2011/05/03(火) 23:09:25 ID:kLneOfZo0: >>191
IRCのログを見たら「お前は何を(ry」と言われてしまっていたので改めて確認してきました。
現在の正式版 (1755～) では何もしなくとも普通に全角スペースを文字として認識してくれますね。

俺が >>191 の現象に出くわしたのはかなり前 (確認したところ、1736 当時) だったので、
その後のバージョンで現在の仕様に変わった (直った？) のを知らないまま
>>193 のような認識を続けていた、というオチでした。
(半角スペースがどうしようもないのは変わらないので、個人的には %""% 方式を続けますが)

ということで、

　・Emuera のバージョンが古くないか
　・「設定」→「システム」→「全角スペースをホワイトスペースに含める」にチェックが入っていないか

の２点をご確認ください。
1736 は１年以上前のバージョンなので、おそらく後者でしょう。

お目汚し失礼しました。
203：妊）|дﾟ)：2011/05/04(水) 00:55:40 ID:HLSH3oW60: ttp://ux.getuploader.com/ninnohito/download/244/Emuera1756beta2%2B.zip

・bata2+v27
RETURNの引数が省略されたときRESULT:0に0が代入されなくなっていたのを修正

（報告抜け）
・beta2+v26
定義済み色名から文字色を定義するSETCOLORBYNAME実装
書式：SETCOLORBYNAME <定義済み色名>
定義済みの色名はC#内部で扱われるKnownColor列挙体(ttp://msdn.microsoft.com/ja-jp/library/system.drawing.knowncolor%28v=VS.80%29.aspx)に準拠します
204：妊）|дﾟ)：2011/05/09(月) 23:44:35 ID:B6u2k7TU0: ttp://ux.getuploader.com/ninnohito/download/245/Emuera1756beta2%2B.zip

・bata2+v28
システム関数中でARGを使っても警告が出ないのを修正
205：妊）|дﾟ)：2011/05/10(火) 00:06:20 ID:MX71cchw0: ttp://ux.getuploader.com/ninnohito/download/246/Emuera1756beta2%2B.zip

・bata2+v28（差し替え）
ちょっと事故コードをインプリしていたので修正
206：名無しさん：2011/05/21(土) 02:12:12 ID:me1SN8Mc0: 要望ですが、キャラクター変数に２次元変数を追加出来ないでしょうか

主人中心では無く、キャラ同士の好感度や恋慕等の素質を実装したバリアントなども増えて来ている為、
それらの情報を格納し易いメモリ領域を用意して貰えれば、開発が楽になると思います
（キャラクター変数の２次元変数なので、実質的には３次元変数です）

要素数も初期値を最小にしておけば、使わないバリアントでもメモリ消費は気にしなくて良いレベルになると思うので、
ご検討頂けたら嬉しいです
207：妊）|дﾟ)：2011/06/03(金) 01:33:29 ID:S5bRnLts0: ttp://ux.getuploader.com/ninnohito/download/248/Emuera1756beta2%2B.zip

・bata2+v30
TINPUTSの実装がtypoの結果大変なことになっていたのを修正

>>206
これについてはEmuの人の判断次第ということで
208：名無しさん：2011/06/11(土) 03:41:24 ID:5uQrGsLk0: ユーザー視点での要望です。
セーブデータのうっかり上書き対策として、セーブデータが上書きの場合、
旧データのバックアップを自動的に作ってくれると嬉しいです
（付けるとしたらオプション機能で番号はsave98あたりが適当か？）
よろしくお願いします
209：名無しさん：2011/06/11(土) 10:20:11 ID:588fbNjc0: 要求するのはいいけどもうちょっと仕様つめた方がいいんじゃない？

上書き時には、本当に上書きするか聞いてくるのにまだバックアップ必要？
バックアップのさらにバックアップは要らない？
(上で言うとsave98のバックアップ)
210：名無しさん：2011/06/11(土) 22:44:05 ID:gfzIDmbA0: うっかり上書きして困るんなら、上書き禁止機能のほうが確実なんじゃ？

上書きしようとすると
＞このセーブデータには上書きできません。
＞別のセーブデータを選択してください。
てな感じの。
211：名無しさん：2011/06/11(土) 23:27:45 ID:588fbNjc0: それだとセーブ数の20回しかセーブできないことになるわけだがそれで良いのか？

実のところ、オートセーブの世代数を無限にするとかの方がいい気もするな。
212：名無しさん：2011/06/12(日) 00:36:08 ID:ug7zCFWM0: 上書き禁止フラグＯＮ／ＯＦＦの切り替え可にしとけばいいんじゃないか？
この場合、どこで切り替えるかが問題だが。

バリアントによってはセーブデータ個数・容量が恐ろしいことになりそうだから
オートセーブの世代数を無限ってのは勘弁して欲しいけどね。

・・・そんなＰＣ使うな、って言われそうだが。
213：名無しさん：2011/06/12(日) 01:21:43 ID:GKNQbq2o0: さすがに再起動しないとオンオフが切り替えられないのでは、お話にはならんだろうなぁ。

ある意味では上書きフラグは「オフ」になっていて、上書きするかどうかその都度聞かれて「オン」になっているとも言えるわけだが。

オートセーブの世代数に関しては当然コンフィギュレータブルで、
現在OFF/ON(1世代)となってるのを、OFF/n世代/無制限とするだけだろうね。
面倒くさいのはロードの扱いだが。

結局>208みたいな粗忽なバカは何をやっても救えないので「ファイルシステムの方のスナップショットを拾ってください」でもいいい気はする。
214：名無しさん：2011/06/13(月) 02:54:56 ID:3i0HKCr.0: 以前にもちょろっと話があったかも知れませんが、
「関数が存在するかどうかをチェックする命令」が欲しいです。
関数がある／式中関数がある／ない　の3つが分かると理想的ですが、いかがでしょ。
215：名無しさん：2011/06/13(月) 03:05:51 ID:N6HBRjOM0: で、try catchでいいじゃんって話になったと思うわけだが。

それでダメだと思うなら、妥当なユースケースを提示しないと実装する気にならんと思うよ。
216：名無しさん：2011/06/13(月) 21:39:23 ID:3i0HKCr.0: 「あったら実行する、なければ何もしない」だと
あるかどうか知りたいけど実行させたくないときがちょっと不便ですね

ま、今遭遇したのはCOM**作りきる前にテストプレイしてるときとかですので
これがないと作れないものがあるとかってわけじゃないですが。
217：名無しさん：2011/06/14(火) 00:11:26 ID:BAge3lgI0: 実行しなくてもいいなら、テキストエディタのGrep機能で
@COM1～@COM9やればリストアウトできるんじゃね？
218：名無しさん：2011/06/14(火) 01:08:09 ID:MCOYkqZg0: というか、TRYC～でいいじゃんという話になった、というよりは

「関数の存在チェックが～」
「TRYC～でできるだろ」
「どれだよできなくね？」

で止まってる話題だねえ
219：名無しさん：2011/06/14(火) 01:25:24 ID:a2HnH8NA0: >>215
昔>>183で要望した者だが、>>183-185の話だな

＞で、try catchでいいじゃんって話になったと思うわけだが。
>>218氏に書かれてしまったが、途中で止まってるのが正解

＞妥当なユースケースを提示しないと実装する気にならんと思うよ。
事前判定に使うので、以下の様な用途じゃ駄目かね
> 「存在しても実行せず、存在の確認だけを行う命令」
> （用途：事典などで説明関数が存在しない項目をグレーにしたり、事前判定に使用）

存在チェックはtry catchじゃ不可能なんで、実装を心待ちにしていたり。あると便利だし
220：名無しさん：2011/06/14(火) 01:54:43 ID:7vW/IFgg0: 適当な引数渡して、それを見たら関数の冒頭でRETURNさせればいいだけなのでは
SIF ARGS == "CHECK"
　　RETURN 0
とかなんとか
まあ、あればあった方が楽なんだろうけど、心待ちにするほどの用途かは疑問
221：名無しさん：2011/06/14(火) 02:11:05 ID:MCOYkqZg0: 引数のない関数に限定すればそれでもいいかもね
222：名無しさん：2011/06/14(火) 02:18:59 ID:7vW/IFgg0: 言ってることがよく判らない
引数があるとなんで>>220の方法が使えないのだろう
定義したARGSのサイズを、全て本来の引数で使い切ってたら無理だけど、
それなら定義変えりゃいいだけだしねぇ…
223：名無しさん：2011/06/14(火) 02:20:08 ID:a2HnH8NA0: > 心待ちにするほどの用途かは疑問
辞書項目とか下手すると200とか300とかの関数が作られるんだし、
これら全てに関数内部でチェックさせるのは流石に非効率かと
また他にチェックしたい場面が発生した場合に、個別にカスタマイズしないといけない労力が発生するのも難点

一応現在はインデックス関数作ってそこ見る様にしてるけど、これも２重管理だし正直どうかなっていう
そりゃ「○○すれば良いじゃん」って言うのなら、過去の変数の宣言不能ですらメモリ管理すれば何も問題無い筈だし…
それは要望の本質間違えて無い？っていう。現状より便利にしたいのと、現状で不可能か可能かは視線が違うかと
224：名無しさん：2011/06/14(火) 02:22:13 ID:85xwxaKM0: そもそも存在の確認だけだったらERBフォルダのD&Dでいいじゃん
あとはデバッグウィンドウの活用でどうにかなるんじゃない？
225：名無しさん：2011/06/14(火) 02:23:15 ID:MCOYkqZg0: >>222
現実的じゃないと思うの
226：名無しさん：2011/06/14(火) 02:28:16 ID:7vW/IFgg0: >>223
何百個も並列で存在する関数なんて、最初にテンプレ作って内容埋めるんじゃないの？
全部1から書き起こす訳じゃあるまいし、
テンプレに入れといたら労力としては実質0だと思うけど
それこそインデックスで二重管理するよりは、シンプルで楽だと思うけどなぁ

いや別に俺は、その要望に反対してる訳じゃないよｗ
ただ心待ちにするくらいなら、自前で解決した方が早いんじゃないかと思っただけ
227：名無しさん：2011/06/14(火) 02:29:19 ID:MCOYkqZg0: >>226
どうして「関数の存在をチェックする関数」の使用対象が
「何百個も並列で存在する関数」だけってことになっちゃってるの？
228：名無しさん：2011/06/14(火) 02:38:37 ID:7vW/IFgg0: >>227
別にそれはお前さんに言った訳じゃないし…
お前さんにレスをつけるとするなら、現実的じゃないとは思えない
そんだけ

なんか作りかけで具体的に困ってるなら、それを見てみたいな
ひょっとしたら、解決に協力出来るかもしれないよ
229：名無しさん：2011/06/14(火) 02:52:10 ID:yTsl2IMM0: テンプレ作る段階じゃなくて既に相当数ある関数に存在判定付けたい場合はまあ>>220は正規表現+置換とかでも使わんとめんどくさいというかしんどいよね
例えば口上とかRPG系のスキルやらなんやらとか

あと地味なところで式中関数である＝他の式中関数で使用可能っていうのが便利というか
FORMで呼べる式中関数とても待ち遠しいですハイ
230：名無しさん：2011/06/14(火) 04:26:32 ID:l37tGw5Q0: >>229
> テンプレ作る段階じゃなくて既に相当数ある関数に存在判定付けたい場合はまあ>>220は正規表現+置換とかでも使わんとめんどくさいというかしんどいよね

？？？
既に存在判定がなくても動作していたコード群なら、わざわざ後から存在判定関数を追加する必要がないのでは？

> 例えば口上とかRPG系のスキルやらなんやらとか
今でも口上のテンプレートを変更するときには、どうせ苦労して追加する必要はあるので、何が問題だか分からない。

> あと地味なところで式中関数である＝他の式中関数で使用可能っていうのが便利というか
> FORMで呼べる式中関数とても待ち遠しいですハイ

式中関数の有無が、どのようにチェックできることを想定しているの？
上のARGS == "CHECK"でなにか困るの？
イメージが沸かないから一度サンプルコード書いてみてよ。
231：名無しさん：2011/06/14(火) 05:14:45 ID:7vW/IFgg0: ＞わざわざ後から存在判定関数を追加
>>223の方式から移行するとしたら、ということでしょう

式中関数云々はよく判んない
↓みたいなことを言ってるのかし…
PRINTFORML %%hoge_f()%_f()%
@hoge_f
#FUNCTIONS
RETURNF "hogehoge"
@hogehoge_f
#FUNCTIONS
RETURNF "hogehogehoge"
232：名無しさん：2011/06/14(火) 08:17:01 ID:l37tGw5Q0: >>231
> ＞わざわざ後から存在判定関数を追加
> >>223の方式から移行するとしたら、ということでしょう
意味がわからない。

> 式中関数云々はよく判んない
> ↓みたいなことを言ってるのかし…
式中関数の有無の確認をしているコードには見えない
233：名無しさん：2011/06/14(火) 08:31:55 ID:l37tGw5Q0: >>231
> 式中関数云々はよく判んない
> ↓みたいなことを言ってるのかし…
あぁ。>229は途中で全く別のことをいい始めていたのか。

意味はわかったが、具体的な使用コード例をあげて欲しいところ。
どうしても式中関数でそれをしたいというシーンが思い浮かばん。
式中関数は制限も多いし。
234：名無しさん：2011/06/14(火) 09:48:41 ID:1x0TlfykO: 誰も「こんな関数がないと開発ができなくて困ってます」とは言ってないのに
なぜか既存の関数でいかにして実現するかの流れになる不思議

そりゃおめえ、切符間違えて買わないように気を付けりゃいいし
安いの買っちゃったら駅員に言えばいいから乗り越し精算機は要らんね
235：名無しさん：2011/06/14(火) 10:18:04 ID:A4ZNDegw0: その辺は利用頻度というか費用対効果しだいでしょうな
東京駅に乗り越し精算機を置くのは有用だけれど
地方の寂れたローカル駅に置くかどうかは鉄道会社の判断しだいだ

もちろん意見出すのは有意義だけど、開発側からレスポンスがないってことは
作る苦労に見合わなさそうだと思われているんじゃない？
236：名無しさん：2011/06/14(火) 11:32:04 ID:1x0TlfykO: そうだねえ。例えばテンプレに

要望に対して開発者からのレスポンスがつかないものは、
費用対効果に見合わないなどの理由で実装される予定がないものだと思ってください。

とでも書いておけば同じ話題が繰り返されることもなくなって良いのではないでしょうか
237：名無しさん：2011/06/14(火) 15:49:45 ID:B2HombaI0: 費用対効果なんか、もともと存在しねぇよｗ（フリーなんで持ち出しオンリー）　というひやかしはさておき
なんにしろ開発者以外が要望にたいしてあーだこーだ言う類のもんでもなかろう
開発者にしたって、Emuの人と妊の人ぐらいなんだから、そうそうレスポンスもないしな
238：名無しさん：2011/06/14(火) 17:08:53 ID:FArEGD1I0: 今更ですまんが、関数の存在だけを判定する命令は随分前にIRCで案が出されて速攻で却下されてたぞ
239：名無しさん：2011/06/14(火) 20:30:18 ID:l37tGw5Q0: >>234
そりゃ困ってもいない。つまり使うあてもない新機能を実装を実装しろといってるとは誰も考えないからだよ。

お前の例えで言えば、電車に乗ったこともない奴が乗り越し精算機を導入しろと騒ぎ立てているようなもの。
そんなキチガイ相手する必要ないだろ
240：名無しさん：2011/06/14(火) 20:47:20 ID:1x0TlfykO: ははあ
ちょっと待ってくれ、翻訳機の調子がおかしい
241：名無しさん：2011/06/14(火) 20:51:59 ID:l37tGw5Q0: チョンかよ。
242：名無しさん：2011/06/14(火) 21:06:21 ID:85xwxaKM0: >>241
ぅゎ……
243：名無しさん：2011/06/14(火) 21:08:21 ID:BDi7Ide60: どさくさに紛れて今更な質問するが
emueraってeramakerで採用されているERBに独自拡張を加えていて、
どの程度拡張するかはemueraの人の裁量って事でいいんだよね？
244：名無しさん：2011/06/14(火) 21:52:47 ID:l37tGw5Q0: >>243
> どの程度拡張するかはemueraの人の裁量って事でいいんだよね？
今更で当然の話だね。

ただ、ライセンスには
以下の制限に従う限り(略)自由に改変して再頒布することをすべての人に許可します。
(以下略
とあるわけだから、ライセンスに従って自由に派生して独自拡張してもいいのよ。

>>229は待ち遠しいなんて言わずに自分で追加実装してもいいし。
IRCで断られたという、関数の存在だけを判定する命令だって、自前で実装して配布してもかまわないわけよ。
245：名無しさん：2011/06/14(火) 22:37:24 ID:3QV7F76E0: 今では共同開発みたいな感じだけど、元々私家版もそういう本家と無関係な派生物だったわけだしな
実際本家では実装が見送られたり、取り込まれても仕様が異なったりしていた
246：名無しさん：2011/06/14(火) 22:49:26 ID:BDi7Ide60: >>244
サンクス
そうであるなら個人的には、指摘だけでなくコードの提示も行った方が建設的だと思うよ

>>245
なんとなく、機能的には私家版∋emuera本家∋eramekaerって思い込んでいたが
そういう訳ではないね
どもです
247：名無しさん：2011/06/14(火) 23:01:28 ID:l37tGw5Q0: >>246
> そうであるなら個人的には、指摘だけでなくコードの提示も行った方が建設的だと思うよ

オレもそう思うよ。そこまでやろうとするひとは全く見られないが。

もしオレに「コードの提示も行った方が建設的だと思うよ」と言ってるなら筋違い。
新機能を実装しろなんて指摘はしたことがないのだから。
オレから見て妥当な仕様提案は一つも見られないから、コードの実装をする気にはならんね。

実際に使用してうれしい使用例の提示があれば、妥当な仕様提案に見えるかもしれないが、そういう提示も全く見られない。
248：名無しさん：2011/06/14(火) 23:57:47 ID:a2HnH8NA0: バリアントと違って本体だからね。余り派生とか私家版専用命令とかは作りたくないっていう
今でさえEmueraの機能を全部把握してる人間なんて少ないんだし、この上派生で仕様が違うとか勘弁だろｗ
「こういう命令組もうと思ってるけど取り込める？」とか相談して、開発前に実装可否が聞けるのならコード組む気は起きるけどね
作った後で「取り込み無理」ってなって、本体の派生毎に仕様が違うとかなったら目も当てられないかと

私家版でスタンダードになってやる、ぐらいの気概が無いと無理だし、そんな気力は無い。というか不可能。本体が優秀過ぎる
でもってEmuの人も見えないし、相談して開発とか無理っていう。それなら要望を出して実装を待ちつつも、既存機能で組むのが安牌となる
249：名無しさん：2011/06/15(水) 00:55:25 ID:U9m.p6Fo0: このスレいつからこんな変なのが来るようになったんだろうな
250：名無しさん：2011/06/15(水) 01:13:24 ID:tpc7SvCU0: かといって、やれば出来るからで全部却下ってのも、それはそれで変な気がする
出来る出来ないで言えば、TRY系が無くてもダミー関数等で対応は出来る
100以上のキャラの扱いも
可読性が失われるとか、処理が遅いという問題はあったけど

これが無いと出来ないって事はもう出尽くしてる
やらないと明言された物以外だと、利便性の向上ぐらいしか出てこないと思う
251：名無しさん：2011/06/15(水) 02:25:48 ID:tpc7SvCU0: >214の件実装出来たのでソースだけ貼っとく
下の２つを似たようなのが並んでる箇所に挿入してコンパイルすれば
FUNCTIONEXISTS( 関数名 )　という式中関数が使えるようになる

>Creator.cs
methodList["FUNCTIONEXISTS"] = new FunctionExistsMethod();

>Creator.Method.cs
private sealed class FunctionExistsMethod : FunctionMethod
{
public FunctionExistsMethod()
{
ReturnType = typeof(Int64);
argumentTypeArray = new Type[] { typeof(string) };
CanRestructure = true;
}
public override Int64 GetIntValue(ExpressionMediator exm, IOperandTerm[] arguments)
{
return (exm.Process.LabelDictionary.GetNonEventLabel(arguments[0].GetStrValue(exm)) == null ? 0 : 1);
}
}

#動作確認用のERB
IF FUNCTIONEXISTS("SHOW_SHOP")
PRINT 関数有り
ELSE
PRINT 関数無し
ENDIF
252：妊）|дﾟ)：2011/06/15(水) 02:34:30 ID:/H8WE2yY0: さて、何かよくわからんことになってますが

Emuの人がどう考えるかは自分にはわかりませんが
自分としては関数の存在判定の必要性を感じませんので実装予定はありません
253：妊）|дﾟ)：2011/06/15(水) 02:39:08 ID:/H8WE2yY0: 後、Emuの人ですが、
こちらの方でももう1ヶ月以上音信がない状態が続いておりまして、
いつ正式版が出るのか皆目見当もつかない状態になっています
254：名無しさん：2011/06/15(水) 02:39:59 ID:JCvsg9920: 妊の人に代わって私家版を作る時期かなこれは
ぶっちゃけた話遅くならない限り、メソッドは何があっても良い筈だし
YMみたいにバンバン混ぜれば良いんじゃね。使いたい奴だけ使う感じで
255：名無しさん：2011/06/15(水) 02:51:56 ID:U9m.p6Fo0: ま、本家が更新されるごとに>>251のコードを拝借して逐一追加してもいいんでない
256：名無しさん：2011/06/15(水) 04:42:33 ID:OCHaGaro0: そもそもTRY何とかの山をつくるよりも、確認関数を１本作るだけの方が筋が良かったと思うけど。
257：妊）|дﾟ)：2011/06/15(水) 05:17:30 ID:/H8WE2yY0: >>256
エンジンの側から見れば、想定通りの動作を保証できないような処理の方がはるかに筋が悪いのです

文字列をキーした探査なんて、その人1人で閉じたコードならともかく、
それ以外の環境ではバグハッピーで、とてもじゃないが使わせたくない代物です
自分が見ようとしているものが本当に自分が見たいものかなんて確認のしようがないのですよ
258：名無しさん：2011/06/15(水) 05:23:23 ID:OCHaGaro0: >>257
結局trycallだって同じ処理をしてるわけで。
何を気にしてるのかさっぱり分かりません。
259：名無しさん：2011/06/15(水) 05:25:12 ID:JCvsg9920: まぁ少なくとも平方根出す関数が追加されてる時点で、必要性云々を言い出すのは何の冗談だよと思ってしまうが
大事なのは一体何人がその関数を使いそうなのかと、実装が面倒かどうかだけかと

必要性とかお題目唱えるより、「面倒だからパス」と言ってくれた方がまだ理解出来る。変に取り繕われると心証悪いかもね

>>257
＞文字列をキーした探査なんて、その人1人で閉じたコードならともかく、
＞それ以外の環境ではバグハッピーで、とてもじゃないが使わせたくない代物です
文字列って結局文字コードなんだし、実行環境が変わっても同じなんでは？
実行機はクライアントで完結してるんだし、実行環境の文字コードが実行中に変わるとか言うのなら、それどんな状況っていう
260：妊）|дﾟ)：2011/06/15(水) 05:43:07 ID:/H8WE2yY0: >>258
実際に呼ばれる→想定外の呼び出しが起こればほとんどの場合すぐにわかる
呼ばれない→想定外に存在があった場合に開発側がそれを検知するのがまず困難
問題が起きた時に雲泥の差なんですよ
特にera系の開発はこういう問題起こりやすいバッググラウンド抱えてますので

で、おそらく、こういう事をやりたいということならば、
何かしら識別用の専用プリプロセッサでも作るか、ファイルの存在判定あたりを考えたくなるところです
もちろん、そのパッチが何かしら独自のファイル持つという形になるならということになりますが

ここらへんについては重複が容易に起こる関数名に頼る実装よりは、
見たい物がそれ自身であることをもっと容易に識別できる仕様であるべきだと考えてます
261：名無しさん：2011/06/15(水) 05:51:56 ID:OCHaGaro0: >>260
だからすでにTRY系関数を実装して実行時に関数の有無をチェックする仕組み
をつくっている時点で何を言ってるのかと。

TRYCALLFORM foo_{ARG}
bar
CATCH
bas
ENDCATCH

は

IF EXISTFUNCTION( foo_{ARG} )
CALLFORM foo_{ARG}
bar
ELSE
bas
ENDIF

と等価でしょ。

TRY系関数を作ったこと自体失敗だったって話をしてるの？

処理系のテスト的にはtry系のテストケースが素直に増える前者よりEXISTFUNCTION関数のテストをするだけの後者の方が楽だと思うが。
262：名無しさん：2011/06/15(水) 06:06:58 ID:JCvsg9920: TRYの山は最初見た時同じ事思ったかも知れんが、昔過ぎて忘れたな…
ただ素人が作ってるんだろうし、目くじら立てずに適当でも良いんじゃねとは思う。動くのが凄いし、開発側も楽しめばおけ
もし本職なら、少なくとも仕事では出会いたくないが。超設計が結構ある…

>>260
>重複が容易に起こる関数名に頼る実装よりは、
>見たい物がそれ自身であることをもっと容易に識別できる仕様であるべきだと考えてます
IRCでの反応でレスすると、「？ｗ」ってなるレスだな…
勿論この反応は失礼極まりないので水に流して…ERB上で重複が起きると何か問題なの？

そもそも関数の存在チェックなんてERB解析時に関数名を文字列配列にスタックして、
チェック時にそれを走査すれば良いだけと思ってんだが…配列の仕様は重複無しのユニーク配列で。
１レコード半角40文字の40byteとしても、1000関数で40kb。メモリもそんなに食わないだろうし
263：妊）|дﾟ)：2011/06/15(水) 06:17:51 ID:/H8WE2yY0: >>260
そういう話はしてないです
デバッギングを考えた時、実際に呼ばれて処理がされるものとそうでないものとでは
状況によっては問題の度合いが変わるということを言ってるだけです
直接原因の見えにくい問題はデバッグが大変なのです

TRYCALL系の実装はその名前の関数があれば読むなので、
単純な関数名探査と同じ欠点を抱えているのは確かですが、
それはもっと処理量の多くならざるを得ない実装にすることを避けた結果です
（基本、フロー処理を含む場合、Emueraの内部処理でifされるかスクリプトでIFされるかは
　処理量の差が結構大きいので後者は非常に無駄が多いのです
　なので、TRYCALL型の方がEmueraの実装としては遙かにベターです
　同じ欠点を抱えてるのに処理がさらに重たくなる形をわざわざ実装する意味はないですし）

関数存在確認が必要と言えるのは、>>261のような呼び出す前提のコードなどではなく
関数の存在は確認するけど「そこでは絶対に呼び出さない」という形でしか実装しようがない処理が必要になる場合だけだと思います

で、この場合で関数探査だけが必要というのであれば
もっと欠点の少ない方法でほぼ同等の機能の実装が可能な領域にあたります
なので、この場合も関数名をキーする実装ではなく、そちらでやるべきというだけです
（もちろんパフォーマンス上はTRYCALL系に比べて多少落ちるのはしょうがないとしても
　こちらはconsistentな処理結果が期待できるという差別化もできますし）
264：名無しさん：2011/06/15(水) 06:50:48 ID:OCHaGaro0: >>263
> そういう話はしてないです
> デバッギングを考えた時、実際に呼ばれて処理がされるものとそうでないものとでは
> 状況によっては問題の度合いが変わるということを言ってるだけです
> 直接原因の見えにくい問題はデバッグが大変なのです
TRY系命令で全く同じ問題があるのに今更何を言ってるのですか？

> TRYCALL系の実装はその名前の関数があれば読むなので、
> 単純な関数名探査と同じ欠点を抱えているのは確かですが、
> それはもっと処理量の多くならざるを得ない実装にすることを避けた結果です
全く関係ない話ですね。
パフォーマンスの問題は実装するかしないかの後にくる話です。
正直どうでもいいレベルの速度差しかでないと思いますけど。
VARSETみたいな劇的な違いがでるとおもっているの？

> 　同じ欠点を抱えてるのに処理がさらに重たくなる形をわざわざ実装する意味はないですし）
IFで自前で処理させた方が柔軟な処理が行えますね。

> 関数存在確認が必要と言えるのは、>>261のような呼び出す前提のコードなどではなく
> 関数の存在は確認するけど「そこでは絶対に呼び出さない」という形でしか実装しようがない処理が必要になる場合だけだと思います

口上などで、
必須サブ関数を処理の頭で全部チェックして弾く。
(チェックロジックを頭にまとめたい)
複数の関数のうち存在するもの一つをランダムで呼び出す。
(存在する関数のみ文字配列に突っ込んで、CALFORM %LOCALS:(RAND:個数)%で呼び出す)
というような場合は、存在確認関数がないとダメ/すっきりかけますね。

> なので、この場合も関数名をキーする実装ではなく、そちらでやるべきというだけです
そちらってなんですか？
プリプロセッサで静的に処理という話であれば、
動的にやってるTRY系命令があるのになんで？
静的に有無をチェックしても結局呼び出し時は
CALLFORMで動的に関数を探して呼ばないといけないし。
中途半端じゃないですか？

そもそもプリプロセッサで静的に処理という考え自体が
TALENT配列の添え字に文字列がそのまま使える用に拡張されている
というような今までの拡張方針に反していると思いますが。

プリプロセッサにかける前のコードとかけた後のコードの二重配布とかバカバカしいですし。
265：妊）|дﾟ)：2011/06/15(水) 07:07:16 ID:/H8WE2yY0: >>264
さすがにもう眠いのと、最早議論自体が目的化してきてしまったのでそろそろしめますが、
あなたが上げた理由は関数名探査関数が必要な理由にはなりませんし、
そもそもTRYCALL系に欠点があるのにというのであれば、
こちらはその避けようがない欠点があるものをさらに増やすつもりはありません
（当たり前ですが、すでに広い範囲で用いられているTRYCALL系の実装を消すことはありません）
欠点は減らしていくものであって、増やすものではないですし

Emuの人がどう考えるかは自分の関与するところではないので、
最後はEmuの人の判断次第でしょうが、
少なくとも自分の私家改造でこれまでに上げられたような実装をすることはなく、

関数の存在は確認するけど「そこでは絶対に呼び出さない」という形でしか実装しようがない処理がどうしても避けられない
ということがあれば、もう少しconsistentに処理できる実装で実装しようかと思います
266：名無しさん：2011/06/15(水) 07:14:05 ID:OCHaGaro0: >>265
> あなたが上げた理由は関数名探査関数が必要な理由にはなりませんし、
あなたが挙げた理由は関数名探査関数を実装してはならないという理由にはなりません。
267：名無しさん：2011/06/15(水) 07:20:26 ID:JCvsg9920: >>263
すんげー何言ってんのか分かんなくて、俺の中の妊の人の株がガタ落ちなんだけど…

>>265
>関数の存在は確認するけど「そこでは絶対に呼び出さない」という形でしか実装しようがない処理がどうしても避けられない
>ということがあれば、もう少しconsistentに処理できる実装で実装しようかと思います
いや既に「そう言う事がある」んですが…上の方で出てますがな
勿論代替方法があるから、各自それを行っているだけで。あるいは諦めたり。問題自体は既に発生してますよ。うん

なんつーか妊の人は「俺が絶対正しい」という感じの思想なのがこの件で垣間見えたし、論調的にも期待できそうにない
Emuの人も音信不通…
もうこれは自分で作れって事じゃね多分。実にeraらしいが
268：名無しさん：2011/06/15(水) 07:21:14 ID:OCHaGaro0: こちらは、TRY系関数に問題があるとも思っていないし、同様に関数の有無をチェックする関数にも問題があるとは思っていないわけです。

あなたの関数の有無をチェックする関数を実装すると問題があるという主張を読むと、
TRY系関数にも同様の共通する問題があるということになり、そもそもTRY系関数も実装するべきではなかったと言うことになる。

だから>261で確認したのだが、違うという回答があった。わけが分からん。

あそこでもし、はいその通り、TRY系関数の存在は問題。しかし自分が設計した仕様じゃないし既に利用したコードがたくさんあるのでどうしようもない。

という答えが返ってきていたら、はいそうですか、で終わっていたはずの話です。
269：名無しさん：2011/06/15(水) 09:49:56 ID:CiS6Zjag0: >>260 >>263で妊の人が言いたいのは
存在するけど中身が別物、な場合の話じゃないのかしらん。
TRYCALLだったら存在してたら呼ぶから違ったことしてるのが分かるが、とか
そういうレベルの。

ここで想定されてる開発側は妊の人とかEmuの人でなくバリアントやパッチ作者だと
そう読んだわけだが、どないなものだろう
270：名無しさん：2011/06/15(水) 09:59:33 ID:OiZlCIAwO: ERB側で「行けると思ったけど行けなかった」って勘違いするからダメってことなら、
Emueraのバージョンを取得する関数が必要になってくるな
271：名無しさん：2011/06/15(水) 10:45:28 ID:tEfHSxd.0: ＞>269
そもそも
>TRYCALLだったら存在してたら呼ぶから違ったことしてるのが分かる
というのが妄想だと思う。

実行するから一貫性が保証されるって論理が意味不明。
そもそもEXISTFUNCTION()を使うやり方でも結局関数を呼ぶわけだし。

関数の存在をフラグとして使うだけで呼ばないって使い方もないことはないけど。
なにもしない関数をTRYCALL - CATCHで呼ぶのと変わらないし、
実際に関数を呼んだからといってその関数が期待通り空だったかどうかなんてチェックのしようがない。
272：名無しさん：2011/06/15(水) 11:21:15 ID:yhergTr.0: 本家の人はいないし妊の人は家版では実装しないって言ってるのだから
必要に感じてる人たちが自分らで作る方が建設的だわな

派生品がいくつも出ることに関して言えば
バリアント製作者が自分のバリアントに必要な機能を持ったeraを選べばよいだけだよ
プレイヤー側が迷惑被るなんてそうそうないでしょ
バリアント同梱のeraを別の物に変えてプレイするなんて
自己責任でお願いしますで良いレベルだ
273：名無しさん：2011/06/15(水) 19:38:41 ID:JCvsg9920: era本体の派生品がいくつも出ることの問題点は、バリアント作者はともかくパッチ作者が困る点かと
プレイヤーは困らないよ。でもパッチ作者は、軽い改造すら本体の仕様を理解して無いと書けなくなる可能性がある
つまり協力者が出にくくなるから、結果的に廃れる原因になる
era2なんか、独自拡張した派生と言えなくも無いし、そう考えるとまさに「仕様が違うから協力者が出ない」っていう状況になってるし

と言う訳で、本体の乱立はオススメはしないかな。乱立されてるバリアントの流行り廃りと、恐らく相似形の結果になる
しかもバリアントと違って、本体なんか作ってても楽しくないしね。折角作ったのに誰にも使われなければ、尚更詰まらんだろう

って事で、結局実装待ちながら代替方法で解決するのが安牌かと。もしくは集団移籍を決めてから新eraの開発とか
274：名無しさん：2011/06/15(水) 20:42:25 ID:SO90FN5s0: 別に集団移籍だろうが私家版だろうがそれは自由だけど、ネーミングは従来のEmueraとは
区別つけるようにしてほしいね。
それさえすれば問題はないだろう。どっちが生き残るか？なんてやってみなければわからんし
275：名無しさん：2011/06/15(水) 21:00:46 ID:QcGdkWkM0: ここだけはっきりさせて欲しいんだが
>あるかどうか知りたいけど実行させたくない
って言う状況はどういう状況？

あと>>183-185の部分だけど>>183を見ると
事前に判定する必要がない様に思えるから>>184がTRYCCALLでその場で判定させるといいよって言ってるんだと思う
276：名無しさん：2011/06/15(水) 21:12:06 ID:JCvsg9920: >>275
＞事前に判定する必要がない様に思えるから>>184がTRYCCALLでその場で判定させるといいよって言ってるんだと思う
例えば事典機能ってまず「項目一覧画面」があって、そこから「個別詳細画面」に移ると思うんだが、
この一覧画面の時点で、「その項目の説明関数が無ければグレーアウト」って処理をしたいの
もしここでTRYCCALLでやると、一覧画面に説明文が表示されてしまう。存在だけが知りたいと

そして「それなら確認関数作れ」って言うのなら、二重管理じゃんかウボァーって話
または「引数でリターン制御しろ」って言うのなら、テンプレ作成時のコストがハンパ無いし言語として問題じゃねって話
で、今は泣く泣く二重管理してるって訳
277：名無しさん：2011/06/15(水) 21:14:05 ID:U9m.p6Fo0: もう、この話はスパッと打ち切って双方住み分けに徹しましょうよ
278：名無しさん：2011/06/15(水) 21:15:30 ID:Z7qbYMAc0: 関数名探査関数を実装しなければemueraが動かないというのでないならならわざわざ妊の人が実装する必要はないと思います
開発者は実装してはならないものでなければ実装しなければならないなんてことは無く、そんなのは開発者に期待しすぎだと思います
そんなに必要だと思うならあなたが実装してあなた自身の私家版を作ってはいかがですか？　それならば、誰も文句は言いません
279：名無しさん：2011/06/15(水) 21:24:45 ID:JCvsg9920: >>278
だからまぁ前レスでも書いたが、「必要性云々とかは関係無く好き嫌いで決めてます」とか言って貰った方が心証が良いと
必要性なら欲しがってる奴が居るんだし、ゼロでは無い。好き嫌いならまさに開発者の自由だし
それに必要性云々を言うなら、LOGとかあの辺の意味不明な命令の方が謎だよねって言う。誰が使うんだよｗとかなる

変に理屈こねて耳触りが良い様に正当化してるから、いらない所で突っ込まれてるんじゃねーのかな、うん
「好き嫌いで何が悪い」ってんなら、誰も文句は言いませんかと。こんなに伸びて無い筈
280：名無しさん：2011/06/15(水) 21:25:49 ID:RUrS26Zg0: >>276
それなら「関数名」で探させなくてもいいんじゃない？
たとえば#VERSION 12とかを関数に仕込んでCHECKFUNCVER(関数名)で関数のバージョン（キーとしても使えるか）を返させれば
仮に無いなら0でも返させれば関数が存在するかだけでなく新旧もわかってより効果的
281：名無しさん：2011/06/15(水) 21:33:53 ID:U9m.p6Fo0: >>279
ま、なんだ、「不要だと一蹴された」と思うよりは
「不要だと思う人もいた」くらいに思っておいた方がいいんじゃないかな
他の誰かが必要だと思って作り込むかも知れないし
282：名無しさん：2011/06/15(水) 22:09:27 ID:QcGdkWkM0: >>276
これも二重管理なのかもしれないけど例えば
@項目一覧
TRYCCALL 詳細A ～ CHACH ～ ENDCATCH

で『詳細A.ERB』の中に
@詳細A
CALL 詳細A-1
@詳細A-1
詳細A-1の内容

とかやって『詳細A.ERB』を消したり中身を[SKIP]させちゃう方法じゃダメなの？
って俺は思ってしまう。

あと、妊の人はきちんと必要性も感じないし『欠点を増やすのが嫌だから』実装しませんって言ってると思う。
283：名無しさん：2011/06/15(水) 22:39:16 ID:JCvsg9920: まぁここまで結構レスしたが、正直実装されなくてもなんとかなるよねっていう

>SKIP
その手があった。ループのネスト並にあんまり好きじゃないけど、作業はスリム化しそう
まぁ「欠点を増やすのが嫌だから」ってのは分からなくも無いが…実際は影響無いと思うけど。余り書かないが
284：名無しさん：2011/06/15(水) 22:42:02 ID:CiS6Zjag0: ゲーム開発におけるLOGの有用性について語ったら日が暮れる

>>269で何が言いたかったかと言うと、
>>264の
> > デバッギングを考えた時、実際に呼ばれて処理がされるものとそうでないものとでは
> > 状況によっては問題の度合いが変わるということを言ってるだけです
> > 直接原因の見えにくい問題はデバッグが大変なのです
> TRY系命令で全く同じ問題があるのに今更何を言ってるのですか？

これがぜんぜん分からんって言いたいだけなんだ
TRY系、関数あったら呼ばれて処理がされるんじゃないの違うの？

それだけ。俺は撤収。
285：名無しさん：2011/06/15(水) 23:44:14 ID:U9m.p6Fo0: まあ、これ以上議論したいならIRCにでも行ってみればいいんでないの
向こうでこの話題に触れてるかどうかは知らんけど
286：名無しさん：2011/06/16(木) 06:14:34 ID:IdbazFt20: >>284
>271
287：名無しさん：2011/06/16(木) 08:04:17 ID:DBLtyGc60: すまん、>>284に対して>>271だと何が言いいたいのかよく分からん。
288：名無しさん：2011/06/16(木) 09:28:36 ID:SMSFobG6O: この件についてはIRCでも議論されているので、
これ以上続ける前に一度6/14～6/15あたりのログに目を通しておくことをオススメします
289：名無しさん：2011/06/16(木) 09:53:34 ID:8/gy9tmg0: これ以上続けても好転はしないだろう。開発者自身が、言い方が気に入らないから作る気しないとか言ってるし…
心変わりでも待ってこの話題は終わっとこう
290：名無しさん：2011/06/16(木) 13:05:38 ID:YP3lF/QU0: >>289
どこで誰がそんなこと言ってたのかと
291：名無しさん：2011/06/16(木) 17:44:11 ID:1zfVGPCg0: 続けろとも言わんが、別に終わらせる必要があるとも思わぬ
関係者以外は黙ってりゃいいし、
このスレに沿った話題が別にあれば気にせず出せばよい
292：名無しさん：2011/06/16(木) 18:37:23 ID:tAGpV.Ds0: 結論はでてるから意味ないよね
この話を続けると開発者のモチベーションをどんどん下げるからね
「俺の考えた一番いい提案を受け入れられない開発者はいなくなってしまえ」
とか考えてるのでなければ、終わらせた方がいいよね
293：名無しさん：2011/06/16(木) 21:29:14 ID:IdbazFt20: >>288
> この件についてはIRCでも議論されているので、
> これ以上続ける前に一度6/14～6/15あたりのログに目を通しておくことをオススメします

どこでログが読めるの？
ざっくり検索した感じではログの公開ページは見当たらなかったけど。
294：名無しさん：2011/06/16(木) 22:58:03 ID:UnGt1AUE0: >>293
パチュロダにIRCログがあるよ
たぶん&Emueraのことだと思う
295：名無しさん：2011/06/16(木) 23:00:11 ID:YP3lF/QU0: >>293
前提。このスレで名前が出ているIRCチャンネルは&Emueraである(>>2)
名前的にもそうだよね。

で、「&Emueraのログ」でGoogle検索してみると出る
296：名無しさん：2011/06/16(木) 23:05:17 ID:YP3lF/QU0: ただしあれを議論と呼ぶかどうかとかその辺は私は知らない。