Fandom

Second Life in Japan

スクリプターズカフェ/ログ/state構成のパターン

483このwikiの
ページ数
新しいページをつくる
トーク0 シェアする

Scripters_cafeログ


08/08/16 編集

「設定をnotecardから読み込んで動作する」というスクリプトのstate構成のパターンについての話です。

以下のようなstate構成を例として出しました。


default {
    state_entry() {
        //  ここで全体の初期化
        
        //  設定の読み込みへ
        state ReadSetting;
    }
}


//  設定ファイルの読み込み
state   ReadSetting {
    state_entry() {
        //  設定ファイルの存在チェック、読み込み前の初期化
        //  読み込み開始
    }
    
    dataserver( key requested, string data ) {
        if ( data == EOF ) {
            state ErrorCheck;   
        } else {
            //  読み込み継続
        }
    }
    
    changed( integer changed_flag ) {
        if ( changed_flag & CHANGED_INVENTORY ) {
            //  リセット
        }
    }
}

//  設定のエラーチェック
state   ErrorCheck {
    state_entry() {
        //  エラーチェックを行う
        
        //  エラーありなら、Error stateへ
        state Error;
        
        //  エラーなしなら、Active stateへ
        state Active;
    }   
}

//  本体
state   Active {
    state_entry() {
        
    }
}


//  エラー
state   Error {
    state_entry() {
        //  エラー表示など
    }   

    changed( integer changed_flag ) {
        if ( changed_flag & CHANGED_INVENTORY ) {
            //  リセット
        }
    }
}


このスクリプトではdefaultステートでの処理はほとんど行っていませんが、設定読み込み部分などの初期化関連をdefaultステートで行う、という意見もありました。

また、設定の読み込み+設定のエラーチェック自体を別スクリプトに分けている、という意見もありました。

設定ファイルをユーザーに変更させるような汎用的なスクリプトを作成する場合、設定項目のエラーチェックが必要になりますが、このようなエラーチェックは時にはスクリプト本体と同じくらいのコード量になってしまう場合もあるので、別スクリプトで行うというアイデアも納得できます。

ただし、設定の読み込み処理が本体スクリプトと非同期になるため、工夫が必要かもしれません。こちらのパターンでも、典型的なstate構成を考えてみたいです。


リセットを前提としないスクリプト 編集

上のスクリプト例は、「初期化」という操作をスクリプトのリセットによって行うイメージですが、スクリプトによってはリセットを行われては困るものもあります。

リセットと初期化を切り離した場合のstate構成パターンも考えておきたいです。

広告ブロッカーが検出されました。


広告収入で運営されている無料サイトWikiaでは、このたび広告ブロッカーをご利用の方向けの変更が加わりました。

広告ブロッカーが改変されている場合、Wikiaにアクセスしていただくことができなくなっています。カスタム広告ブロッカーを解除してご利用ください。

Fandomでも見てみる

おまかせWiki