Corona-cation (Day -2)

Git Commit: f59f36b  

"Added main menu Settings, Added class selection, Changed hosting"

Added main menu settings:

    The main menu settings screen is not even close to complete but this is where it starts. The only working settings currently are the color deficiency options. The reason for this was that Unreal's built in implementation of color blind settings was super simple. With one 'Set Color Vision Deficiency Type' node doing all the heavy lifting; taking in every input and changing accordingly. The color palette on the side was just to make sure it was working. Additionally, the 'Display Subtitles' checkbox is not functional and I am not really sure right now how that will interact with the cutscenes. In the future I plan to add other more basic settings like display options, sound, inputs, and the like. 

Added class selection and Changed hosting:

    This section took by far the longest to get working and I ran into two major issues along the way. 

Issue 1: Why is the UI displaying incorrectly? Oh, and the top-down character is also broken?

    Basically the problem was with the gamemode. The main menu and the game world had the same gamemode and so the class selection screen came up instead of the main menu. Because of this I knew that the main menu and the actual game level had to have seperate gamemodes. So I changed the main menu level gamemode override to the base gamemode class and the main menu worked as intended. But as soon as I clicked host to start a match another problem became apparent. The host was not possessing the top-down pawn and was instead just a camera at 0, 0, 0 staring off into the void. After a good amount of time and no less than 20 game restarts I figured out that, yes, they did need to be separate gamemodes, but the gamemode was not actually changing. I thought back to the creative jam and how a similar problem happened. It was fixed by the 'Absolute' option when opening the new level, essentially resetting all settings and letting the new gamemode take over. 

    The problem with this solution is that I was now using a console command to open the new level and so I didn't have that option available to me. I spent at least half an hour googling how to open an absolute level through the console, but it almost always landed me on the unreal engine 3 documentation for some reason. It was then that I tried to just use that same open level node with the absolute option ticked. And you know what? It worked. Just like that. I have been kicking myself all day since. 

    So now the gamemode is taking effect, people are joining the same game, and pawns are spawning in correctly, but...

Issue 2: Wait, the class select code that I wrote before even testing if players could join the same game doesn't work perfectly the first time? That's crazy!

    So the basic idea behind the class selection is that the top-down player will always be the host and so the first person to join, no big deal. Then, everyone else will possess a separate pawn that has a screen (like above) and will see what classes are available and be able to choose one that is not taken, so there can only be one person per class. In the picture, the cleric is locked because another client already picked it, the sharpshooter is available, and there are no other classes yet so the other two are disabled for now. Now, the issues arose with the part where there can only be one person of each class. 

    I had solved this during the creative jam but in a real creative jam type way. The way that it worked for the jam was: every tick the new player would ask the server "What classes are taken?", the server would return an array of classes that were already chosen to the player, then the player would take that information to update the UI. Basically, I wanted to not use the event tick. And that desire cost me two hours of time. 

    Well, that's a bit misleading. I also wanted to change the way that the server handled it's logging of player classes. I did this by changing the array of classes that were taken to a map container type of player classes connected to a player controller. I believe that sometime in the future this ease of knowing of which player is what class will be very useful. 

    So now armed with this map of player classes, I started off to only allow one player of each class. My plan was to fire a single event when a player picks a class which will then update the UI on the rest of the players. The first attempt involved just passing that map down the line from server to client to UI, then the UI would see which classes to update. This just didn't work. I put print strings and breakpoints all down the line and they all worked but none of the buttons were changing. So I started printing the values of the map down the line and this gave the first clue. As soon as the map was transferred from server to client the map was just null, gone in the wind... This was very confusing, because I was just passing a direct reference that I hadn't touched. I had a suspicion that it was the player controller references that was messing it up as I know that clients and other player controllers don't usually play nice. So instead of player controllers, I converted them to booleans. At this point the map passed to the client was player class and bool if it was taken or not. Still nothing. 

    I solved the problem by not using the map. Basically, I cut out the player class completely and just passed the UI an array of booleans in order of class availability. Even now I have no clue why it didn't work the other way. My suspicion is on either the map container type or the custom player class enum. The server still has access to the map but it seems it can't give that information directly to the clients. But it works now so who cares right.