Things to Avoid

From Neos Wiki
Jump to navigation Jump to search
Translate this page
Other languages:
Deutsch • ‎English • ‎日本語 • ‎한국어

Summary

Neos is a fantastic engine with a whole lot of power, options and capabilities. Some methods or practices can however be problematic or may lead to breakages at a later date. This is a general list of things to avoid or not do and the reasons behind them and some solutions or work arounds to assist you. Feel free to continue using these features.

Items on this page are NOT against the Guidelines.

Wherever possible, it is recommended to avoid using these items though.

This list is also, not meant to call out anyone or have any bad intentions etc. but is worth a read to understand where you might be able to improve your creations and to ensure that Neos updates or other users do not unintentionally end up in breaking things.

If something feels hacky or undesirable please ask the community or the team if its a good idea or not. If there are problems or gaps within Neos that you'd like to see resolved please open an issue on our Issue Tracker.

Working around unsupported or not yet implemented features

Certain features that are yet to be implemented officially can be "hacked in" or achieved through modifying certain internal systems and properties. While we're ok with experimenting and toying around, please be aware that those approaches will very likely break, without guaranteed prior warning and official implementation in place.

This can leave you with broken content without ability to fix it until a much later point in the future, so we recommend avoiding such approaches in the first place and instead finding different method using already supported features.

You can find list of planned features on our official GitHub: https://github.com/Neos-Metaverse/NeosPublic/issues and vote on them so we prioritize them sooner. For any official features we always put a great care into ensuring long term content compatibility over implementing them quicker, to ensure that future Neos updates will keep your content functional.

If we close certain issue as something that we don't plan on implementing, we strongly advise against using hacks and workarounds to achieve that result completely, as those will be brittle and will break without replacement coming at all. In such cases you'll have to find a different approach that works with the design of the system to ensure long term compatibility.

Slots

Avoid relying on Slot names or structure for items and slots that you don’t own or control within your LogiX or components. The names of slots and their structure for items you don’t own or control may change at any time and this can break things you’ve made.

Here are some examples of where this may occur and some alternatives or suggestions to attempt to mitigate the issues

Names or structure of a user Root

Items may be added or removed from the User Root with the addition of new features or updates to features. So try not to rely on this structure or naming conventions that these slots have. Additionally, do not rely on the ordering of these slots as they may change at any time.

Recently for example new Slots were added to a User root to cover the new "Freeform Camera".

Things to avoid in this area:

  • Find Child By Name
  • Repeated use of Get Parent / Get Child nodes to locate a slot using searching or understood hierarchy depths

Solutions for this area:

Names or structure of an Avatar

Avatars are very complex creations.

Avoid:

  • Find Child By Name to locate avatar parts
  • Repeated use of Get Parent / Get Child nodes to locate avatar parts
  • Assuming the structure of an avatar
    • For example, head and hands avatars don't have an "Avatar Root"

Solutions in this area:

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 Issue Tracker.

Names or structures of other people’s worlds

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.

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.

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.

Slot obfuscation / "Encryption"

Once you've made something in Neos you may want to protect it. When doing this don't:

  • Rename Slots, LogiX Nodes etc.
  • Move, scale, rotate slots
  • Apply LogiX to your creation which does any of the above.

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.

Instead:

  • For Avatars: utilize Avatar protection systems such a 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

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:

Avatars

Disabling key Avatar Components

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.

Disabling Raycasts on your Avatar

Neos has 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 Neos components or systems to not function. This can reduce your quality of experience across Neos. It is also actually hiding a larger problem and this is culture and guidelines related.

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.

Components

Forcing auto-disabled Components to be enabled

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 Issue Tracker. 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.

Reference IDs / "Ref Hacking"

When building in Neos, it may be desirable to use reference ids to get around certain restrictions or feature gaps that exist within Neos. 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 behaviour that is against our Guidelines such as using references/ref hacking for harassment.

Generally, you should use dedicated nodes and concepts instead such as:

  • The Allocating User Node
  • Typed References and Casts

If you find yourself continually needing to use a certain reference id or path consider making a feature request on our Issue Tracker.

Depending on the order of Components

Components have an inherent order in which they appear in the inspector and are processed by Neos. 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.

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

Using the ToString Node on complex data types

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.

Comparing strings for these items is brittle and may change with Neos Updates.

Instead:

If you find yourself continually needing to do this, consider making a feature request on our Issue Tracker.

Using Fire On True etc. when there are better alternatives

Several nodes in the Flow category can fire impulses when specific values change, e.g. Fire On True, Fire On False, 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.

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.

Buttons

Often users want to make something happen, for example changing a value or causing some LogiX to trigger, when a button is pressed.

Avoid:

  • Using e.g. the IsPressed bool field on the various button components and to providing that as the input to Fire On True in order to fire LogiX impulses.

Instead:

  • Use the dedicated node for this purpose, 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 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 LogiX.
  • It is reasonable to use the IsPressed 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.

Tooltips

Grabbable items can be made equippable by adding the RawDataTooltip component. This allows users to make custom tooltips, weapons, and gadgets which can be programmed to perform actions based on controller button presses much like the standard Neos tooltips.

Avoid:

  • Using e.g. the Primary or Secondary bool fields on the RawDataTooltip component with Fire On True in order to fire LogiX impulses.

Instead:

  • Use the dedicated node for this purpose, RawDataTooltip Events. This is more efficient and impulses can be fired when various different things happen when a RawDataTooltip is equipped.
  • It is reasonable to use the Primary and Secondary 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.

Combining multiple nodes into the same slot

When looking to optimize LogiX, you might be worried about how many slots a set of LogiX takes up and look to improve this by collapsing the nodes down into one slot. This usually needs a plugin and is referred to as "Mono-Packing".

While this does cut down on the slot count of LogiX, it makes the "mono-packed" LogiX difficult to edit, read and understand. Additionally, it makes the LogiX more difficult for Neos to optimize for you in the future.

Instead:

  • Wait for additional Optimizations and enhancements to LogiX such as LogiX Functions.
  • 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.

Inspectors

Relying on/using the text found in inspectors

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

Relying on the text is fragile and may break. Inspectors within Neos 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.

Instead:

  • Wait for features such as component access which will allow you to use these fields directly rather than via string matching.

Graphics

Material "Stacking"

When creating visual effects in Neos 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.

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 in Neos.
  • Consider opening a Feature Request for the effect you're looking at.

Notes:

  • This does not affect meshes with multiple material slots. For example Avatars. It just refers to using the same material slot used multiple times.
  • For more information on this see this GitHub Issue.

Switching Neos DB URLs for Shaders

You may have noticed that you can swap URLs on 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.

Assets

Using .7zbson/json/bson

Within Neos 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 Neos Items and Assets.

While this may seem handy and desirable to use, it unfortunately may break at any time for a number of reasons:

  • Neos' format or structure for these assets may change.
  • Neos may introduce/remove components within these files causing incompatibility.
  • These files often refer or cross-link to other files which may be removed or changed further increasing the chance of incompatibility.

It is therefore not recommended to use this approach. It is not a supported feature.

If you have one of these files and it is not able to be imported in a newer version of Neos, older versions of Neos will continue to work, so try using a version of Neos released before the date the file was modified.

Using Keyboard Components/Nodes to spawn items

By combining multiple Keyboard related components it is possible to trigger the spawning of an item from Neos' cloud. This usually uses a URL which points to a Neos 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.

This functionality is commonly known as "Cloud Spawning" right now but it isn't. Cloud Spawning is actually a feature that Neos plans to support in the future

Instead of using this method for "Cloud Spawning", please continue to vote on the ability to do this natively with LogiX.

Inventory

Long/Complex folder names

When creating folders within your inventory, you may be tempted to use very long folder names or names which contain 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.

Emojis and a few RTF Formatting tags(such as changing the color) are ok though. Just do not overuse them.

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.

Retrieved from "https://wiki.neosvr.com/index.php?title=Things_to_Avoid/en&oldid=65319"