約 120,268 件
https://w.atwiki.jp/romancing/pages/41.html
ロマンシングサガ ロマンシングサガ2 RS2_アイテム名称 ロマンシングサガ3 RS3_アイテムデータ RS3_技データ RS3_仲間ステータス RS3_敵のステータス 構造体の使い方 1 Stirlingをダウンロードする 2 Struct.defをアップローダーから入手し、Stirlingと同じフォルダに置く 3 編集→構造体編集を選択 4 「RS1_○○」や「RS2_○○」「RS3_○○」を選択する。それ以外はただの定義なので無視して結構 5 現状、元ファイルはRS1・RS2はヘッダ有り、RS3はヘッダ無しでとりあえず統一されている。 Struct.defはメモ帳や秀丸などのテキストエディタで編集が可能。 ヘッダの有無を調整する場合は、各項目の頭についている space[xxxxx]の数値に+512や-512すればいい。
https://w.atwiki.jp/romancing/pages/40.html
構造体について 基本 Stirlingをインストールする。 アップローダから構造体定義ファイルを落とす。 落としたファイルを展開して中にあるstruct.defファイルをStirling.exeと同じフォルダに入れて上書き。 利用 Stirlingで対象ファイルを開き、設定→構造体編集を選択。 編集したい項目を左上のボックスから選ぶ。 ※名称にRS1_やRS2_、RS3_と書いてあるものを選ぶこと。 色々出てくるので、+をクリックすると内容が表示される。 ※物によっては+はない場合があるが気にしない。 値の欄をダブルクリックし数値を変える。 保存すれば改造完了。 *最初は16進数で表示されていてわかりにくいので、右クリック→一括指定で符号なし10進数表示にするとわかりやすい。 *ただし、技番号など16進数でしか意味の通じないものもある。 *アドレスが0の位置から構造体編集を開かないとズレてしまうので要注意。
https://w.atwiki.jp/besiegejpwiki/pages/116.html
ここでは、様々な機能や役割を持ったブロックの組み合わせ方を簡潔にまとめている。 マシンデータはこちらからダウンロードできる。 制御系リアクションホイール リアクションドリル ジャイロスタビライザー 角度計スタビライザー 風船スタビライザー FBT 周期運動タイマー 周期運動タイマー2 オーバーフロー 角度同期装置 トラッカー 構造系サスグラバーフレーム サスヒンジフレーム ２マスログ 0.5戻し直列ログブロック 強化回転軸 車両超信地旋回 減衰機構付きサスペンション ドリル駆動 履帯と転輪装甲履帯と中空転輪 サスペンション軸転輪 ヒンジ履帯と有軸転輪 巻き付け履帯 空力操舵直線移動を変換する方式 回転体を固定する方式 二重コグ式操舵 STEERING HINGE の自動戻り機能 推進装置蒸気推進 プロペラ推進 無抵抗錘式エンジン 二重反転プロペラ 可変ピッチ式プロペラ 動力源直付け方式の双発 直列双発 プロペラエンジンの出力調整方法 バキュームエンジン NIVES(ナイブス) 武装サス式反動吸収機構 サス式反動吸収機構2(通称：グラバー砲) 火炎ロケット(火炎ミサイル) 制御系 リアクションホイール 抵抗のある物体を錘として回転させた反動を利用する。車輪の回転で車体まで回ってしまうのを打ち消したり、反トルクそのものを使って機体を旋回させたりと利用の幅は広い。 簡素で設計が許す限り気軽に設置でき、原理上静止状態でも姿勢を変えられる。 反面、反動により機体にかかる負荷も比較的大きいので頑丈に作る必要があり、空力操舵と比べると低速域では機敏、高速域では緩慢になる傾向にある。 MOTOR WHEEL や POWERED MEDIUM COG はBRACEを直接設置でき、任意の操作が可能で十分な回転速度があるためよく用いられる。 抵抗は重量による慣性、あるいは空気抵抗から得る。 BRACEはそのサイズや重量に対して生み出す慣性の比率が最も大きく、錘にすれば効率よく反トルクを得られる。仮置したブロックから回転するブロックにかけてBRACEを設置し、仮ブロックを消すことで図のように回転体にのみ接続されたBRACEを錘として持つ構造ができる。 空気抵抗から得る場合ただの減速装置に成りかねないため航空機での採用例は少ないが、マルチコプターにおいてはローターの出力差制御や空力バランサーとの複合が可能なため採用される場合がある。 リアクションドリル 操作可能なブロックの中で最速の回転速度を持つDRILLを使った反トルク機構。DRILLには接続判定がないため、BRACEの代わりにGRABBERの接着を使って錘としている。 構造自体は破壊不可能だが、回転が速すぎると遠心力で伸びたグラバーが当たって自機が損傷したり爆散 現象を起こしたりするので過信はできない。 ジャイロスタビライザー Besiegeにはジャイロ効果が存在し、回転系に対して回転の軸に交わる方向に対して強い回転抵抗を発生させる。 簡単なものだと、無動力回転ブロックに動力回転ブロックを取り付け、その両方にブレースを取り付けて回す構造が強い効果を得られる。 また回転ブロックを機体に直付けして反トルクを打ち消した場合でも同様の効果が得られる。 回転数が大きくなるほど、動力ブロックに取り付けるブレースが多いほど効果は大きい。 角度計スタビライザー 角度計を用いて上述のリアクションホイールなどを自動操作させてやることで、マシンを常に水平に保たせることができる。 マシンが下を向いたら上を、上を向いたら下を向かせるように角度計のエミュレートを設定する。この時、5～10度程度、どちらの方向にもエミュレートしないバッファゾーンを設けてやると良い。 マシン全体のサイズや出力トルクの強さによっては振動を続ける場合があることに注意しよう。 なお、ステアリングヒンジなどの自動戻り機能を用いながら角度計を回転させるスタビライザー（自動戻り角度計スタビライザー）も存在する。こちらはスペースこそ取るものの、安定性が大幅に上昇する。 詳しい仕組みの解説： 本来リアクションホイールには回転の速さをシミュレーション中に変える手段が無い。しかし、ステアリングヒンジ（あるいはステアリングブロック）の回転と自動戻りを利用することで、目標の角度付近で角度計のON/OFFを高速で往復させ、ホイールのデューティー比を変化させられる。 これにより、目標角度との差に応じた出力の調整が可能になる。 y軸に関して姿勢を固定するときなどは、角度系をステアリングブロック等で回せるようにすると、好きな向きで固定することができる（y軸スタビライザー）。y軸スタビライザーは2つ以上載せて、タイマー等で最初に片方のトグルをオンにし、以降キー操作等で入れ替えるようにすると、例えば砲塔の向きを車体合わせにしたり固定にしたりとを素早くスイッチングすることができる。 もちろんy軸スタビライザーもステアリングヒンジを挟むことで、より滑らかな挙動にすることができる。 風船スタビライザー 風船による姿勢安定化装置。 NoBounds modを使うと、浮力がマイナスの風船を作ることができる。マイナス風船は地面に沈むような力を与える。 これと通常の風船を縦に置くと、上下から紐で引っ張るかのように姿勢を安定させることができる。 y軸回りの回転には安定化作用が働かないことと、片方の風船が割れるとマシンが吹っ飛んでしまうことに注意。 FBT 一定の角度を保とうとする強力なスタビライザー 曲薄スタビライザーとも Flat Block Stabilizationの略 スケーリングで極端に薄くしたブロックに別のブロックを一体化させることで、ブロックの重心を遥か遠方に飛ばし、回転のしにくさを表す慣性モーメントを大幅に増加させる ※NoBounds modとBlock Scaling Toolsが必須 + 作り方 作り方 1. 何でもいいのでブロックの上にスケーリングブロックを設置する 2. スケーリングブロックのz方向のスケール値を極小値（0.000001など）にする（コンマ2桁までしか表示されないが問題ない） 3. 鉄製プレート（小）などの一体化するブロックをスケーリングブロックの上に設置する 4. 鉄製プレート（小）を上下反転し、下向きに0.1移動する 5. スケーリングブロックを上向きに0.2移動する ※FBTは徐々に傾いてしまうため、傾きを均すようにスピニングブロックなどで回すと良い VES※現在のバージョンでは機能しません 常に一定の方向を向こうとするスタビライザー Vector Entanglement Stabilizationの略 バルーンスタビライザーと似通った挙動を取るが、こちらはオン・オフの切り替えが可能なことが利点である + 作り方 作り方 下の画像のようにスプリングを設置する ステアリングヒンジを設置し、スプリングとステアリングヒンジを設置しているブロックの中心にくるように移動させる ステアリングヒンジのz軸スケーリング値を2.5にする（可動域は90°） 同様にスプリングのz軸のスケーリング値を0、硬さを99999にする(注意 スプリングのz軸のスケーリング値は0でないと機能しない) スタビライザーを安定させるためにスイベルジョイントとスピニングブロックを用いてジャイロスタビライザーを併設する（任意） 正常に動作すると下のgifのようになる このようにバルーンスタビライザーと似たような動きをするようになるが、このままでは使い物にならないので、 スプリングをロープウィンチに置き換え、さらに3個追加するとより強力なものになる（ロープの伸縮スピードは10e+20程度が目安） 下のgifは3個追加したもの VESサンプル 周期運動タイマー 歩行機など、複数のブロックを一定の周期で動かしたいときに使える回路。画像では周期1秒で2つのステアリングヒンジが交互に動くような回路を作っている。 左のタイマーは決まった周期ごと（この場合は1秒ごと）にキー操作をエミュレートする。これに中央のタイマーが反応し、0.5秒だけステアリングヒンジを動かす（左矢印キー）。それと同時に右のタイマーを反応させ、今度は逆向きに0.5秒だけステアリングヒンジを動かす。左のタイマーはループ設定にしてあるので、この0.5秒ごとの運動を繰り返す。 この回路を応用すれば、キー操作を2回以上エミュレートさせることができ、より複雑な周期運動が可能になる。 周期運動タイマー2 ホイール等の上に角度計を置いて回すと、角度に応じて周期的に出力させることができる。 角度計を水平に保つ必要があり設置場所が限られるが、ホイールの回転数を変えれば全体の周期を簡単に変えられるので調整がしやすい。 オーバーフロー NoBounds modを使ってブロックの数値を極端な値に設定すると、出力がオーバーフローを起こして通常の挙動をしなくなることがある。オーバーフローする閾値は一律で。 オーバーフローで挙動が変化するブロックは以下の通り ブロックの種類 元々の挙動 オーバーフロー後の挙動 ウォーターキャノン 水発射 速度に対する強力な抵抗 フライングブロック 推進 ロケット バキューム 吸引 吸引対象に強力な抵抗を付加 これらを使用すると、ブロックの振動や武装の反動などを軽減できる。 角度同期装置 揺動するパーツにステアリングヒンジと角度計を取り付け、常に同じ方向を向くようにキーを設定する。そして、そのキーを他のステアリングヒンジに設定することで、角度を同期できる。なお、ステアリングヒンジの代わりにステアリングブロックを用いても同様のことが行える。ホイール、コグを用いた場合は力の加わり方によっては角度がずれていってしまうので注意すること。 また、角度計の検出をキーで制御すれば、必要な時だけ角度を同期することもできる。 トラッカー センサーで地面を検知し、ステアリングヒンジの角度で出力する。 １センサー式と２センサー式があり、前者は常に振動するものの精度が良く、後者はしきい値の中であれば振動しないが精度が低いことが多い。 構造系 サスグラバーフレーム 弾性に富むサスペンションを主とするフレーム構造。 縦横に組み合わせるだけでも衝撃を抑え壊れにくくなるが、GRABBERやSTEERING HINGEと組み合わせるとさらに強固になり弾性ゆえの歪みも抑えられる。 サスヒンジフレーム サスグラバーフレームのグラバーをヒンジに変えた構造。 ヒンジの強い接続を活かした頑丈な構造で、ヒンジを増やせばその分耐久性の向上が見込める。 ログと比べると燃えないという利点があるが、耐久性や歪み耐性が劣り、ブロック数も増える。 ヒンジを反対向きに接続するとうまくくっつかないので注意。 ２マスログ 2ブロック分しかないスペースにLOG BLOCKを設置すると長さ2ブロックのLOG BLOCKができる。同じ大きさのWOODEN BLOCKと比べると重量は倍になるものの強度も倍になる。 WOODEN BLOCK, WOODEN POLEも１ブロック分短縮できる。 0.5戻し直列ログブロック LOGを直列に設置し、0.5ブロック分以上埋め込む構造。 LOGの特性として、LOG(A)の根本側の接続がLOG(B)を接続し、LOG(B)の頭側の接続がLOG(A)を接続する場合どちらも有効になるという特性があり、LOGは破壊されたような判定をされることもあるが実質LOGの頭側の接続だけを使って直接にLOGを置くことが可能になる。 LOGを0.5戻す必要があるのは、頭側の接続判定と根本側の接続判定が重なると場合頭側の接続判定が消失するという仕様があり、0.5ブロックずらす必要性が発生するためである。 強化回転軸 HINGEやSTEERING HINGE等の回転軸を重ねて補助するもの。画像では様々な種類があることを示すため雑多に組み合わせている。 複数ブロックの回転軸を重ねることで可動を阻害せず付加を分散できる。 車両 超信地旋回 キー設定のみで実現でき、１キー式と２キー式がある。 １キーならひとつのキーで左右が別々に前/後進するようにし、２キーならホイールに後進と左右のいずれかに進むよう設定して後進と左右旋回のキーを同時に押す。 画像は２キー式の例。 減衰機構付きサスペンション 一部の回転ブロックにある軸抵抗を減衰機構（ダンパー）として利用し、サスペンションの浮き沈みを緩やかにする機構。 サスペンションの動きに合わせダンパーが回転するように組み合わせる。 ACCELERATION（加速）の数値は軸抵抗の値でもあり、ダンパーの強度を調整できる。 画像ではSPINNING BLOCKを用いている。考案者の名前を取って”ヒゲダン”とも呼ばれる。 ドリル駆動 円形のブロックに設置したDRILLをGRABBERで懸架し、駆動系としたもの。GRABBERとDRILLが耐火なので必然的に耐火構造になる。 画像のようにCIRCULAR SAWは円形に近いだけでなく、軽いため反トルクが小さいので採用例が多い。 履帯と転輪 より詳細な履帯の情報や作り方はこちら →履帯の作り方 装甲履帯と中空転輪 装甲履帯はBesiegeにおいて古典的かつ一般的な履帯。中空転輪はさらに後代に開発された。 HINGEがやや余裕を持って収まる距離（１ブロック以上）でPOWERED MEDIUM COGを向かい合わせにしBRACEで接続する。ARMOR PLATEを設置したHINGEを軸にアドバンスドツールで複製・移動・回転させて転輪を囲むような輪にする。 COGの動力をPLATEに伝えることで駆動し、COGがHINGEを挟んで履帯の脱落を防いでいる。 サスペンション軸転輪 上の中空転輪を省ブロック化したもの。 履帯を噛むための空間と外側の転輪の懸架場所の両方をSUSPENTIONで確保したもの。 BRACEを使わずに済むため反トルクを減らすことができるが、SUSPENTIONなので旋回など横方向の力を受けると伸びて脱帯することがある。機動を穏やかにする、車体を軽量化する、回転を阻害しない形で転輪に直結した外部フレームの設置などで対応する。 ヒンジ履帯と有軸転輪 装甲履帯＋中空転輪と双璧を成す、HINGEのみで作られた履帯と当方式に適した転輪。 実体のあるブロックで履帯に動力を伝え、その左右をCOG系ブロックで挟むことで脱帯を防いでいる。 単純に履帯を軽量化できるだけでなく、HINGEはMETAL PLATEよりも摩擦が小さいため副推進装置による高速化効果の効果をより得られる。反面その摩擦の小ささゆえに機敏さで劣り坂道でもよく滑る。 巻き付け履帯 何らかの機構で車体を伸展し履帯を張るのではなく、最初から転輪の配置にあわせて履帯を装着するもの。操作の手間やコストを省ける。 この製作にはADVANCED BUILDINGを活用する。複数のブロックを選択していてかつツールの基点が選択されたブロックの総和点でない場合、移動・回転・反転は最後に選択されたブロックを基点とする。転輪に合わせ履帯を曲げる際は基点にしたいヒンジを選択、あるいは同時選択（シフトキー押しながら選択）の解除と再選択で選択順を若くする。 中空転輪+装甲履帯においては、水平に伸びた状態から30度→60度→60度→30度の角度で巻きつけると丁度COGに沿う。また上図のように直角につなげても辻褄が合うため、履帯の張り具合を調整することができる。 空力操舵 現実の航空機に最も近い方式。任意で作動する動翼の角度を変えることで揚力バランスを変化させ、機体の向きを変える。 風を受ける=移動していなければ揚力が生まれないため静止状態では動けないが、適切な設計ならトルク式より小さい負荷でより機敏に、あるいはあえてゆったりと機体を操作できる。空力の性質上得られる揚力は高速であるほど大きい。 良好な空力操舵の実現には空力に関する概念が重要になる。 直線移動を変換する方式 キーを入力している間のみ伸縮するPISTON（ピストン）でRTCを実現した構造。この記事の中では最も歴史のある空力操舵方式である。 ピストンの直線上の動きを、動翼とは別の回転軸を介して回転運動に変換し動翼の角度を変える。 構造的負荷が小さいため設計は比較的容易で、破損しても連鎖的な自壊を起こしにくい。ピストンを利用した直方体の構造は造形の邪魔にもなりにくい。 動翼の固定は弱く、空力のバランス次第では風に煽られ制御不能になる可能性がある。 またピストンが慣性によって若干動く。ニュートラル状態の動翼や安定板に角度をつける、エンジンの位置を上下するなどで対策しよう。 回転体を固定する方式 MOTOR WHEELやPOWERED MEDIUM COGの回転を制限してRTCを実現した方式。ホイールそのものやホイールによって回転するブロックをHINGE等で固定しつつある程度の歪みを許容する。 ピストン操舵と比較すると固定力があり構造上慣性で動翼が動くことはない点で優れている。だが空力バランスを無視できるほどではない。 またブロックの歪みを多分に利用しているため構造への負荷が大きい。BRACEのみでは耐久性や重量に不安が残るので、頑丈に組み込むには一工夫要る。 二重コグ式操舵 上のホイール式を発展させたもの。 ２つのPOWERED MEDIUM COGがある程度の間隔で設置され、頭接続で片方がもう片方に接続している。 ピストン式以上ステアリング式未満の固定力があり比較的頑丈だが、破損するとCOG同士が反発し最悪連鎖的な自壊を起こし得る、製作するために接続判定や設置順等隠しパラメータ的知識が必要と製作難度は高め。 大まかな作り方と解説 + ... ２つのCOGを間隔を開けて、単一ブロックあるいは十分な強度の複合体に設置する。基部は単一のほうが望ましく、間隔は0.5ブロックが最も安定しやすい。 COGの天板に何かを設置する場合、設置するブロックの接続判定がCOG同士を繋げている頭接続を無効にしないよう注意する。 次に当方式の理論を述べる。 まずブロックには一部を除き、接続されていれば実体が重なっていても反発しないという性質がある。 COGの天面には接続判定と披接続判定の両方があり、設置順の古い方が若い方に接続することで二重コグは成り立っている。 重なったCOGは設置順の古い方のCOGの回転軸で可動し、若い方の軸は可動の範囲を定めるストッパーの役割を持つ。 可動範囲はCOGの間隔でも調節できるが、他にもCOG根元が接続した基部ブロックの重さ、基部の根元と先端それぞれからの距離にも影響される。 Besiegeにおいてブロックの重さとは接続しているブロックの歪みにくさでもあり、この歪みを利用した当方式も基本的に基部が軽いほどより柔軟に可動する。 しかし要の頭接続は強固ながら単純な外力で壊れ得るため、広すぎる可動域や基部重量に対するCOGの出力過剰で許容量を超えた負荷を与えないよう気を付けなければいけない。 STEERING HINGE の自動戻り機能 2019年7月のアップデートでステアリングヒンジに追加されたRTC(自動で戻る)機能を用いる。前述の方式はこのRTC機能がない時代にRTC操作を実現するため考案されたものであるが、アップデートにより操舵機構の設計や造形が大幅に容易になった。 可動部がほとんど歪まないため多少無理のある空力デザインも許容でき、接続も頑丈で造形の邪魔もしない。 とても優秀なステアリングヒンジだが、シミュレーションを開始すると回転軸が接続しているブロックが他のブロックと全く干渉してなくともほんの少し曲がるという性質もある。 小型な機体や高速で飛行する場合は案外影響が大きく、修正には0.1度単位での角度調整が求められる。 また動翼の動きは比較的緩慢であるため、特に戦闘機においては他の2方式も根強い支持がある。 推進装置 蒸気推進 加熱したWATER CANNONから蒸気を噴出する反動で推進する。 WATER CANNON同士は物理的に干渉しないので同じ場所に複数重ねられ、SHRAPNEL CANNONから数値をコピー（→）すればより少数で大きな推進力を得られる。しかしひとつのブロックにWATER CANNONを設置しすぎると振動や爆散を起こすため、重い基部を選ぶ、分散させる、そもそも減らすなどして対策しよう。 プロペラ推進 AERODYNAMIC PROPELLER（長短よらず）は一定方向に移動することで擬似的な揚力を発生させるのだが、移動方向に対する角度（迎え角）を変えることで揚力も増減する。 PROPELLERと回転体を画像のように組み合わせると回転軸の延長線方向に揚力が発生する。この揚力の大きさはPROPELLERの移動速度とPROPELLERの回転方向に対する迎え角によって変化し、PROPELLERによって揚力ないし推進力を調整する場合この二つを適当な値にする。 推進装置だけでなく揚力発生装置としても利用でき、プロペラの空気抵抗をスタビライザーとして利用することも可能。 物体を回転させるので反トルクが発生する。この反トルクは現実のプロペラ航空機よりはるかに莫大で、現実にある主翼の揚力で打ち消す方法は駐機～低速時では打ち消すことが難しいためあまり取られない。滑らかに回転するブロックでトルクを逃がす、逆のトルクで打ち消す手法が主流である。 また回転しているため、機動時にエンジンの回転軸で対称な位置のプロペラの絶対速度すなわちプロペラが生み出す推進力に差が生じ、単発機は進行方向が逸れる傾向にある。固定翼や安定板を増やして影響を相対的に減らそう。 無抵抗錘式エンジン 物体が回転する反作用（反トルク）が発生するので、航空機にプロペラエンジンを何の対策も無しに搭載すると機体はエンジンと逆方向に回転してしまう。 この現象を防ぐ策の1つに、錘をつけた滑らかに回転する物体で反トルクを機体に伝えず抑える方法がある。上の画像ではLARGE WHEEL UNPOWEREDにBRACEを錘として設置し、動力であるMOTOR WHEELの回転の反作用を抑えている。BRACEは先述のリアクションホイールの解説にあるとおり錘として有用なのでよく用いられる。 反トルクが機体に伝わらないだけでなく、錘の効果で動力のロスも抑えられるためプロペラの回転速度を上げることが出来る。しかし錘が多すぎると機体重量の増加でむしろ速度性能が悪化することもあるのでちょうどいい塩梅を探ろう。 二重反転プロペラ 無抵抗錘式エンジンの一種で、錘の側にもプロペラを付けたもの。 回転方向の異なるプロペラを組み合わせることで空力のバランスを改善している。 ただの無抵抗錘式エンジンではエンジンのプロペラ自体が左右非対称な配置である為、空力のバランスも左右で異なる。 空力のバランスが機体の左右で異なると、例えば機首の上げ下げで機体がロールするといった事が起こる。 可変ピッチ式プロペラ (SMALL)AERODYNAMIC PROPELLERの角度によって加速力や最高速度が変化する特性をつかい、動作中に角度を変えられるようにすることで機体の操作性を向上させたもの。 自由な加減速ができるようになると着陸しやすい利点はあるものの、角度を変えた状態でブロックを設置できるようになってから利用者は減った。 動力源直付け方式の双発 自由回転する錘を使わず、回転方向の違う２つのエンジンでもって反トルクを相殺する方式のエンジン。 錘が不要で動力をそちらに取られない（ロスが少ない）というメリットがある。 しかし、エンジンの土台部分は２つのエンジンの反トルクを直接受け止める為、相応の強度が必要となる。 また、左右のエンジンの土台部分の歪みにより相殺しきれない反トルクがわずかに生じる。 歪み方が大きくなるほど相殺しきれない反トルクも大きくなるので、強力なエンジンになればなるほど、土台部分を歪みにくくする、空力パーツで反トルクとは逆方向の回転を与えるなどの対策が必要になる。 直列双発 回転方向の異なる２つのエンジンを同軸に配置し、無抵抗錘式エンジンの錘に当たる部分を連結したもの。 自由回転する連結部は２つのエンジンを区切るスペーサーの役目もしている。 無抵抗錘式でも動力源直付け方式の双発でも、抑えきれない（相殺しきれない）反トルクがわずかに生じるが、このエンジンはそれがほとんど無い。 回転方向の異なるエンジン同士で反トルクを相殺しつつ、連結したスペーサー部分が回転する事で相殺しきれない反トルクを吸収する２段構造となっている。 なお、画像の様に回転方向の異なるプロペラ同士が隣接せずに距離が離れていると、左右の空力バランスの違いが大きくなる為、注意が必要である。 プロペラエンジンの出力調整方法 プロペラエンジンはプロペラのピッチ角（回転方向に対してプロペラが立っているか寝ているか）を調整することで、加速力や最高速などの出力特性を変える事ができる。 しかし、ピッチ角以外にも出力特性を変化させる方法があるのでここに記載する。 前倒しプロペラ ピッチ角を変更したプロペラを進行方向に向けて前傾させたもの。 前傾させないものと比較して加速力は落ちるが最高速が伸びる。 後述のひねりプロペラが発見されたことで、現在はあまり使われなくなった。 ひねりプロペラ ピッチ角を変更していない（回転ツールで角度を変更していない）プロペラを前傾させた後、横にひねったもの。 前倒しプロペラよりも加速力と最高速に優れ、性能面では上位互換的なものになっている。 また、ピッチ角を変更しただけのものと比較すると、停止状態からの加速力では若干劣る。 ひねりプロペラの作り方 １、ピッチ角を変更していないプロペラを進行方向へ前傾させる（上画像中、赤の円の方向に回転させる）。 ２、プロペラが回転方向とは逆方向に向く様、横にひねる（上画像中、黄緑の円の方向に回転させる）。 横倒しプロペラ ピッチ角を変更したプロペラを回転方向とは逆方向に倒したもの。 ピッチ角を変更しただけのものと比較すると、加速力を増強する事ができる。 ただし、プロペラの回転速度が遅い場合、倒さない方が有利なこともあるため注意。 バキュームエンジン バキュームは吸引範囲内にある別クラスタのオブジェクトを吸引する性質がある。 よって、バキュームの吸引範囲内にクロスボウの矢を撃つことで、これを吸い続ける推進装置を作れる。 NIVES(ナイブス) ウォーターキャノンのパワーをNoBounds modを使ってマイナス値にすると、水を発射せず逆方向に推力が発生するようになる。この状態ではフライングブロックのような純粋な推力として利用できるようになる。 NegatIVE water cannonの略でナイブスと呼ばれる。 推力の強さは、おおよそ「x倍の加熱ウォーターキャノンの推力 = -10*x倍の非加熱ナイブスの推力」 フライングブロックと異なり不燃だが、こちらは加熱すると通常のウォーターキャノンと同じく推力が飛躍的に増加するため、火炎により暴走する可能性がある。 modを使わなければナイブスを作ることができないので、多くのマルチ対戦レギュレーションで使用できないことに注意が必要。 武装 対戦用武装に関してはこちらにも掲載している。 →対戦用武装図鑑 サス式反動吸収機構 BALLASTなどの重たいブロックにCANNON(またはSHRAPNEL CANNON)を接着し、BALLASTを複数のSUSPENSIONで支える事で発砲の反動を柔軟に基部に伝える。 画像では仰俯角も兼ねて基部にSTEERING HINGEを使用している。 サス式反動吸収機構2(通称：グラバー砲) Besiegeの仕様として、CANNON(またはSHRAPNEL CANNON)の接着はCANNONの弾の炸裂を受ける事により剥がれる。 そこで、大砲の接着を使わずにGRABBERでCANNONを支える事で炸裂に対する耐性を高めたのがこのグラバー砲である。 火炎ロケット(火炎ミサイル) FLAME THROWERをEXPLOSIVE ROCKETに接続して飛ばす機構。 画像では初速の向上も兼ねて基部にDECOUPLERを使用している。
https://w.atwiki.jp/shin-15m/pages/31.html
人体の構造 人体の構造の試験対策ページです。 シケプリなど随時載せていきます。リンク切れは陶山まで ☆15M 本試問題 ☆15M 本試解答（解剖・佐々木先生）※修正しました ☆15M 本試解答（組織・城倉先生） ☆15M 追試解答（解剖・佐々木先生） 再現解答も大体出来上がっています、編集が完了し次第上げます 人体の構造 過去問 今年度の参考になるのは13M、11M(10Mと合同)、08Mの過去問です 13M 本試問題 13M 本試解答 13M 追試(問題のみ) 11M 本試問題 11M 本試解答 08M 本試問題 08M 本試（解答抜き版） 08M 追試問題 08M 追試解答(09Mとなっていますが08M追試です) その他の年度の過去問 ☆人体の構造 ノート 人体の構造 第一週①（担当：佐々木、下山田） 人体の構造 第一週② 人体の構造 第二週①（担当：夏山、油井） 人体の構造 第二週② 人体の構造 第三週①（担当：林、杠） 人体の構造 第三週② 作成中 人体の構造 第四週①（担当：山田、依田） 人体の構造 第四週② 人体の構造 第五週 （担当：末廣、濱村） 人体の構造 第六週 （担当：伊藤、中村） 人体の構造 第七週 （担当：山田、杉田）(暫定版) 城倉の範囲・問題と参考資料 組織(消化器)の問題と解答
https://w.atwiki.jp/setechdiv/pages/14.html
データ構造の主な種類 配列 リスト ハッシュテーブル .
https://w.atwiki.jp/opengl/pages/110.html
今回、階層構造を作ってアニメーションするために、色々なソフトを試してみたのですが、http //www.vixar.jp/cyberdelia/ こちらの Cyberdelia というソフトがメタセコイアのファイルとも相性が良く最もシンプルで 操作性も良かったので Cyberdelia を使う事にします。 .X のアニメーションを作成できるソフトは他にもたくさんあるのですが、階層メッシュアニメーションだけを 出力するソフトはおそらく Cyberdelia だけではないでしょうか。詳しく調べていないので他にもあるかも しれませんが。 まず、メタセコイアで↓の図のような戦車を作成します。 戦車は 『本体』 と 『砲台』 と 『砲身』 から出来ていてそれらは のような親子関係を持っています。 それを Cyberdelia で読み込んで階層構造を設定し、アニメーションを作って .X形式で保存します。 まず、砲台をドラッグして本体にドロップします。そして砲身をドラッグして砲台にドロップします。 すると階層構造が出来上がりました。 最後のフレームを30にして、現在のフレームを0にします。 本体を選択するとアニメーションキーを作成できるようになりました。 鍵のマークをクリックして 全てのモデルのキーフレームを追加 します。 最初のキーフレームが作成されたので次のキーフレームを作成します。 下にあるスライダーを横に移動させて現在のフレームを10にします。 モデル移動コマンドを選択し、3Dビューの本体を右ドラッグで青い線（Z軸)の方に 少し移動させます。 すると、本体の子オブジェクトである砲台と砲台の子オブジェクトの砲身が一緒に 追随してきます。 子オブジェクトは親オブジェクトに設定された移動や回転、拡大縮小をすべて、 そのまま受け継ぎます。 これが階層構造の特徴です。 そして鍵のマークをクリックして、また 全てのモデルのキーフレームを追加 します。 今度は、下のスライダーを動かして現在のフレームを15にします。 モデル回転コマンドを選択し、砲台を選択します。 3Dビューの砲台を左ドラッグで回転させます。 砲台に行った回転は子オブジェクトの砲身が受け継いでいますが、 親オブジェクトの本体は一切、影響がありません。 そして鍵のマークをクリックして、また 全てのモデルのキーフレームを追加 します。 また、下のスライダーで現在のフレームを20にします。 モデル回転コマンドで砲身を選択し、3Dビューの砲身を左ドラッグで回転させます。 砲身に行った回転は砲身だけが動き、本体と砲台はそのままです。 そして鍵のマークをクリックして、また 全てのモデルのキーフレームを追加 します。 次が最後のキーフレームです。 下のスライダーで現在のフレームを30にします。 モデル回転コマンドで本体を選択し、3Dビューの本体を左ドラッグで回転させ、 後ろを向かせます。 今度は砲身を選択し、少し下に回転させます。 そして鍵のマークをクリックして、 全てのモデルのキーフレームを追加 します。 これでアニメーションが完成しました。 試しに再生ボタンをクリックしてアニメーションを見てみましょう。 正常にアニメーションが再生されるのを確認したら停止ボタンで停止し、 ファイル 名前を付けて保存 で、Cyberdeliaファイルで保存しましょう。 .X形式のアニメーションを読み込む事はできないのでCyberdeliaファイルで 保存しておかないと後でアニメーションが読み込めなくなります。 Cyberdeliaファイルの保存が終わったら、本体の名前をobj1に、砲台をobj2に、 砲身をobj3にします。 日本語名だと DirectX SDK のビューワーで表示できないようです。 そしてまた、ファイル 名前を付けて保存 で今度は DirectXファイルの .X形式で保存します。 すると次のようなダイアログが出てくるので画像と同じ設定でOKボタンを押します。 試しに DirectX SDK のビューワーでアニメーションを確認します。 これで .Xの階層メッシュアニメーションのファイルが作成できたので次回、中身を 解析してみましょう。
https://w.atwiki.jp/gamexprogram/pages/36.html
C言語 構造体1 構造体は、一見難しそうに見えますが、実はそんなことはありません。 ゲームでは、各キャラの座標とかを保持しておくことができます。 使用方法1 宣言方法 struct タグ名 { メンバ変数1, メンバ変数2, }; 実体宣言 struct タグ名 構造体変数; 使用方法2 struct タグ名 { メンバ変数1, メンバ変数2, }構造体変数1, 構造体変数2, …; 初期化方法1 構造体変数.メンバ変数1 = 初期値; 構造体変数.メンバ変数2 = 初期値; … 初期化方法2 struct タグ名 構造体変数 = { メンバ変数1に対応する初期値, メンバ変数2に対応する初期値, … }; メンバ変数とは メンバ変数とは、構造体内で、宣言した変数の事をいいます。 ここで、注意したいのが、メンバ変数は変数宣言と同時に、 初期化ができないということです。 例えば、aという変数を宣言する例を見てみましょう。 普通は、 int a = 0; のように宣言と同時に初期化できますが、メンバ変数では、 struct タグ名 { int a = 0;//エラー }; のようにできないということです。 なので、初期化するには、外部で初期化する必要があります。 例文 //================================================ //include //================================================ #include stdio.h //================================================ //define //================================================ #define PLAYER_ATTACK 5 #define PLAYER_DEFENCE 4 #define PLAYER_HP 4 //================================================ //struct //================================================ struct CharaData { int attack;//攻撃力 int defence;//防御力 int Hp;//体力 char *name;//名前 }; //================================================ //メイン関数 //================================================ int main(void) { struct CharaData player; //struct CharaData player = //{ //PLAYER_ATTACK, //PLAYER_DEFENCE, //PLAYER_HP, //"勇者" //}; //という風に初期化することも出来ます。 /*初期化*/ player.attack = PLAYER_ATTACK; player.defence = PLAYER_DEFENCE; player.Hp = PLAYER_HP; player.name = "勇者"; printf("%sのステータス", player.name); printf("Hp %d", player.Hp); printf("attack %d", player.attack); printf("defence %d", player.defence); return 0; } 実行結果 解説 struct CharaData { int attack;//攻撃力 int defence;//防御力 int Hp;//体力 char *name;//名前 }; CharaDataという構造体の宣言をしています。 struct CharaData player; playerという構造体変数を実体化しています。 player.attack = PLAYER_ATTACK; 構造体内の変数を使う場合は、最初に宣言した構造体変数を書き、 .(ドット)で区切って、メンバ変数にアクセスしています。 この場合、CharaData構造体内のattack変数を使いますよ、 という意味になります。 C言語に戻る
https://w.atwiki.jp/manage_2ch/pages/18.html
組織論 組織構造
https://w.atwiki.jp/javadsge/pages/879.html
賃金構造基本統計調査 (1)表 2017年 過去の研究 (2)プログラム データ処理 (3)グラフ エクセル (4)出所 厚生労働省 (5)コード (6)作業記録 1月15日 プログラム追加 6月11日 プログラム追加 imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 -
https://w.atwiki.jp/rubyiw/pages/34.html
5.制御構造 プログラムというものは、最初から最後まで、順番にコードが実行されるだけでは、さっぱり何の役にも立たないのである。とまあ、そこまで言い切ってしまうとあれだが、とてもではないが複雑な処理をすることはできない。ある条件に従って実行する行を変更したり、必要回数同じ処理を繰り返すためにくるくる回ったり、どこか別の場所にあるルーチンの内容を実行したりすることが必要なのだ。 エドガー・ダイクストラというオランダの情報工学者がいた。この学者先生は、ことプログラミングを勉強した人々の間では、非常に有名なのだ。『構造化プログラミング』という概念の提唱者なのである。 『構造化プログラミング』とは、年々大規模複雑化するシステム開発を円滑に進める方法論として、1967年に提唱されたものなのである。既に40年以上の歳月が流れているのだが、現在ただ今でも現役バリバリの理論であり、従来よりのプログラミングの概念を打ち破る革命的な手法が登場しない限り、まあこれ以外にないでしょうというものなのである。 『構造化プログラミング』の概念を実装できるプログラミング言語群は、『構造化プログラミング言語』と呼ばれており、Rubyなどの『オブジェクト指向プログラミング言語』よりほと世代前とされているわけだが、実際のところ、オブジェクト指向プログラミング言語で登場する『クラス』や『オブジェクト』は、その中に構造化されたプログラムロジックを内包、隠蔽しているだけと考えることができる。極論を言うと。 オブジェクト指向プログラミング言語を使用して開発する末端のプログラマこそ、オブジェクト間のメッセージのやり取りだけでアプリケーションを構築できるかもしれないが、クラス設計／実装者は、ダイクストラの提唱した『構造化プログラミング』の概念でもって中身を詰めているのである。 『構造化プログラミング』とは、プログラムをお互いに依存することなく、かつ不変契約（同じ値を渡せば常に同じ結果となることが約束されている）ちいさな部品（モジュール）を組み合わせて構築するという考え方である。さらに、そのモジュール内部は、構造化定理にのっとって記述されていなければならないとしている。 構造化定理とは、『全てのプログラムは、一つの入口と出口を持つ形（適正プログラム）に等価変形可能であり、適正プログラムでは任意のアルゴリズムを次の三つの基本的な制御構造で記述できる。その基本的な制御構造とは、順次(Seqence)、選択(Selection)、反復(Iteration)である』ということである。 Rubyにも、この三つの制御構造を実現するための命令（コマンド）が用意されているのである。 といっても『順次』構造は、命令が記述された順番に整然と実行されるということなので、とりたてて制御命令は存在しないのだが。 強いて言えば、『Rubyでは、特に明示的に実行順を入れ替えたり分岐させたりする制御命令を記述しなければ、なんと、書いた順番で処理しますよ。すごいでしょ』という言語仕様であろうか。まあ、そんなこと当たり前なのだが。 (1).選択(Selection) 『分岐』と表現している場合もある。ある条件があって、それが成立する場合（真の場合）と、成立しない場合（偽の場合）で、異なる処理を行うのが『選択』である。 Rubyには、選択構造を実現する命令として、次のものが準備されている。 if制御命令 if修飾子 unless制御命令 unless修飾子 case制御命令 (i)if制御命令 if制御命令は、プログラミング言語と名がつけば普通あるだろというほどメジャーなものだ。日本語で表現すると、『もし(if)、なになにがどうならば、これをせよ。でなければ(else)、あれをせよ。おしまい』となる。 だが、プログラミング言語によって書式が微妙に違い、同時期に複数の言語でプログラムを作っていたりすると、わけがわからなくなるときもある。Rubyでの書式は次の通りである。 if 条件式1 then 条件式が真の場合の処理(ステートメント) elsif 条件式2 then 条件式2が真の場合の処理(ステートメント) else 条件式2が偽の場合の処理(ステートメント) end 勿論、偽の場合を省略したいこともあるから、else以降は省略することができる。ただし、『おしまい』にあたるendは省略することができない。構文解析エラーとなってしまう。 厄介なことに、他のプログラミング言語には、この『おしまい』の合図を省略できるものが多いから、Ruby以外の言語をお使いの方は、ついうっかり忘れてしまうことがあるので気をつけよう。 なぜRubyでは endを省略できないのか。それは、『処理ブロックを明確にする』という目的というか、Rubyの設計哲学がある。ここで、プログラミング言語界の古株にして最強の武闘派であるC言語に登場してもらおう。 if ( a 10 ) b=1; else c=1; 仮に、上記のようなif文があったとしよう。このプログラムにある日仕様変更が入り、a 10の条件式が成立しなかった場合、変数dにも1を設定して欲しいということになったのだ。 神様であるお客様の意向には逆らえないので、プログラマ君はしぶしぶプログラムを書き換えたのである。 if ( a 10 ) b=1; else c=1; d=1; C言語をご存知の方であれば、このコードのアホさ加減はお分かりだと思う。 このコードは全くプログラマ君の意図した動きはせず、a 10の条件式が成立しようがしまいが、d=1の代入式が実行されてしまうのである。なぜならd=1の式は、if文の処理ブロック外にあるからなのである。 C言語の場合、if文の中で実行されるステートメントが1個だけの場合、処理ブロック指定を省略できるのだ。従って2個以上のステートメントを処理したければ、次のように、明示的に{}(中括弧)でブロックを指定してやらなければならない。 if ( a 10 ) b=1; else { c=1; d=1; } C言語では、改行コードに意味はないから、次のように記述してもなんら変わらない。 if ( a 10 ) b=1; else { c=1; d=1; } 次に、異形の怪物言語 VisualBasicを見てみよう。これがまた独特のルールに則っている。さすがは異形の怪物言語だけのことはあるのだ。 if ( a 10 ) b=1; else c=1; d=1; 上記のコードをVisualBasicで書き換えると次のようになる。 If a 10 Then b = 1 Else c = 1 d = 1 実はこのコード、なんとプログラマ君の意図した通りに動いてくれるのである。a 10の条件式が成立しなかった場合にのみ、ちゃんとd=1の代入が実行されるのだ。 一体どういうルールに則って動いているんだVisualBasicよ。と言いたくなるではないか。 VisualBasicの場合『同一行に記述されていれば、処理ブロックとしてみなしてあげます』というルールがあるのだ。VisualBasicの場合、改行コードというのが非常に重要な役割を持っているのである。ためしに、C言語のように行をわけて記述しようとすると、いきなり構文エラーになる。 If a 10 Then b = 1 Else c = 1 d = 1 エラー If の終わりには、対応する End If を 指定しなければなりません VisualBasicでは、if制御文が複数行に渡るときだけ、『おしまい』の合図、End Ifを指定しなければならないというわけだ。 このように、他の言語においてif制御構文は、よく言えばフレキシブル、悪く言えばよくわからない状態となっているので、Rubyにおいては、『たとえステートメントが1個であろうが、ちゃんとendを記述して、処理ブロックを明確にしようじゃないか』というルールを定めているのである。 なお、これも、他の言語の経験がある方に注意していただきたいのが、elseの場合に、また条件式を指定したい場合だ。 Rubyの場合、elsifという独特な記述方法になる。 elseif でも else if でもないから注意しよう。このelsifという書式は、スクリプト言語の偉大なる先達、Perlと同じだということを参考までに付記しておく。 さて、Rubyのif制御文には、他のプログラミング言語では見かけない特色がある。それは、『if制御文自身が値を保持する』ということなのである。 代入式が値を持つプログラミング言語はあちらこちらで散見されるものの、if制御文自体が値を保持するプログラム言語は少ないのだ。 a = if b 10 then true else false end 『あれ？なあんだ。三項演算子と同じじゃないですか』 まあそうなのだが。 (ii)if修飾子 if制御命令は、プログラミング言語と名がつけば、普通あって当たり前なのだが、このif修飾子については、存在する言語は少ない。先達のPerlがこのif修飾子を持っているので、Perlから強く影響を受けているRubyにもあると言ってもいいかもしれない。 if修飾子は、次のように記述する。 puts "aは10より小さい" if a 10 コードを眺めていれば、自然と納得がいくかと思うが、要するに、”aは10より小さい”という文字列を出力したいわけだが、それを実行するにあたって、コードの後ろに条件式を指定することができるのである。この場合、if a 10 がその条件になる。irbで動作を確認してみよう。 この判定は、普通にif制御命令を使用して記述することもできるのだが、なんとなく回りくどい感じがする。if修飾子は面倒くさがりのプログラマへのRubyからのささやかなプレゼントと言えよう。 (iii)unless制御命令 unlessは、ifの逆である。ifは、条件文が真となったときにステートメントが実行されるが、unlessは偽となったときに実行される。 プログラミングの経験がある皆さんには、なにやら複雑な複合条件でif文を構築して、なんとなく動いたと思ったら、『悪りぃ。あそこの条件だけどさ。逆にしてくんない』といわれ、もうわけがわからん！とやけを起こして、次のような記述にしてしまったことはないだろうか。 (オリジナル） if ( a =4 || b 1 ) ( c 5 c 10 ) then 処理 end (修正後) if ( a =4 || b 1 ) ( c 5 c 10 ) then #何もしない else 処理 end これはちょっと不細工な気がする。明らかに考えることを放棄しているのがバレバレだ。そういうときにunlessを使用すると、少しは体裁がよくなる。 unless ( a =4 || b 1 ) ( c 5 c 10 ) then 処理 end まあ、条件式を組み立てなおさないという意味では同じなのだが。 unless制御命令にもelseを書くことができる。この場合、else以下は条件式が真の時に実行されることになる。ただし残念ながら、elsifは指定できないし、elunlessなどという記法はない。『もしかしてあるかもね？』と期待された方には申し訳ないが。 (iv)unless修飾子 unless修飾子は、if修飾子と逆の動きをする。 puts "aは10以上である" unless a 10 unlessが存在することにより、条件式の組み立てが非常に楽になるのだが、残念ながらC、C++言語、C#といった中大規模システム構築用のコンパイラ系言語には準備されていない。それらの言語でややこしい条件式を組み立てているときに、ふと『unlessがあればなあ』と思うことがよくあるのだが。 (v).case制御命令 if制御文は、ある条件式があって、それが真か偽かの二者択一であったが、世の中そうなにごとも、真偽で判定できるものではなく、三通り以上の選択肢があることが多いのだ。その場合に重宝するのがこのcase制御命令なのである。 case month when 2 puts "二月は特別です" when 4,6,9,11 puts "西向くさむらい小の月です" else puts "大の月です" end 上記は、変数monthの値が、2の場合、4か6か9か11の場合、そして、それ以外の場合で出力するメッセージを切り替えている例だ。 この場合、たまたま評価されるものが変数となっているが、当然演算式でも、代入式でも、比較演算式でも構わない。 when節にある値の指定は、演算子のところででてきた、範囲演算子が指定できる。 case ji when 6..11 puts "おはようございます" when 12..18 puts "こんにちは" else puts "こんばんは" end それぞれ、6から11、12から18の範囲を持つということになるわけだ。 さらに、case に続く式を省略することもできる。この場合、 when節が順に評価されていき、最初に真となった式が評価される。 case when (6..11) === ji puts "おはようございます" when (12..18) === ji puts "こんにちは" else puts "こんばんは" end 以上で『選択』の解説は終了だ。 ん？『さらっと流さないでください。===(イコールみっつ）ってなんですか？そんな演算子、解説してないじゃないですか』 実はこの===演算子、普遍的な演算子ではない。Rangeオブジェクトだけに定義されている特別な演算子なのだ。 これを『クラスにおける演算子の多重定義（オーバーローディング）』と呼ぶのだが、詳細はクラスの解説をするときに併せて説明しよう。===は、右辺の値が、左辺のRangeオブジェクトが持つ範囲にあれば真、なければ偽になるという便利な演算子というわけなのであった。 (2).反復(Iteration) 反復を実現する制御命令には、次のものがある。 while 制御命令 while 修飾子 until 制御命令 until 修飾子 for 制御命令 (i)while制御命令 while制御命令の書式は以下の通りだ。 while 式 [do] ... end whileは、条件式が真である間、endまでに記述されたステートメントを繰り返し実行する。 whileの条件式は、可能な限りいつか偽となることが保証されるものが望ましい。さもないと、忌むべき永久ループという状態に陥ってしまう。 例として、Rubyリファレンスマニュアルに記載されているサンプルコードを見てみよう。 001 | ary = [0,2,4,8,16,32,64,128,256,512,1024] 002 | i = 0 003 | while i ary.length 004 | print ary[i] 005 | i += 1 006 | end これは、配列aryの要素を順番に出力していくものだ。条件式は i ary.lengh だから、変数iが、配列aryの要素数より小さい間は真になる。そしてこの条件式が偽になるのはいつかというと、5行目のi += 1で、変数iの値がiづつカウントアップされている。ここでいつかはiの値が配列aryの要素数と同じになるときがくるのだ。そのとき、めでたくこの条件式が偽となるのである。 なぜiが配列aryの要素数とイコールになるまでではなく、-1までかというと、変数iがそのまま配列aryの要素番号になっているからだ。 配列の要素番号は 0から要素数-1までであるから。これは、あまたのプログラミング言語仕様においては、最も基礎的なことだ。 さて、このようなコード記述したときに、うっかり忘れてしまいがちなのが、5行目のカウントアップ処理なのである。これがないと、このwhile文は、永久にループしてしまうのだ。であるから、配列の要素数分処理をしたい場合は、イテレータ、すなわち配列オブジェクトが持つeachメソッドを使用するほうが無難だし、簡単だ。 001 | ary = [0,2,4,8,16,32,64,128,256,512,1024] 002 | ary.each { |i| 003 | print i 004 | } (ii)while修飾子 while にもifやunlessと同様に、修飾子としての書式が存在する。ステートメントの実行にあたって条件があるので、修飾子が存在するのが普通と考えるべきだ。 前出のコードを修飾子を使って書き換えると次のようになる。 001 | ary = [0,2,4,8,16,32,64,128,256,512,1024] 002 | i = 0 003 | begin 004 | print ary[i] 005 | i += 1 006 | end while i ary.length なんだ、余計に記述量が増えているではないか。このコードの場合、whileで実行されるステートメントが複数あるから、 begin～endで処理ブロックを作る必要がある。whileで実行するステートメントがひとつである場合に限り、whileに対するendを省略できるから、若干記述量の節約になるのであった。 (iii)until制御命令 while制御命令は、条件式が真である間、処理を実行するものであったが、until制御命令はその逆、即ち条件が真になる間、言い換えれば、条件が偽である間処理を実行するものである。 until 式 [do] ... end 前出のwhileのコードをuntilで書き換えると次のようになる。 001 | ary = [0,2,4,8,16,32,64,128,256,512,1024] 002 | i = 0 003 | until i =ary.length 004 | print ary[i] 005 | i += 1 006 | end (iv)until修飾子 whileにも修飾子としての記述法があるので、当然このuntilにも修飾子としての記述法が存在する。条件が『～の間』と『～になる迄』という相違だけで、この二つの制御構造は一卵性双生児といえるのである。 001 | ary = [0,2,4,8,16,32,64,128,256,512,1024] 002 | i = 0 003 | begin 004 | print ary[i] 005 | i += 1 006 | end until i =ary.length while制御構造とuntil制御構造、そしてwhile修飾子とuntil修飾子。先ほど評したように双生児ではなく、こりゃはっきり言って四つ子のようなこれらの命令群をどのような局面で使い分けたらよいのであろうか。 それは、最終的に個人の好みに帰結するのである。 (v)for制御命令 while制御命令、until制御命令とも、実は他のプログラミング言語にも普通に存在し、かつ同様な書式で、同様な動きをするので、ほっと一安心されたかと思う。 その流れから判断すれば、 for制御命令だって他のと同じようなものだろうと甘く見るとノツボにはまるので注意が必要だ。 Rubyのfor制御文は、他の言語とは一味違うのである。 もし皆さんが他のプログラミング言語をご存知であればあれば、 for制御文というと、次のようなものを想起されると思う。 【C、C++、C#、Java】 int i; for ( i=0; i 10; i++ ) { ... } 【Visual Basic】 Dim i as Integer For i=0 To 9 ... next 【pascal】 var i Integer; begin for i =0 to 9 do begin ... end; end; Rubyと関係ないことをだらだら書いて、行を無駄遣いしやがってこの野郎とのご批判もあろうが、要するに、『凡百（？）のプログラミング言語では軒並み、 for文とは、ある変数（カウンタ）があって、それがある決まった値になるまで、増加（または減少）している間、ステートメントが実行されるのだぞ』ということを強調したいのである。 で、最終的に、『ところがどっこいRubyの For文はちょっと違うぞ』ということが言いたいのだ。 Rubyにおいて、for制御命令の書式は次の通りだ。 for 変数 ... in 式 [do] ... end 【in 式】の式の部分には、以前解説させていただいた『範囲オブジェクト』、または『配列オブジェクト』が指定されるのだ。結果的に『範囲オブジェクト』または、『配列オブジェクト』であればよいわけだから、関数の戻り値でも、クラスメソッドの戻り値でも、値を保持するステートメントでもよいのである。 他のプログラミング言語で例示したコードをRubyの for制御命令で書き換えると、次のようになる。 for i in 0..9 ... end あれ。これも前回の最後に出てきた配列または範囲オブジェクトのeachメソッドで処理してもいいのでは？と思われた方も多数いらっしゃると思う。なにを隠そうそれは正解だ。 実際に、eachメソッドで処理してもなんら問題ないのである。 (0..9).each { |i| ... } ところが、 for制御命令とeachメソッドの呼び出しには、決定的な違いがひとつだけ存在するのだ。Rubyのリファレンスマニュアルには、次のように記してある。 『 do ... endまたは{ }によるブロックは新しいローカル変数の有効範囲を導入するのに対し、 for文はローカル変数のスコープに影響を及ぼさない点が異なるからです』 一読して何のことやらよくわからないかもしれないので、例示して説明しよう。次のコードを見ていただきたい。あまり素敵な例とは言えないのだが。 001 | j=10 002 | for i in 1..10 003 | if i==1 then k=10 end 004 | puts (i+j).to_s 005 | k+= (i+j) 006 | end 007 | puts k.to_s forループの中で、kという変数が突然誕生しているのがわかると思う(3行目)。その変数kをforループの外側で参照しているのである。 このコードは、無事正常終了する。では同じことをeachメソッドでやってみる。 001 | j=10 002 | (1..10).each { |i| 003 | if i==1 then k=10 end 004 | puts (i+j).to_s 005 | k+= (i+j) 006 | } 007 | puts k.to_s 残念なことに、これは正常に実行できず、エラーとなってしまうのだ。 【NameError undefined local variable or method `k for main Object】 7行目の変数kなどというものは知らんと怒っているのである。 なぜそのようにRubyが怒るのかというと、変数 kは、each文の{}(中括弧)で閉ざされた内部だけで有効なローカル変数であり、eachの外部からは見えないのだ。要するにスコープが違うのである。 しかし、For文の中であれば、外部と同じスコープであるというわけなのだ。 さて、 for制御命令でも、配列のeachメソッドでもループ処理ができて嬉しいなと喜んでいたところ、なんとRubyには、まだ別の方法が存在する。 サンプルコードの場合、くるくる回る回数は10回であるということがあらかじめわかっている。であれば、次のような記述も可能なのである。 001 | j=10 002 | k=0 003 | 10.times{ |i| 004 | puts (i+1+j).to_s 005 | k += (i+1+j) 006 | } 007 | puts k.to_s 数値オブジェクトの timesメソッドを使用する方法だ。ループ処理ひとつをとってもこれだけたくさんの書法が存在するのである。一体どれを使えばいいのだと悩ましいところであるが、結論から言うと先ほど申し上げたように、最後は実装者個々の好みということになる。 さて、これで反復を実現する制御命令について解説し終わったわけだが、補足として、反復用制御命令と関連して動作する制御命令を解説しておく。 (vi)break break は、反復処理制御を開始するときに定められた終了条件を満たす以前に、反復処理を抜け出したいときに使用する。反復処理とは、以下のものを指すということは、既にみなさんお分かりだと思う。 while until for イテレータ コード例を挙げておこう。 001 | ary = [0,2,4,8,16,32,64,128,256,512,1024] 002 | i = 0 003 | while i ary.length 004 | unless DoSomeThing(ary[i]) then 005 | break 006 | end 007 | print ary[i] 008 | i += 1 009 | end さてここで、もし貴方がC系のプログラミング言語経験者である場合、ひとつ疑問に思ってほしいことがあるのだ。 それは『case制御命令において、breakは必要ないのか？』ということだ。 C言語において、Rubyのcase制御命令に該当するswitch制御命令の構文は次の通りだ。 001 | switch ( month ) 002 | { 003 | case 2 004 | printf "二月は特別です\n"; 005 | break; 006 | case 4 007 | case 6 008 | case 9 009 | case 11 010 | printf "西向くさむらい小の月です\n"; 011 | break; 012 | default 013 | printf "大の月です\n"; 014 | } このように、 C言語系のswitch制御構文においては、各case節に記述されるステートメントの最後は、breakであることが望ましい。なぜなら、breakを指定しておかないと、下までずるずるっと実行されてしまうからである。 上記のコードで、5行目のbreakを忘れると、変数monthの値が2であった場合、 6行目から10行目までが一気に実行されてしまい、11行目の breakでやっと止まるということになってしまうのである。 変数monthの値が4でも6でも9でも11でもないに関わらずだ。 『なぜそんな変な仕様になっているのですか？』 知らん。 幸いなことにRubyでは、このcaseのずるずる流れ込みが存在しない。 変数の値が2であれば、2の場合に実行するよう記述したステートメントしか実行されないことが保証されている。従ってcase制御構文に breakは必要ないというわけである。 (vii)next nextは、 for制御構文内、または、イテレータの処理内において、ある条件であれば処理をスキップしたいときに使用する。 001 | #for制御構文の場合 002 | for i in 1..10 003 | next if i==5 004 | puts i.to_s 005 | end 006 | 007 | #イテレータの場合 008 | (1..10).each { |i| 009 | next if i==5 010 | puts i.to_s 011 | } 上記二つのコードは、どちらもiの値が5の場合、処理をスキップする。念のため、irbで動作を確認しておこう。5の表示がすっ飛ばされていることを確認していただきたい。 (viii)redo redoも、 for制御構文内、または、イテレータの処理内において使用する。ある条件が成立すれば、ループ条件のチェックを行わず、現在の処理を繰り返すものである。 001 | #for制御構文の場合 002 | for i in 1..10 003 | puts i.to_s 004 | redo if i==5 005 | end 006 | 007 | #イテレータの場合 008 | j=10 009 | k=0 010 | (1..10).each { |i| 011 | puts i.to_s 012 | redo if i==5 013 | } 上記二つのコードは、どちらもiの値が5の場合、処理を繰り返す。ご想像の通り、これらコードは、1から5の数字を画面表示した後、そのままループして永遠に5を表示し続けるのだ。実際には、こんなコード書いてはいけないし、実行してもいけない。 (ix)retry retryも、for制御構文内、または、イテレータの処理内において使用するものだ。 retryは、ある条件が成立すれば、なんとご苦労なことに、ループ処理の最初からもう一度やり直のである。。 001 | #for制御構文の場合 002 | for i in 1..10 003 | puts i.to_s 004 | retry if i==5 005 | end 006 | 007 | #イテレータの場合 008 | j=10 009 | k=0 010 | (1..10).each { |i| 011 | puts i.to_s 012 | retry if i==5 013 | } 上記二つのコードは、どちらもiの値が5の場合、ループの最初に状態を戻す。ご想像の通り、これらのコードは、1から5までの表示を永遠に繰り返すのである。くどいようだが、実際にはこんなコード書いちゃいけないからね。