Reference ID
43b5ceb5-4b2a-15f3-1abf-a1a6c3599b0a
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Verse
Summary
Invoking the Hide() or Show() methods on a creative_prop object within the ‘Fortnite.digest.verse’ file does not alter the collision properties as documented. Although the visual state of the object changes appropriately with method calls, the collision state remains unaffected, leading to a discrepancy between expected and actual behavior during runtime.
Steps to Reproduce
-
Create new blank island
-
Add 2x ‘button device’ to the level as well as 2x Fortnite Props (or any static mesh) [Agency Door Frame & Agency Wall in my Case]
-
Convert the 2x Fortnite Props to ‘FortCreativeDeviceProp’ Blueprints
-
Create a new verse file called ‘PropHider’ and insert the following code
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }
Prop_Hider := class <concrete> {
@editable Button : button_device = button_device{}
@editable Prop : creative_prop = creative_prop{}
@editable var Shown : logic = true
Setup () : void = {
Button.InteractedWithEvent.Subscribe(OnButtonInteractedWith)
if (Shown = true) {
Prop.Show()
} else {
Prop.Hide()
}
}
OnButtonInteractedWith (Agent : agent) : void = {
if (Shown = true) {
Prop.Hide()
set Shown = false
} else {
Prop.Show()
set Shown = true
}
}
}
PropHider := class(creative_device) {
@editable Hiders : []Prop_Hider = array{}
OnBegin<override>()<suspends>:void={
for (Hider : Hiders) {
Hider.Setup()
}
}
}
-
Build verse code, locate the ‘PropHider’ device in the ‘CreativeDevices’ folder and add to the level
-
Add the two buttons and props to the PropHider device in the editor menu.
-
Save & Launch Session
-
Attempt to toggle the props with the buttons
Expected Result
Upon First Interaction (Hide Action):
- The associated prop should become visually hidden.
- Collision with the prop should be disabled, allowing me to walk through the space previously occupied by it.
Upon Second Interaction (Show Action):
- The prop should reappear, becoming visually present in the world.
- Collision should be re-enabled, preventing me from walking through the prop.
In both actions, the changes in visibility and collision properties should be seamless and immediate upon interaction, ensuring a consistent and predictable user experience.
Observed Result
Upon First Interaction (Attempt to Hide Action):
- The associated prop becomes visually hidden as expected.
- However, collision with the prop is not disabled; I cannot move through the space where the prop was visually present, indicating that the collision properties remain active despite the visual disappearance of the prop.
Upon Second Interaction (Attempt to Show Action):
- The prop becomes visually present in the world as expected.
- Collision continues to function as it did before the prop was hidden, without any noticeable change or update in the collision properties.
This behavior misaligns with the documentation and expected outcomes, as the collision properties are not altered upon calling the Hide() and Show() methods, causing unintended obstructions and interactions within the environment.
Platform(s)
Windows 11
Additional Notes
Approximately two months ago, while experimenting with verse for the first time, I discovered a bug that has persisted and significantly impacted my work with the ‘Fortnite.digest.verse’ file. My assumption regarding the intended functionality—specifically the ability to disable and enable collisions through the ‘Show’ and ‘Hide’ methods within the creative_prop class—stems from the documentation provided in build ‘++Fortnite+Release-26.20-CL-28096793’.
Here’s a snippet from the file indicating this suggested functionality:
creative_prop<native><public> := class<concrete><final>(creative_object, invalidatable):
...
# Shows the `creative_prop` in the world and enable collisions.
Show<native><public>()<transacts>:void
# Hides the `creative_prop` in the world and disable collisions.
Hide<native><public>()<transacts>:void
However, my experience reveals a misalignment between the documentation and the actual behavior of these methods, as the collision properties do not seem to be affected when they are invoked. You can view the issue in action in this video: https://i.imgur.com/ARpA5tm.mp4.
This inconsistency between the documented functionality and actual behavior has been quite impactful on the building process, especially for Tycoons. I believe addressing this discrepancy will not only assist me but potentially other developers who might be facing similar challenges. I appreciate your attention to this matter and am happy to provide any further information or testing that might assist in resolving this issue.
