Export translations

Settings

Group

Language

Format

Export for off-line translation

Export in native format

Export in CSV format

{{DISPLAYTITLE:避けるべきこと}}<languages />

=  概要  =

Resoniteは、多くのパワー、オプション、機能を備えた素晴らしいエンジンです。しかし、いくつかの方法やプラクティスは、問題があったり、後日破損につながる可能性があります。これは、避けるべきこと、してはいけないこと、それらの背後にある理由、およびいくつかの解決策や回避策の一般的なリストです。これらの機能を (訳註: 問題点を把握した上で) 自由に使い続けてください。

<p style="font-size:2em;">'''このページで紹介されている内容は [[Special:MyLanguage/Guidelines | ガイドライン]] に違反するものではありません'''。</p>

ただし、以下に記される実装は可能な限り避けることが推奨されています。

このページは、誰かを非難したり、悪意を煽るためのものではなく、皆さんが作ったもののうち改善しうる場所を理解し、Resoniteのアップデートや他のユーザーの過失で何かが壊れてしまわないようにするためのものとして読む価値があるものです。

何かについてハックじみている、または望ましくないと感じた場合は、コミュニティまたはチームに、これは本当に良いアイデアなのかかどうかを尋ねてください。解決してほしい問題やギャップがある場合は、[https://github.com/Yellow-Dog-Man/Resonite-Issues/issues GitHub] でIssueを作成してください。

=  サポートされていない機能の利用、または未実装機能の再現  =

まだ公式に実装されていない特定の機能は、「ハック」や、特定の内部システムやプロパティを変更することによって実現できることがあります。実験したりいじったりするのは構いませんが、このようなアプローチは「事前の警告と正式な実装が保証されていない限り」、非常に壊れやすいということをよく認識しておいてください。

これにより、将来のかなり後の時点まで修正できない壊れたコンテンツが残る可能性があるため、可能な限り最初からこのようなアプローチを避け、代わりに既にサポートされている機能を使用して別の方法を見つけることをお勧めします。

予定されている機能のリストは、 [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues GitHub] で確認できます。優先順位を早められるように、投票してください。公式機能については、今後の更新でコンテンツの機能を維持するために、迅速な実装よりも長期的なコンテンツの互換性を確保することに常に細心の注意を払っています。

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

=  バグを利用した動作  =

意図した機能ではない、正しくないと思われる動作を発見した場合は、できるだけ早く報告し、バグのあるシステムの動作に依存しないことを強く推奨します。

バグ報告やシステム再設計のいずれかによってバグが修正される際、バグの挙動を再現してコンテンツを保持することが合理的な理由で不可能になる可能性があります。つまり、技術的にはそのコンテンツが（訳註: バグが修正されたことで）"破損" します。

バグ自体も信頼性が低く、特定の条件下でのみ発生する可能性があります。そのため、バグの挙動に依存するものは、コードを変更しなくても壊れやすくなります。

=  スロット(Slot)  =
ProtoFluxまたはコンポーネント内で '''「所有または制御下にない」''' アイテムおよびスロットのスロット名またはスロット構造に依存しないでください。所有または管理していないアイテムのスロット名とその構造は '''予告なく変更される可能性がある''' ため、作成したコンテンツが壊れる可能性があります。

以下は、このような問題が発生する可能性がある例、そして、その問題を軽減するための代替策、代替案になります。

==  ユーザー直下 (UserRoot) の名前や構造に関するもの  ==

新機能の追加や機能の更新に伴って、User Root以下のSlotは追加または削除されることがあります。User Root直下のスロットの構造や命名規則に依存しないようにしてください。加えて、User Root直下のスロットはいつでも変更される可能性があるため、Slotが並ぶ順番にも依存しないでください。

たとえば最近、新しいスロットとして"Freeform Camera"をカバーするための新しいスロットがユーザ直下に追加されました。

この領域の実装において避けるべきこと
* Find Child By Name ノードの使用
* Get Parent・Get Child を多用して特定のSlotを探したり、どのSlotからどれくらい深いところにいるかを計算すること

この領域における解決策
* ユーザーのSlotの取得のためには[[:Category:ProtoFlux:Users:UserRoot|User Root Nodes]]を使う
* [[:Category:ProtoFlux:Users|User Nodes]]を利用する

==  アバターのSlot名や構造に関するもの  ==

アバターは非常に複雑なつくりをしています。

避けるべきこと
* アバターの特定の部分の取得のために Find Child By Name を使用すること
* Get Parent・Get Childの繰り返しでアバターの特定の部位を取得すること
* アバターの構造はこうなっているだろうと決め打ちすること
** 例えば、3点アバター（訳注: 頭と手のみのアバター。NeoRoidなど）は「Avatar Root」を持ちません。

すべきこと
* [[:Category:ProtoFlux:Avatar|Avatar Nodes]] を使う。

<div lang="en" dir="ltr" class="mw-content-ltr">
If you’d like to routinely find or acquire a slot in the User Root, consider requesting a new node or feature for it on our [https://github.com/Yellow-Dog-Man/Resonite-Issues Github] if it doesn't exist.
</div>

==  <span lang="en" dir="ltr" class="mw-content-ltr">Names or structures of other people’s worlds</span>  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
When visiting other user’s worlds it is very important to remember that you are a guest in their space. When creating gadgets, tools and avatars you should try to be respectful of their world.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Things to avoid:
* Placing items in the root from Guns/Rockets and other items.
* Assuming the setup of the world is standard in terms of hierarchy for things like spawn or lights etc.
* Custom Culling systems or locomotion modules
* Avoid Calling [[Dynamic Impulses]] to the Root Slot
* Avoid placing [[Dynamic Variables]] in the Root Slot or World Variable Space
* Avoid leaving items in the world when you leave. Clean up after yourself.
** Temporary items from Guns/Rockets & Particles should clean up after themselves. Consider marking them as non-persistent or setting them to delete themselves when you leave.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Solutions:
* When using the Set Parent node with a Root Slot Parent, Instead Supply a “Local User Space” node this will function identically in most cases but will keep items parented correctly to any world management systems rather than littering the root.
* Ask the world owner before spawning complex gadgets or modifying the world root.
</div>

==  スロットに関して伏せる / "暗号化(Encryption)"する  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Once you've made something you may want to protect it. When doing this don't:
* Rename Slots, Nodes etc.
* Move, scale, rotate slots
* Apply [[ProtoFlux]] to your creation which does any of the above.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
While, this may seem like a way to protect your creation it doesn't do much for a knowledgeable user who has Builder permissions. Regardless of your methodology any in-app obfuscation is relatively easy to break in this manner.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
* For Avatars: utilize Avatar protection systems such as [[Component:SimpleAvatarProtection|Simple Avatar Protection]]
* Avoid setting users as Builder in a world you want protected
* Avoid spawning items in sessions with users you do not know or trust
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We also have several items on our roadmap to aid in this area, we'd encourage you to follow their progress and to vote on them:
* Hard Permissions ([https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1103 #1103]) - Protects assets, items and ProtoFlux within a World.
* Object ID / Licenses ([https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/626 #626]) - Protects assets, avatars, items, worlds etc. from being saved.
</div>

=  アバター  =

==  主要なアバターコンポーネントを無効化する  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Avatars are very complex things, please don't disable any of the key components that avatars need to function. If you find yourself doing this too often please open a GitHub issue or ask a question on our discord about the behaviour you are trying to achieve.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Disabling Raycasts on your Avatar == 
We have a lot of tools, gadgets and items which may affect your avatar. Things like Knockback guns, explosions, guns, tools that mess with your scale etc. are quite common. A solution to this which is common is for users to disable the ability for their avatar to respond to ray casts. While this works in principle it can cause game experiences and standard components or systems to not function. This can reduce your quality of experience across Resonite. It is also actually hiding a larger problem and this is culture and guidelines related.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Editing, messing with, and affecting you or your avatar in a session without your consent is against the [[Guidelines]]. Users doing this might not be aware that what they are doing is wrong so please take the time to inform them about the importance of consent and our [[Guidelines]]. Should the behavior continue please utilize session moderation or if it repeated or particularly malicious please make a [[Moderation]] ticket.
</div>

=  コンポーネント  =
==  自動で無効化されるべき状態のコンポーネントを強制的に有効化する  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Occasionally when using a component you may find that it disables itself. This usually means that something in the component setup or the slot that it was added to is problematic and would cause the component to fail to function. 
* Do not drive the enabled checkbox/field to true in these cases
* Consider reporting a bug on our [https://github.com/Yellow-Dog-Man/Resonite-Issues Github]. These situations may be a problem that can be resolved.
* Sometimes, these are actual miss-use of a component and may not be fixed. 
* Properties within components that start with _ may be changed or removed at anytime and should be avoided where possible.
</div>

==  リファレンスID / "Ref Hacking(レフハッキング)"  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
When building, it may be desirable to use [[Type:RefID|Reference IDs]] to get around certain restrictions or feature gaps that exist. This is often called [[Ref_Hacking|Reference hacking (Ref Hacking)]]. When doing this, keep the following in mind:
* Reference IDs may change at any time.
* Your use of them may break at any time.
* Certain uses of References may be considered a security issue.
** If you notice something concerning please follow our [[Security]] Policy.
* Some uses of References may allow for behavior that is against our [[Guidelines]] such as using references/ref hacking for harassment.
** If you have a concern, or notice a '''user breaking the [[Guidelines]]''' with or without Ref Hacking [https://moderation.resonite.com please submit a ticket].
** Ref hacking by itself is NOT against the [[Guidelines]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Generally, you should use dedicated nodes and concepts instead such as:
* The [[ProtoFlux:Allocating User|Allocating User]] Node
* [[Reference_Type|Typed References]] and [[:Category:ProtoFlux:Core:Casts|Casts]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you find yourself continually needing to use a certain reference ID or path consider making a feature request on our [https://github.com/Yellow-Dog-Man/Resonite-Issues Github].
</div>

==  <span lang="en" dir="ltr" class="mw-content-ltr">Depending on the order of Components</span>  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Components have an inherent order in which they appear in the inspector and are processed by Resonite. However, this order should be considered non-deterministic as they are internally stored in an unordered collection. There are ways to modify that order, but it is not guaranteed that existing objects will indefinitely preserve that order. Therefore, creations that depend on the order of components may break at any time.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
An example of this is utilizing multiple button actions on the same button event that depend on being processed in a specific order.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
* Use ProtoFlux impulses. ProtoFlux 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.
</div>

=  ProtoFlux  =

==  <span lang="en" dir="ltr" class="mw-content-ltr">Using the ToString Node on complex data types</span>  ==
<div lang="en" dir="ltr" class="mw-content-ltr">
When using the ToString node on non-primitive data types(e.g. '''NOT''' float, int, double etc.), do not rely on the output of the node. It may change or be updated at any time. This includes things such as Data Types, Users, Slots, IFields, Sync, SyncRef etc.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Comparing strings for these items is brittle and may change with Updates.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
* For Users, use [[:Category:ProtoFlux:Users:UserRoot|User Root Nodes]]
* For Slots, use [[:Category:ProtoFlux:Slots|Slots]].
* For Types, use the Type nodes.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you find yourself continually needing to do this, consider making a feature request on our [https://github.com/Yellow-Dog-Man/Resonite-Issues Github].
</div>

==  <span lang="en" dir="ltr" class="mw-content-ltr">Using Fire On True etc. when there are better alternatives</span>  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Several nodes in the [[:Category:ProtoFlux:Flow|Flow]] category can fire impulses when specific values change, e.g. [[Fire On True (ProtoFlux)|Fire On True]], [[Fire On False (ProtoFlux)|Fire On False]], [[Fire While True (ProtoFlux)|Fire While True]] etc. These can be very powerful and are fine to use where they're the best solution for a specific use case. However, there are a few common situations where they may seem like a good option, but there are actually much better and more efficient alternatives.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
In cases where e.g. Fire On True is appropriate, it is also advisable to provide a user value to the UpdatingUser input on these nodes rather than leaving it empty.
</div>

===  ボタン  ===

<div lang="en" dir="ltr" class="mw-content-ltr">
Often users want to make something happen, for example changing a value or causing some ProtoFlux to trigger, when a button is pressed.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Avoid:
*Using the IsPressed bool field on the various button components and to providing that as the input to Fire On True in order to fire ProtoFlux impulses.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
*Use the dedicated node for this purpose, [[Button Events (ProtoFlux)|Button Events]]. This is more efficient and impulses can be fired when various different things happen with the given button (Pressed, Pressing, Released etc.). 
**ProbablePrime has produced a short tutorial on how to use this node [https://www.youtube.com/watch?v=5xplINNXGco here].
*If you only want to perform a simple action based on a button press, such as changing a value, consider the components in the Common UI > Button Interactions category. These can often replace simple actions you might otherwise perform with ProtoFlux.
**ProbablePrime has tutorials for several of these components - [https://www.youtube.com/watch?v=CuoqMWl9m9o ButtonValueCycle], [https://www.youtube.com/watch?v=EamDQP9DAfs ButtonValueShift], [https://www.youtube.com/watch?v=yXD3EKqKoWg ButtonValueSet], [https://www.youtube.com/watch?v=ufFli5Zn884 ButtonToggle].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* It ''is'' reasonable to use the IsPressed [[Types:Bool|bool]] for some effects which may be related to the button press state, such as driving the color of the button based on whether it is pressed or not.
</div>

===  ツール  === 
<div lang="en" dir="ltr" class="mw-content-ltr">
Grabbable items can be made equippable by adding the [[RawDataTool (Component)|Raw Data Tool]] component. This allows users to make custom tools, weapons, and gadgets which can be programmed to perform actions based on controller button presses much like the standard tools.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Avoid:
*Using e.g. the Primary or Secondary [[Types:Bool|bool]] fields on the [[RawDataTool (Component)|Raw Data Tool]] component with Fire On True in order to fire ProtoFlux impulses.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
*Use the dedicated node for this purpose, [[ProtoFlux:RawDataTool_Events|RawDataTool Events]]. This is more efficient and impulses can be fired when various different things happen when a [[RawDataTool (Component)|Raw Data Tool]] is equipped.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* It ''is'' reasonable to use the Primary and Secondary [[Types:Bool|bool]] fields for some effects which may be related to when a user presses a controller button, such as driving the color of the equipped item based on whether the user is pressing primary fire.
</div>

==  <span lang="en" dir="ltr" class="mw-content-ltr">Combining multiple nodes into the same slot</span>  == 
<div lang="en" dir="ltr" class="mw-content-ltr">
'''We do not recommend doing this for any reason.'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When looking to optimize ProtoFlux, you might be worried about how many slots a set of ProtoFlux takes up and look to improve this by collapsing the nodes down into one slot. This usually needs a [[Plugins|plugin]] and is referred to as "Mono-Packing".
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
While this does cut down on the slot count of ProtoFlux, it makes the "mono-packed" ProtoFlux difficult to edit, read and understand. Additionally, it makes the ProtoFlux more difficult or not possible for Resonite to optimize for you in the future.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
* Wait for additional optimizations and enhancements to ProtoFlux such as Nested Nodes
* Consider looking into other optimization techniques and sources such as the [[Optimization Guidelines]].
* Wait for a native equivalent which may allow for seamless unpacking/packing
* Remember that the slot count of an object does not necessarily dictate how performant it is. Performance comes from a variety of sources and Slot count is just one.
</div>

= インスペクター =

== <span lang="en" dir="ltr" class="mw-content-ltr">Relying on/using the text found in inspectors</span> ==

<div lang="en" dir="ltr" class="mw-content-ltr">
Sometimes within inspectors, you might find some useful information, such as in the "Ref Editor" component's inspector. Including(but not limited to):
* Running string comparisons/filtering/searching on Inspector UI component properties
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Relying on the text is fragile and may break. Inspectors are due for serious amounts of re-working due to a number of features such as collections, hard permissions, The UI Update, component access etc. These changes may change the text that is shown in the inspector windows. So relying on the text here to remain the same across these updates is not recommended.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
* Wait for features such as component access which will allow you to use these fields directly rather than via string matching.
</div>

=  描画処理（グラフィック）  =

==  マテリアルの重ね掛け "スタッキング"  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
When creating visual effects you can add multiple material slots to a Mesh Renderer to stack materials on-top of each other. This can have a great visual effect but '''it may break at a later date'''. Wherever possible, '''you should avoid doing this'''.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Instead:
* Create multiple Mesh Renderers in the same location each with a different material. This will lead to the same effect.
* Try experimenting with different material types available to you.
* Consider opening a [https://github.com/Yellow-Dog-Man/Resonite-Issues feature request] for the effect you're looking at.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* This does not affect meshes with multiple material slots. For example Avatars. It just refers to using the same material slot used multiple times.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
According to [[User:Geenz|Geenz]] during multiple office hours, [[Sauce]] release will probably break Material stacking. Alternative have also been disused to be implemented to Sauce (sometime ''after'' its initial release, as initial release will be parity of supported feature only), like Material Layering<ref>https://drive.google.com/file/d/1uCbzXDT_PXv_PgByuBAFcvVX1tTtSF53/view</ref>
</div>

==  シェーダーのURLを変更する  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
You may have noticed that you can swap URLs on [[Component:StaticShader|StaticShader]] assets with URLs from other StaticShader assets with varying degrees of visual impact.  '''This will break at a later date''', particularly when custom shaders land with our upcoming graphics engine replacement.  You should not rely on this for any sort of visual effect when producing your content.
</div>

=  アセット  =

==  .7zbson/json/bson を使用する  ==
<div lang="en" dir="ltr" class="mw-content-ltr">
Items, avatars, gadgets and even worlds are sometimes stored in a variety of files that are usually some form of JSON, Binary JSON or Compressed variants of them. There are a few methods available which allow you to gain access to these files in these forms and these files can then be used to import, edit, save, backup, etc. Items and Assets.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
While this may seem handy and desirable to use, it unfortunately '''may break at any time''' for a number of reasons:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* Our format or structure for these assets may change.

* These files often refer or cross-link to other files which may be removed or changed further increasing the chance of incompatibility.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''It is therefore not recommended to use this approach. It is not a supported feature.'''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you have one of these files and it is not able to be imported in a newer version of Resonite, older versions will continue to work, so try using a version of Resonite released before the date the file was modified.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
When wanting to share content made on Resonite, use the [[ResonitePackage]] format which is made for this use, and avoids some of the issues mentioned.
</div>

==  <span lang="en" dir="ltr" class="mw-content-ltr">Using Keyboard Components/Nodes to spawn items</span>  ==

<div lang="en" dir="ltr" class="mw-content-ltr">
By combining multiple Keyboard related components it is possible to trigger the spawning of an item from the cloud. This usually uses a URL which points to an Item or asset. While doing this can provide a good experience it is not something that is supported long term. This functionality may break or become non-functional at a later date.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''This functionality is commonly known as "Cloud Spawning" right now but it isn't'''. Cloud Spawning is actually a feature that Resonite plans to support in the future.
</div>

=  <span lang="en" dir="ltr" class="mw-content-ltr">Inventory</span>  =

==  <span lang="en" dir="ltr" class="mw-content-ltr">Long/Complex folder names</span>  ==
<div lang="en" dir="ltr" class="mw-content-ltr">
When creating folders within your inventory, you may be tempted to use very long folder names or names which contain [https://en.wikipedia.org/wiki/ASCII_art ASCII Art]. Doing this is not recommended as it may not display the same on all platforms and will cause navigational and technical issues in some areas. Additionally when inventory management/searching is added in the future it may cause issues with searching or indexing your inventory.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Emojis and a few RTF Formatting tags(such as changing the color) are ok though. Just do not overuse them.
</div>

==  <span lang="en" dir="ltr" class="mw-content-ltr">Sources</span>  ==
<references />