Summary
“No Class” is, in programmatic terms, treated as an actual class. This creates significant issues for the functionality and interoperability of devices, limiting creative possibilities. Similar to how gold was once included in building resources in earlier builds, this is an outdated remnant of Creative 1.0 and should be addressed. I will further outline the argument for this in the additional notes.
Please select what you are reporting on:
Creative
What Type of Bug are you experiencing?
Devices
Steps to Reproduce
Step 1: Create 3 Class and Team Selector Devices.
Step 2: Set the first to No Class, Second to Class 1, and Third to Class 2.
Step 3: Create 3 Map Indicator Devices.
Step 4: Set Assigned Class on the first Map Indicator to No Class.
Step 5: Set the assigned Class on the second Map Indicator to Class 1, and the third to Class 2 and then enable Invert Class on both devices.
Step 6: Enter the game and toggle each of the class selectors and observe the visible Map Indicators.
Expected Result
You would expect “No Class” to not see the second and third map indicators, as it implies “no class,” “not a class,” or “the absence of a class” by any reasonable interpretation of the term.
Observed Result
All three indicators appear at game start because “No Class” is actually treated as “Class 0” (or perhaps 255) and is included in the class inversion visibility set. This creates a significant obstacle for custom game design, as I will detail in additional notes.
Platform(s)
PC
Upload an image
Video
Additional Notes
Treating “No Class” as an additional class is problematic for several reasons:
Misleading Labeling: “No Class” is not truly absence of a class; it functions as Class 0 or another actual class, which is inaccurate and misleading.
Contradictory UI: The presence of both “No Class” and Class Selection on devices implies that “No Class” is a separate status, not a class.
Limited Functionality: We cannot use “No Class” as a distinct state to gate visibility or interaction in devices, restricting our creative flexibility and design capabilities.
I discovered a major scalability issue while designing a UAV-like minimap indicator for my map. The feature requires a minimap indicator for all players except the activating player. With the current implementation in UEFN, this necessitates 𝑛⋅(𝑛−1) devices, where
𝑛 is the number of players. This is because each player needs a unique device setup to exclude themselves while being visible to all others.
If “No Class” were treated as a true class state (as implied by the name, description, and UI of devices), this problem could be resolved. It would allow the use of class inversion to differentiate between a defined class and “No Class” as mutually exclusive states. In this scenario, I would only need 𝑛 devices, as “No Class” players would automatically fail the inversion check, making it a natural gating mechanism for visibility.
This approach is not only more accurate and intuitive to the definition but also expands creative possibilities for feature and game design.
If I were to address this in Verse, I would represent Class as an optional integer value. The default false state would map to the current “No Class” setup when necessary, while other cases would resolve to a specific class value for more flexible handling.