Java コマンド作成者に対する Bedrock コマンドの制限事項

Java は、summon コマンド内に再帰的なpassengerデータを配置できます。 Bedrock は通常、代わりに乗車コマンドと段階的なセットアップを必要とします。つまり、1 行の Java mob スタックが複数の Bedrock コマンドになるか、別の設計が必要になる可能性があります。

正確な 1 行の構造よりも視覚的なアイデアが重要な場合は、まず Java バージョンを構築してから、その関係を Bedrock 乗車ワークフローに変換します。

Java NBT およびアイテムコンポーネントは、詳細なアイテム、エンティティ、および表示データを保持できます。 Bedrock は同じ場所で同じペイロードを受け入れないため、高度な Java Output を Bedrock に直接貼り付けないでください。

Bedrock の安全なコンテンツの場合は、サポートされているコマンド引数の近くにコマンドを配置し、NBTForge 警告を提案ではなく停止標識として使用してください。

• カスタム Java アイテムコンポーネントは、Bedrock アイテムシステムではありません。
• JavaエンティティNBTは有効なBedrock召喚データになりません。
• datapack JSON リソースは、Bedrock ビヘイビア パックではなく、Java datapack リソースです。

記事、プリセット、または Command Packが両方のエディションを対象としている場合は、Java ステップと Bedrock ステップを別々に作成します。脚注で制限事項を隠さないでください。クリエイターは貼り付ける前に知っておく必要があります。

NBTForge は、ダウンコンバートされた Java コマンドではなく、Bedrock バージョンが独自のコマンド レシピとして扱われる場合に最適に機能します。

このガイドを使用して、プレーヤーまたはマップ メーカーが実際に実行するアーティファクト (Copy したコマンド、注文された Project パック、またはdatapack リソース) を作成します。最終レビューは、編集可能なビルダーの状態だけでなく、Copy したOutputに対して行われる必要があります。

ワークフローがバージョンに依存する場合は、コマンドの横にターゲット バージョンのラベルを付けます。セレクター、scoreboard、boss bar、タグ、loot table、またはProject順序を使用する場合は、セットアップを公開する前にクリーンな環境でそれらの依存関係をテストしてください。

• 1 つのコマンドの場合は Output からの Copy、注文されたパックの場合は Project から。
• Java、Bedrock、およびスナップショット バリアントを分離してください。
• 最初に無害なOutputで破壊的なセレクターをテストします。
• ガイドが標準ワークフローになったら、関連するプリセットを更新します。