約 1,243,749 件
https://w.atwiki.jp/shikaden/pages/45.html
外見 名前 HP EXP 所持アイテム 当たり判定 攻撃方法 備考 BOSSマスター・ウペペ 接触特殊攻撃 エアカッタートゲダーク追跡体当たり BOSSネイチャー4二世 特殊攻撃 炎ダッシュ 本体当たり判定無し 特殊攻撃 パンチアースウェイブ 本体当たり判定無し 特殊攻撃 アイス（硬直効果） 本体当たり判定無し 特殊攻撃 つむじ風 本体当たり判定無し マスター・ウペペ こちらはウペペ族とボマー以外のキャラを使えない。 見た目強そうだが、マリが怖いとへたれるところからも察せる通り、下記ネイチャー4二世に比べて非常に弱い。 通常はウペペ族で攻撃し、鋼化して体当たりしてくるようになったら、ボマーで爆弾をばら撒くのが定石。 だが、別に敵が通常時でも爆弾は普通に当てることが出来るので、終始一貫してボマーで攻めても化。 ネイチャー4二世 炎水土風それぞれの属性のボスが一挙に襲い掛かってくる。 各属性はそれと対になる属性の攻撃以外受け付けない。 攻撃方法は土以外1パターン。土も2パターンだけなので、それぞれは単体なら怖くない。 が、4人揃っているとかなり厄介。 まずおすすめは炎を速攻で倒すこと。 ヘルマリが使えるならヘルマリの炎の紋章ですぐに撃破できるだろう。 目カニのアワフライトでも十分倒せる。右側に陣取って適度に攻撃を避けつつアワフライトする。 左側は土が陣取っているので危険。 次は風を倒すのがおすすめ。 右に陣取ってミミズjrの誘導弾を放つのがいいだろう。 水と土だけになったらあとは好みで。 水はマリの炎の紋章かフェニックスjrの攻撃で、土はウィウィで竜巻。 なお、最後の一匹になると発狂するので注意。 水もちゃんとダメージを与えてくるようになる。
https://w.atwiki.jp/stgbuilder/pages/146.html
＜背景編集＞ ステージに使用する背景を登録。 イメージ登録：各バンクに使用するイメージを登録。（登録したイメージをチップ単位に分割し、マップ上に配置したものが最終的な背景） バンク：1枚の背景に対して、最大8枚のイメージをバンクを切り替えて使用可能。 カラーキー：透明色へ変換するカラーをARGB32ビットで指定。 カラーキーで指定した透過色は、保存して終了後に背景編集の画面に反映。 左側のイメージ画面では透過色は純黒色に、右側の配置画面では透過色は下地色となる。 倍率タブ：バンクの内容表示の縮尺を等倍，1/2，1/4に変更。 チップサイズ（ピクセル）：1チップのサイズ（横幅×縦幅）をピクセル単位で指定。このチップ単位でイメージから切り出して背景マップを構成。 マップサイズ（チップ数）：マップ全体のサイズ（横幅×縦幅）をチップ単位で指定。 更新：チップサイズやマップサイズの変更を反映。 マップ編集 ウインドウ内の左側に表示されているのが登録したイメージで、クリック＋ドラッグでマップへ配置するためのチップを選択。（選択されたチップの周りに赤い枠が表示） 右側のマップエリアの上方にあるツールボタンが「セット」になっていると、マップ内をクリック＋ドラッグすると、選択したチップがマップへ配置。 セット：左側のイメージエリアで選択したチップを右側のマップエリアへ配置。 （マップエリア内のカーソルの色が赤色に変化） クリア：右側のマップエリアを未配置状態へクリア。 （マップエリア内のカーソルの色が緑色に変化） コピー：右側のマップエリアに配置されたチップを別の箇所へ複製。コピー元の範囲をクリック＋ドラッグで指定した後にコピー先をクリック。（右クリックでキャンセル可能） （マップエリア内のカーソルの色が白色に変化） 縮尺：マップエリアの表示を等倍，1/2，1/4に変更。 同期スクロール：背景を複数枚使用して1つの背景を構成する場合に、複数のウインドウに表示された背景の同一の場所を表示。（カーソル位置も同じ箇所に表示） 編集したい背景ウインドウを2つ以上開いた状態で、ツールバーの同期スクロールボタンをロック。 1つのウインドウでロックすれば、開いているウインドウ全てのボタンがロックされ、以後スクロール、及びカーソル位置は全てのウインドウで同じ位置となる。 ショートカットキー：カーソルキーでマップ領域を上下左右にスクロール可能。 背景との当たり判定：バンク0-7の右端にあるHITをクリックすると背景へ当たり判定の属性を付けるモードとなり、左側のイメージに当たり判定用のリストが表示。 設定したい当たり判定を選択後、通常のモードと同じように右側のマップへと配置。 （背景パーツが無い部分に当たり判定を配置することはできない。） 背景とキャラクタとの当たり判定を有効にするには、ステージ編集で「背景の当たり判定を有効」にし、キャラクタ編集で「背景と判定あり」に設定。 →背景とキャラクタの当たり判定，背景とキャラクタの当たり判定2 プロジェクトマネージャ＞＞ スプライト編集，効果音編集，BGM編集，プレイヤー編集，ステージ編集，エフェクト編集 弾幕編集，スクリプト編集，キャラクタ編集，編隊編集，フォント編集，レイアウト編集，パス編集，3Dモデル編集
https://w.atwiki.jp/stgbuilder/pages/282.html
＜表示優先設定 タブ＞ ステージで表示する背景の優先順位とスクロール速度などのパラメータを設定。 表示優先：各背景の表示優先順位を設定。（上層ほど優先が高い） 上空-空中物高-空中物中-空中物低-中空-地上物高-地上物中-地上物低-低空 →Z値オフセット 追加：新規に背景を追加。 削除：選択した背景を削除。 ↑：選択した上層に移動。 ↓：選択した下層に移動。 ID：スクリプトから指定する際に使用する識別番号を設定。 メイン背景：onにすると、スクロールの基準となる唯一の背景を設定。（背景に同期するキャラクタの同期の基準） スクロール開始位置（X，Y）：ステージ開始時の背景を表示する位置を設定。 スクロール速度（X，Y）：背景がスクロールする速度を設定。 →速度（背景） 描画方式：背景を描画する方式を指定。 不透明：一般的な描画方式で最も高速に描画。 半透明：テクスチャにα値が設定されてるものや、頂点カラーのα値を変更する場合。 加算：すでに描画されてる物に色を加算して描画。 減算：すでに描画されてる物から色を減算して描画。 描画色：背景を描画する際のカラーを32ビットARGBで指定。 →描画方式 ラップアラウンド表示：onにすると、背景の範囲外を繰り返して表示。 時間停止中でもスクロールする：onにすると、時間停止キャラクタが出現中でもスクロールを停止させない。 左右にフリースクロールする：onにすると、自機の左右の動きに合わせて背景が左右にスクロール。（背景の横幅を画面サイズより大きくする必要あり） 背景の当たり判定：ありにすると、このステージにおいて背景とキャラクタとの当たり判定が有効。 背景とキャラクタとの当たり判定を有効にするには、背景編集で「HIT」を設定し、キャラクタ編集で「背景と判定あり」に設定。 攻撃力：背景と接触時に受けるダメージ（0～）を設定。（防御力は無効） →背景とキャラクタの当たり判定，背景とキャラクタの当たり判定2 →制御（背景） →Z値オフセット，キャラクタのカスタム編集，表示優先 →速度（背景） →背景とキャラクタの当たり判定，背景とキャラクタの当たり判定2 ステージ編集＞＞基本設定 タブ，敵配置 タブ
https://w.atwiki.jp/holydiver/pages/23.html
ダメージ調査の際に気付いた事をいくつか紹介 マジックの与ダメージ (理論値と実測値を基に算出した期待値) 当て方、当たり判定によって誤差があるので、おおよその数値です。ダメージ表を参考に比較してみて下さい TWIN FIRE …… 2.0 BREAKER(近) …… 12.0～20.0 BREAKER(遠) …… 3.0 OVER DRIVE …… 1.0 THUNDER(稲妻のみ) …… 5.0 THUNDER(全体のみ) …… 2.0 THUNDER(複合) …… 7.0～37.0 TWIN FIREは見た目通りに1x2発。BREAKERの近距離は12以上20以下と推測。遠距離は1x3発。OVER DRIVEは1x2発だが、旋回中に再判定が行われるので耐久力2の敵も1発で倒せると推測。THUNDERの稲妻は1x5のパーツ、全体は一様に2。複合は全ての合計。問題なのは、敵が激しく動く場合や、画面内に敵や弾が溢れてキャラオーバーを起こすと、この数値が信用できなくなる事 敵キャラクターの当たり判定 その1 移動型の敵に当たり判定が複数ある場合は、安定した与ダメージを確保する事は難しいようです。当たり判定の範囲は、大きく分けて「見た目通り」「縦長」「横長」のタイプがあります。また、例外的な当たり判定を持つ敵キャラクターも存在します。 ステージ1のボス、フレイム・ガーディアンの弱点は頭部ですが、当たり判定がTWIN FIREの効果範囲よりも狭いため、2発の内1発しか当たりません。イーヴル・アイなども同様です(密着すれば当たります) マッド・ブッチャー、ヘリオンなどの飛行型やモッシュ、メタルブレイドの様な激しく動く敵キャラクターに逃げ撃ちをすると、与ダメージが減ってしまいます(当たる瞬間に動かれた場合も同様) ファントム・ロードは当たり判定が特殊です。THUNDERの全体攻撃以外では、何をしても与ダメージは1です。また、図の様に高速弾を撃つ瞬間だけ与ダメージが2になる事が判明しています 敵キャラクターの当たり判定 その2 ・見た目通り 小さな敵や障害ブロックが該当。基本となる8x8ドットの□型。アイオンの当たり判定は8x8のパーツ8個で構成され、それぞれが連なり高速で動いている ・縦長 メタルブレイド、ヘルレイザーなどが該当。□型を縦に積んだイメージ。ジェノサイドは縦2列になっていると推測される。横からの攻撃はダメージが少ない ・横長 デス・ギドラ、マッド・ブッチャーなどが該当。□型を横に並べたイメージ。貫通力のあるマジックに弱い ・特殊 ファントム・ロードが該当。複数の□型で構成されているが、2箇所以上同時にダメージを与える事ができない BREAKERのポテンシャル BREAKERは3連の青い貫通弾。発射前に掌を突き出す溜め動作があり、人によっては使い難いと感じるかもしれません。しかし、この溜め動作は想像以上の攻撃力を秘めています。ほとんどのザコキャラが1発で沈むほどに…… これが溜め動作。青く発光している箇所が攻撃判定。敵に密着して使用するので、当てるには相応の勇気が必要 ステージ3のボス、アクセル＆スラッシュは、下から現れたところに近距離BREAKER1発(x2匹)で倒せます。上から降りてきた時も、タイミングを合わせて上に撃てば同様です ステージ5のボス、パワースレイヴは高い耐久力を誇りますが、3発程度で倒すことができます。常時弾を吐いているので接近するのは大変ですが、狙う価値はあるかも まとめ 上ではBREAKERを取り挙げましたが、OVER DRIVEやTHUNDERも当て方を工夫することによって、少ない消費マジックで敵を倒すことができます。詳細な対処法についてはステージ攻略を参照して下さい
https://w.atwiki.jp/1524/pages/63.html
【プレイヤのガードの仕様】 【ガードの仕様】 ガードは盾を持つ片手剣のみ実行可能 ガードの範囲は正面のみ ガード中は攻撃や移動のコマンドは受け付けない カメラの移動は可能 方向も変えられない。 ＊ガードの当たり判定処理は未実装 【処理例を考えてみた】 本体の持つ当たり判定用のダミーの前にもうひとつガード用ダミーを置く ■ガード用の当たり判定用のダミ ■本体のあたり判定ダミ こちらから攻撃が来る場合①→■■←②こちらから攻g(ry ①から受けた場合先に■当たるのでガード判定に入る ②から受けた場合先に■当たるので被弾判定に入る ちなみに■が出る方向はガードしている方向 ガード.ノックバック等のモーション待ち 仕様ページTOP
https://w.atwiki.jp/goodgames/pages/832.html
ラグと当たり判定 1 何度お問い合わせ頂いたかわからない程の人気テーマでございます。 人気があるのにここで扱わなかった理由は単純明快。 きちんと書くと半端な量じゃなくなるから。 このテーマだけでも、 世界トップクラスの権威を誇る学術雑誌ネイチャーや ノーベル賞受賞論文掲載数世界一(未確認)の科学情報誌サイエンスに掲載されるぐらいの論文が書けるかもしれない。 (あくまでも「かもしれない」) そもそも「ラグ」と呼ばれる現象の多くは、非常に短いタイムスパンの中で発生する現象であり 説明の過程で必要となる検証を行おうにも、安定してラグを再現させるのことが非常に困難だったりします。 それとラグと必ずセットで語られるのがPing。 Pingについて100人中99人ぐらいは間違って理解しています。 Pingと言うと多くの場合は数値で表記され、 数値の大小とその意味については多くの人が理解していると思いますが、 本来、Pingに値など無関係であることを知っている人は意外と少ないものです。 何しろPingとはプログラムに付けられた単なる固有名詞ですから。 話は変わって「当たり判定」については明確に定義付けることが可能であるため、 説明すること自体は容易だが「説明したつもり」になるだけで相手が理解しているかどうかは甚だ疑問だったりします。 なにしろ「当たり判定」は英語ではCollision Detection(衝突検出)と呼ばれますが、 それ自体が一つの学問として研究されるぐらい奥の深い技術です。 本日はこの辺で... と終わりにしたら怒られるので最近多いお問い合わせについて記載致します。 Q1.BF3はクライアント側で当たり判定を実行しているのか? A1.Yes(正確には射撃側のみで判定し、被弾側では判定していない) Q2.BF4はサーバ側で当たり判定を実行するのか? A2.私が知っていたらおかしいでしょ。(笑) Q3.BF4がサーバ側当たり判定になった場合何が変わるの? A3.被弾判定に於けるラグの程度が「安定」します。 ある種のチートが激減します。(BF3ではクライアント側判定であるが故に成り立つチートが多数存在していた) サーバ負荷が上昇します。 Q4.BFBC2まではサーバ側当たり判定だったって本当なの? A4.BF1942は知りません。BF2とBF2142は忘れました。BFBC2は原則的にサーバ側当たり判定です。 但し、サーバ側判定とクライアント側判定を共に実施し、 結果が異なる場合にはサーバ側判定結果を優先する仕様でした。 お、比較的最近サーバを借りられた方からメールが。 御返事作成のため本日はここまで。 近日中に続きを記載致します。 (2013/08/22 00 30追記) 立て続けに同じようなお問い合わせを頂きましたのでこちらにも記載いたします。 BF4の当たり判定方式が「サーバ側のみ」になることはまず無いと考えて良いと思います。 BFBC2のサーバ/クライアント双方での判定方式と比較しメリットがほとんど無いためです。 意味合いとしては「まずクライアント側で仮の判定を実施し、その後サーバ側で正式な判定を実施する」ことになるため、 正式である「サーバ側判定」のみが語られているのではないかと思います。 ちなみにBFBC2をプレイしていた方なら誰でも経験がある(と思う)おかしな現象のひとつとして、 {自分の死体が別のところに落ちている」現象が挙げられます。 別のところと言っても死体が100mもワープするようなことは起らず、 死体がワープする場合、多くは数メートル手前に落ちています。 この「手前」が重要なポイントになります。 (続きは後日) ( - )
https://w.atwiki.jp/besiegejpwiki/pages/114.html
接続学概論ブロックは"接続"される ColliderScopeについて 基礎接続学そもそも接続ってなんやねん 被接続判定 接続判定 接続学接続による当たり判定の無効化 接続強度 接続強度表 応用接続学根本接続で互いに接続している場合の根本接続の無効化（設置順） 機構系根本接続による通常根本接続の無効化（機構系優先） 接続判定内に複数の被接続判定がある場合の接続優先度（座標優先） 座標優先の利用例（内側優先の定理） 設置順・機構系優先・座標優先の適用順 接続学概論 ブロックは"接続"される 世の中には様々なクラフトゲームがあるが、ブロックが特定の接続点で 他ブロックに接続されるシステムなのがBesiegeの特性とも言える要素である。 Besiegeのマシン制作を理解するには、この接続に対する理解が必要不可欠である。 この記事では、Besiegeの接続を取り巻く判定について記述する。 以下の動画も接続学について述べている。こちらも参照されたし。 解説内容 接続判定・被接続判定の概要 重ね設置について パーツの破損と接着強度 他 解説内容 接続判定、被接続判定の概要 Collider scopeの解説 各種接続判定の種類と解説 解説内容 重ね設置について 一体化について 根本接続の無効化について 他 ColliderScopeについて ColliderScopeは、Besiegeの接続判定各種の種類、及びその他判定などを可視化するMODである。 接続を学ぶ上で極めて役に立つMODであるので、これをサブスクライブしよう。 ColliderScopeはアップデートにより、前提MODとしてUIFactoryが必要になりました。使用する際は両方ともサブスクライブし、有効化しましょう。 ※スクショの表示はブロックを4つ重ねて見やすくしています 基礎接続学 そもそも接続ってなんやねん Besiegeの接続の定義を簡潔に述べる場合、次の通りになる。 これが接続の大前提となる。 では、接続判定と被接続判定とは何か？これを紹介する 被接続判定 被接続判定とは、接続"される"側の判定となる。被接続判定には２種類ある。 一つは当たり判定を兼ねた被接続当たり判定。画像右側の水色の部分にあたる。 ColliderScopeでの名称はConnectable Colliderである。 もう一つは当たり判定を持たない単なる被接続判定。画像左側の緑色の部分にあたる。 ColliderScopeでの名称はAdding Pointである。 接続判定 接続判定とは、接続"する"側の判定である。接続判定には4種類ある。 一つ目は根本接続。接続できるブロックの多くがこの判定を持つ、基本的な判定。 根本接続を持つブロックの例。ColliderScopeでの名称はPrimaryであり、赤丸で表示される。 二つ目は機構系根本接続。通常の根本接続と区別されるが、 基本的には通常根本接続と同じと考えてよい。ColliderScopeでの名称はMechanicalである。 機構系根本接続を持つブロックの一覧。全て可動ブロックであることがわかる。 通常根本接続にはない特別な性質があるが、特殊な働きであるため後述。 3つ目は頭側接続。一部のブロックが根本接続とは別に持つ接続判定である。 頭側接続を持つブロックの一覧。ColliderScopeでの名称はSecondaryである。 頭側接続には根本接続とは違う2つの特性がある。 ①一律の強度を持つ 根本接続の強度に関わらず、頭側接続の強度は一律である。 さらに接続強度が強く、バラストのおよそ5.6倍の強度を持つ。 ②燃えても炸裂を受けても凍っても壊れない v1.50より根本接続と同様の破壊属性を持つようになりました。 ③根本接続が重なることで無効化される これまでの性質を見れば非常に優秀に思える頭側接続だが、大きな弱点がある。 それが、頭側接続判定に根本接続判定が重なってしまうと、頭側接続判定が消失することだ。 そのため、頭側接続を有効に扱う場合には根本接続が重ならないように 十分に注意して設計を行う必要がある。 ただし、ブレース、スプリング、ロープ、サーフェス、距離計、ユニバーサルジョイントの根本接続では無効化されない。 4つ目はブレースの終端側接続。ブレースをドラッグした時の終端側が持つ接続である。ColliderScopeでの名称はMultiである。 前提として、通常では接続判定一つにつき一つのブロックしか固定できない。しかし、 この終端側接続は唯一、複数のブロックを同時に接続できる性質を持つ。 画像では、4つのバラストを一つのブレースで接続している状態。 利用方法次第で、複数のブロックの間に入れることでより強力に補強したり 複数のロケットを一つのブレースで保持する、などが可能となる。 接続学 接続による当たり判定の無効化 接続されたブロック同士は、当たり判定が消失し、互いに干渉することがなくなる。 この法則は友達ルールと呼ばれる。 この状態はブロックの破損などで接着判定が失われるまで保たれ、可動ブロックなどが回転して接着しているブロックに触れた場合も、当たり判定がないものとしてすり抜ける。 注意点として、この法則が適用されるのはあくまで接着しているブロック同士となるため 下図のように複数の接着ブロックの間では干渉してしまう。 さらに注意点として、この友達ルールが対象外のブロックが3つ存在する。 それが、スライダー、バルーン、丸太(根本接続のみ)（ver1.26にて修正）である。 接続強度 接着判定にどれだけの力が加われば結合が外れるか、という値はdiscordでは接続強度と呼ばれる。 動画にもありましたが、ステアリングヒンジとロープのキーを同一にし、壊れるまでロープを引っ張った時間でおおよその強度を算出しています。 その後アップデートや計測漏れなどで数値の改定、更新があり、以下に最新版を掲載します。 注 計測結果は手動、目分量で算出したものです。また、ロープの伸び縮みなどは考慮していません。ロープ１本では接続の切れない数値５以上のパーツには、ロープを追加して計測しています。あくまで目安として考えること。 接続強度表 ブロック接続強度が内部データから解析されました。 最新の接続強度等のデータはこちらから (tamakoro氏のスプレッドシート) https //docs.google.com/spreadsheets/d/14_QISDZe4cLrCiJPu0582J_SwphtTWOFvWS6ToUAStI/edit#gid=1197147439 解析以前のデータ 2018.8.15更新 ※無敵の接続中、爆弾でもげる表記のものはマルチでの挙動です。 応用接続学 根本接続で互いに接続している場合の根本接続の無効化（設置順） 二つのブロックが互いに根本接続同士で接続されている場合、 片方のブロックの接続が無効化される。これは通常根本でも機構系根本でも起こる。 上の画像のような状態の時に片方が無効化される。どちらが無効化されるかについては、 後から接続したブロック、つまり一度消してアンドゥで戻したブロックの接続が無効化される。 画像の場合では、スケーリングブロックを消して戻したらスケーリングブロックの接続が、 丸太を消して戻したら丸太の接続が無効化される。 機構系根本接続による通常根本接続の無効化（機構系優先） 先述した"機構系根本接続の持つ特別な性質"について述べる。 ①通常根本接続を持つブロックが機構系根本接続を持つブロックに接続している。 ②機構系根本接続判定と通常根本接続判定が重なっている この二つを両方とも満たす場合、通常根本接続が無効化される。 複雑だが、画像のような状況であれば通常根本接続が無効化されるということになる。 ただし、以下のブロックはこれによって無効化されない。 スケーリングブロック ・ヒンジ ・タイマー ・高度計 ・ロジックゲート ・角度計 ・速度計 サーフェス ・ブレース ・スプリング ・ロープ ・距離計 画像じゃタイマーを使ってますがこの撮影で無効化されない事実が判明しました 接続判定内に複数の被接続判定がある場合の接続優先度（座標優先） 同じ接続判定内に複数の被接続判定があった場合、どちらか片方の被接続判定のみ接続される。 あるブロックの被接続判定において、そのX座標が最小な面を、このページでは接続面と呼ぶことにする（下図では緑の線が小型木製ブロックの接続面で、赤い線がバラストの接続面）。 この時接続する側のブロックは、接続面のX座標が大きい方のブロックを優先して接続する。 バレンの山の方向を向いた場合、X軸は右向きとなるため、被接続の左端が右側にある方のブロックに優先して接続される。 被接続の端が条件に関わる理由は、恐らくバウンディングボックス（軸平行境界ボックス）が接続に関係するためである。バウンディングボックスについては自葬砲を参照。 座標優先の利用例（内側優先の定理） 座標優先の応用として、内側優先の定理がある。 内側優先の定理とは、２つのブロックと接続判定が座標優先の起こる条件下において、上から見たときにブロックAの被接続がブロックBの被接続から一切はみ出ていない時、座標優先によりブロックAに優先して接続される}、という定理である。 上図の場合、上から見たときに木製ポールの被接続がバラストの被接続から一切はみ出ていないため、マシンがどの向きでも木製ポールの接続面が右側に来る。従ってドリル根本は常に木製ポールに接続する。 下図は内側優先の定理の使用例である。 ホイールの被接続判定はバラストよりも小さいため、内側優先によりホイール→ホイール→バラストの接続となる。 設置順・機構系優先・座標優先の適用順 しっぴつちゅう
https://w.atwiki.jp/stgbuilder/pages/29.html
コメントまとめでもスレ抜粋でも良いので、スクリプト情報を蓄積させるページ ■被弾時に死亡して、残機を減らし、次自機を出すスクリプト タスクナンバー及びタスクメニュー ⇒ 配置パネル及び設定 ０：メインタスク ⇒ 【制御：タスク開始】タスク番号１３、「最初から開始する」にチェック。時間待ちしない . 【制御：タスク停止】タスク番号 ０、「最初から開始する」にチェック。時間待ち1F 11：破壊時 ⇒ 【制御：タスク開始】タスク番号１３、「最初から開始する」にチェック。時間待ちしない ※ゲートを作る事 【制御：タスク停止】タスク番号１１、「最初から開始する」にチェック。時間待ち1F （Ｓぷ者 ◆n3VrL7XRbc） ＜全般＞ 画面解像度 ステージの起動順序 ＜タスク関連＞ タスク，マルチタスク メニューの作成法，自機死亡時の再出撃 ＜スクリプト関連＞ デフォルトスクリプト，継承スクリプト デフォルトスクリプトの解析，継承スクリプトの活用法，無限ループ・エラー ネストの説明，条件分岐の説明，ループの説明，タスク・ループの説明 ＜スクリプトパネル関連＞ スクリプト編集 ラベルパネル，制御パネル，移動パネル，攻撃パネル，描画パネル，サウンドパネル，背景パネル，スコアパネル，変数パネル，物理パネル，予備パネル ＜スクリプトサンプル集＞ 自機の目的別スクリプト，自機のタスク別スクリプト，敵機のタスク別スクリプト，ウエポン関連のスクリプト，オプション関連のスクリプト ＜変数関連＞ 変数の説明，変数の使用例1，変数の使用例2，変数の使用例3 ビット，桁の取り出し，三角関数値，三角関数値の使用法 ＜親子関連＞ 親子の説明，シグナルの説明，子生成とショット，弾幕とショット，自機とオプション シグナルの検証結果 ＜移動関連＞ 移動の説明，移動速度，移動力，移動の単位，相対設定，座標軸と角度，パスの使用方法 放物線移動，地形誘導移動 等速・加速・減速・加減速の違い，等速・加速・減速・加減速の検証，移動速度の検証，慣性と移動停止 線形加速，移動と回転 ＜当たり判定関連＞ 当たり判定，キャラクタ同士の当たり判定，背景とキャラクタの当たり判定，背景とキャラクタの当たり判定2，画面端の当たり判定 表示オフと当たり判定，かすりの解説 ＜キャラクタ関連＞ キャラクタ別のフラグ設定，キャラクタ別のスクリプト設定，多関節キャラクタの作成方法，ラスターの解説，ラスターの解説（イラスト） ＜スプライト・アニメ関連＞ 自機移動時のアニメ 色の解説，透過色，画像の反転，表示の優先順位 ＜スコア関連＞ ランキング，ネームエントリー，リプレイ，永久パターン，タイム ＜ステージ関連＞ ステージの起動順序 ＜背景関連＞ 背景のスクロール，キャラクタの影の描画，背景のカラー，キャラクタのカラー ラップアラウンドの解説，フリースクロールの解説，フリーループスクロールの解説，自機ループの解説 ＜レイアウト関連＞ レイアウトの注意，ゲージ管理，HPゲージ スクリプト情報蓄積 コメント TIPS情報蓄積
https://w.atwiki.jp/wsc3kai/pages/47.html
cginfo.cgs cginfo.cgsは、HLG設計画面における船体以外のパーツについて、その画像や当たり判定を定義しているファイルです。 なお、厳密には個々のパーツではなく、パーツの形毎の定義になります。 ファイル長：1,174,000byte（固定） 現状ではわからない部分だらけですが、実用（パーツの改変）上問題ないと判断し、解析データを公開します。 仮作成 データ構造 cginfo.cgsには全体のヘッダがありません。単純に各画像のデータが並んでいます。 各々のパーツのデータについては、定義ブロック、側面図当たり判定ブロック、上面図当たり判定ブロックの3ブロックに分かれます。 1パーツあたり、0x024B=587byteのデータサイズになります。 定義ブロック まだわからない部分が多いです。 注意点として、側面図、上面図の画像ID（読み込み画像の左上の座標）が挙げられます。 例えば元の画像が640x640のサイズであれば、640x640=409,600pixel存在することになりますが、0x20-0x23及び0x24-0x27の値は、この中の何番目のpixelに当たるかを指しています。 仮に0x20-0x23の値が0x00024F32であった場合、0x00024F32=151346番目のpixelを指していることになります。画像の横のサイズが640であれば、 151346÷640=236余り306なので、この場合、座標（305,236）のpixelを指している事になります。 次の注意点は画像読み込み範囲です。 兵装の前後、高さ、幅が定義されており、その値に従います。側面図なら縦＝高さ、横＝前後、上面図なら縦＝幅、横＝前後です。 また、HLGにおける1マスは4pxになります。このため、例えばHLG上での高さ＝10なら、読み込まれる画像の高さは40pxになります。 address ： 説明 0x00-0x1B？ ： パーツの名称ですが、正確なサイズがわかりません。短いものは9byte程度で終わり、すぐにデータ列が続きます。一方長いものは24byte以上あります。 0x0A ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x0B-0x0E ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x0F ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x10-0x13 ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x14-0x17 ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x18-0x1B ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x1C-0x1F ： ？名前の短いものはデータが始まります。ダミーデータの可能性もあります。 0x20-0x23 ： パーツの側面図の画像IDです。※厳密には画像の左上の座標です。 0x24-0x27 ： パーツの上面図の画像IDです。※厳密には画像の左上の座標です。 0x28-0x2B ： ほとんど0xFFFFFFFFだが、一部例外有り。何かのフラグ？ 0x2C-0x2D ： 0x0000 0x2E ： 画像読み込み範囲（前後長）※この値*4pxの範囲を読み込む 0x2F ： 画像読み込み範囲（高さ）※この値*4pxの範囲を読み込む 0x30 ： 画像読み込み範囲（幅）※この値*4pxの範囲を読み込む 0x31 ： ？おそらくは、前向き後ろ向き兵装の違いに由来する何か 0x32 ： 甲板からの高さ。※但し使われている気配がない 0x33 ： ？ 0x34 ： ？ 0x35 ： ？ 0x36 ： 甲板から沈み込む深さ。砲塔基部やVLSなど、甲板下が存在するものに利用。一応定義上0x32+0x36=0x2Fになる。但し0x32は使われている気配なし 0x37 ： ？ 0x38 ： 画像の読み込みファイルを指定。0：駆逐兵装-FR、1：空母兵装-FR.bmp、2：巡洋兵装-FR.bmp、3：戦艦兵装-FR.bmp等画像変更の際はかならずこれもセットで。 0x39 ： ？0x00？ 0x3A ： ？0x00？ 側面図当たり判定ブロック アドレス0x3B～0xBAにかけて記述されます。 側面図を横に短冊切りにして、右の方から構造物の存在フラグをつけていくような感じです。 （後日画像での説明） 短冊切り1行分のデータは4byteで構成され、最大で32列分のデータが存在します。 面倒なのは、この存在フラグはbit単位（つまり1行32bit）で管理されていることです。すなわち、以下のようになります。 例：0x001FC03C（バイナリエディタ上では3CC01F00）なら以下のとおりです。※下の黒四角にあたり判定あり 0x00 0x1F 0xC0 0x3C 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 0 0 □ □ □ □ □ □ □ □ □ □ □ ■ ■ ■ ■ ■ ■ ■ □ □ □ □ □ □ □ □ ■ ■ ■ ■ □ □ 注意すべき点は、0x2Fで定義された分の行データが存在しないと、その分当たり判定が沈み込んでいってしまう点です。 例えば砲塔の基部が邪魔だなと思って、基部のデータを除去すると、砲塔自体が船体に沈み込んでしまいます。 これを回避するには、0x2Fの高さと0x36の沈み込み深さを書き換えてやる必要があります。 以下、さらに実際の例を示します。 100cmⅠＲ1（100cm砲、前向きの画像）側面図の当たり判定（全高12、甲板上高さ5、深さ7） バイナリデータ：00FFFF01FFFFFF01FFFFFFFF00E0FFFF00C0FFFF00C0FFFF00C0FFFF00C0FFFF00C0FFFF00C0FFFF00C0FFFF00C0FFFF00C0FFFF →0x01FFFF00、0x01FFFFFF、0xFFFFFFFF、0xFFFFE000、0xFFFFC000、0xFFFFC000、0xFFFFC000、0xFFFFC000、0xFFFFC000、0xFFFFC000、0xFFFFC000、0xFFFFC000、0xFFFFC000 □□□□□□□■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□↑ここから上が甲板上の構造物■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□↓ここから下は甲板の下の砲塔基部■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□ 上面図当たり判定ブロック アドレス0x00CF～0x014Eにかけて記述されます。 側面図と同様、上面図を上から（艦の左側面から）短冊切りにして、右の方から構造物の存在フラグをつけていくような感じです。 （後日画像での説明？側面図だけにするかも） 短冊切り1行分のデータは4byteで構成され、最大で32列分のデータが存在します。 側面図の場合と異なり、当たり判定の中央部に気をつけて記述していく必要があります。 以下、実際の例を示します。 100cmⅠＲ1（100cm砲、前向きの画像）上面図の当たり判定（当たり判定のある部分のみ抜粋） バイナリデータ：0000C0010000F80F0000FC1F0000FE3F0000FF7F0000FF7F0080FFFF00F8FFFFFFFFFFFF FFFFFFFF00F8FFFF0080FFFF0000FF7F0000FF7F0000FE3F0000FC1F0000F80F0000C001 →0x01C00000、0x0FF80000、0x1FFC0000、0x3FFE0000、0x7FFF0000、0x7FFF0000、0xFFFF8000、0xFFFFF800、0xFFFFFFFF 0xFFFFFFFF、0xFFFFF800、0xFFFF8000、0x7FFF0000、0x7FFF0000、0x3FFE0000、0x1FFC0000、0x0FF80000、0x01C00000 □□□□□□□■■■□□□□□□□□□□□□□□□□□□□□□□□□□□■■■■■■■■■□□□□□□□□□□□□□□□□□□□□□□■■■■■■■■■■■□□□□□□□□□□□□□□□□□□□□■■■■■■■■■■■■■□□□□□□□□□□□□□□□□□□■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□□□■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□□ ■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□■■■■■■■■■■■■■■■■■■■■■□□□□□□□□□□□■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■□□□□□□□□□□□■■■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□□■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□□□■■■■■■■■■■■■■■■□□□□□□□□□□□□□□□□ □□■■■■■■■■■■■■■□□□□□□□□□□□□□□□□□□□□■■■■■■■■■■■□□□□□□□□□□□□□□□□□□□□□□■■■■■■■■■□□□□□□□□□□□□□□□□□□□□□□□□□□■■■□□□□□□□□□□□□□□□□□□□□□□ なお、0xBB～0xCE、0x014E～0x24Aにはデータがありません。 実際の当たり判定 実際の当たり判定は、あるパーツの側面図、上面図の両方の当たり判定のあるマスに、別のパーツの両方の当たり判定のあるマスが重なった時に「重なった」と判定されます。 逆に言えば、側面図だけでの重なりや上面図だけでの重なりは「重なり」と判定されません。 よって、当たり判定を減らしたい時には、上面図、または側面図のいずれかの当たり判定を減らすだけで十分であると考えられます。 （※色々考える必要がないという点では上面図の当たり判定編集がオススメ） 逆に、当たり判定を追加したい時には、上面図、側面図両方の編集が必要であると考えられます。 また、これらの仕様上、思っても見なかった場所や、邪魔な部分にも当たり判定が出てきてしまう場合があります。 具体的に、ここまで例として出してきた100cm砲が、3次元的にはどのような当たり判定を持っているか示します（甲板上のみ） HLG上の100cm砲と比べて、ターンテーブル上に巨大な張り出し部分が出てきている事が分かります。 このため、一見何もない部分にもパーツが配置出来ない事になってしまうのです。 （「リアルに」考えるなら砲身の旋回部分に余計な物のっけようとする方がアレなのですが・・・） 可能っぽい改造の一例 煙突の内部の当たり判定削って、内部にVLS仕込めるようにする。（煙突ミサイル化） 波動砲をいっその事甲板下に沈めてしまう（宇宙戦艦ヤ●ト） 艦橋の重ねあわせ（現代型艦橋等）
https://w.atwiki.jp/besiegejpwiki/pages/250.html
デフォルトスキン 当たり判定 オブジェクトを収めるためのブロック ステータス 基本情報 使い方バニラ mod independent 関連項目 ステータス パラメータ名 値 ID 30 通称 ボムホルダー 英語名 BombHolder 質量 0.5 空気抵抗 0.2 回転抵抗 0.05 HP 0 根元強度 9625 頭強度 - 根元曲げ強度 9625 頭曲げ強度 - 静止摩擦係数 1000 動摩擦係数 1000 弾性 0 オブジェクト間の摩擦処理 平均 オブジェクト間の衝突処理 平均 破壊属性 衝撃（M） 一体化（ウッドパネル） × 一体化（鉄プレート） 〇 入力キー 初期値 効果 なし 設定 定義域 初期値 説明 なし 基本情報 ボムやファイアーボールなどを置く台としての役割を担う金属製のブロック。 独特な当たり判定を持つ。 ハーフパイプと共に、ボムを取り扱うことを意図されており、これを2つ重ねることでボムを覆うことができる。ただし、こちらもハーフパイプと同様に、ボムを爆発から守るような特性は無い。 使い方 バニラ ボムやファイアーボールを保持するという基本的な用途の他は、その独特な当たり判定を活用されることが多い。 例えば、無敵接続で当たり判定が円状であることを利用して、車輪や戦車の転輪に使われることがある。 また、2つのホルダーの当たり判定を噛み合わせることで、歯車的な力の伝達装置としても利用できる。歯が4つしかないので精度は期待できないが、ブロック数を抑えつつクラッチやユニバーサルジョイントのような機構が作成できる。 mod independent 関連項目