Verse API Issue: SetMesh() for CreativeProp(BP) cannot use any Mesh other than those hard-coded in Verse.

General Issues and Bug Reporting
, , ,
1

Summary

As of UEFN version 36.00, the SetMesh() function provided by the Verse API for CreativeProp(BP) does not accept Meshes set via Editable variables as arguments. It only accepts Meshes that are hard-coded.

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Assets

Steps to Reproduce

  • Prepare a Verse device using the sample code in the second post of this thread
  • Create a Blueprint that inherits from CreativeProp
  • Place both the Verse device and the Blueprint in the level, and set the necessary Editable variables

Expected Result

Even when assigning a Mesh created in Modeling Mode or imported into the project to a Mesh-type Editable variable that is not hard-coded in Verse, the Mesh should correctly switch using SetMesh().

Observed Result

Meshes that are not hard-coded in Verse do not switch via SetMesh(), even when the Editable variable is changed to a different Mesh.

Platform(s)

Windows 11

Additional Notes

  • Meshes located in the Fortnite folder can be used when assigned through Editable variables, but custom-imported Meshes cannot be used.
  • As long as the Mesh is referenced in the Verse script, it can be used. So, as a temporary workaround, the Editable variable can be set to an Enum or Int instead of a Mesh, and the desired Mesh can be selected programmatically based on the that value.
2

Sample code:

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }
using { /Verse.org/Assets }

toggle_mesh_test_device := class(creative_device):

@editable
TargetCreativeProp : creative_prop = creative_prop{}

@editable
Mesh_A : mesh = # Please set static mesh
@editable
Mesh_B : mesh = # Please set static mesh

@editable
InputTrigger : input_trigger_device = input_trigger_device{}

var ToggleState : logic = false

OnBegin<override>()<suspends>:void=
    
    InputTrigger.PressedEvent.Subscribe(OnPressedEvent)

    return

OnPressedEvent(Agent : agent):void=

    if(not ToggleState?):
        TargetCreativeProp.SetMesh(Mesh_A)
        set ToggleState = true
        Print("Change to Mesh A")
    else if(ToggleState?):
        TargetCreativeProp.SetMesh(Mesh_B)
        set ToggleState = false
        Print("Change to Mesh B")

    return
3

Are you on about a mesh or bp ? As far as i know you can only do the bp prop right ? Ive never seen a direct mesh be able to attach to a vd

5

Oh, sorry. This is for BP.

6

Mines working

I do it like

@editable
MeshName : creative_prop = creative_prop{}

If your spawning props ect you have to use the default asset like this…

@editable
MeshName : creative_prop_asset = DefaultCreativePropAsset

Im unsure if you got confused on how you ref them or if im confused on reading what you mean but no harm in sharing this.

1 Like
7

@YuyaShiotani Can you provide media of the issue you’re seeing?

8

Off course, These here.

Working:

Not Working:

This is a video based on the snippet from the thread.
In the first video, everything works as expected.
In the second video, when the Mesh_A and Mesh_B editable variables exposed on the VerseDevice are modified in the level, the mesh switching via the ButtonDevice no longer works.

It seems that, in the Verse code, only the meshes initially assigned to Mesh_A and Mesh_B can be used — any other mesh changes are not applied.

9

What if you push changes ?

10

The same issue occurs even after performing a “Push Change” following the modification of the meshes inside the VerseDevice.

1 Like
11

I aint ever seen this very strange behavior. Hope they fix it for you :slight_smile:

12

Yeah, I think so…
Thank you for checking. :grinning_face:

1 Like
13

Thank you @YuyaShiotani, I’ll ping @Vath to come take a look.

1 Like
14

Thanks @YuyaShiotani

In your video where the issue occurs. I see that you have a minigame actively running.

I’m finding on my end that when modifying the @editable reference for the mesh while a minigame is actively running, the issue occurs. Otherwise SetMesh() properly works as expected.

In addition, ending the minigame and Pushing Changes after making the modifications should also workaround the issue.

Let me know if you are seeing differring results

15

Thanks for checking, @Vath

Regarding SetMesh(), I tried a pattern where I exited Fortnite, changed the @editable Mesh, and then restarted Fortnite, but the Mesh still did not update.

When using Static Meshes located under the Fortnite folder, this method applied the changes successfully. However, it seems that it might not work with custom meshes that were imported independently or created using Modeling Mode.

1 Like
17

Hi @YuyaShiotani! Thanks for the detailed report. I’ve been looking into this issue and having the video with sample code and steps to reproduce have been very handy!

The behaviour as displayed in the videos is actually as expected even if it doesn’t seem very intuitive, and perhaps it might be useful if I explain why. When you select to launch your UEFN experience we only try to upload the content in your source project which is actually being referenced by your experience. This is to reduce time spent uploading and makes it so content which won’t actually ever be included in the game doesn’t detract from your project size budget.

When you upload in the first case we recognize your SM_Box and SM_Cylinder aren’t included in the map or referenced by your verse source code so we don’t even upload them. Unfortunately this means when you attempt to use live edit to reference content which hasn’t been uploaded it doesn’t work correctly until you fully refresh, and you can see you get a warning in your editor output log for “LogValkyrieFortniteEditorLiveEdit: Warning: Asset reference replaced with proxy because it has not been uploaded yet: ‘StaticMesh /YourProject/Meshes/SM_Box.SM_Box’”.

You can verify this is what is happening by either placing those 2 meshes in the map before initially launching the experience, or add a reference to those 2 meshes somewhere in your verse code (even if you’re not actually using that reference to perform any logic). In both cases the repro shown in your video should work and live edit should update the reference to the new content correctly. I also tried this out myself and confirmed that it was working with either of those steps.

All this aside, replacing the end/start game in your video with a full ‘Push Changes’ (not just push verse changes!) should work. And a few of us have tried that here and it does work from what we can see. Can you try this out again and maybe provide a video of the repro using ‘Push Changes’ if you’re still hitting issues? Thanks!

19

Thanks for the detailed information, Tom!
I see—given that specification, it makes sense that assets referenced by Verse would also be subject to Asset Localization. That’s excellent information!

Based on what you shared, I ran a few tests, but in my environment, the mesh didn’t change.
I’m sharing videos of the two test cases I conducted below:

The following is a case where I added and configured a mesh to a device that was already placed in the level beforehand, then pushed it:

This one is a case where I placed everything from scratch after creating the level, changed both Mesh_A and Mesh_B, and then started a session:

Do you have any advice or suggestions…?

21

FORT-920805 is now ‘In Progress’! Our team is actively working on it!