避けるべきこと

From Neos Wiki
Revision as of 16:58, 28 February 2023 by Aesc (talk | contribs) (Created page with "== Componentの順番に依存する== コンポーネントには、インスペクタに表示され、Neos によって処理される固有の順序があります。し...")
Jump to navigation Jump to search
Other languages:
Deutsch • ‎English • ‎日本語 • ‎한국어

概要

Neosは、パワー、オプション、機能をすべて備えた素晴らしいエンジンです。しかし、いくつかの方法ややり方は問題があったり、後日故障につながる可能性があります。これは、避けるべきこと、やってはいけないこと、その理由、そして解決策や回避策をまとめた一般的なリストです。これらの機能は、引き続きご自由にお使いください。

このページの項目は、ガイドラインに反するものではありません。.

しかし、可能な限りこのページの項目を使用しないことをお勧めします。

また、このリストは、誰かを罵倒したり悪意を持ったりすることを意図したものではありませんが、自分の作品をより良くするためのポイントを理解し、Neosアップデートや他のユーザーが意図せずに物を壊してしまわないようにするためにも、一読の価値はあると思います。

もし、何か不便に感じることがあれば、コミュニティやチームに相談してください。もし、Neosに問題やギャップがあり、解決してほしいことがあれば、Issueを立ててください。

サポートされていない機能や未対応・未実装の機能を利用する

公式まだ実装されていない機能は、内部のシステムやプロパティを変更することで「ハック」したり、実現したりすることができます。実験したり遊んだりすることは構いませんが、そのようなアプローチは事前の警告や公式な実装が保証されていない限り、壊れてしまう可能性が高いことをご了承ください。

そのため、このような方法は避け、すでにサポートされている機能を使って別の方法を取ることをお勧めします。

予定されている機能のリストは、公式のGitHubでご覧いただけます。https://github.com/Neos-Metaverse/NeosPublic/issues に投票していただければ、より早く優先順位をつけることができます。公式の機能については、将来のNeosのアップデートでもユーザーのコンテンツが機能し続けるように、迅速な実装よりも長期的なコンテンツの互換性を確保することに、常に細心の注意を払っています。

ある問題を実装する予定のないものとしてクローズした場合、その結果を完全に達成するためにハックや回避策を使うことは強くお勧めします。それらは脆く、代替品が全く来ないまま壊れてしまうからです。このような場合は、長期的な互換性を確保するために、システムの設計に沿った別のアプローチを見つけなければなりません。

スロット

自分が所有・管理していないアイテムやスロットのスロット名や構造を、LogiXやコンポーネントに当てはめないようにしてください。自分が所有・管理していないアイテムのスロット名や構造は、いつでも変更される可能性があり、せっかく作ったものが壊れてしまうことがあります。

以下は、このような問題が発生する可能性のある例と、問題を軽減するための代替案や提案です。

ユーザルートの名称や構造について

新機能の追加や機能の更新に伴い、ユーザールートにアイテムが追加されたり削除されたりすることがあります。そのため、これらのスロットが持つ構造や命名規則に依存しないようにしてください。さらに、これらのスロットはいつでも変更される可能性があるため、これらのスロットの順序に依存しないでください。

たとえば最近、新しい「フリーフォームカメラ」をカバーするために新しいスロットがユーザールートに追加されました。

このエリアで避けるべきこと:

  • 名前で子を探す
  • Get Parent / Get Child ノードを繰り返し使用して、検索または階層の深さを理解してスロットを見つける。

この解決策:

アバターの名前や構造

アバターは非常に複雑な構造をしています。

避けるべきこと:

  • アバターのパーツを探すのに「Find Child By Name」を使用する。
  • Get Parent / Get Child ノードを繰り返し使用してアバターパーツを探す。
  • アバターの構造を想定する
    • 例えば、頭や手のアバターには "Avatar Root "がありません。

代わりに:

ユーザールートのスロットを日常的に見つけたり獲得したりしたい場合は、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などのアバター保護システムを利用する
  • 保護したいワールドでユーザーをビルダーとして設定することは避ける
  • 知らない、または信頼できないユーザーと一緒のセッションでアイテムをスポーンしないようにする

また、この分野を支援するためにロードマップにいくつかの項目があります。それらの進捗状況を追跡し、それらに投票することをお勧めします。

アバター

重要なアバターコンポーネントの無効化

アバターは非常に複雑なものです。アバターが機能するために必要な主要コンポーネントを無効にしないでください。 これを頻繁に行う場合は、GitHubのissueを開くか、達成しようとしている動作についてDiscordで質問してください。

アバターでレイキャストを無効にする

Neosには、アバターに影響を与える可能性のあるツール、ガジェット、アイテムがたくさんあります。 ノックバックガン、爆発、ガン、体重計を台無しにするツールなどは非常に一般的です。 一般的なこれに対する解決策は、ユーザーがアバターがレイキャストに応答する機能を無効にすることです。 これは原則として機能しますが、ゲームエクスペリエンスや標準のNeosコンポーネントまたはシステムが機能しなくなる可能性があります。 これにより、Neos全体のエクスペリエンスの質が低下する可能性があります。 それはまた実際にはより大きな問題を隠しており、これは文化とガイドラインに関連しています。

あなたの同意なしにセッションであなたやあなたのアバターを編集したり、いじったり、影響を与えたりすることは、ガイドラインに違反します。 これを行うユーザーは、自分が行っていることが間違っていることに気付いていない可能性があるため、同意の重要性とガイドラインについて時間をかけて通知してください。 動作が続く場合は、セッションモデレートを利用するか、繰り返しまたは特に悪意のある場合は、モデレーションチケットを作成してください。

コンポーネント

自動で無効化されたコンポーネントを強制的に有効にする

時折、コンポーネントを使用しているときに、そのコンポーネントが自動的に無効になることがあります。これは通常、コンポーネントの設定や追加されたスロットに何か問題があり、コンポーネントが機能しなくなっていることを意味します。

  • このような場合、有効なチェックボックス/フィールドをtrueにしないでください。
  • Issue Trackerでのバグ報告をご検討ください。このような状況は、解決できる問題かもしれません。
  • 時には、これらはコンポーネントの間違った使用法であり、修正できない場合があります。
  • コンポーネント内の _ で始まるプロパティは、いつでも変更または削除される可能性があるため、可能な限り回避する必要があります。

リファレンスID / "Ref Hacking"

Neosで構築する際に、Neos内に存在する特定の制限や機能のギャップを回避するために、リファレンスIDを使用することが望ましい場合があります。その際には、以下の点に注意してください。

  • リファレンスIDはいつでも変更される可能性があります。
  • あなたの仕様はいつでも壊れるかもしれません。
    • もし何かお気づきの点があれば、セキュリティポリシーに従ってください。
  • Referencesの使い方によっては、嫌がらせのためにreferences/ref hackingを使うなど、ガイドラインに反する行為を許してしまう可能性があります。
    • 懸念事項がある場合、またはRef Hackingの有無にかかわらず、ガイドラインに違反しているユーザに気づいた場合 チケットで報告ください。
    • Ref Hacking自体はガイドラインに反していません。

一般的には、以下のような専用のノードやコンセプトを使用するべきです。

  • ユーザーノードを割り当てる
  • 型付きの参照とキャスト

もし、特定のreference IDやパスを使用する必要がある場合は、Issue Trackerで機能リクエストを行ってください。

Componentの順番に依存する

コンポーネントには、インスペクタに表示され、Neos によって処理される固有の順序があります。しかし、内部的には順不同のコレクションに格納されているため、この順序は非決定的であると考えるべきです。 この順序を変更する方法はありますが、既存のオブジェクトがその順序を永久に維持することは保証されていません。したがって、Componentの順序に依存する作成は、いつ壊れてもおかしくありません。

An example of this is utilizing multiple button actions on the same button event that depend on being processed in a specific order.

Instead:

  • Use LogiX impulses. LogiX is designed to be used for complex behaviors and program logic while components are generally intended for simple tasks. You can always depend on the order of operations in an impulse chain.

LogiX

複雑なデータ型でのToStringノードの使用

非プリミティブデータ型(例:float, int, doubleなどでないもの)でToStringノードを使用する場合は、ノードの出力に依存しないでください。 いつでも変更または更新される可能性があります。 これには、データ型、ユーザー、スロット、IField、Sync、SyncRefなどが含まれます。

これらの項目の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を使って行うことができる簡単なアクションを置き換えることができます。
  • ボタンが押されているかどうかに基づいてボタンの色をドライブするなど、ボタンの押下状態に関連する可能性のあるいくつかの効果にIsPressedブール値を使用することは「合理的」です。

ツールチップ

RawDataTooltipコンポーネントを追加することで、グラブ可能なアイテムを装備可能にすることができます。 これにより、ユーザーは、標準のNeosツールチップと同様に、コントローラーボタンの押下に基づいてアクションを実行するようにプログラムできるカスタムツールチップ、武器、およびガジェットを作成できます。

避けるべきこと:

  • 例えばLogiXインパルスを起動するために、Fire OnTrueでRawDataTooltipコンポーネントのプライマリまたはセカンダリブールフィールドを使用すること。

代わりに:

  • この目的には専用ノードRawDataTooltip Eventsを使用してください。 これはより効率的であり、RawDataTooltipが装備されているときにさまざまなことが起こったときにインパルスを発生させることができます。
  • ユーザーがユーザーがコントローラーボタンを押しているかどうかに基づいて装備アイテムの色を駆動するなどに関連する可能性のあるいくつかの効果にプライマリーやセカンダリーブールフィールドを使用することは「合理的」です 。

複数のノードを同じスロットに結合する

LogiXの最適化を検討している場合、LogiXのセットが占めるスロットの数が心配になる可能性があり、ノードを1つのスロットにまとめることでこれを改善しようとします。 これには通常プラグインが必要であり、「モノパッキング」と呼ばれます。

これによりLogiXのスロット数は削減されますが、「モノパック」のLogiXの編集、読み取り、および理解が困難になります。 さらに、Neosが将来的に最適化することをLogiXがより困難にします。

その代わり:

  • LogiXFunctionsなどのLogiXの追加の最適化と拡張機能を待つ。
  • 他の最適化手法とソースを調べることを検討する。最適化ガイドライン
  • シームレスな開梱/開梱を可能にする可能性のあるネイティブな同等物の実装を待つ
  • オブジェクトのスロット数は、必ずしもパフォーマンスを決定するわけではないことに注意してください。 パフォーマンスはさまざまなソースからもたらされ、スロット数は1つにすぎません。

インスペクター

インスペクタにあるテキストに依存する/使用する

インスペクタの中には、「Ref Editor」コンポーネントのように、有用な情報を見つけることができる場合があります。これには以下のようなものがあります(ただし、これらに限定されません):

  • インスペクター UI コンポーネントのプロパティで、文字列比較、フィルタリング、検索を実行する。

テキストに頼ると壊れやすいので、壊れる可能性があります。Neos のインスペクタは、コレクション、ハードパーミッション、UI アップデート、コンポーネントアクセスなど、多くの機能のために、深刻な量の再作成が予定されています。これらの変更により、インスペクタウィンドウに表示されるテキストが変更される可能性があります。そのため、アップデートでこれらのテキストが同じであることを保証することできません。

代わりに:

  • コンポーネントアクセスなどの機能により、文字列のマッチングではなく、これらのフィールドを直接使用できるようになるのを待つ。

グラフィック

マテリアルの "重ね"について

Neosでビジュアルエフェクトを作成する際、メッシュレンダラーに複数のマテリアルスロットを追加して、マテリアルを重ねることができます。これは素晴らしい視覚効果をもたらしますが、後で壊れる可能性があります。可能な限り、これは避けてください。

代わりに:

  • 同じ場所にそれぞれ異なるマテリアルで複数のメッシュレンダラーを作成します。 これは同じ効果につながります。
  • Neosで利用できるさまざまなマテリアルを試してみてください。
  • 追加してほしい効果については、将来の実装リクエストを開くことを検討してください。

ノート:

  • これは、アバターのように複数のマテリアルスロットを持つメッシュには影響しません。これは、同じマテリアルスロットを複数回使用することを指します。
  • この詳細については、このGitHub Issueを参照してください。

シェーダーのNeos DB URLの切り替え

StaticShaderアセットのURLを、視覚的な影響の程度が異なる他のStaticShaderアセットのURLと交換できることに気付いたかもしれません。 これは後日壊れます、特にカスタムシェーダーが今後のグラフィックエンジンで対応する場合は特にそうです。コンテンツを制作するときは、視覚効果のためにこれに頼るべきではありません。

アセット

7zbson/json/bsonの使用

Neosのアイテム、アバター、ガジェット、そしてワールドは、通常JSON、Binary JSON、またはそれらを圧縮した形の様々なファイルに格納されていることがあります。これらのファイルにアクセスするためのいくつかの方法があり、これらのファイルを使ってNeosのアイテムやアセットのインポート、編集、保存、バックアップなどを行うことができます。

これは便利で望ましい使用方法に思えるかもしれませんが、残念ながらいくつかの理由で「いつでも壊れる可能性がある」のです:

  • Neosがこれらのアセットのフォーマットや構造を変更する可能性があります。
  • Neosがこれらのファイル内のコンポーネントを導入/削除し、非互換性を引き起こす可能性があります。
  • これらのファイルは、しばしば他のファイルを参照または相互リンクしており、これらのファイルが削除または変更されると、非互換性の可能性がさらに高まります。

従って、この方法を使用することは推奨されません。また、サポートされている機能ではありません。

これらのファイルを持っていて、新しいバージョンのNeosでインポートできない場合、古いバージョンのNeosは引き続き動作します。ファイルが変更された日以前にリリースされたNeosのバージョンを使用してみてください。

キーボードコンポーネント/ノードを使用してアイテムをスポーンする

複数のキーボード関連コンポーネントを組み合わせることにより、Neosのクラウドからアイテムスポーンをトリガーすることができます。 これは通常、Neosアイテムやアセットを指定するURLを使用します。 これを行うことは良い経験を提供することができますが、それは長期的にサポートされるものではありません。 この機能は、後日機能しなくなるか、機能しなくなる可能性があります。

この機能は現在一般的に"クラウドスポーン"として知られていますが、そうではありません。 クラウドスポーンは実際にはNeosが将来サポートする予定の機能です。

「クラウドスポーン」にこの方法を使用する代わりに、LogiXでネイティブにこれを行う機能に投票してください。

インベントリ

長い/複雑なフォルダ名

インベントリ内にフォルダを作成する際、非常に長いフォルダ名やアスキーアートを含む名前を使用したくなるかもしれません。これは、すべてのプラットフォームで同じように表示されない可能性があり、一部の地域ではナビゲーションや技術的な問題が発生するため、お勧めできません。また、将来的にインベントリ管理/検索機能が追加された場合、インベントリの検索やインデックス作成に問題が生じる可能性があります。

ただし、絵文字といくつかのRTFフォーマットタグ(色の変更など)は問題ありません。 それらを使いすぎないでください。

Systems

Custom "Blocking" Systems

Neos currently does not have a User Blocking feature. This is a very high priority item for the team, which you can on GitHub.

While this lack of feature remains in Neos, some users have discovered ways to created Custom Blocking Systems inside Neos. These systems usually:

  • Disable the User slot of "Blocked" users.
  • Disable parts of "Blocked" users.
  • Use other items, that are on this page to modify users etc.

While these systems provide safety and security for those who wish to block users, we do not recommend them and therefore they're on this page.

Such systems can cause the following issues:

  • Session Crashes
  • Neos Crashes
  • Unsynchronized Sessions - Objects and values being out of sync or different for different users.
  • Data Loss - Items/Worlds that are being created are at risk of being lost.

We understand that this is a problematic topic, but encourage everyone to follow our existing tooling in order to attempt to resolve the issues that might lead to blocking:

  • Using standard session moderation features - Muting, Kicking, Banning
  • Removing the user as a Neos Contact.
  • Speaking to the session host to ask them to use session moderation features
  • Creating a ticket on our Moderation Portal

You can read more about moderation on our dedicated Moderation page.