BRIDGEの衝突
基本:BRIDGEとダミートリガ
条件:フラグメンテッドトリガ
コンディショントリガの制限と可能性
BRIDGEオブジェクト
フレームワークBRIDGEによる計画
BRIDGEの厚さ:Staticsの衝突をシミュレート
Miscellanous IIサンプルプロジェクトについて
レベルエディタでは、ダミートリガでトリガされたBRIDGE_FLATオブジェクトを使用して吊り橋を作成できます。

しかしダミートリガを使用する必要はないことが分かりました。普通のトリガを使用して同じ結果を得ることができます。
ところでBRIDGE用のトリガを設置したセクターにコンディショントリガを配置するとどうなるでしょう?以前のバージョンでは興味深いことは何もありませんでした。BRIDGEは常に条件の応答を無視して有効になっていましたが、1.2.2.4のバージョンからはエンジンがコンディショントリガをチェックするため、BRIDGE用のトリガが実行されたり、されなかったりします。
この新しい機能のおかげで、不規則な形の足場を作ることができます。
例えば、同じセクターに次のようなコンディショントリガを配置するとします。
; Set Trigger Type - CONDITION 6
; Exporting: CONDITION(6:62) for PARAMETER(5)
; <#> : Square fragment (1,1)
; <&> : Fragmented trigger. Check in (E) way if lara is in <#>fragment of 2x2 sector grid
; (E) : DEFAULT. Lara is over current #fragment
条件は、ララがセクターの1/4である左上の小さな正方形にいる場合にのみtrueとなります。
そこで、BRIDGEオブジェクトとBRIDGEオブジェクトのトリガも置くと、ララが左上の小さな正方形にいるときはどうなるでしょう?
答え:ララはBRIDGEの上に残ります。
しかし、ララがその左上の小さな正方形の外にいるときは、どうなるでしょう?

単にBRIDGEが有効にならないので、BRIDGEがそのセクターに存在していなかったかのように、ララは落ちます。
この方法のおかげで、非常に興味深い詳細な床(および天井)の衝突を作成することができます。
この新しいBRIDGE衝突機能をよりよくサポートするために、フラグメンテッドトリガを大量に追加しました。
この章では、使用可能な古いフラグメンテッドトリガと新しいフラグメンテッドトリガを確認できます。



コンディショントリガを検証するために使用された新しいコードを重複することはできません。セクターのトリガは2つしか管理できません。コンディショントリガとBRIDGEオブジェクトのトリガです。
ダミートリガはコンディショントリガと使用することはできません。なぜなら、それらは特別なトリガであり、それらを混在させることができないからです。
フラグメンテッドトリガとは異なるコンディショントリガを使用することはできません。そうしないと、予期しない結果になる可能性があります。
同じセクターに2つ以上のコンディショントリガを配置することはできません。そのかわり次のような単一のコンディショントリガを使用することができます。
; Set Trigger Type - CONDITION 15
; Exporting: CONDITION(15:0) for PARAMETER(1)
; <#> : TriggerGroup= 1
; <&> : Multiple condition of <#>TriggerGroup script command
このようにして、複数の条件がtrueかfalseであるかを設定するには、Script.txtのTriggerGroupコマンドにエクスポートされた条件を追加し、上記の制限を避けて多くのコンディショントリガを使用できます。
TriggerGroup条件トリックは、単一のフラグメンテッドトリガから供給された様々な形状を混合して、新しい形状を得るのに非常に便利です。
例えば、ララが歩くことができる滑らかな斜めのストリップを作成したい場合は、いくつかの計算を実行する必要があります。

Pic1の緑色のトリガゾーンを作成したいとしましょう(Pic1参照)。
残念ながら、このような条件はありません。似たようなコンディショントリガはPic2しかありません(Pic2参照)。ララはその一連の小さな四角で作られているコンディショントリガの隙間を歩くことができないため、望んだものと同じではありません。
ですから、何らかの方法で別の条件と混ぜて目標を達成する必要があります。
Pic1を見ると、2種類の白い三角形(「A」と「B」が書かれている)があります。
似たような三角形のコンディショントリガにPic3とPic4があるので、おそらくこれが正解です。
Alfa三角形(Pic3)は「A」(Pic1)と同じ形状を持ち、Beta三角形(Pic4)は「B」(Pic1)と同じ形状をしています。
ところがPic1の三角形は白(トリガから除外されたゾーン)ですが、Pic3とPic4の三角形は緑(トリガされたゾーン)です。そこで、これらのトリガをInverse(反転)モードで使用してこの問題を解決できます。このようにトリガされたゾーンは、与えられた三角形の外側にあります。この方法で、Pic5の黄(Alfa三角形の逆ゾーン)とPic6の黄(Beta三角形の逆ゾーン)が得られます。
今度はTriggerGroupに三角形のコンディショントリガを両方ともエクスポートするだけです。
====== PIC5の黄色のゾーンを得る ==========
; Set Trigger Type - CONDITION 70
; Exporting: CONDITION(70:58) for PARAMETER(768)
; <#> : Cathetus Size= 768
; <&> : Fragmented trigger. Check in (E) way if lara is in the North-West corner triangle with <#>Size
; (E) : INVERSE. Lara is outside of current Triangle
====== PIC6の黄色のゾーンを得る ==========
; Set Trigger Type - CONDITION 71
; Exporting: CONDITION(71:58) for PARAMETER(768)
; <#> : Cathetus Size= 768
; <&> : Fragmented trigger. Check in (E) way if lara is in the South-East corner triangle with <#>Size
; (E) : INVERSE. Lara is outside of current Triangle
次に、デフォルトの論理演算子ANDがあるので、2つのトリガをリンクして、両方の条件がtrueであるときにTriggerGroup条件全体がtrueとなります。すなわちララが最初のトリガのゾーンを越えていて、 第二のトリガのゾーンも越えたときです。
この状況はPic7に表示される青いゾーンにある場合にのみ発生します。
そのゾーンはまさに作成したいものです。
注意:直角三角形トリガでNOT演算子を使用しても同じ結果を得ることができます。つまりララが最初の(Alfa)三角形でなく、(Beta)三角形でない場合です。この2番目の方法では、コンディショントリガはINVERSEモードではなくNOT演算子を使用します。結果はまったく同じになります。
TriggerGroupコマンドにコンディショントリガを入力し、OR演算子を使用してそれらをリンクするだけで、複数の断片化されたゾーンを作成することができます。

例えば上の画像では、Pic1のゾーンを作成したい場合は、円を作成するコンディショントリガ(Pic3)と一緒に3x3グリッドの垂直カラムのコンディショントリガ(Pic2)を作成するだけです。
OR演算子を使用すると結果はPic1になります。
複雑な形を作成するときは、すべての演算子AND、ORおよびNOTを使用する必要があります。

上の画像で、Pic1に表示される形状を作成するには、次のようにTriggerGroupを作成する必要があります。
NOT 画像Pic3のコンディショントリガ:半径150のサークル
AND 画像Pic2のコンディショントリガ:半径400のサークル
OR 画像Pic4のコンディショントリガ:3x3グリッドの3番目の水平ストリップ
備考:説明するのは簡単ではありませんが、ANDとORを組み合わせるとき、条件を入力する順序は非常に重要です。
例えば、上記の順序ではうまくいく一方、次の順序では、
画像Pic2のコンディショントリガ:半径400のサークル
NOT 画像Pic3のコンディショントリガ:半径150のサークル
OR 画像Pic4のコンディショントリガ:3x3グリッドの3番目の水平ストリップ

ララが画像のPic1に示された赤い点にいると落ちます。
ララは緑色のゾーンにいるので、それはtrueであるはずですが、結果はfalseです。
コンディショントリガの解析が次のように動作するからです。
最初のトリガを分析し(半径400のサークル)、条件はfalseです。
次の演算子をチェックし、NOTを見つけますが、他の演算子がない場合はNOT値が「AND NOT」になり、
次のANDにリンクされた最初のfalseの条件が見つかったので、解析は即座に完了します。条件はfalseです。
一方で、もしNOTとORを一緒に使って上記の順序を変更すると、
画像Pic2のコンディショントリガ:半径400のサークル
OR NOT 画像Pic3のコンディショントリガ:半径150のサークル
OR 画像Pic4のコンディショントリガ:3x3グリッドの3番目の水平ストリップ
上記の画像のPic2では、ララが赤い位置にいるたびTriggerGroupが新たに失敗します。
その理由は、この場合の構文解析が次のように動作するからです。
最初のトリガを分析し(半径400のサークル)、条件はfalseです。
次の演算子をチェックしてORを見つけるので、次の条件がtrueであるかどうかを確認します。
(半径150のサークルではない)を分析して、それはtrueです。
次の演算子をチェックして、それがORであることを見いだすので、構文解析は次の条件をスキップします。なぜなら、条件A、B、Cのいずれか(A、B、C)がtrueなら他はtrueである必要がないからです。
しかし、次の条件(3x3グリッドの3番目の水平ストリップ)をスキップすると、上記の画像のPic2に示されているようなララが単に「半径150のサークル」の外にあるときにも当てはまります。にもかかわらずララはホワイトゾーンにいます。
これらのあいまいさを理解するには、TRNGで処理される優先順位がNOT、OR、ANDの順になっていることを覚えておいてください。
優先度を括弧を使って説明します。
最初の例:
a AND b AND NOT c OR d
それは次のようになります。
a AND b AND ((NOT c) OR d)
2番目の例:
a OR b AND c OR NOT d
それは次のようになります。
(a OR b) AND (c OR (NOT d))
非常に詳細な形を作ることができますが、エンジンはあまりにもスリムな衝突を検出できません。

上記の画像にはこの問題があります。このスリムな長方形の衝突を可能にするコンディショントリガを作成しても、ララは衝突を通過する可能性があります。
その理由は、エンジンが約200単位の増分を使用してララの前(ランニング方向)を点検するからです。衝突の幅がその値よりも小さい場合、エンジンは前方に障害物がないとみなし、実際には、エンジンが衝突のゾーンをスキップして、障害物の反対側を直接点検するためです。
TRLEには、BRIDGEが3つしかありませんでした:BRIDGE_FLAT、BRIDGE_TILT1、BRIDGE_TILT2
「TILT」は、傾斜のあるBRIDGEになります。TILT1は1クリックの傾きを意味し、TILT2は2クリックの傾きを意味します。
これらのBRIDGEオブジェクトは、ララが滑らずに歩くことが出来ます。

それとは違って、新しいBRIDGEオブジェクト、BRIDGE_TILT3、BRIDGE_TILT4、BRIDGE_CUSTOMは、ララが歩くことができない傾斜を持っているので、彼女はそれらの上でスライドします。
ララが歩くことができないBRIDGEは奇妙に思えるかもしれませんが、2つの例外があります。新しいBRIDGEは両方ともカスタマイズ可能であり、OCBで歩行可能にすることができます。サンプルレベルで、ララが傾斜4の斜面を歩いているのを見ることができます。
もう1つの例外は、BRIDGEを使用して巨大な像のようなStaticの上に詳細な衝突を作成している場合です。この状況では、歩行可能なBRIDGE(FLAT、TILT1、TILT2)が必要ですが、TILT3、TILT4またはCUSTOMのように、ララが滑るような斜面が必要になることがあります。
この方法は、目に見えない衝突で床から彫像の上まであがらないようにしたいときに重要です。この方法は動作しますが、ララは巨大な彫像の腕の上など、彫像の上を歩くことができないという問題があります。
BRIDGE_CUSTOMは奇妙な形をしていますが、実際の床の衝突は表示されません。勾配を変えることができるBRIDGEであるため、この形を使いました。
実際、OCBに値を設定するとTILT機能を設定することができます。
つまりBRIDGE_CUSTOMを使用してどんな傾斜でも持たせることができます。
すべての新しいBRIDGEオブジェクトは、OCBフィールドでカスタマイズできます。
これらのオブジェクトのOCB値を作成するために使用される式は次のとおりです。
TiltFactor + NoSlidingFlag + EnableHangFlag + Depth*256
式の説明:
TiltFactorはTilt値です。例えば、TiltFactor = 0の場合はBRIDGE_FLAT、TiltFactor = 2の場合はBRIDGE_TILT2のスロープを作成します。
許容される最大値は、傾き63です。
この値はBRIDGE_CUSTOMオブジェクトに対してのみ機能します。他のBRIDGEオブジェクトでは、
BRIDGE_FLATオブジェクトは傾きなし。
BRIDGE_TILT1オブジェクトは1クリック傾いた足場。
BRIDGE_TILT2オブジェクトは2クリック傾いた足場。
BRIDGE_TILT3オブジェクトは3クリック傾いた足場。
BRIDGE_TILT4オブジェクトは4クリック傾いた足場。
となります。
NoSlidingFlagは値128です。この値をOCBに追加すると、ララはこのBRIDGEを滑らず渡ることができます。
EnableHangFlagは値64です。この値を追加すると、ララはBRIDGEのエッジをぶら下がりできます。デフォルトでは、すべての新しいエッジ、つまり標準のゲームスクエアに一致しないエッジで多くの問題が発生したため、ぶら下がり機能が削除されました。
一般的なセクターに沿ったBRIDGEを使用している場合(フラグメンテッドトリガはない)を除いて、ぶら下がり機能を無効にすることをお勧めします。
DepthはBRIDGEオブジェクトの厚さで、1/4クリックになります。1セクターの厚さを持つBRIDGEは、Depth = 16を使用します。
厚さは重要です。なぜなら、BRIDGEはララがその下にいるときに天井の機能も持つからです。
古いBRIDGEは1クリックの厚さを持っていました。
備考:
*上記のOCB記述は古い可能性があります。最新の情報はNG_Center[Reference]を参照してください。
misc2.wadのBRIDGEオブジェクト(上の画像)を一新しました。
使用された「フレームワーク」の形は奇妙に見えるかもしれませんが、それには理由があります。
これらのBRIDGEと一緒にコンディショントリガを使用して衝突を変更すると、レベルで異なる形をカバーする同じ形の同じBRIDGEを使用することは不可能です。
このような理由からレベルの足場を以下の図のように計画しています。
BRIDGEオブジェクトを使用して新しい衝突を作成しますが、これらのオブジェクトはすべて非表示のボタンを選択します。
するとBRIDGEは見えなくなり、それとは別に見える足場を用意しなければなりません。
つまり同じセクターに2つのオブジェクトを置く必要があります。これがフレーム状のレイアウトをBRIDGEに与えた理由です。同じセクターの2つのオブジェクトを表示し、簡単に選択、回転、移動することができます。
BRIDGEは単にララが歩くことができる吊り下げられた面だけではありません。
適切なOCBを使用すると、数クリックのセクターのような厚みのある真の3DソリッドにBRIDGEを変換できます。
フラグメンテッドトリガに追加されたこの機能により、BRIDGE衝突を使用して静的または移動可能な(アニメーション化された)衝突を作成することができます。
例えば、次の画像例:

今、四角い台座と上部が傾斜した円柱があります。
さて、BRIDGEの衝突とコリジョントリガを組み合わせて使用すると、これらの形状を衝突でカバーできます。
ララは台座(画像A)上を歩いたり、円形面(画像B)を歩くことができ、衝突は斜面を持つ円になります。
オブジェクトの周りに衝突を適応させるために、いくつかの小さなトリックを適用する必要があります。
私たちは非常にしばしば、メッシュの元の位置を(Metasequoiaを使用して)少し変更して、フロアの衝突と合わせる必要があります。
この説明では、128単位、すなわち1/2クリックの傾きを持つBRIDGEを置くことができ、衝突の高さ(厚さ)は1/4クリックで作用するので、64単位の倍数でなければなりません。
例えば、台座付きの柱の例では、勾配面をBRIDGE_TILT2オブジェクトのサーフェスに合わせて変更しました。

この操作を実行する良い方法は、Metasequoiaで両方のオブジェクトをロードすることです。最初に柱を作成し、次に挿入コマンドを使用して、BRIDGEを挿入します。(画像A)
次に、BRIDGEだけを選択し、移動コマンドを使用して、柱の位置に非常に似通った位置に到達するまで128を掛けて移動します。
最後に、柱の頂点をBRIDGEの傾斜面と一致させるため、頂点を上下に動かします。
上記の手順でNGLE(およびゲーム)では、柱の表面をBRIDGE表面で完全にカバーすることができます(画像B)
この場合、コリジョントリガを使用して、静的な衝突の形状を作成する必要があります。
コリジョントリガは、NGLEのOutput WADコマンドでTOMファイルを作成する前に衝突を変更する(偽の)フリップエフェクトトリガです。
床や天井からの衝突を上下に移動し、さらに三角形の勾配を設定することができます。
「コンディショントリガの制限と可能性」の章では、床のデータトリガに過負荷をかけないほうがいいと言いました。すなわち、セクターにはコンディショントリガとBRIDGEオブジェクトのトリガのみを許可するように提案しました。
しかし一部の状況では、セクターに他のトリガを置くことができ、この操作が危険なときとそうでないときがあります。
コリジョントリガの場合、操作は完全に安全です。これは、ゲーム内で動作する実際のトリガではなく、時間を置いてプレースホルダとして機能する偽のトリガだけが、WADを出力する前に衝突を修正する場所を覚えているからです。
つまりゲームが開始されると、コリジョントリガはTR4ファイルに存在しなくなるため、この場合は過負荷は発生しません。
しかし、ここではコンディション/BRIDGEトリガに実際に過負荷をかける可能性のあるめったにない状況とその理由を説明することができます。
BRIDGEのトリガとそれ以上の条件は、ゲームフェーズに応じて異なる方法で動作します。
第1段階では、ゲームエンジンは、フロアデータを解析するBRIDGEのトリガをチェックして衝突を発見するだけです。BRIDGEのトリガが見つかったら、BRIDGEの位置を確認し、衝突を設定します。
第2段階では、ゲームエンジンは、オブジェクト、フリップマップ、効果およびその他のゲームを管理するためのすべてのトリガをチェックします。この第2段階では、BRIDGEのトリガは無視されます。
結果が非常に異なるため、上記の2つの段階でトリガがどのように機能するかを理解することが重要です。
この第1段階では、唯一考慮するトリガは、さらなるコンディショントリガとBRIDGEのトリガです。
エンジンはこの計算を実行します。
- 条件が見つかった場合は、それがtrueであるかどうかをチェックし、trueであれば、次のトリガ(次のトリガだけが)が実行されます。
- 条件が満たされている場合、または条件がない場合は、BRIDGEのトリガが管理され、新しいフロア衝突を計算します。
- BRIDGEのトリガがさらにある場合は、条件がtrueかfalseかを問わず、衝突計算のためにすべて管理されます。
上記の説明を読むと、同じセクターで異なる高さのBRIDGEオブジェクトが2つ以上ある場合に過負荷が発生する可能性があります。
セクターに次のようなトリガを置くと、
コンディショントリガ
BRIDGE77のトリガ
BRIDGE81のトリガ
BRIDGE77(インデックス=77)とBRIDGE81が同じセクターの垂直線上にある場合、エンジンは次のように動作します。
コンディショントリガを実行します。条件がtrueであれば、BRIDGE77の衝突が生成され、falseの場合、BRIDGE77は無視されます。
BRIDGE81については、コンディショントリガの結果に関係なく常に衝突が発生します。
これは、2つ以上のBRIDGEを同じセクターに配置できることを意味します。つまり、条件の後の最初のトリガは、断片化された形状になり、他のすべてのBRIDGEは正方形になります。
この説明には面倒な質問があります。
BRIDGEのトリガが1番目か、2番目かに応じて動作が異なるため、トリガは正しい順序で設置しなければなりません。
例えば、BRIDGE77が細い形状をしていて、BRIDGE81が正方形をしているのであれば、条件の後、BRIDGE77のトリガが常に最初のものである必要があります。
2dパネルビューでトリガをクリックしてトリガの順序を確認できますが、順序が間違っている場合(例:BRIDGE77のトリガが2番目の場合)、問題を解決するにはどうすればよいでしょう?
解決策は簡単です。トリガ(BRIDGE77)が選択されたら、Delキーを押してそれを削除します。新しいセクターを選択し、ピンクボタンをクリックしてトリガを追加します。こうして、BRIDGE77のトリガの順序を変更し、最初のトリガにします。
多くのトリガがある場合、少し面倒かもしれませんが、結果は明白です。条件の影響を受けるトリガは、条件の後の最初のものでなければなりません。
備考:いくつかのチェック結果の後、条件付きBRIDGEは3d空間内で常にコンディショントリガより先になければならないが、同じセクターにある後のものは全てフルサイズになる(条件の影響を受けない)
第2段階では、つまりゲームエンジンがフリップエフェクト、アクションなどのその他のトリガをチェックするとき、特定のセクターのトリガの解析はより簡単です。
- それがtrueかfalseかの条件チェックがある場合。
- 条件がtrueであれば、それに続くすべてのトリガを実行する。
- 条件がfalseの場合、エンジンはこのセクターのすべてのトリガを無視します。
つまり、次のような状況になります。
コンディショントリガ
BRIDGE77のトリガ
BRIDGE81のトリガ
サウンドを再生するためのトリガ34
BADDY_1を有効にするためのトリガ143
トリガは条件がtrueである場合にのみ実行され、falseの場合はすべてのトリガが無視されます。
ここではBRIDGE77の形状をサポートするためのコンディショントリガ(フラグメンテッドトリガ)だと仮定しているので、これは、ララがBRIDGE77に設定された形状を超えたときにのみトリガが実行されることを意味します。
3つのタイプの足場で使用されるOCB値を調べると、次の値が見つかります。
L字型の歩道橋:512
リング:0
階段:384

一方、柱(上の画像)は:4608
厚さ係数は1/16セクターとして格納され、OCBでは厚さに256を掛けなければならないため、上記BRIDGEの厚さに関する設定は次のようになります。
歩道橋:512 = 2 * 256(厚さ= 2)
リングは0ですが、デフォルトでゼロがある場合、厚さは1クリック、すなわち16分の4セクター(厚さ= 4)
階段:384:スライディング無効(128)のOCBフラグを削除:384 - 128 = 256。したがって、1 * 256(厚さ= 1)
柱:4608/256 = 18(厚さ= 18)
実際のゲームユニットについては、16分の1セクターが64(1024/16)なので、上記オブジェクトの厚さ(または高さ)は次のとおりです。
歩道橋= 128
リング= 256
階段= 64
柱= 1152
いつものように、BRIDGEの下側もモンキースイングの天井として使うことができます。BRIDGEがあるセクターにモンキースイングの属性を置くだけです。
ところが、この属性がスリムなBRIDGEにあるとき、奇妙なことが起こります。
ララはBRIDGEの床から出発してBRIDGEの天井にぶら下がることができます。
上記の画像を見ると、バグのように見えます。特に、画像4の場合が非常に疑わしい、バグだと言えます。
しかし、このバグは避けることができません。なぜなら、ララが落ちて断片化された境界線の端をつかむときに起こった他のバグの修正の効果であるからです。そのバグを修正するためには、ララの腕から衝突を取り除く必要がありました。
画像4では、ララの腕がBRIDGEを横切っていることがわかります。なぜなら、ララがよりダウンしているとき(画像5)、天井にぶら下がることができるようにエンジンがしているからです。その瞬間のララは、モンキースイングにとって正しい位置にあります。
上記の手順にもかかわらず、BRIDGEの形状を変えてその妥当性を得ることができます。BRIDGEは金属製のパイプを使って構築されたようなフレーム状の形をしています。
上記の方法では、動きが非常に速いので、そのトリックは妥当と思われます。
とにかくこのような状況が望ましくない場合は、フラグメンテッドトリガを使用しているBRIDGEにモンキースイングの属性を置くのは避けるべきです。