The player state contains a boolean called “Is Spectator” which is used to denominate if the player is spectating. This boolean can’t be explicitly set, meaning that it probably updates on its own (I assume by checking if the player controller’s possessed pawn is the same class as our game mode’s spectator pawn).
Unfortunately, Is Spectator is seemingly stuck in “false”, even when the player is explicitly possessing our spectator class.
I have some test logic in my player controller that lets the player possess the spectator pawn (ignore the true branch, it’s just some placeholder and irrelevant to the test).
I get the feeling that I’ve misunderstood how “Is Spectator” is set, unfortunately search engines decided to stop being helpful a few years back, and attempting to find any documentation to clarify the matter has proven rather fruitless.
Of course, I do appreciate the opportunity to get a refresher on the basics. But it is a shame that the best I could find were some samples of how to force set the variable with C++ (which seems to me like a hacky and unintended approach), I’d like to stick to blueprints for my project if possible, and more importantly, stick somewhat to what is actually the intended use for setting and getting this variable.
To summarize this post: “How is ‘IsSpectator’ set? What sets it?”
I would appreciate any advice on the matter.
Some information I’ve been able to gather from various questionable sources:
The game mode has an option to start players off as spectators. However, in my testing, while this will spawn you as the spectator class, still won’t set the bool for if you are a spectator. This implies that the bool is not actually set by the engine.
The player controller is supposed to have a method that lets you change the “state” of a player. However, I’ve not seen this for myself, and it might only exist for C++.
There might however be a method called something along the lines of “Client Go To State” that is exposed to blueprints. However, I’ve yet to see this mythical node with my own eyes.
In all likelihood, this boolean is entirely useless, considering that it can’t be set by developers, and it is seemingly not managed by the engine either, which is a shame because it is replicated and taking up precious network packages.
I’m ashamed to admit that I am a little bit confused by this finding. The most reasonable approach seems to be to make another replicated bool to do the exact same thing. I would much appreciate it if Epic Games could remove the original bool, because as it stands, its only real function is to possibly cause confusion between it and the user-made replacement.
At the sacrifice of no longer having a purely blueprint-only game, unfortunately proving that you can’t make a game with just blueprints, I came up with this:
This overwrites the state of the bool, whether the engine wants you to or not. This means the bool won’t go to waste, no variable left behind is my motto.
Please don’t ask me how it works, I don’t have the slightest idea, and honestly I’ll be waiting for my game to pay for a CS degree before I even dare bother.
More importantly, to the future user reading this post 2 years from now because it somehow became the first result in Google. If I were you, I’d just give up, I’m serious here, clearly some parts of the engine are not meant to work, be used, or even acknowledged. Just make a second replicated bool and use that instead while pretending that the original one does not exist, being as stubborn as me is not worth the RAM, time, and sanity sacrifices involved in installing and running Visual Studio. If you insist, at least use Visual Studio Code, it can build too, and it’s not as awful.