NGLE講座

■#DEFINE

サンプルレベル

http://www.trlevelmanager.eu/download/lightning.zip

構文

#DEFINE CONSTANT VALUE

記述場所

任意で使用します。

インスタンスの最大値

特にありません。

使用例

;最初のTriggerGroupインデックスに4を設定する。
#DEFINE BS_TG 4

機能概要

必要な値を持つ一時的なニーモニックコンスタンツを作成します。
このコマンドの主な使い方は、一連のスクリプトコマンドの再マッピングを簡単にできるようにすることです。
いくつかのコマンドは一意のIDを必要とするので、スクリプトにコマンドのブロックを挿入すると、IDが競合するリスクがあります。
これらの競合を速やかに解決するには、このコマンドで定義されたニーモニックコンスタンツを使用してスクリプトを構築し、コマンドのIDのベースとして使用することができます。
例えば：

TriggerGroup= 4, $8000, 112, $2C
TriggerGroup= 5, $2000, 271, $52
TriggerGroup= 6, $2000, 235, $70, $2000, 232, $52
GlobalTrigger=2, IGNORE, GT_CONDITION_GROUP, IGNORE, 4, 5, IGNORE
GlobalTrigger=3, IGNORE, GT_TRNG_L_TIMER_EQUALS, 45, IGNORE, 6, INGORE

上記のコードは、IDを使用する異なるコマンド間のリンクを示しています。

GlobalTrigger2は、インデックス4と5を持つTriggerGroupにリンクされ、GlobalTrigger3はTriggerGroup6とリンクされています。

コマンドが多くなると、IDの数が多くなりすべてのIDを変更するのが面倒になります。
しかし、このコマンドを使用すると、上記のコードをこのように変更することができます。

#DEFINE BS_TG 4 ;最初のTriggerGroupインデックス
#DEFINE BS_GT 2 ;最初のGlobalTriggerインデックス

TriggerGroup= BS_TG, $8000, 112, $2C
TriggerGroup= BS_TG+1, $2000, 271, $52
TriggerGroup= BS_TG+2, $2000, 235, $70, $2000, 232, $52
GlobalTrigger=BS_GT, IGNORE, GT_CONDITION_GROUP, IGNORE, BS_TG, BS_TG+1, IGNORE
GlobalTrigger=BS_GT+1, IGNORE, GT_TRNG_L_TIMER_EQUALS, 45, IGNORE, BS_TG+2, IGNORE

この場合、最終的に実行されるコードはまったく同じですが、2番目のバージョンの利点は、競合が発生したときに、最初の2行の命令を変更するだけで、すべてのTriggerGroupおよびGlobalTriggerインデックスを変更し、それらの間の内部リンクを保持できます。

#DEFINE BS_TG 10
#DEFINE BS_GT 8

こうすると、すべてのIDは、正しい内部リンクを維持しながらより大きい値に変更されます。

これらのID再マッピングの問題は、いくつかの機能を説明するときに、レベルビルダー同士でコマンドのブロックを交換する際によく起こります。
このコマンドを使用してすべてのID番号を設定するという習慣を覚えていると、あなたのコードサンプルはどんなスクリプトにも簡単に適応できます。
備考：#FIRST_ID命令も参照すると、目的をより簡単に達成できます。

このコマンドの他の使い方はあまり役立ちませんが、とにかく考え方は次のようになります。
非常に頻繁に使用する公式ニーモニックコンスタンツのグループを簡単な単語に書き換えるのにこのコマンドを使います。

#DEFINE DEBUG DGX_LOG_SCRIPT_COMMANDS+DGX_COMMON_VARIABLES+DGX_LARA
#DEFINE USUAL DGX_LARA+DGX_SFX_SOUNDS+DGX_CHEATS

こうすると、DiagnosticTypeコマンドの入力が簡単に変更できます。

DiagnosticType=DEBUG, 0

または

DiagnosticType=USUAL, 0

記述時の注意点・備考

このコマンドはローカルで、現在のソース内でのみ動作します。インクルードファイルで使用していると、異なるソースのため、その命令はそのインクルードファイルでのみ動作します。異なるソースでスクリプトを配置する利点は、異なる値を持つ同じ命令を任意のソースで使用できることです。

同じソースで同じコンスタンツを2回使用することはできません。
例えば：

#DEFINE MYNAME 12
#DEFINE MYNAME FT_BOTTOM_CENTER+FT_SIZE_ATOMIC_CHAR

この場合、MYNAMEというコンスタンツが12なのか、FT_フラグなのかわかりません。

同じソースの別のDEFINEコマンドに設定されたコンスタンツを（VALUEを得るために）数式で使用できますが、これらのコンスタンツを使用するDEFINEコマンドの前に配置する必要があります。
これは間違っています。

#DEFINE BS_ALL 10
#DEFINE BS_GT BS_TG+15
#DEFINE BS_TG BS_ALL+30

BS_TGの値は#DEFINE BS_GT命令が解析されるときにまだ定義されていないためです。
これは正しいです。

#DEFINE BS_ALL 10
#DEFINE BS_TG BS_ALL+30
#DEFINE BS_GT BS_TG+15

VALUEフィールドの間に空白（スペース）を入れることはできません。
これは間違っています。

#DEFINE MYSUM ALFA +BETA

これは正しいです。

#DEFINE MYSUM ALFA+BETA

各フィールドの説明

CONSTANT: このフィールドには、一時的なニーモニックコンスタンツを入力します。
VALUE: このフィールドには、一時的なニーモニックコンスタンツに代入する値を入力します。

TriggerGroupコマンドでPluginIdを宣言するためのDEFINEの使い方

このコマンドはトリガのエクスポートやプラグイン管理に合わせて使用できます。
NGLEからエクスポートされたトリガにプラグインを含んでいた場合、そのエクスポートされたトリガを処理するプラグインが何であるかを見つける必要があります。

トリガをエクスポートすると、そのトリガを所有するPluginIdをエクスポートファイルに追加します。
問題はIDが数字だけであることですが、NG_CenterはそのPluginIdに対応するPlugin_name.dllをどうやって知ってるのでしょう？

トリガをエクスポートする際、Script.txtファイルが読み込まれ、Pluginコマンドから、NG_Centerはplugin_nameのPluginIdを検出します。
PluginIdを検出すると、NG_Center用に変換しトリガをエクスポートしたファイルに挿入します。

エクスポートされたトリガをTriggerGroupコマンドに追加すると、NG_Centerはトリガ内にPluginIdを見つけると、Pluginコマンドから右のプラグイン名と関連付けることができるので、正常に機能します。

問題は、トリガが別のスクリプトで使用される場合に発生します。
この状況では、新しいスクリプトはそのPluginIdに対応するPluginNameが何であるか知る方法がありません。
NG_CenterがPluginIdとPluginNameの間のリンクを発見するのを助けるために#DEFINEコマンドを使用できます。
この状況では、この#DEFINEの位置は非常に重要です。なぜなら、指定されたTriggerGroupにPluginIdがある場合は、最初に#DEFINEを宣言する必要があるからです。

例えば：

#DEFINE @plugin_train 3

TriggerGroup=.......

上のスクリプトでは、NG_Centerがコードを解析し、plugin_trainにはPluginId=3があり、次のTriggerGroupを解析するときにPluginId=3のトリガが見つかると、ID=3は「plugin_train」だと認識します。

TriggerGroupの前の行で#DEFINEが自分のものである必要はありません。とにかく、TriggerGroupのリンクを無効とするためにDEFINEを閉じることを忘れないでください。
以前の#DEFINEを閉じるには、特別な値「@plugins CLEAR」を使用します。
したがって、上記の例は次のようになります。

#DEFINE @plugin_train 3

TriggerGroup=.......

#DEFINE @plugins CLEAR

次のような行は入力しないでください。

#DEFINE @plugin_train CLEAR

固定名「@plugins」を使用する理由は、単にこの構文上の理由だからにすぎません。
将来は多くのプラグインが存在するかもしれないので、次のような構文が必要かもしれません。

#DEFINE @plugin_smartlights 4
#DEFINE @plugin_robots 3
#DEFINE @plugin_train 1

TriggerGroup=....

#DEFINE @plugins CLEAR

上記の例では、PluginId情報のリストを与えた後、最終的な「#DEFINE @plugins CLEAR」という行ですべてクリアしています。

最後のCLEAR行を省略または間違えた場合、問題が発生する可能性があります。
次に、より詳細なサンプルを見てみましょう。

これらのPluginコマンドが[Options]セクションにあるとします。

[Options]

Plugin=1, plugin_people, IGNORE
Plugin=2, plugin_train, IGNORE
Plugin=3, plugin_demo, IGNORE

次に、NGLEからplugin_trainが所有するトリガをエクスポートし、このトリガをTriggerGroup=10に追加します。

TriggerGroup=10, $024000, 132, $0012

このような状況では、#DEFINE @pluginを使用する必要はありません。なぜなら、NGLEがスクリプト内で読み取ったのと同じPluginIdをトリガに設定しているからです。したがって、plugin_trainはスクリプト内でID=2を使い、NGLEはトリガ内でID=2を使います。
最初にエクスポートされた番号（$024000）の最初の2つの16進文字をIDとして見ることができます。最初の$02はPluginID=2です。

では次に進みましょう...

ここでは、新しいスキルについて、友人からTriggerGroup（またはより多くのコード）を入手したと仮定します。友人は、それらのTriggerGroupの中でplugin_peopleを使用し、そのスクリプトでplugin_peopleがID=2としています。あなたのスクリプトではID=2はplugin_trainですが、DEFINEコマンドを使ってこの競合を解決できます。

#DEFINE @plugin_people 2
TriggerGroup=21, $02200, 17, $0124....

NG_Centerが「#DEFINE @plugin_people 2」行を読み込むとID=2をplugin_peopleに関連付けるので、NG_Centerはあなたのスクリプトでplugin_peopleのID=1を（トリガの内部にある）ID=2に変換します。
しかし、最後のCLEARを省略して、この順番でコマンドを入力すると、

#DEFINE @plugin_people 2

TriggerGroup=21, $02200, 17, $0124.... ;plugin_peopleのためのあなたの友人からのTriggerGroup

...他のコマンド....

TriggerGroup=10, $024000, 132, $0012 ;plugin_trainのためのあなたのTriggerGroup

NG_CenterはあなたのTriggerGroup=10を、plugin_peopleの場合と同じようにID=2（plugin_peopleのもの）として処理します。

この問題を解決するには、以前の#DEFINEをクリアして他のTriggerGroupを入力する前に閉じることを覚えておいてください。

#DEFINE @plugin_people 2

TriggerGroup=21, $02200, 17, $0124.... ;plugin_peopleのためのあなたの友人からのTriggerGroup

#DEFINE @plugins CLEAR

TriggerGroup=10, $024000, 132, $0012 ;plugin_trainのためのあなたのTriggerGroup

この新しいコードでは、「CLEAR」を指定すると前の定義が削除され、NG_CenterがTriggerGroup=10を解析して内部プラグインテーブルのプラグイン定義を見つけられないときは、元々[Options]セクションにあったPluginIdつまりplugin_trainを使用します。そのIDは2であり、これはplugin_trainの正しいIDです。