feat/friends

[yparmar2024]

Friends Functionality - SoDOff PR & SoDOff-MMO PR

Summary

Implemented friends functionality, you can send friend requests, receive them, ignore them, etc. The messaging system is also implemented but purely for system messages and so that I don't have to stub the system messages for friend requests, there's no peer to peer messaging due to the moderation caveat. We also now ping the bridge for packets that need to be sent immediately instead of when the game is launched again and fetched from database, these packets include buddy events and buddy location, as seen in the game files.

Changes

Endpoints which now work as intended:

• GetBuddyList(), AddBuddy(), ApproveBuddy(), RemoveBuddy(), BlockBuddy(), UpdateBestBuddy()
• GetFriendCode(), AddBuddyByFriendCode()
• GetUserMessageQueue(), SaveMessage(), GetCombinedListMessages()

Database had 3 tables added:

• BuddyRelationships: stores a relationship between two vikings, buddy code is generated by fetching the first 6 digits of a viking's UID
• Messages: stores messages
• UserMessageQueues: stores status on messages per viking

Notes

Messages acts as storage for messages, and UserMessageQueues points to which message a viking has read/deleted. The game files dictate that this is most likely how the messaging was stored, and it also saves storing the same message multiple times per user.

[Spirtix]

Thanks for putting this together. This functionality is something I've been designing on and off for a while now and never really gotten to it fully.
I can tell that at least parts of this were AI generated, which is fine because I see that you put at least some time into researching this, but I want to be careful what goes into the codebase (especially from first time contributors) and a disclousure would be nice.

Given the design-level issues below, I haven't done a full review yet and only looked at the surface. I'd rather get these settled first, since they'll mean some of the internals change anyway.

Things I think need to be addressed before we can get deeper:

• You committed your DB file. This shouldn't be in the repo and should've been caught by gitignore.
• Every file you touched has a change on the first line. That might be an editor issue worth checking.
• Friend codes are generated by slicing the first 6 chars of the UUID, which increases the chance of collision and causes obvious issues when looking players up by code. Also, right now lookup downloads the whole viking table and filters row by row. This is not a good design for servers with hundreds of thousands of vikings and constant traffic.
• BuddyRelationships stores two rows per one relationship, which is reasonable, but we're already space constrained on the experimental server and trading a bit of compute for space seems like the better option here.
• I don't think BuddyLocation will be needed. The location of a viking is stored as a Pair and Server and Zone are determined by the MMO server (we currently only support one server and zone anyway).
• There should be a FriendService instead of putting all the logic in the controllers.
• Running a webserver alongside the MMO server is up for debate. Better than pulling in the full Kestrel server as attempted by contributors before, but I think it would be nice to not have an HTTP server inside the MMO server. Maybe grpc or take advantage of that it already is a TCP server...
• There are several unconfigurable constants scattered through the code

[yparmar2024]

Here's a change log with some comments from the previous comments:

• Empty database file, happened from when I ran the project from root, I removed it though.
• I can't seem to figure this out, it's still showing the same thing, I'll look more into it tomorrow.
• We now generate a 6-digit alphanumeric code per player (10 + 26)^{6} combinations ~ 2 billion. We only generate this code if the viking does not have a FriendCode (added to Viking table) and they go into the friends menu.
• We now store one row per relationship, but store some extra columns such as who initiated the request, who sent it to who, who ignored it, etc. to conform with previous SoD enum types.
• BuddyLocation is needed because MultiplayerID and Room instance differ each time, thus we need to fetch those (now via TCP) from the MMO server to fully send that request.
• Organized a FriendService for all friend related methods to abstract logic into there.
• I've used TCP to now send packets along with commands for fetching or sending multiplayerId, etc.
• Instead of random strings + integers, I've now labeled constants for good practice.

Lastly, I implemented the invite endpoint for friends, it just sends a invite to someone to teleport them to you. All relevant notifications show up in system messages. For now, the implementation is done, I just need to fix that weird invisible diff issue, the other commits are on SoDOff-MMO.

[Spirtix]

Holy AI slop...

[yparmar2024]

I've reviewed the code, it's not complete AI slop. All of the ideas were from me and I didn't one shot this code either with a singular prompt pasting your comments, I was constantly iterating it. Not to mention, it works and applies the ideas that you presented.

If you don't find it to be something that you can merge to production, can you list some reasons why? Otherwise, the comment itself doesn't help me make changes since it works and follows similar pieces of code already in the codebase.