概要
neosでlogixやってみる。
避けるべきこと。
避けるべきこと
- スロット名と構造
自分が所有・管理していないアイテムやスロットのスロット名や構造を、LogiXやコンポーネントに当てはめないようにしてください。
自分が所有・管理していないアイテムのスロット名や構造は、いつでも変更される可能性があり、せっかく作ったものが壊れてしまうことがあります。
以下は、このような問題が発生する可能性のある例と、問題を軽減するための代替案や提案です。
ユーザルートの名称や構造について
新機能の追加や機能の更新に伴い、ユーザールートにアイテムが追加されたり削除されたりすることがあります。
そのため、これらのスロットが持つ構造や命名規則に依存しないようにしてください。
さらに、これらのスロットはいつでも変更される可能性があるため、これらのスロットの順序に依存しないでください。
たとえば最近、新しい「フリーフォームカメラ」をカバーするために新しいスロットがユーザールートに追加されました。
このエリアで避けるべきこと:
名前で子を探す
Get Parent / Get Child ノードを繰り返し使用して、検索または階層の深さを理解してスロットを見つける。
この解決策:
User Root Nodesを使用して、ユーザーのスロットを探す。
User Nodesを使用する。
- アバターの名前や構造
アバターは非常に複雑な構造をしています。
避けるべきこと:
アバターのパーツを探すのに「Find Child By Name」を使用する。
Get Parent / Get Child ノードを繰り返し使用してアバターパーツを探す。
アバターの構造を想定する
例えば、頭や手のアバターには "Avatar Root "がありません。
代わりに:
Avatar Nodesをしようする。
ユーザールートのスロットを日常的に見つけたり獲得したりしたい場合は、Issue Trackerで新しいノードや機能をリクエストしてください。
- 他人のワールドの名前や構造
他のユーザーの世界を訪れる際には、自分がその空間のゲストであることを忘れないようにすることが非常に重要です。
ガジェットやツール、アバターを作成する際には、相手の世界に敬意を払うようにしましょう。
避けるべきこと:
銃やロケットなどのアイテムをルートに配置すること。
spawnやlightなどの階層について、ワールドのセットアップが標準的であると仮定すること。
Custom Culling systems や locomotion modules
Dynamic ImpulsesをRoot Slotに呼び出さないでください。
ダイナミックバリアブルをルートスロットやワールドバリアブルスペースに置かないようにします。
帰るときにワールド内にアイテムを残さないようにしてください。
後片付けは自分で行ってください。
銃やパーティクルなどのアイテムは、後で掃除する必要があります。
それらのpersistentのチェックを外すか、自分がワールドを離れるときに削除されるように設定することを検討してください。
解決方法:
Set ParentノードをRoot Slot Parentで使用する場合、代わりに "Local User Space "ノードを使用する。
これはほとんどの場合、同じ機能を持ちますが、アイテムがルートに散らばるのではなく、あらゆるワールド管理システムに正しくペアリングされます。
複雑なガジェットを取り出したり、ワールドのルートを変更する前に、ワールドのオーナーに尋ねてください。
- スロット
スロットの難読化/「暗号化」
Neosで何かを作ったら、それを保護したいと思うかもしれません。
次のことは行わないでください。
スロット、LogiXノードなどの名前の変更
スロットの移動、拡大縮小、回転
上記のいずれかを実行するクリエーションにLogiXを使用する
これはあなたの作品を保護する方法のように思えるかもしれませんが、ビルダーの権限を持つ知識のあるユーザーにはあまり効果がありません。
方法論に関係なく、アプリ内の難読化はこの方法で比較的簡単に破ることができます。
その代わり：
アバターの場合：Simple Avatar Protectionなどのアバター保護システムを利用する
保護したいワールドでユーザーをビルダーとして設定することは避ける
知らない、または信頼できないユーザーと一緒のセッションでアイテムをスポーンしないようにする
また、この分野を支援するためにロードマップにいくつかの項目があります。
それらの進捗状況を追跡し、それらに投票することをお勧めします。
ハードパーミッション-ワールド内のアセット、アイテム、LogiXを保護する。
オブジェクトID/ライセンス-アセット、アバター、アイテム、ワールドなどが保存されないように保護する。
- アバター
重要なアバターコンポーネントの無効化
アバターは非常に複雑なものです。
アバターが機能するために必要な主要コンポーネントを無効にしないでください。
これを頻繁に行う場合は、GitHubのissueを開くか、達成しようとしている動作についてDiscordで質問してください。
アバターでレイキャストを無効にする
Neosには、アバターに影響を与える可能性のあるツール、ガジェット、アイテムがたくさんあります。
ノックバックガン、爆発、ガン、体重計を台無しにするツールなどは非常に一般的です。
一般的なこれに対する解決策は、ユーザーがアバターがレイキャストに応答する機能を無効にすることです。
これは原則として機能しますが、ゲームエクスペリエンスや標準のNeosコンポーネントまたはシステムが機能しなくなる可能性があります。
これにより、Neos全体のエクスペリエンスの質が低下する可能性があります。
それはまた実際にはより大きな問題を隠しており、これは文化とガイドラインに関連しています。
あなたの同意なしにセッションであなたやあなたのアバターを編集したり、いじったり、影響を与えたりすることは、ガイドラインに違反します。
これを行うユーザーは、自分が行っていることが間違っていることに気付いていない可能性があるため、同意の重要性とガイドラインについて時間をかけて通知してください。
動作が続く場合は、セッションモデレートを利用するか、繰り返しまたは特に悪意のある場合は、モデレーションチケットを作成してください。
- コンポーネント
自動で無効化されたコンポーネントを強制的に有効にする
時折、コンポーネントを使用しているときに、そのコンポーネントが自動的に無効になることがあります。
これは通常、コンポーネントの設定や追加されたスロットに何か問題があり、コンポーネントが機能しなくなっていることを意味します。
このような場合、有効なチェックボックス/フィールドをtrueにしないでください。
Issue Trackerでのバグ報告をご検討ください。
このような状況は、解決できる問題かもしれません。
時には、これらはコンポーネントの間違った使用法であり、修正できない場合があります。
コンポーネント内の _ で始まるプロパティは、いつでも変更または削除される可能性があるため、可能な限り回避する必要があります。
- リファレンスID / "Ref Hacking"
Neosで構築する際に、Neos内に存在する特定の制限や機能のギャップを回避するために、リファレンスIDを使用することが望ましい場合があります。
その際には、以下の点に注意してください。
リファレンスIDはいつでも変更される可能性があります。
リファレンスの使い方によっては、セキュリティ上の問題とみなされ、予告なしに修正されることがあります。
もし何か問題を発見した場合は、Moderation Systemで報告してください。
一般的には、以下のような専用のノードやコンセプトを使用するべきです。
ユーザーノードを割り当てる
型付きの参照とキャスト
もし、特定のreference IDやパスを使用する必要がある場合は、Issue Trackerで機能リクエストを行ってください。
- LogiX
複雑なデータ型でのToStringノードの使用
非プリミティブデータ型（例：float, int, doubleなどでないもの）でToStringノードを使用する場合は、ノードの出力に依存しないでください。
いつでも変更または更新される可能性があります。 これには、データ型、ユーザー、スロットなどが含まれます。
これらの項目のstringsの比較は脆く、Neos Updatesで変更される可能性があります。
代わりに:
ユーザーの場合、User Root NodesまたはUser Nodesを使用してください。
スロットについては、Slots Nodesを使用します。
型については、Typeノードを使用します。
もし、このようなことが必要になった場合は、Issue Trackerで機能リクエストを行ってください。
より良い選択肢がある場合にFireOnTrueなどを使用する
Flowカテゴリのいくつかのノードは、特定の値が変更されたときにインパルスを発生させることができます。
例えばFire On True, Fire On False, Fire While Trueなど。
これらは非常に強力であり、特定のユースケースに最適なソリューションである場合には問題なく使用できます。
しかし、一見良い選択肢のように見えても、実際にはもっと優れた効率的な代替手段がある場合も少なくありません。
Fire On Trueなどが適切な場合、これらのノードのUpdatingUser入力を空のままにしておくのではなく、ユーザー値を指定することを推奨します。
ボタンについて
ボタンが押されたときに、値の変更やLogiXのトリガーなど、何かを起こさせたいと思うことがよくあります。
避けるべきこと:
例えば、様々なボタンコンポーネントのIsPressed boolフィールドを使用し、それをFire On Trueの入力とすることで、LogiXインパルスを発生させること。
代わりに:
この目的のための専用ノード、Button Eventsを使用してください。
これはより効率的で、与えられたボタンで様々な異なることが起こったときにインパルスを発生させることができます（押された、押した、離されたなど）。
ProbablePrimeがこのノードの使い方について短いチュートリアルを作成していますここ。
ボタンの押下に基づいて、値を変更するなどの単純なアクションを実行したいだけの場合は、Common UI > Button Interactionsカテゴリのコンポーネントを検討してください。
これらのコンポーネントは、他の方法でLogiXを使って行うことができる簡単なアクションを置き換えることができます。
ProbablePrimeがこれらのコンポーネントのいくつかについて、チュートリアルを用意しています - ButtonValueCycle, ButtonValueShift, ButtonValueSet, ButtonToggle.
ボタンが押されているかどうかに基づいてボタンの色をドライブするなど、ボタンの押下状態に関連する可能性のあるいくつかの効果にIsPressedブール値を使用することは
「合理的」です。
- ツールチップ
RawDataTooltipコンポーネントを追加することで、グラブ可能なアイテムを装備可能にすることができます。
これにより、ユーザーは、標準のNeosツールチップと同様に、コントローラーボタンの押下に基づいてアクションを実行するようにプログラムできるカスタムツールチップ、
武器、およびガジェットを作成できます。
避けるべきこと：
例えばLogiXインパルスを起動するために、Fire OnTrueでRawDataTooltipコンポーネントのプライマリまたはセカンダリブールフィールドを使用すること。
代わりに：
この目的には専用ノードRawDataTooltip Eventsを使用してください。
これはより効率的であり、RawDataTooltipが装備されているときにさまざまなことが起こったときにインパルスを発生させることができます。
ユーザーがユーザーがコントローラーボタンを押しているかどうかに基づいて装備アイテムの色を駆動するなどに関連する可能性のあるいくつかの効果に
プライマリーやセカンダリーブールフィールドを使用することは「合理的」です 。
- 複数のノードを同じスロットに結合する
LogiXの最適化を検討している場合、LogiXのセットが占めるスロットの数が心配になる可能性があり、ノードを1つのスロットにまとめることでこれを改善しようとします。
これには通常プラグインが必要であり、「モノパッキング」と呼ばれます。
これによりLogiXのスロット数は削減されますが、「モノパック」のLogiXの編集、読み取り、および理解が困難になります。
さらに、Neosが将来的に最適化することをLogiXがより困難にします。
その代わり：
LogiXFunctionsなどのLogiXの追加の最適化と拡張機能を待つ。
他の最適化手法とソースを調べることを検討する。
最適化ガイドライン。
シームレスな開梱/開梱を可能にする可能性のあるネイティブな同等物の実装を待つ
オブジェクトのスロット数は、必ずしもパフォーマンスを決定するわけではないことに注意してください。
パフォーマンスはさまざまなソースからもたらされ、スロット数は1つにすぎません。
- グラフィック
マテリアルの "重ね"について
Neosでビジュアルエフェクトを作成する際、メッシュレンダラーに複数のマテリアルスロットを追加して、マテリアルを重ねることができます。
これは素晴らしい視覚効果をもたらしますが、後で壊れる可能性があります。
可能な限り、これは避けてください。
代わりに：
同じ場所にそれぞれ異なるマテリアルで複数のメッシュレンダラーを作成します。
これは同じ効果につながります。
Neosで利用できるさまざまなマテリアルを試してみてください。
追加してほしい効果については、将来の実装リクエストを開くことを検討してください。
ノート：
これは、アバターのように複数のマテリアルスロットを持つメッシュには影響しません。
これは、同じマテリアルスロットを複数回使用することを指します。
この詳細については、このGitHub Issueを参照してください。
シェーダーのNeos DB URLの切り替え
StaticShaderアセットのURLを、視覚的な影響の程度が異なる他のStaticShaderアセットのURLと交換できることに気付いたかもしれません。
これは後日壊れます、特にカスタムシェーダーが今後のグラフィックエンジンで対応する場合は特にそうです。
コンテンツを制作するときは、視覚効果のためにこれに頼るべきではありません。
- アセット
7zbson/json/bsonの使用
Neosのアイテム、アバター、ガジェット、そしてワールドは、通常JSON、Binary JSON、またはそれらを圧縮した形の様々なファイルに格納されていることがあります。
これらのファイルにアクセスするためのいくつかの方法があり、これらのファイルを使ってNeosのアイテムやアセットのインポート、編集、保存、バックアップなどを行うことができます。
これは便利で望ましい使用方法に思えるかもしれませんが、残念ながらいくつかの理由で「いつでも壊れる可能性がある」のです。
Neosがこれらのアセットのフォーマットや構造を変更する可能性があります。
Neosがこれらのファイル内のコンポーネントを導入/削除し、非互換性を引き起こす可能性があります。
これらのファイルは、しばしば他のファイルを参照または相互リンクしており、これらのファイルが削除または変更されると、非互換性の可能性がさらに高まります。
従って、この方法を使用することは推奨されません。
また、サポートされている機能ではありません。
- キーボードコンポーネント/ノードを使用してアイテムをスポーンする
複数のキーボード関連コンポーネントを組み合わせることにより、Neosのクラウドからアイテムスポーンをトリガーすることができます。
これは通常、Neosアイテムやアセットを指定するURLを使用します。
これを行うことは良い経験を提供することができますが、それは長期的にサポートされるものではありません。
この機能は、後日機能しなくなるか、機能しなくなる可能性があります。
この機能は現在一般的に"クラウドスポーン"として知られていますが、そうではありません。
クラウドスポーンは実際にはNeosが将来サポートする予定の機能です。
「クラウドスポーン」にこの方法を使用する代わりに、LogiXでネイティブにこれを行う機能に投票してください。
- インベントリ
長い/複雑なフォルダ名
インベントリ内にフォルダを作成する際、非常に長いフォルダ名やアスキーアートを含む名前を使用したくなるかもしれません。
これは、すべてのプラットフォームで同じように表示されない可能性があり、一部の地域ではナビゲーションや技術的な問題が発生するため、お勧めできません。
また、将来的にインベントリ管理/検索機能が追加された場合、インベントリの検索やインデックス作成に問題が生じる可能性があります。
ただし、絵文字といくつかのRTFフォーマットタグ（色の変更など）は問題ありません。
それらを使いすぎないでください。
以上。