約 4,125,200 件
https://w.atwiki.jp/shfarts/pages/568.html
モジュール一覧 各モジュールがどこに付属するのかの一覧です。 モジュール付属早見表(商品別) 商品 ○ × △ □ ベースステイツ 1（ロケット） - 3（ドリル） - エレキステイツ 10（ビリーザロッド） 12（ビート） - 11（シザース） ファイヤーステイツ 20（ヒーハックガン） - 15（スパイク） - マグネットステイツ 30（Nマグネットキャノン） 不明 不明 31（Sマグネットキャノン） コズミックステイツ 40（コズミック） - - - ロケットステイツ S-1（ロケット） - - S-1（ロケット） なでしこ 1（ロケット） - - - マシンマッシグラー 17（フラッシュ） - - - クローモジュール+コズミックステイツ魂ステージ 33（クロー） - - - モジュールセット01 5（マジックハンド） 2（ランチャー） - 4（レーダー）6（カメラ） モジュールセット02 - 8（チェーンソー）14（スモーク） 9（ホッピング） 7（パラシュート） モジュールセット03 13（チェーンアレイ） 21（ステルス） 19（ガトリング） 16（ウインチ）18（シールド） モジュールセット04 - 25（ペン） 23（ウォーター）26（ホイール） 22（ハンマー）24（メディカル） モジュールセット05 29（スコップ） 28（ハンド）32（フリーズ）35（ジャイアントフット）38（ネット） 27（スクリュー）34（ボード）36（エアロ）39（スタンパー） 37（ジャイロ） モジュール付属早見表(番号順) 番号 モジュール名 装着部位○×△□ モジュールの付属する商品 備考 1 ロケット ○ ベースステイツロケットステイツ（魂ウェブ商店限定）なでしこ（魂ウェブ商店限定） ロケットステイツには2個付属また、S-1という特殊スイッチも付属 2 ランチャー × モジュールセット01 3 ドリル △ ベースステイツ 4 レーダー □ モジュールセット01 5 マジックハンド ○ モジュールセット01 6 カメラ □ モジュールセット01 7 パラシュート □ モジュールセット02 8 チェーンソー × モジュールセット02 9 ホッピング △ モジュールセット02 10 ビリーザロッド ○ エレキステイツ 11 シザース □ エレキステイツ 12 ビート × エレキステイツ 13 チェーンアレイ ○ モジュールセット03 14 スモーク × モジュールセット02 15 スパイク △ ファイヤーステイツ 16 ウインチ □ モジュールセット03 17 フラッシュ ○ マシンマッシグラー 18 シールド □ モジュールセット03 19 ガトリング △ モジュールセット03 20 ヒーハックガン ○ ファイヤーステイツ 21 ステルス × モジュールセット03 22 ハンマー □ モジュールセット04 23 ウォーター △ モジュールセット04 24 メディカル □ モジュールセット04 25 ペン × モジュールセット04 26 ホイール △ モジュールセット04 27 スクリュー △ モジュールセット05 魂ウェブ商店限定 28 ハンド × モジュールセット05 魂ウェブ商店限定 29 スコップ ○ モジュールセット05 魂ウェブ商店限定 30 Nマグネットキャノン ○ マグネットステイツ 31 Sマグネットキャノン □ マグネットステイツ 32 フリーズ × モジュールセット05 魂ウェブ商店限定 33 クロー ○ クローモジュール+コズミックステイツ魂ステージ 電撃ホビーマガジン2012年11月号付録 34 ボード □ モジュールセット05 魂ウェブ商店限定 35 ジャイアントフット × モジュールセット05 魂ウェブ商店限定 36 エアロ △ モジュールセット05 魂ウェブ商店限定 37 ジャイロ □ モジュールセット05 魂ウェブ商店限定 38 ネット × モジュールセット05 魂ウェブ商店限定 39 スタンパー △ モジュールセット05 魂ウェブ商店限定 40 コズミック ○ コズミックステイツ 関連商品 仮面ライダーフォーゼ ベースステイツ 仮面ライダーフォーゼ エレキステイツ 仮面ライダーフォーゼ ファイヤーステイツ 仮面ライダーフォーゼ マグネットステイツ 仮面ライダーフォーゼ コズミックステイツ 仮面ライダーフォーゼ ロケットステイツ 仮面ライダーフォーゼ モジュールセット01 仮面ライダーフォーゼ モジュールセット02 仮面ライダーフォーゼ モジュールセット03 仮面ライダーフォーゼ モジュールセット04 仮面ライダーフォーゼ モジュールセット05 仮面ライダーフォーゼ スタンド＆エフェクトセット クローモジュール+コズミックステイツ魂ステージ 仮面ライダーフォーゼ エフェクトセット TAMASHII NATION SPECIAL 仮面ライダーなでしこ マシンマッシグラー コメント 暇だったんで各ステイツからリンク貼れるように作ってみました。商品別のとこはベースステイツからのコピペですが -- 名無しさん (2012-07-16 01 03 38) ありがとうございます。 -- 名無しさん (2012-07-16 12 05 01) ベルトに刺さった中途半端な奴じゃなくてスイッチ単体のパーツも欲しいよね -- 名無しさん (2012-07-17 16 06 36) 今んとこNSマグネットと一応ファイヤーもベルト部がないから3つ？ -- 名無しさん (2012-07-17 22 03 55) 残りの５×２でモジュールセット…目立つのがいないな、限定行きかな？ -- 名無しさん (2012-07-18 00 42 20) ジャイアントフット、ボード、ジャイロ、スタンパーを平等に分ければ何とか…スタンパーにプラ製のエフェクトシート付けるなりは必要だが -- 名無しさん (2012-07-19 01 45 27) フリーズやスコップみたいな小物類はコズミックにつけても良かったのに -- 名無しさん (2012-07-19 13 51 21) ↑そうなると残りが半端になるからなぁ。でもいっそ価格千円くらい上げて無理にでもコズミックに四つくらい付ければ、残りの六個でたくさんモジュール入ったセットってことで目玉モジュール無しでも何とかなったような気がする -- 名無しさん (2012-07-19 21 49 50) 名前 コメント
https://w.atwiki.jp/mikudiva2/pages/15.html
モジュール一覧 初音ミク 名前 獲得条件 ショップ価格 初音ミクオリジナル 初期所持 - ヴィンテージドレス ロミオとシンデレラ NORMALクリア 15000 初音ミク 蝶 magnet NORMALクリア 15000 スピリチュアル 愛言葉 HARDクリア 20000 おさんぽスタイル サウンド NORMALクリア 15000 みくずきん クローバー・クラブ NORMALクリア 15000 イエロー Yellow NORMALクリア 20000 ジャー★ジ ぽっぴっぽー NORMALクリア 15000 ノーブル カンタレラ NORMALクリア 15000 パウダー 初めての恋が終わる時 NORMALクリア 15000 ナチュラル 巨大少女 NORMALクリア 20000 ホワイトワンピース Dear NORMALクリア 15000 エールダンジュ VOiCE-DIVA MIX- NORMALクリア 15000 スペイシーナース 恋色病棟 NORMALクリア 15000 初音ミク キュート Promise NORMALクリア 15000 エンジェル ハジメテノオト NORMALクリア 15000 サイハテミク サイハテ NORMALクリア 20000 ピンクポップス こっち向いてBaby NORMALクリア 15000 ピンクポップス AS こっち向いてBabyNORMALクリア 15000 カラフルドロップ カラフルxメロディ NORMALクリア 20000 ∞ 初音ミクの激唱 NORMALクリア 20000 - - - メイコスタイル ミラクルペイント HARDクリア 10000 リンスタイル いのちの歌 HARDクリア 10000 スペチャン5 みくみくにしてあげる♪ HARDクリア 10000 スペチャン39 みくみくにしてあげる♪ NORMALクリア 10000 ガリア軍第7小隊 荒野と森と魔法の歌 NORMALクリア 10000 チア DearCocoaGirls NORMALクリア 10000 プラグイン マージナル HARDクリア 10000 ゴシック 天鷲絨アラベスク HARDクリア 10000 プリンセス ワールドイズマイン HARDクリア 10000 ミコ いのちの歌 HARDクリア 10000 にゃんこ ハト HARDクリア 10000 ねむねむ マージナル NORMALクリア 10000 ハートハンター ワールドイズマイン NORMALクリア 10000 ボーカル Packaged NORMALクリア 10000 パンク ストロボナイツ HARDクリア 10000 ダンサー ラブリスト更新中？ HARDクリア 10000 スター Packaged HARDクリア 10000 フェアリー みくみく菌にご注意♪ NORMALクリア 10000 スクール The secret garden HARDクリア 10000 スノウ ストロボナイツ NORMALクリア 10000 アラビアン 天鷲絨アラベスク NORMALクリア 10000 みやび みくみく菌にご注意♪ HARDクリア 10000 チャイナ ラブリスト更新中？ NORMALクリア 10000 マジシャン ミラクルペイント NORMALクリア 10000 ホワイトドレス メルト NORMALクリア 10000 パイレーツ ハト NORMALクリア 10000 VN02 moon NORMALクリア 10000 ギャラクシー moon HARDクリア 10000 初音ミク スイムウェアS メルト HARDクリア 30000 初音ミク スイムウェア 全楽曲 NORMALクリア 30000 ハツネミク The secret garden NORMALクリア 10000 P-スタイルPB 全楽曲 EASYクリア 10000 P-スタイルCW 全楽曲 EASYクリア 10000 P-スタイルIS 全楽曲 EASYクリア 10000 P-スタイルRP 全楽曲 EASYクリア 10000 P-スタイルLP 全楽曲 EASYクリア 10000 P-スタイルFB 全楽曲 EASYクリア 10000 P-スタイルMG 全楽曲 EASYクリア 10000 P-スタイルCG 全楽曲 EASYクリア 10000 鏡音リン アシンメトリーR ジェミニ NORMALクリア 15000 リアクター 炉心融解 NORMALクリア 20000 EoEスタイル 炉心融解 HARDクリア 20000 鏡音リン キュート Promise NORMALクリア 15000 チアフルキャンディ カラフルxメロディ NORMALクリア 20000 - - - 鏡音リン スイムウェア 全楽曲 NORMALクリア 30000 鏡音レン パンキッシュ 右肩の蝶 NORMALクリア 15000 スクールジャージ 右肩の蝶 HARDクリア 15000 アシンメトリーL ジェミニ NORMALクリア 15000 - - - 鏡音レン スイムウェア 全楽曲 NORMALクリア 30000 巡音ルカ 巡音ルカ 華 magnet NORMALクリア 15000 シフォンワンピース Just Be Friends NORMALクリア 15000 フロイライン Just Be Friends HARDクリア 15000 ハードロック ダブルラリアット NORMALクリア 15000 VFスーツ ダブルラリアット HARDクリア 15000 - - - 巡音ルカ スイムウェア 全楽曲 NORMALクリア 30000 KAITO クラシック カンタレラ NORMALクリア 15000 - - - - - - - - - - - - カイト スイムウェア 全楽曲 NORMALクリア 30000 MEIKO - - - スカーレット Change me NORMALクリア 15000 モダンガール Change me HARDクリア 15000 モダンガール AS Change me HARDクリア 15000 - - - メイコ スイムウェア 全楽曲 NORMALクリア 30000 亞北ネル エスニック 巨大少女 HARDクリア 20000 - - - 弱音ハク - - - - - - 咲音メイコ ブラックワンピース Dear cocoa girls HARDクリア 20000 - - -
https://w.atwiki.jp/mizcremorne/pages/274.html
はじめに スクリプトのサイズ モジュール化の概念 モジュール化の手法 ドア・システム・スクリプト基本的なモジュールslide door module standard door module door main module short touch module group touch module 拡張モジュールsensor module phantom door module モジュール化の効果 モジュール化のデメリット はじめに LSLでは巨大なプログラムを作ることができません。 というのも一つのLSLのサイズは16KByteまでという制限があるためです。 この制限は、スクリプトコードの本体のサイズだけでなく、スクリプトが動作したときのメモリを含めたサイズです。 スクリプトを正しく書いていても、サイズが大きくなって16KByteの制限を越えてしまうと、 「Stack-Heap Collision」 などのエラーが発生し、スクリプトは動かなくなってしまいます。 今回はこの問題に対処するための、中級者向けのお話をしておきます。 スクリプトのサイズ メモリとかコードサイズと言われても何のことやら、という方もいらっしゃると思いますので、簡単に解説します。 解説なんかいらんからサンプルコードを見せい！という方はこちらまで読み飛ばしちゃって下さい。 スクリプトが動作するときには、当然ながらサーバーのパワーを使うわけですが、一つのスクリプトが動作するときに使えるパワーには限度があるということです。 ここで言う「サーバー側のパワー」というのは、スクリプトが動作するための場所のことです。 たとえば、学校の校庭を思い浮かべて見て下さい。 校庭ではいろいろなスポーツが出来るようになっていますが、面積には限りがありますよね。 テニスならば4面取れるけど、サッカーをするときは1面しか取れないとか。 コンピュータ上で何かプログラムが動くときは、校庭にコートを確保するのと同じように、プログラムが動作できるスペースを確保して動くようになっています。 このスペースのことを「メモリ」と言います。 LSLは、このメモリの大きさが16KByteまでに制限されているのです。 校庭のごく一部だけを自由に使えるようなものです。 16KByteというのがどのくらいのサイズかと言うと、例えば、 "こんにちは" という文字データは、1文字4Byte、5文字なので20Byteです。 16キロByteというのは約16,000Byteのことですので、 "こんにちは" に換算すると800個分ですｗ 「おお、800回も"こんにちは"が言えるのか！」 とは思わないで下さい。 今回の記事のここまでの記述をデータ量に置き換えると、1,700Byteあります。 わずか30行程度の文章でそこまで行きますので、16,000Byte程度ならあっという間に埋まります。 あるいは、皆さんが今使っているかもしれない、インターネットのブラウザ。 私は先ほどインターネットエクスプローラを立ち上げてみましたが、何のページも表示していない状態で、使用メモリは6,000KByteでした。 6,000KByteというのは6,000,000Byteのことです。 16,000Byteと比べると桁違いですね（＾＾； 「たった16KByteしか使えないのか！」 と思っていただければ幸いです。 スクリプトのサイズを制限しているのは、言うまでもなくサーバー負荷を軽減するためでしょう。 無制限にメモリを使えてしまったら、一本のスクリプトが校庭全面を占拠して、 「今日は俺様のリサイタルだ～！」 などという暴挙が可能になってしまいます。 そんな野望を阻止するため、スクリプトのサイズは16KByteに制限されているわけです。 しかし・・・。 「お、お願いです、うちには相撲取りの息子が5人も居るんです・・・」 「ええい、黙れ！配給は一家につきイモ16個と決まっておる！」 「そ、そんな、それでは息子たちは食べていけません！」 「うるさいヤツめ、ならば食わなければよかろう！」 我々はそんな抑圧された環境下で、黙って耐え忍んでいくしかないのでしょうか。 モジュール化の概念 16KByteの制限はLSLの仕様ですので、これを打ち破ることは不可能です。 一つのスクリプトは必ず16KByte以内で収まるように作らなければいけません。 ですが、複雑なことをしようと思うと、どう頑張ってみたところで16KByteには収まりきらないという事態が起こりえます。 この限界は想像以上にすぐにぶち当たる壁です。 そして、正面からぶつかっていっても、絶対に越えることのできない困難な壁でもあります。 ではどうやったらこの壁を越えることができるでしょうか。 その答えは少年ジャンプあたりを読むと書いてあります。 少年ジャンプのストーリーは「努力」「友情」「勝利」がテーマなんだそうです。 最近のジャンプは知りませんが、ドラゴンボールなどはまさに典型的ですよね。 スクリプトの限界サイズは「努力」しても越えることができません。 こうなると「友情」に頼るしかありません。 一人の小さな手では何もできませんが、皆が集まると何かできてしまうのです。 これがLSLのモジュール化の発想です。 つまり、一つのスクリプトの限界は16KByteですが、複数のスクリプトを組み合わせ、全体として一つの大きなシステムにしてやるのです。 スクリプトの機能を分化し、連携して動くようにすることをモジュール化と言います。 モジュール化してやれば、トータルで見たときには16KByteの制限を越えるシステムを作ることが可能になります。 また、モジュール化には他のメリットもあります。 第一に開発効率が良くなります。 ダイアログモジュールやリッスンモジュール、アニメーション、サウンドなどをモジュール化しておくと、次にそれらの機能を使いたいときにはそのモジュールをほぼそのまま使うことが可能です。 一つ一つのスクリプトにいちいちリッスンやアニメーションのわずらわしいコードを書く必要がなくなります。 メンテナンス性の向上もみこめます。 モジュールごとに機能が分かれていれば、何か修正するときには一部のモジュールだけを更新するだけでOKになります。 例えばゲームの点数やRPGシステムの経験値など、データを保存するようなスクリプトの場合、スクリプトを修正するとデータはリセットされてしまいます。 しかしモジュール化によってデータを管理するスクリプトと、他の機能のスクリプトが分かれていれば、データ管理のスクリプトを修正しない限りはデータは保持されます。 また、拡張性も高くなります。 機能が分割されていますので、新しい機能を追加するときには別のモジュールを作って追加すれば良いのです。 例えば、オブジェクトの色が変わる機能を追加したいと思ったら、色変更用のモジュールを追加するだけです。 モジュール化を上手に実現しておくと、もとからあるスクリプトを一切いじらなくても大丈夫です。 モジュール化の手法 モジュール化を行うには、別に難しいコードを書く必要はありません。 初級スクリプトでも解説しているリンクメッセージ機能を利用すれば良いのです。 リンクメッセージは違うprimのスクリプト同士で通信を行う機能として紹介しましたが、実は同じprim内のスクリプト同士の通信も可能です。 同一prim内のスクリプトへのリンクメッセージ送信： llMessageLinked(LINK_THIS, integer ,string, key); 同一オブジェクト内（全リンクprim）のスクリプトへのリンクメッセージ送信： llMessageLinked(LINK_SET, integer ,string, key); この二つを知っていれば十分にモジュール化は可能です。 モジュールのイベントは基本的に全てlink_messageイベントに統一しておきます。 普通のLSLの構造は、「きっかけ」があったら「処理」を行うものだと何度も説明していますが、「きっかけ」をリンクメッセージだけに統一してしまうのです。 そして「処理」のほうは実現したい機能に応じたものを書きます。 つまり、 「リンクメッセージを受信したら、何らかの処理を行うスクリプト」 これがモジュールの基礎スタイルになります。 イベントをリンクメッセージのみに限定することで、考えるべきポイントは「いかに処理を行うか」だけになります。 処理を実現する仕組みのことを「ロジック」と言いますが、このことから、こうしたモジュールを「ロジック・モジュール」と私は勝手に呼んでいます（＾＾； 要するに「処理」が主体のモジュールのことです。 一方、タッチやリッスンなど、外部からの操作を受け付けるモジュールもまた必要です。 アバターが直接リンクメッセージを送る方法はありませんので、 「タッチされたらリンクメッセージを送る」 「コマンドを聞いたらリンクメッセージを送る」 というような、先ほどの「ロジック・モジュール」とは逆の働きをするモジュールを用意しなければなりません。 これらは様々なイベントを受け取りますが、あくまでも「処理」は「リンクメッセージの送信」です。 私はこれらのモジュールを「イベント・モジュール」と呼んでます。 ロジック・モジュールイベント：リンクメッセージ 処理：任意 イベント・モジュールイベント：任意 処理：リンクメッセージ さてさて。 少し具体的に考えて見ましょう。 例えば、ドア・システムのモジュール群です。 あんまりモジュール化するメリットはないかもしれませんが、説明するのにわかり易いと思うので（＾＾； ドアと言っても、いろんな種類のものがありますよね。 初級スクリプトの記事の中でも、回転して開くドアや自動スライドドアなどを作りました。 同じ自動ドアでも、センサーを使ったもの、衝突判定を使ったものなど、作り方を変えることもできました。 そんな風にいろいろな実現方法があるドアを、モジュール化することでひとまとまりの「ドア・システム」にし、どのモジュールを使うかによって回転ドアになったり、スライドドアになったり、はたまた自動ドアにする、手動ドアにするなど、自由自在に組み替えられるようにしてみたいと思います。 まず、ロジック・モジュール。 「処理」を実現する部分です。 今回はドアですから、「ドアの開閉」を実現できればどんなものでも良いでしょう。 ドアの開閉方法はいくつか考えられますね。 回転 スライド（横に限らず。上下とかも） 薄くなって消える 穴が開く／削れる（ホロウやパスカットを使用した変形） 開・閉のテクスチャ切り替え（開いた画像のときにはファントム化する） 他にもあるでしょうが、まぁこんなところで。 それからイベント・モジュール。 ドアが開く「きっかけ」となる部分です。 これもいろんなものが考えられます。 タッチ（誰でもタッチ可能なものから、特定グループ、オーナーのみ等、様々） 合言葉（リッスンを利用したもの） センサー（自動ドア用） 衝突判定（自動ドア用） タイマー（特定時間で開閉） 基本的にはこんなところでしょうか。 やろうと思えばもっと変なのも出来ますが（＾＾；強い風が吹くと開くとかｗｗｗ 以上のようなモジュールを用意したとすると、ドアを作る際、使いたいものを組み合わせてオブジェクトに放り込むだけでOKになります。 いちいちスクリプトを書き直す必要がなくなります。 また、「風で開くドア」を作りたいと思ったら、追加するのはイベントモジュール一つだけで済みます。 ロジックモジュール部分はなんら変える必要がありません。 そのように使い勝手が良く、拡張も楽なのがモジュール化のメリットです。 ドア・システム・スクリプト 具体的にコーディングしてみましょう。 ここに載せたスクリプトは自由に改造・再利用していただいて構いません。 組み合わせていろいろドアを作ってみるといいでしょう。 なお、モジュール・スクリプトはオブジェクトの中に直接作るのではなく、インベントリ内に作ったほうが後で使いやすいかと思います。 基本的なモジュール slide door module まずは「ロジック・モジュール」をいくつか作ります。 「ドアの開閉の仕組み」です。 インベントリのお好みの位置に新しいスクリプトを作成し、"slide door module"という名前を付けて下さい。 そして以下のコードを記述します。 slide door module vector pos; vector move_to = 0.0, 1.5, 0.0 ; integer opened = FALSE; default { state_entry(){ pos = llGetLocalPos(); } moving_end(){ if (opened){ pos = llGetLocalPos() - (move_to * llGetRot()); }else{ pos = llGetLocalPos(); } } link_message(integer send, integer num, string str, key id){ if (str == "door"){ if (num){ // open llSetPos(pos + (move_to * llGetRot())); opened = TRUE; } else { // close llSetPos(pos); opened = FALSE; } } } } このモジュールはオブジェクト（prim）をY軸方向に1.5ｍスライドさせます。 スライドして開くドアの動きを実現したものです。 しかしながら、あくまでも「開閉の動き」だけしか実現していません。 何をしたときにドアが開くかについては一切記述されていませんので、アバターがタッチしたり体当たりしたところで何も起こりません。 standard door module もう一つ「ロジック・モジュール」を作っておきましょう。 インベントリのお好みの位置に新しいスクリプトを作成し、"standard door module"という名前を付けて下さい。 そして以下のコードを記述します。 standard door module rotation rot; vector rotation_to = 0.0, 0.0, 90.0 ; integer opened = FALSE; default { state_entry(){ rot = llGetLocalRot(); } moving_end(){ if (opened){ rot = llGetLocalRot() / llEuler2Rot(rotation_to * DEG_TO_RAD); }else{ rot = llGetLocalRot(); } } link_message(integer send, integer num, string str, key id){ if (str == "door"){ if (num){ // open llSetLocalRot(rot * llEuler2Rot(rotation_to * DEG_TO_RAD)); opened = TRUE; } else { // close llSetLocalRot(rot); opened = FALSE; } } } } このモジュールはオブジェクト（prim）をZ軸基準に90度回転させます。 一般的なドアの動きを実現したものです。 しかしながら、先ほどのスライドドアと同様、あくまでも「開閉の動き」だけしか実現していません。 ２つの「ロジック・モジュール」を載せましたが、これらのモジュールはどちらも、リンク・メッセージを受信したときに動き出します。 特に、リンクメッセージの文字列が"door"の場合にのみ「開閉動作」を行うようになっています。 リンクメッセージのinteger値がTRUEの場合は「開」、FALSEの場合は「閉」の動作です。 door main module さて、それでは次に、この二つの「ロジック・モジュール」にリンクメッセージを送る部分のLSLを書いてみます。 インベントリのお好みの位置に新しいスクリプトを作成し、"door main module"という名前を付けて下さい。 コードは以下のようになります。 door main module float auto_close_timer = 60.0; integer opened = FALSE; default { link_message(integer send, integer num, string str, key id){ if (str == "action"){ opened = (!opened) * (num == -1) + (num != FALSE) * (num != -1); llMessageLinked(LINK_SET,opened,"door",NULL_KEY); llSetTimerEvent(auto_close_timer * opened); } } timer(){ llSetTimerEvent(0.0); llMessageLinked(LINK_SET,FALSE,"action",NULL_KEY); } } このロジックモジュールは、あらゆるドアに共通した性質・動作を実装したものです。 共通した性質とは「ドアには開・閉の２つの状態がある」という点です。 共通した動作とは「開けてから一定時間が経過すると自動的に閉まる」ことです。 スライドドアであろうと、普通のドアであろうと、開・閉の２状態があることには変わりないし、一定時間経つと自動で閉まる機能があってしかるべきでしょう。 つまりこのモジュールは「ドアの基本的な性質」を実現したものです。 あらゆるドアは全てこのモジュールをコアとして使います。 コードをざっとながめていただくと分かるかと思いますが、このモジュールはリンクメッセージ"action"を受信したときに動き、"door"というリンクメッセージを送信するだけの動きしかしません。 先ほど載せたスライドドア、スタンダードドアはどちらもリンクメッセージ"door"で動き出すようになっていましたから、このメインモジュールからのリンクメッセージを受けて動くということになります。 ドアの動きをスライド式にしたければ、スライド・ドア・モジュールを使い、一般的なドアにしたければスタンダード・ドア・モジュールを使います。 どちらのモジュールを使うにしても、メイン・モジュールは同一のものでOKになります。 short touch module さて、これでロジックモジュールができましたので、次に「イベントモジュール」を作ってみましょう。 「ドアの開閉するきっかけ」です。 インベントリのお好みの位置に新しいスクリプトを作成し、"short touch module"という名前を付けて下さい。 そして以下のコードを記述します。 short touch module float distance = 5.0; default { touch_start(integer detected){ if (llVecDist(llGetPos(), llDetectedPos(0)) = distance){ llMessageLinked(LINK_SET,-1,"action",llDetectedKey(0)); }else{ llInstantMessage(llDetectedKey(0), "There is out of your reach. You can t touch. "); } } } このモジュールは基本的にタッチイベントに反応しますが、距離の制限が付いています。 先頭に定義している変数distanceがタッチが有効になる距離です。 ここに記載した例（distance = 5.0）であれば、オブジェクトから５ｍ以内ならタッチできますが、それより距離があるとタッチしたことになりません。 適切な距離からオブジェクトにタッチすると、リンクメッセージ"action"が送信されます。 このリンクメッセージはドアのメインモジュールで受信され、最終的にドアの開閉が行われます。 遠い位置からのタッチを無効にすることで、ドア開閉の動きはより自然になるはずです（ドアの側にいないのにタッチして開けられるのは不自然ですのでｗ）。 group touch module もう一つイベントモジュールを作りましょう。 インベントリのお好みの位置に新しいスクリプトを作成し、"group touch module"という名前を付けて下さい。 group touch module float distance = 5.0; default { touch_start(integer detected){ if (llVecDist(llGetPos(), llDetectedPos(0)) = distance ){ if (llSameGroup(llDetectedKey(0))){ llMessageLinked(LINK_SET,-1,"action",llDetectedKey(0)); }else{ llInstantMessage(llDetectedKey(0), "Group member only."); } }else{ llInstantMessage(llDetectedKey(0), "There is out of your reach. You can t touch. "); } } } ほとんどショート・タッチと一緒ですが、グループ判定を付け加えてみました。 オブジェクトと同一グループをアクティブにしていないと反応しません。 グループメンバーが適切な距離からオブジェクトにタッチすると、リンクメッセージ"action"が送信されます。 そしてドアメインモジュールを経由し、ドアの開閉が行われることになります。 拡張モジュール ロジック、イベントモジュールともに２つ載せましたが、どちらを使うかは用途に応じて選択すればOKです。 さらには、もっと他のモジュールを用意しても構いません。 必要なことは、 １、イベントモジュールはリンクメッセージ"action"を送信する ２、ロジックモジュールはリンクメッセージ"door"を受信して動く この２点です。 さらに詳しく書くなら、リンクメッセージに指定する整数値と文字列は以下のような意味になります。 イベントモジュールから送信するリンクメッセージ 整数値 文字列 意味 TRUE "action" ドアを開く FALSE "action" ドアを閉じる -1 "action" ドアが開いてれば閉じる、閉じていれば開く ロジックモジュールで受信するリンクメッセージ 整数値 文字列 意味 TRUE "door" ドアを開く FALSE "door" ドアを閉じる 以上のルールを逸脱しなければ、どのようなモジュールを追加することも可能です。 では拡張してみましょう。 sensor module 自動ドアに対応するため、センサーイベントを使ったイベントモジュールを追加してみます。 インベントリのお好みの位置に新しいスクリプトを作成し、"sensor module"という名前を付けて下さい。 せっかくですので、以前すくりぷたXさんがおっしゃっていた段階的な探知を実現してみましょう。 sensor module default { state_entry(){ llSensorRepeat("", "", AGENT, 15, PI, 10.0); } sensor(integer detected){ state wait_level2; } } state wait_level2 { state_entry(){ llSensorRepeat("", "", AGENT, 10, PI, 3.0); } sensor(integer detected){ state wait_level3; } no_sensor(){ state default; } } state wait_level3 { state_entry(){ llSensorRepeat("", "", AGENT, 5, PI, 0.25); } sensor(integer detected){ state activate; } no_sensor(){ state wait_level2; } } state activate { state_entry(){ llMessageLinked(LINK_SET,TRUE,"action",llDetectedKey(0)); llSensorRepeat("", "", AGENT, 5, PI, 5.0); } no_sensor(){ llMessageLinked(LINK_SET,FALSE,"action",llDetectedKey(0)); state wait_level3; } } 遠距離・長間隔の探知から近距離・短間隔の探知へと遷移していき、至近距離に入ったときにリンクメッセージTRUE,"action"を送信し、ドアを開きます。 逆に、至近距離に誰もいなくなったときにはリンクメッセージFALSE,"action"を送り、ドアを閉じます。 これで自動ドアも作れるようになりました。 ショートタッチやグループタッチの代わりにセンサーモジュールを使えば、そのまま自動ドアになります。 phantom door module ロジックモジュールも拡張してみましょう。 バリアのように、薄れて消えるタイプのドアを作ってみます。 インベントリのお好みの位置に新しいスクリプトを作成し、"phantom door module"という名前を付けて下さい。 phantom door module float alpha_max = 0.5; integer opened = FALSE; default { state_entry(){ llSetStatus(STATUS_PHANTOM, FALSE); } link_message(integer send, integer num, string str, key id){ if (str == "door"){ if (num){ if (!opened){ float a; // open for (a = alpha_max; a 0.0; a -= 0.05){ llSetAlpha(a, ALL_SIDES); llSleep(0.05); } llSetAlpha(0.0, ALL_SIDES); llSetStatus(STATUS_PHANTOM, TRUE); opened = TRUE; } } else { if (opened){ float a; // close for (a = 0.0; a alpha_max; a += 0.05){ llSetAlpha(a, ALL_SIDES); llSleep(0.05); } llSetAlpha(alpha_max, ALL_SIDES); llSetStatus(STATUS_PHANTOM, FALSE); opened = FALSE; } } } } } このモジュールはドアを透明にし、ファントム化（幻影）にします。 閉じるときは半透明（先頭の変数alpha_maxに定義した透明度）になります。 開閉のきっかけはリンクメッセージ"door"ですので、スライドドアやスタンダードドアの代わりとしてそのまま使えます。 モジュール化の効果 以上でスクリプトを合計７本、載せました。 今回載せたスクリプトによって、何種類のドアが作れるでしょうか？ イベントモジュール、メインモジュール、ロジックモジュールの３つを組み合わせて使いますが、組み合わせは以下の通りです。 No イベント メイン ロジック ドアの機能 1 short touch main slide タッチするとスライドして開くドア 2 short touch main standard タッチすると回転して開くドア 3 short touch main phantom タッチすると透明になるドア 4 group touch main slide スライドして開くグループ専用ドア 5 group touch main standard 回転して開くグループ専用ドア 6 group touch main phantom 透明になるグループ専用ドア 7 sensor main slide スライドして開く自動ドア 8 sensor main standard 回転して開く自動ドア 9 sensor main phantom 透明になる自動ドア 全部で9種類のドアが実現可能であることがおわかりいただけるかと思います。 スクリプトは7種類しか書いていないのに、9種類の機能が実現できる、これがモジュール化の利点です。 イベントモジュールやロジックモジュールを追加するたびに実現可能なドアは増えます。 例えば、イベント・ロジックともにもう一つずつ追加すると、スクリプトの数は９個で、作れるドアは４×４の１６種類になります。かなりのお得感♪ まぁ、今回取り上げたのはドアですから、わざわざモジュール化しなくてもどれも簡単に作れるだろうとは思います。 しかし、より複雑なものを作るにあたり、モジュール化を念頭にして作っていくのと、ひたすら一つのスクリプトとして組み上げるのでは、後々の効率が大きく異なってきます。 例えば、今回作ったイベントモジュールなどは他のものを作るときにも流用可能なはずです。 仲間と一緒に複雑なシステムを組み上げるなんていうときにも便利です。 リンクメッセージでやり取りする内容さえ決めておけば、あとはそれぞれに分業が可能になりますので。 一つのスクリプトのサイズ上限を克服するための小細工が、ここまでくると実に有用な開発手法であることがお分かりいただけるかと思います。 なんでもかんでもモジュール化すれば良いとは言いませんけども（＾＾； モジュール化のデメリット 良いところばかり挙げて問題点に触れないわけにもいきませんので、最後に補足です。 一つのLSLモジュールは16kのサイズであると、最初に書きました。 逆説的に言うなら、モジュールを１つ作ると16kのサーバーリソースを消費する、とも言えます。 モジュール化が便利だからといって何でもかんでも分割していたら、トータルのサイズはどんどん大きくなっていきますので、一概にメリットばかりではなくなってきます。 また、モジュール間のやりとりにはリンクメッセージを使っていますが、同一prim内のスクリプトが増加すると、一度のリンクメッセージでそれらが一斉に反応することになります。 listenなどに比べれば負荷は軽いとは言え、数が増せばそれなりに重くなっていくのは確かです。 最も良いのは、各モジュールを16k単位に分割することです。 ぴったり分けるのは困難ですから、可能な範囲でモジュールを一つにまとめ、なるべく無駄のない形に仕上げることが最良の道になります。 例えば、一つのスクリプトで済むところを４つも５つものモジュールにするというのは少々安易です。 バランスの問題になりますので、難しいところではありますが。 名前 コメント
https://w.atwiki.jp/fourze13/pages/84.html
【種別】 用語 フォーゼモジュール 【用語】 ドリルモジュール 【よみがな】 どりるもじゅーる 【登場話】 第1話 【特徴】 【アストロスイッチと特殊装備（モジュール）】 仮面ライダーフォーゼ ベースステイツ 番号 アストロスイッチ 特殊装備（モジュール） 部位 記号 01 ロケットスイッチ ロケットモジュール 右腕 ○ 02 ランチャースイッチ ランチャーモジュール 右脚 × 03 ドリルスイッチ ドリルモジュール 左脚 △ 04 レーダースイッチ レーダーモジュール 左腕 □ 05 マジックハンドスイッチ マジックハンドモジュール 右腕 ○ 06 カメラスイッチ 07 パラシュートスイッチ パラシュートモジュール 左腕 □ 08 チェーンソースイッチ チェーンソーモジュール 右脚 × 09 ホッピングスイッチ ホッピングモジュール 左脚 △ 【関連するページ】 MOVIE大戦 MEGAMAX フォーゼ編（仮） アストロスイッチ カメラスイッチ チェーンソースイッチ チェーンソーモジュール ドリルスイッチ パラシュートスイッチ パラシュートモジュール フォーゼドライバー フォーゼモジュール ホッピングスイッチ マジックハンドスイッチ マジックハンドモジュール ランチャースイッチ ランチャーモジュール レーダースイッチ レーダーモジュール ロケットスイッチ ロケットドリルキック ロケットモジュール 仮面ライダー×仮面ライダー フォーゼ＆オーズ MOVIE大戦 MEGAMAX 仮面ライダーフォーゼ 仮面ライダーフォーゼ エレキステイツ 仮面ライダーフォーゼ ファイヤーステイツ 仮面ライダーフォーゼ ベースステイツ 用語 第10話 第12話 第14話 第16話 第18話 第1話 第20話 第24話 第26話 第28話 第2話 第30話 第3話 第4話 第5話 第6話 第7話 第8話
https://w.atwiki.jp/sentai-soubi/pages/2538.html
【名前】 パラシュートモジュール 【読み方】 ぱらしゅーともじゅーる 【登場作品】 仮面ライダーフォーゼ 【初登場話】 第2話「宇・宙・上・等」 【分類】 フォーゼモジュール 【対応】 左腕/パラシュートスイッチ 【詳細】 パラシュートスイッチをONにすると左腕に出現するフォーゼモジュール。 司る色は「コバルトグリーン（濃緑色）」。 左腕の部分に装着するパックコンテナから高度に応じてトライキャノピー（3つのパラシュートの傘）が自動展開する。 ライダーロケットドリル宇宙キックから、地上へ無事に着地する際に使用された。
https://w.atwiki.jp/rubyiw/pages/48.html
Rubyには、モジュールという概念がある。この機能により、クラスが128倍パワーアップするという素敵なものなのである。これから解説していこうと考えているわけだが、ちょっとその前に、少しお話しておきたいことがあるのだ。 あるクラスを基にして新しいクラスを作成することを『継承』と呼ぶのであるが、実はこの『継承』には、2種類の方法がある。 それは、基になるクラスをひとつだけに限定するか、もしくは複数を許すかということなのだ。前者は『単一継承』、後者は『多重継承』と呼ばれている。 下等な生物であれば単一生殖もありうるが、通常単一では子供が生まれない。であるから、親子という概念からすると、『多重継承』の方が自然であるような気もするが、オブジェクト指向プログラミング言語においての継承は、親子関係のメタファーではなくどちらかというと『種の進化』という側面が強いので、『単一継承』も十分アリだという気もする。 しかしまあ、現実の世界になぞらえて、プログラミング言語を考えるのは、楽しいけれども、あまり意味のないことなので、言語仕様という側面から２つの継承方法を考えてみよう。 実は、数あるオブジェクト指向（っぽいものも含む）プログラミング言語で、多重継承をサポートしているものは少ないのである。Eiffel(アイフェル、エッフェル)、C++言語、Perl、Pythonぐらいのものであろうか。その他の言語は、多重継承はサーポートしていない。なぜなら、多重継承は、非常に問題点が多いのだ。 1.継承関係が複雑になりすぎる。 2.メンバ名の衝突。 3.コンパイラ、インタプリタの実装が難しくなる。 とまあ、3番目の問題は、言語開発者サイドからみた問題点であるので、使う立場の者にとっては関係ないことだが、1と2については、なかなかに問題は深刻だ。そのため、比較的新しく誕生したオブジェクト指向プログラミング言語、例えば、Objective-C、Java、C#、VisualBasic.NETなどは、多重継承をサポートしていないのである。その代わりといっては何だが、これらの言語にはInterfase(インターフェイス)という概念がある。 例えば、人間クラスと鳥クラスの両方の機能を継承して、鳥人間クラスを作りたいとする。どうしてそのようなクラスを作りたいかというと、鳥のように大空を飛び回る人間を作りたかったのだ。これが多重継承であれば話は簡単で、例えば次のようにすればよい。 001 | // 人間クラス 002 | class CHuman 003 | { 004 | }; 005 | // 鳥クラス 006 | class CBard 007 | { 008 | void fly() 009 | { 010 | } 011 | }; 012 | // 鳥人間クラス 013 | class CBardMan public CHuman, public CBard 014 | { 015 | }; 016 | 017 | CBardMan bm; 018 | bm.fly(); これで、大空を自由に飛べる新しい人類が誕生し、めでたしめでたしと思っていたのだが、様々な問題があることがわかってきたのである。例えば、鳥目のために夜何も見えないとか、公園の池でぴちょっと跳ねる鯉をパクッといきたいという衝動にかられるなどの問題だ。 これはやはりまずいよということで登場したのが、インターフェイスという概念なのである。 今回、人間クラスに追加したいのは、『空を飛ぶ』という機能なのである。そこで、『空を飛ぶ』という機能を仕様として切り出し、インターフェイスとして定義するのである。C#を例に、実際に定義してみよう。 001 | // 空飛ぶインターフェイス 002 | public interfase IFly 003 | { 004 | void approach(); // 助走 005 | bool takeoff(); // 離陸 006 | void flutter(); // 羽ばたき 007 | void ascend(); // 上昇 008 | void gliding(); // 滑空 009 | void descent(); // 下降 010 | bool landing(); // 着地 011 | } そして、この空飛ぶインターフェイスを鳥クラスと、人間クラスに定義してやるのだ。 001 | class CHuman IFly 002 | { 003 | } 004 | class CBard IFly 005 | { 006 | } よしこれで完璧だと安心するのはまだ早計で、実はIFlayインターフェースにある7つのメソッドは、全てガラだで、中身が詰まっていないのである。『鳥と人間とでは、同じ空を飛ぶにしたって、やることはちょっとずつ違うだろう。だから、各メソッドの中身は全部自分で実装してくれ』というスタンスなのだ。その代わり、IFlyというインターフェースを持つクラスのインスタンスは、外部から見ると全く同じ操作で空を飛ばすことができるというわけである。 継承できるクラスはたったひとつだけだが、インターフェイスは複数くっつけることができる。要するにインターフェースとは『仕様の多重継承』というわけである。 実になんともすばらしい概念なのだが、ここでひとつ不満が沸いてこないだろうか。それは、 「なんだよ。実装を共有できないのかよ」という不満である。可能であれば、マンガのドラえもんに出てくるタケコプターのように、頭にくっつければ後は勝手に飛んでくれるというのがよろしい。 そこで登場したのが、RubyのMix-in(ミックスイン)という考え方だ。これは、中身のつまったインターフェイスと考えればよろしい。それを実現するのがモジュールというわけなのである。 001 | #タケコプターモジュールの定義 002 | module TakeCopter 003 | def fly 004 | #空を飛ぶノウハウがぎっしりと・・・ 005 | puts "飛んで飛んで飛んで" 006 | end 007 | end 008 | 009 | #鳥人間クラスの定義 010 | class BardMan 011 | #タケコプターモジュールのMix-in 012 | include TakeCopter 013 | end 014 | 015 | bm=BardMan.new 016 | bm.fly 12行目が、モジュールをインクルードしているところで、この一行さえあれば、タケコプターモジュールの機能を全て自分の中に取り込むことができる。16行目で、flyメソッドが、さも自分のもののように呼び出されているのを見ていただきたい。 上記のコードは、コード作成時、静的にモジュールを取り込んだわけだが、プログラム実行中、動的に取り込むこともできる。 001 | #タケコプターモジュールの定義 002 | module TakeCopter 003 | def fly 004 | #空を飛ぶノウハウがぎっしりと・・・ 005 | puts "飛んで飛んで飛んで" 006 | end 007 | end 008 | 009 | #鳥人間クラスの定義 010 | class BardMan 011 | end 012 | 013 | bm=BardMan.new 014 | #タケコプターモジュールを動的に取り込む 015 | bm.extend TakeCopter 016 | bm.fly もう、ここまでくると、もうなんでもありなのかという気持ちになってくる。これだけ強力な機能があれば、もしかするとクラスの継承すら、もう必要ないのかもしれない。
https://w.atwiki.jp/modae/pages/12.html
ある種のモジュールは、演奏時に値が変化しないことが保証されているため、 一度だけ評価すればよい、ということがある。 このようなモジュールはその値を出力する Constant クラスのインスタンスに 置換してよい。 このようなモジュールを「定数モジュール」といい、 定数モジュールを Constant のインスタンスに置換することを 「定数モジュールの最適化」ということにする。 定数モジュールの最適化は、演奏時のパフォーマンス向上を目的として構築時に行う。 定数モジュールについては、それに対する入力を考慮する必要がないし、 prepareNext() を呼ぶ必要もない。 定数モジュールの例： 1 は定数モジュールである。 1 + 42 は定数モジュールである。 sin(phase) は、phase が定数モジュールなら定数モジュールであり、そうでないならそうでない。 sin(phase) + 1 も同様に、phase が定数モジュールなら定数モジュールであり、そうでないならそうでない。 Foo() Bar() は、Foo() と Bar() の両方が定数モジュールなら定数モジュールである。また、Foo() または Bar() が定数モジュールで、かつその値が偽であっても定数モジュールである。それ以外ならそうでない。 （ の両辺が定数のとき、 は定数であり、値は通常の と同じ。 の左辺または右辺が定数で、かつそれが偽であるとき、 は定数であり、値は偽。 || の両辺が定数のとき、|| は定数であり、値は通常の || と同じ。 || の左辺または右辺が定数で、かつそれが真であるとき、|| は定数であり、値は真。 これ以外は定数モジュールでない。 ） 一般に、あるモジュールが定数モジュールかどうかは、そのときの接続状況 （具体的には、InJack に接続されているモジュールの定数性）に依存する。 接続関係が変化すると定数性も変化する。 （定数モジュールの最適化は構築中は行わず、演奏開始直前まで遅延した方がよい） モジュールに以下の API を追加： 現在の接続状況において自らが定数モジュールであるかどうか 定数モジュールである場合、構築時に値を得る（generateOutputs() が使えるか？）
https://w.atwiki.jp/shrikemwo/pages/8.html
モジュールの説明になります。
https://w.atwiki.jp/projectdiva_ac/pages/975.html
モジュール 紅葉 キャラクター MEIKO デザイン 仕事してP 価格 250VP 初出 extendより 和服調 コメント 野菜でも揺れるかな？ -- 名無しさん (2012-05-26 02 17 17) まだアケに無いけど羅刹と骸はコレい -- 名無しさん (2012-05-26 14 32 36) ↑途中送信しちゃったorz一択です！！ -- 名無しさん (2012-05-26 14 35 25) 数多の舞でも確認できず。大正浪漫はモロ見えだったのに…って、ワンカップ酒投げつけないで。 -- 名無しさん (2012-05-26 20 58 00) いろは唄の例のところで、黒っぽいのが見えた気が。帯も黒いから見間違いかも。録画してスロー再生してみたい。 -- 名無しさん (2012-05-28 15 47 55) ESのトライアル埋めついでに色々試してみて、ついに当たり引いた。Yellowお勧めマジお勧め。跳ねてはたゆん、回ってはふわり、Cメロ直前なんか少し遠くて後ろ姿だが見事に蹴り上げてくれた。…しかし着物の色(白系)に見えたんだが…↑と違うな、ちょっと遠かったし見間違えたかな。録画すりゃよかった -- 名無しさん (2012-05-28 21 41 47) ↑1～3 ルカルカで確認したらグレーっぽかった。 -- 名無しさん (2012-06-04 20 22 59) 番凩はもちろん羅刹にも合うね。「首輪に繋がる赤い糸は～」の所で紅葉の首飾りがアップになるのがいい -- 名無しさん (2012-06-15 23 45 16) いつもこれと大正ロマンで迷う自分ｗ -- 名無しさん (2012-06-16 21 13 44) MSJとともにアドレサンスに設定してます。どちらもキュートかつビューティーだが、思春期とは思えないとｓ（ｒｙこの後バケットと酒瓶で殴られる。 -- (キュウビ廃) 2016-10-20 20 49 35 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/yryo1005/pages/14.html
モジュールを呼び出すおまじない import モジュール名 モジュール名を変更して呼び出すおまじない import モジュール名 as 変更したい名前 例）import matplotlib.pyplot as plt (matplotlib.pyplotというモジュール(グラフ機能のモジュール)をpltという名前で使えるようにした) モジュールの特定の関数のみ引き出したいときに使う from モジュール名 import 関数名 モジュールを呼び出してからそのモジュール内の関数を使うときは モジュール名.関数名() の形にする randomモジュール 乱数に関する処理を集めたモジュール random.random() 0 X 1の数字を出す関数 ()内に何かを入れるとエラーを起こす random.randint(A, B) A =X =Bの数字(整数のみ)を出す関数 ()内に必ず二つ数字を入れないといけない random.shuffle(リスト名) 作成済みのリストの要素をランダムにシャッフルする シャッフル内容は毎回変わる random.choice(リスト名) 作成済みのリストの要素からランダムに一つ選ぶ statisticsモジュール 統計に関する処理を集めたモジュール statistics.mediam(リスト名) 作成済みのリストの要素の中央値を出す関数 リストは数値のみで構成されてないといけない