This is actually something Iâve been digging into as of late and wondering what exactly is going on behind the scenes with the Playspace and why we may be seeing inconsistencies. Something fundamentally backwards to me is the way the API comments infer that we get a player reference and I believe ties into the larger issue (as this is all I have to go off.)
Playspaces<public> := module:
# A nested container that scopes objects, style, gameplay rules, visuals, etc. All objects and players in an experience will belong to a fort_playspace. There is typically one `fort_playspace` for an entire experience, though this may change in the future as the platform evolves.
#
# To access the `fort_playspace` for a `creative_device` use `creative_device.GetPlayspace`.
fort_playspace<native><public> := interface<epic_internal>:
# Signaled when a `player` joins the `fort_playspace`. Returns a subscribable with a payload of the`fort_character` that entered the `fort_playspace`.
PlayerAddedEvent<public>():listenable(player)
# Signaled when a `player` leaves the `fort_playspace`. Returns a subscribable with a payload of the`fort_character` that left the `fort_playspace`.
PlayerRemovedEvent<public>():listenable(player)
Returns a subscribable with a payload of thefort_character that entered the fort_playspace
Seems indicative of legacy system implementation. Iâve arrived at the conclusion that there must be some fusion of the fort_character and the agent_controller(talking AController uobjects here) causing a lot of the inconsistencies and errors that can be observed.
player.IsActive (not fort_character.IsActive ) is the method intended for avoiding the runtime error when indexing into a persistent weak_map
Indicates that these two things need to be treated separately, which supports class construction and inheritence from a UObject perspective. Typically AController and APawn extend AActor independently and are treated as their own objects, where AController possesses APawn, but based on the way the Playspace has been set up it actually indicates that we get a reference to the PlayerController (extends AController) object via the Fort_Character (extends APawn).
I realize that it may not be accurate to represent UObjects in a 1:1 correlation with Fort_Char and Agent but I have to construct a fundamental framework to understand and apply these concepts since one has not been provided.
The Problem: Fort Character (fort_character) seems to have evolved to represent the character (pawn extension), but originally meant the player_controller and its associated character object, and was all treated as a single entity. This has become problematic as they are no longer addressed as the same object, and now have divergent definitions we can point to indicating such. We are led to believe that Fort_Character is the physical representation as stated in the UObject definitions, but we somehow derrive a Player reference from the Playspace aka fort_playspace through the Fort_Character according to the Playspace API Comments. The Fort_Characterâs existence and relationship to the Agent is an external âblackboxâ to us. (bare with meâŚ)
With the new Player.IsActive[] indicates that we now properly have the capacity to query the Player Controllerâs existence separately from the Fort_Character which allows us to treat these two objects as independent of one another, and accurately reflects the future implementation that I believe is being referenced here.
Where there starts to be a breakdown and where I think the bugs related to this occur from is that the Agent and Fort_Char existence seems to still be treated as a guarantee when they in fact are not:
Reviewing when events are being signaled by your devices and whether or not they contain the appropriate payload (ie: returning agent controller in response to a spawn event, which explicitly handles bringing a Fort_Character into existence) would be a great place to revise and improve the clarity and effectiveness of implemented API functionality.
The Playspace and comments indicate that the entirety of the core of the Playspace functionality may not be clearly or explicitly defined one way or another. It would be great to have someone review internal definitions and functions to ensure nothing was overlooked here, and then update the API comments to reflect the current state by which it is handled.
I know this doesnât address weakmaps directly but I think that we fundamentally need to look at the Playspace itself and âfix the foundationâ in order to suppose anything else as our entire ability to interface with the game is dependent on this objects existence, which is inherently either flawed or misrepresented
