Potential verse digest generator issue or an oversight in Scene Graph APIs

General Issues and Bug Reporting
, ,
1

Summary

Components such as light_component and its subclasses have several fields that are not explicitly marked as @editable, yet they are all exposed in the editor.
This is either an issue in the verse digest generator or the component fields are build on top of native solutions and the editable field exposure is an oversight in the Scene Graph APIs. There could be more components like this, I only noticed it on light_component.

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

# Set the visible light intensity emitted in SI unit Candela./nSpecified before ColorFilter (which multiplies each color component after the intensity calculation and can change the effective intensity of the light).
var Intensity<public>: float = external {}

Here’s one example from capsule_light_component. The variable is exposed in the editor but there’s no @editable attribute on it.

Expected Result

Editor exposed fields should contain @editable attribute.

:warning: Additionally the example comment uses an incorrect line break /n instead of \n.

Observed Result

Some fields are exposed in the editor while they have no @editable attribute in the digest APIs.

Platform(s)

UEFN

4

@Velocity_Zero This is an artifact of some internal implementation details but not actually a bug. Under the hood fields like Intensity are being backed by private fields that are marked @editable and then displayed with the expected user name (ie. Intensity). So only the things that are marked with @editable are being exposed, we just don’t display all the editable fields in the digest since some of them are private variables or other implementation details.

5

While I understand what you mean, shouldn’t the public APIs still be decorated with @editable regardless? If the the public field such Intensity is a computed field (get/set proxy) that reads and mutates the private stored @editable property, shouldn’t that information still bubble up to the end user to see? In case of the @editable effect at least, this wouldn’t hurt anyone.

7

Please do not hijack issue threads like this, instead create your own issue thread. Thank you.

8

sorry but I have a big problem with my map for 2 days I have no help from support on the forums etc. I saw an epic employee I thought he could help me

9

That‘s a wrong way to tackle your issues and with such behavior you risk not getting any help at all. You can either create your own new thread or try to reach in other ways to epic (e.g. DMs or discord). Please edit and remove your issue post from this topic.

10

FORT-883173 has been ‘Closed’. This is working as intended by design.

11

Yeah, totally get it. Just a limitation of the way digest generation works right now, not something that would be locked in time forever. Ultimately, @editable is really only a suggestion to the editor for how/if to display things but not a true limitation on any functionality. I would actually prefer in the future that all accessible properties could be shown, with @editable perhaps acting as an indication between what is shown in the main view vs. an expandable “advanced properties” section.

1 Like