I believe there should be a clear separation between Creative and UEFN/Verse, with no impact from Creative on UEFN/Verse. The current integration raises concerns, here i want to make an example with mutator_zone_devices.
The passage of agents to mutator zone subscriptions seems justified in the context of Creative, where specificity regarding agents, players, or fort_characters may not be crucial. However, when applied to UEFN/Verse, this approach becomes problematic and lacks any justification. fort_characters possess distinct characteristics. Unlike fort_characters, agents lack collision, position, and a physical body. Consequently, it is not an agent entering or leaving zones but a fort_character.
So the way how subscriptions pass agents obviously also has an impact on UEFN/Verse specific extensions to mutator_zone_devices
For instance:
mutator_zone_device<public> := class<concrete><final>(effect_volume_device):
# Is true when `Agent` is in the volume.
IsInVolume<public>(Agent:agent)<transacts><decides>:void = external {}
This snippet is confusing and introduces ambiguity. Defining “IsInVolume” based on an agent’s presence in the volume raises questions about what qualifies as an agent being in the volume. For instance, if a player is spectating an event inside the volume, does it count as the player being in the volume due to their view? The clarity is compromised, and using fort_character instead of agent in this context would better align with the intended functionality. It is clearly only taking in an agent as parameter to stay consistent with stuff like AgentEntersEvent. AgentEntersEvent exists to stay consistent with the same event in Creative. This is the root cause of my criticism - do not try to build up consistency between UEFN and Creative.
To ensure a more logical and coherent system, it is imperative that Creative does not exert any influence on UEFN/Verse. This distinction is crucial because Creative and UEFN clearly weren’t designed with the same complexity in mind.
Mutator zones are not for players only, thus the use of agent. It was changed a while ago, and even though it doesn’t make sense at first, if you start to think AI then you will understand the design choice.
Also Creative has been wonderful for UEFN because it has allowed some agility and ease to ooze in a little, think of Creative as pre-built macros. Not always useful, but once you start working with hybrid workflows you get both flexibility and agility.
The point wasn’t that mutator_zone_devices should pass a player - that also wouldn’t make any sense due to the same reason, why an agent makes no sense.
They should pass a fort_character or alternatively a superclass that represents actors with a body. fort_character is not the same as player, fort_character is the character controller by an agent (including npcs).
Well, that’s where my knowledge stops, I was told this was the reason by Epic and past that I am sure they had a good reason. This is valuable feedback, hopefully someone from Epic can comment on this further
AI, both guards and creatures actually have a fort_character.
FN devices probably use only agentparam as a simplified representation of the underlying UE actors, i.e. player controller or ai controller w/ gameplay abilities component and avatar actor (physical representation in the game that’s roughly equiv to fort_character).
I think it was setup that way originally in UE to help separate logic to make it easier to switch players between characters, spectator mode, etc.
Yeah, agent is basically a Controller, player is a PlayerController and fort_character represents Character.
Creative doesn’t do any distinction between Controller and Character, since it would be horribly inaccessible if Creative users would need to cast from Character to any subclasses of Controller. Creative is just way too limited for abstract concepts. However under the hub, Fortnite is definitely working with the Character when dealing with collision, since a Controller isn’t something that can collide with stuff.
In contrast to Creative, UEFN/Verse (similar to UE/C++) has this distinction between Controller and Character - however it is occasionally thrown abroad overboard to maintain consistency between Creative and Verse.
I consider this a very bad decision. It makes publishing updates for Creative and UEFN easier, since Epic then only needs to create devices with Creative in mind and can deliver the same device straight into UEFN, however i think that this is not a good way to handle UEFN.
It is totally fine if Creative remains a more accessible subset of UEFN, but it should not be a drag on its leg.
I have another incredibly good example for this.
Using item_granter_devices to grant items happens async. If I grant an item and check that item with a conditional_button_device, it will not reflect the inventory change.
If I grant the same item thrice, then the item granter will grant it once after two frames, once after four frames and once after 6 frames.
This design doesn’t make any sense at all. If this was a bug, I could at least report it, but that’s literally how the device is supposed to work in Creatice…