Persistent Client Preferences and Friends of Friends Packets

[desukuran]

This implements the client preferences and relevant Friend Network packets. It also refactors how GameInformation is processed and FriendsGameInfo is sent.

Added Inbound Packet FriendsOfFriendsRequest (5)

• Observations see that this is usually triggered by a non-friend session ID sending game info to you.
• This sends a list of session ids presumably to identify.
• We grab all the info on said session id and put them into a list of UserModels and send it to Outbound FriendsOfFriendsInfo

Added Outbound Packet FriendsOfFriendsInfo (136)

• This packet expects 5 attributes, all lists containing: Friend Session IDs, User IDs, Usernames, Nicknames and a list of their friends.
• Process will process the list of UserModels sent from Packet 5 and gets all the info needed.

Added Inbound UserPreferences (10) Replacing file Unknown10

• This packet sends a keyed map of preferences. (id, value)
• The logic behind this is simply: If the key exists in the packet, disable it. If the key doesn't exist, enable it. Other than 6 per Zelaron and I's observations, enables if it exists.
• This then triggers a new function in the database to save your preferences.

Modified Outbound ClientPreferences (141)

• Changed from the hardcoded table to one that has loaded preferences.

Modifications to GameInformation and FriendsGameInfo

• SendGameInfoToFriends has moved to PFireServer, as it will be called more from different spots.
• FriendsGameInfo has been changed to now be more dynamic and process a list of users instead of one. This saves having to send multiple packets for multiple users (when you log in, etc).

Modifications to Inbound ConnectionInformation

• Chat room mode is now officially disabled. You can re-enable it at the top define. Its not a bad idea, but since we are focusing on getting the core FoF stuff done and moving onto more, I disabled it.
• You are now sent what your friends are playing on log on.

Modifications to Inbound FriendRequestAccept

• You are both sent your respective games when accepted.

Modifications to PFireDatabase

• New functions: QueryFriendsOfFriends (Thanks Darcy) and SaveUserPrefs

Modifications to XFireClient

• UserCameOnline is added with BroadcastSessionStatus, it might seem redundant but it seemed to fix a weird lingering log on and log off issue. More testing would have to be done, but it seemed to fix it.

Modifications to PFireServer

• New function: RemoveGamingSession which clears your gaming session before you log off. Friends are fine but FoF lingers, that fixes it.
• SendGameInfoToFriends is moved from FriendsGameInfo with some refactoring changes. This sends your current game to people who missed the initial game info broadcast packets.

Modifications to UserModel

• Added Preferences into the user. Darcy spoke to possibly in the future to change this, but here it is for now.

Usual MessageFactory and Type changes for new packets implemented.

Database Changes

• Added Preferences into the User Table in the Database
• New Migrations to reflect this.

[Scatt]

Can we make all these numbers a constant or enum or something? What does "3" mean?

[desukuran]

I'll toss in an enum when I get here.

[Scatt]

missing await here

[desukuran]

Good catch

[darcymiranda]

I'm still reviewing; posting what I have so far.

[darcymiranda]

This check is not needed

[darcymiranda]

Suggested change

	public List<int> Userid { get; } = new List<int>();
	public List<int> UserId { get; } = new List<int>();

[darcymiranda]

Suggested change

	Userid.Add(session.User.Id);
	UserId.Add(session.User.Id);

[darcymiranda]

Suggested change

	public FriendScreenshots(int userid, IEnumerable<Screenshot> screenshots) : base(XFireMessageType.FriendScreenshots)
	public FriendScreenshots(int userId, IEnumerable<Screenshot> screenshots) : base(XFireMessageType.FriendScreenshots)

[darcymiranda]

Suggested change

	UserId = userid;
	UserId = userId;

[darcymiranda]

Shouldn't this be a Guid instead of an object?

[desukuran]

If I remember correctly, the way that the serializer works it has to be a List but I will double check when I have time.

[desukuran]

List object*

[darcymiranda]

Can you help me understand what problem this is solving?

[desukuran]

So, the attribute name gets put into utf8 encoding.
Which is fine for strings, but for single byte attributes, the encoding part breaks certain hex values and causes it to return unexpected and unwanted results for Inbound packets with single bytes of certain values.
Chatroom packets suffered the worst with this, so I wrote this to return the exact byte given back so that it all smoothly gets decoded fine if the value is a single byte. It's ugly but it made it work.

[darcymiranda]

Oh yeah, that makes a lot of sense. Instead of this special logic, I wonder if we can just use a 1 byte string encoding like ASCII instead of UTF8. We don't need any fancy characters for our field attribute names.

[desukuran]

As long as ASCII doesn't try to encode say 0x01 and treat it as a special byte like utf8 did, that's my only fear.

[Scatt]

I reverted this change to how it was and am able to update my status to trigger StatusChange (which has the byte type attribute) and it works fine.

Do you have a specific example where you ran into your issue?

[desukuran]

My memory isn't the best but I looked into some notes I took on this.

Most bytes should work, especially if they are near the letters portion of a utf8 charmap.

One of the examples I can think of is when the problem arised when inbound packets for User Group Member adding and User Request Advanced Info, which both contain 0x01 as an attribute name would deserialize and produce an attribute of \u0001 instead of the expected 0x01.

The problem arises when it hits specific utf8 special characters, this would fix the troublesome bytes that would break during incoming packet deserialization.

[Scatt]

If we put back the MessageSerializer.Deserialize to this

var attributeName = GetAttributeName(reader, messageType);
var field = fieldInfo
    .Where(a => a.GetCustomAttribute<XMessageField>() != null)
    .FirstOrDefault(a => a.GetCustomAttribute<XMessageField>()?.Name == attributeName);

Put back the MessageSerializer.GetAttributeName to return the encoded string

var count = messageTypeSet.Contains(messageType) ? 1 : reader.ReadByte();
var readBytes = reader.ReadBytes(count);
return Encoding.UTF8.GetString(readBytes);

Uncomment the call to the other constructor in XMessageField here to set the name property

public XMessageField(params byte[] name) 
    : this(Encoding.UTF8.GetString(name))
{
    NonTextualName = true;
    NameAsBytes = name;
}

Then the .FirstOrDefault above would act like this no?
a.GetCustomAttribute<XMessageField>()?.Name would be "\u0001"
attributeName would be "\u0001" as well

So it should match fine.

[darcymiranda]

Can you help me understand what problem these changes are solving?

[darcymiranda]

Sorry for the big refactor request, but we should do this like how we handle any other message from XFire.

Basically, each of these methods you have would be its own XFireMessage class where what you have as keys would be the XMessageField and its types. Then the process function can be the logic that you have in each method.

You'll want something similar to XFireMessageTypeFactory, but for your chatroom "CliMsg". We can create a IXFireMessageTypeFactory interface that the current XFireMessageTypeFactory implements and your new ChatroomMessageTypeFactory can implement.

Then we pass in the interface into MessageSerializer instead of the concrete type so that we can use that existing logic to serialize/deserialize your chatroom messages.

Let me know if you need some help with this.

[desukuran]

Definitely, I figured this part will be completely refactored but I gave it a shot anyway and made a working proof of concept.

I'll be in touch once I get to this in fixes.

[darcymiranda]

It's confusing to me that this outbound message is creating more messages. What triggers this message? We should try to send these messages from there instead.

Ideally the outbound messages are doing one thing and processing THIS message.

[desukuran]

Join Info is the entire process of attempting to join a chatroom. From checking to see if it's locked down, to password entry to denying for various factors.

The message that gets sent, User joined is telling the other people in the chatroom that you joined if you passed all the checks and you join the chatroom.

If you want to, say keep the ethos of one packet per process, we could maybe return a successful join or something.

[darcymiranda]

Hmm let me think about this one more. Maybe I'll get a better understanding of what we can do with it as I read more of the code

[desukuran]

I can do a write up soon to make it clear. Packet 25 is the all encompassing packet for chatroom actions from the client. So there's a LOT of moving parts.

[Scatt]

This message is chatroom info you get sent when you join a chatroom?

Looks like this is only called from ChatroomInboundMessage so you could move the other logic in there, and it looks like it has a thing to send messages to everyone in chat ya?