Dynamic Variable Naming Standard

---

Proposal by 3x1t_5tyl3 on the 19th of November 2020.

Technical Spec-sheet for the NeosVR Global World-color Standard

As people have realized putting another space directly on root is probably a bad idea. As such putting a new field underneath the users allows for higher flexibility. The examples have mentioned "Data" as a name for it which I tend to find proper.

Player A is now abbreviated as "P-A"

Player B - "P-B"

Examples:

Player A is at the bar. As such The hierarchy looks like:

└── Root
   └── Users
       ├── Lounge
       │   └── P-A
       ├── Bar
       │   └── P-B
       ├── Dance-Hall
       └── Outside

In this case "P-A" would be getting the Data off of "Lounge".

If "P-A" Would move under "Bar" it'd inherit the Data of the "Bar". As such it'd inherit the color that "Bar" implements.

└── Root
   └── Users
       ├── Lounge
       ├── Bar
       │   ├── P-A
       │   └── P-B
       ├── Dance-Hall
       └── Outside

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Fallback system (on avatar!) If the secondary doesn't exist

• fallback to primary
  • fallback to avatar's own color if primary doesn't exist either.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Defined-Color: Colors should only facilitate color.

Defined-Intensity: Intensity should only facilitate how *strong* that color is.

• As such the float value should not exceed 3 and not go below 0.

This makes the system more accessible to users who have some form of photo sensitivity. As the Values can be locally set to 0 for intensity to make sure people with photosensitivity can have a part in a world too.

With this in mind my proposal for the Naming would be: DynamicVariableSpace: Data

• Direct binding enabled.
• This is all that you should name it. For every Slot a user is under. With no dynamic spaces in between.

The Variables should follow a pattern as follows: The beginning marks the Use-case. -So for this case "World" says that the color comes from the world. The middle marks the Type. -Color for color, intensity for a float value that is a multiplier to color. The number (should only be 1 & 2) marks different colors. - Example would be primary and secondary colors. I *personally* don't see a reason for a tertiary number. -- Example: World main color is red and secondary is black. As such an avatar could contain itself in that way as well. -- Example2: World main color is dark green and secondary is white. Same as above just different. Allowing more customization with just one more input node. See "Fallback system" for info on fallback.

If secondary exists but not primary: -> Fallback to the avatar color. (Ignore world color) Secondary never exists alone. Use primary if only one color is given. Not secondary.

My suggestion for naming them:

• Data/WorldColor1
  • Data/WorldColor2
• Data/WorldIntensity1
  • Data/WorldIntensity2

So for implantation it'd look like:

WorldColor1 x WorldIntensity1 -> Apply to avatar for effect.

R: 1, G: 0, B: 0.2 x 1.5 --> R: 1.5, G: 0, B: 0.3

Example use case:

└── Root
   └── Users
       ├── Lounge (Set to Red, mid intensity)
       ├── Bar (Set to Blue high intensity)
       │   ├── P-A
       │   └── P-B
       ├── Dance-Hall (Changing color to the music with intensity as-well)
       └── Outside (Color set to a low creme with low intensity)

This means that the player has to be parented for this work in the way mentioned above.