If I have a character blueprint that has a Class variable (so a UClass* under the hood), set that variable just through normal means (not at runtime or anything, simply exposing the variable and setting it through the editor) - the variable will not properly be set on a dedicated server. Listen server is fine.
To illustrate this, I added a simple Print String in On Begin Play in the Shooter Game example and had it just do a “Is Class Valid check” on the variable to verify this and sure enough:
The only thing I did differently from you is use the Is Valid Class method rather than just trying to print the class name. I’m running with just the Run Dedicated Server option turned on, there isn’t a specific server build.
The class I’m using as a variable is also contained in a plugin, so I’m concerned that maybe there needs to be a special target for a dedicated server - but it seems to be loading at least all the blueprint methods contained by the plugin. Just the serialized class data doesn’t appear to be loading when running with that option (which works fine when using a listen server).
Could you do me a favor as well and try to follow the steps I outlined above to see if you run into the same issue?
The reason I ask is because if the issue is coming from something that is contained in a plugin that isn’t official, this isn’t something that we can offer support for, unfortunately. Is the plugin something that you’ve created yourself?
And yes this is occurring with a plugin class I created as well (so its a bit of relief it happens in basic classes too).
EDIT: If you notice the output log you can see the “False” being printed (ignore that there are two. I initially had this chained with the field I was originally testing to check things side by side but removed that node to clean up blueprint for you).
Thanks for the information. I’ve tested this again in ShooterGame, and I still notice the variable reference returning true.
This time, I created my own actor class (testActor) on top of the one I had earlier, placed that in the level, and then set the variable to reference that actor’s class (testActor). On BeginPlay, the server and both of the clients I was using returned true.
Is it possible that it could be an order of operations issue? Try adding a short delay after begin play. It’s possible that the server tries to grab the variable before it’s been fully initialized. Let me know the results after you add the delay.
So, if I add a 2 second delay, the 2nd character (0 based) that is instantiated has the field and it’s fine. The next time the object is instantiated, the field is not fine.
I should note I’m using 2 players, Run as Dedicated Server and with New Editor Window turned on. If I turn off Dedicated Server, everything works properly. So weird.
After further investigation, I do not believe that this is a bug. The reason for this is because you’re setting the exposed variable on the instance of the class that exists in the level. When connecting to the dedicated server, the server likely spawns another instance of the pawn that does not have this variable set, which would lead it to be considered invalid.
In order to test this, I removed the editable and expose on spawn properties from the variable, and instead set the default value in the blueprint itself. When you do this, you’ll notice that the variable is valid on the server and the clients as well.
