[戻る]
SOLD OUT Item Editor
name：Y.Y 2004/12/22 00：11：12 http://www.tpy.if.tv/
私も、こちらでは、始めまして、ですね^^;
SOLD OUT Item Editor 凄いですねぇ。
実は私もSoldOutItemMakerを作ってみたりしたのですが、
Visualbasic6で製作したため、そこまで使い勝手が良くなくて。
今から完成を楽しみにしています♪
追伸
ＳＯＬＤ ＯＵＴ改造広場ではアドバイス、ありがとうございます。
おかげさまで計画が着々と進行中です。
name：fuku@管理人 2004/12/22 14：02：05
応援ありがとうございます♪
結構な大きさになりそうなので完成までには時間がかかりそうですが、
頑張って完成させたいと思います。
>実は私もSoldOutItemMakerを作ってみたりしたのですが、
実は参考にさせてもらってます、SoldOutItemMaker。
それまで030411バージョンのデータを見てたので、
「購入禁止フラグ」の存在に気付けたりして、結構役にたってますよ♪
name：Y.Y 2004/12/23 23：21：47 http://www.tpy.if.tv/
>結構な大きさになりそうなので完成までには時間がかかりそうですが、
>頑張って完成させたいと思います。
結構大変ですよ^^;SOIMでさえ、予想以上にアイテム文法に幅があるため、単純作業の繰り返し。。。
>それまで030411バージョンのデータを見てたので、
>「購入禁止フラグ」の存在に気付けたりして、結構役にたってますよ♪
お役に立てて嬉しいです。
できることならば、Editorを制作したかったのですが、その頃、VB.netへの移行中でして、inc-item-data.cgiの”編集”という機能を実装出来なかったので、Makerとしました。
その点、スクリーンショット・説明文から推測させていただくと、SOLD OUT Item Editorはインポート(?)出来そうなので。
こういうプログラム、今まで無かったのですよね。
メモ帳等で直接開いてアイテムを増やす。。。
少しの入力ミスでも命取り^^;
なので、改造の敷居が少し高い気がしています。
Item Editorがあれば、新規参入が増え(正直、管理者にとってはあまり嬉しくないのですが)SoldOut界(?)が盛り上がるのではないのかなぁ。
と考えてみたり。。。
name：fuku@管理人 2004/12/24 10：48：10
>結構大変ですよ^^;SOIMでさえ、予想以上にアイテム文法に幅があるため、単純作業の繰り返し。。。
確かに大変そうです。SOIEはアイテムページだけで現状85個ものコントロールが配されているわけですし(笑)
（スタティックテキストも含めると100超えますね）
>その点、スクリーンショット・説明文から推測させていただくと、SOLD OUT Item Editorはインポート(?)出来そうなので。
現状では、特に専用のバイナリ形式を作るかどうかは未定なので、
インポートというより直接開く感じですが、一応そのような予定です。
でも上書き保存できるようにするには全データを読み込んでおく必要があるわけで、
inc-item-data.cgiの構文解析が一番てこずりそうです。
ホント、記述文法に幅ありますからね(笑)
>少しの入力ミスでも命取り^^;
>なので、改造の敷居が少し高い気がしています。
私としては、改造の敷居は少し高い方がいいように思いますね。
あまり簡単に改造できると十分な知識もないまま改造し、
テストもせずにサーバに投入して問題を誘発しやすくなるようにも思えますし。
ローカルアプリと比べるとサーバアプリは暴走したりした時の影響の大きさがかなり違いますからね。
name：Y.Y 2004/12/24 23：36：49 http://www.tpy.if.tv/
>確かに大変そうです。SOIEはアイテムページだけで現状85個ものコントロールが配されているわけですし(笑)
>（スタティックテキストも含めると100超えますね）
えぇ、完成後のメンテナンスに嫌気がさすほどです^^;
開発当初はやる気マンマンなのですが、その後改善する気力が無くなってしまいました。。。
なので、イチから制作し直そうかなぁ、と考えてみたり。
>現状では、特に専用のバイナリ形式を作るかどうかは未定なので、
>インポートというより直接開く感じですが、一応そのような予定です。
>でも上書き保存できるようにするには全データを読み込んでおく必要があるわけで、
>inc-item-data.cgiの構文解析が一番てこずりそうです。
>ホント、記述文法に幅ありますからね(笑)
なるほど。
確かにエディタならば直接弄る方が良いですね。
ふむ、やはり構文解析ですか・・・
一度制作を試みたのですが、makeitem.cgiの出来の良さに感服^^;
とてもアマチュアでは上手く出来ないと思いました。
>私としては、改造の敷居は少し高い方がいいように思いますね。
>あまり簡単に改造できると十分な知識もないまま改造し、
>テストもせずにサーバに投入して問題を誘発しやすくなるようにも思えますし。
>ローカルアプリと比べるとサーバアプリは暴走したりした時の影響の大きさがかなり違いますからね。
確かにそれもありますね。
いきなりサーバーダウンなんて洒落になりませんから^^;
現在のレンタルサーバーでも120人がダウン・・・
やはり、簡易的な文法チェッカも必要かなぁ。。。
name：fuku@管理人 2004/12/25 10：51：32
>ふむ、やはり構文解析ですか・・・
>一度制作を試みたのですが、makeitem.cgiの出来の良さに感服^^;
>とてもアマチュアでは上手く出来ないと思いました。
えぇ、やはり構文解析は強敵の予感です。
makeitem.cgiを見るとPerlのハッシュやら自動的に増える配列などの利点を精一杯使ってるようですからね。
まともに構文解析するなら自動的に増える配列は少なくとも必要でしょうし、
makeitem.cgiと等価に評価しないと後から困りそうですしね・・・。
>いきなりサーバーダウンなんて洒落になりませんから^^;
>現在のレンタルサーバーでも120人がダウン・・・
CGIだと落ちるときは落ちますからねぇ・・・
実際に暴走CGIでサーバー落ちたりしてるんですか？
>やはり、簡易的な文法チェッカも必要かなぁ。。。
文法エラーで止まるならサーバーは多分落ちないと思うんですよ。
問題は無限ループ状態に陥るとかだと思いますから。
あと、Perlは配列の添字に間違って巨大な値を投入するとメモリがすごいことになるんですよねぇ・・・。
この2つはソースレベルでは検出が難しいですし、
やるとしたらDEBUGとRELEASEを分けてDEBUG時には添字とかループ回数とかを検証するソースコードをぶち込む方法しかないかも・・・
でもそうするとPerlの文法を本格的に解析しないといけないなぁ・・・。
name：Y.Y 2004/12/30 00：13：12 http://www.tpy.if.tv/
お返事が遅れまして申し訳ありません^^;
>えぇ、やはり構文解析は強敵の予感です。
>makeitem.cgiを見るとPerlのハッシュやら自動的に増える配列などの利点を精一杯使ってるようですからね。
>まともに構文解析するなら自動的に増える配列は少なくとも必要でしょうし、
>makeitem.cgiと等価に評価しないと後から困りそうですしね・・・。
なるほど、Perlの利点を精一杯、ですか・・・
makeitem.cgiを詳しく解析(?)してみたことがないので解りませんでしたが・・・
因みにSOIMは100%マニュアル準拠(の筈)^^;
>CGIだと落ちるときは落ちますからねぇ・・・
>実際に暴走CGIでサーバー落ちたりしてるんですか？
私も詳しくは解らないのですが、どうやら監視システム(?)のようなモノが導入されており、あまり長時間CPUを占領したりメモリを大量消費したりするとプロセスが強制終了されたりする・・・らしいです。
まぁどちらにしろ「暴走」させてしまわないように気をつけるに越したことはないのですが^^;
>文法エラーで止まるならサーバーは多分落ちないと思うんですよ。
>問題は無限ループ状態に陥るとかだと思いますから。
確かにそうですね。
無限ループの検出は簡単なモノなら可能であっても、特定の条件下で無限ループに陥ってしまうようなモノの検出は困難でしょうから・・・
いっそfunc_local_に簡易無限ループ検出のような機能を搭載させ、エディタ側でも対策コードを埋め込むか否かを選択出来るように・・・といっても難しいですよね。
>あと、Perlは配列の添字に間違って巨大な値を投入するとメモリがすごいことになるんですよねぇ・・・。
>この2つはソースレベルでは検出が難しいですし、
>やるとしたらDEBUGとRELEASEを分けてDEBUG時には添字とかループ回数とかを検証するソースコードをぶち込む方法しかないかも・・・
あ、被っちゃいましたね...
>でもそうするとPerlの文法を本格的に解析しないといけないなぁ・・・。
あー・・・
確かにこの方法を取るためにはしっかり文法を理解する必要がありそうですね。
P.S.
Sold Out on PHP (仮称) を計画しております。
内容は名前のまま、つまりSoldOutをPHPに移植しようという考えです。
しかし、ザッと見た限りでもPerl固有の関数がたくさんあり、移植は困難だと思うのですが・・・
・移植後の利点はあるのか
・そもそも移植は可能なのか^^;
が問題なのですが・・・どうでしょうか？
name：fuku@管理人 2004/12/30 16：54：24
>なるほど、Perlの利点を精一杯、ですか・・・
>makeitem.cgiを詳しく解析(?)してみたことがないので解りませんでしたが・・・
思い出したのですが、自動的に増える配列とハッシュはRubyにもありますねぇ。
他の言語はあまり知らないのですが、スクリプト言語だと大体こうなんでしょうかね？
>因みにSOIMは100%マニュアル準拠(の筈)^^;
ベータ版記述のargselectとfunci _local_の出力逆のような気がしますが・・・^^;
>私も詳しくは解らないのですが、どうやら監視システム(?)のようなモノが導入されており、あまり長時間CPUを占領したりメモリを大量消費したりするとプロセスが強制終了されたりする・・・らしいです。
WinNT系だとGetProcessTimesとかGetProcessMemoryInfoとかで監視するんでしょうかね？
UNIX系は知りませんけど・・・
>無限ループの検出は簡単なモノなら可能であっても、特定の条件下で無限ループに陥ってしまうようなモノの検出は困難でしょうから・・・
>いっそfunc_local_に簡易無限ループ検出のような機能を搭載させ、エディタ側でも対策コードを埋め込むか否かを選択出来るように・・・といっても難しいですよね。
単にforやwhileを検出するだけなら大して難しくないんですけどね・・・
ただ検索するだけですし。
問題は如何にして暴走状態を見分けるかと誤検出の阻止ですね。
一定数ループしたらとしても、多いところでは1万以上のループが正常状態でも走る可能性があるし、
かといって10万とかにすると1周の時間が長いループだと意味がないし・・・（多分先にタイムアウトで強制終了？）
あ、CPU使用時間は基準として使えないですかね？
>Sold Out on PHP (仮称) を計画しております。
>内容は名前のまま、つまりSoldOutをPHPに移植しようという考えです。
私もC++に移植してみようかと思ったりもしたんですが・・・
さすがにスクリプト言語->コンパイル言語では壁が大きすぎると思って断念しました。
アイテムの関数書くたびに要ビルドじゃ、面倒すぎかもと^^;
加えてEXE形式が動作するサーバって少ないですし、事実上自前サーバじゃないと使えないような・・・
>しかし、ザッと見た限りでもPerl固有の関数がたくさんあり、移植は困難だと思うのですが・・・
>・移植後の利点はあるのか
>・そもそも移植は可能なのか^^;
>が問題なのですが・・・どうでしょうか？
PHPやったことがないので、なんともいえないんですけど・・・
とりあえずスクリプト言語（でしたよね？）ですし、移植は不可能ではないと思います。
ただ、既存の追加スクリプトやアイテムの専用関数の使いまわしができないのは結構なマイナスかも・・・