DBAccess should only be accessed by services. GameClientAsync has, for example, a few direct calls into the DB class where instead one of the associated services should be handling that instead.

This should go in line with DBAccess being completely cleaned up and refactored into a proper service. Eventually, this service should be exposed in the web service as to not repeat logic.

If x amount of an item is an a guild shop, and multiple people all try to buy the entire stock, or enough to combined be greater than x, the server will give all players the amount they asked for, and the shop's amount of that item will underflow around to 65535.
While I'm not sure there's a way around everyone getting the items, which opens the possibility of guild shop item duplication, this feels like something that should be relatively™ easy to fix.

Pulling up an online player's profile in the lobby causes their icon to show as a shrunken-down version of the current screen(using the lobbychat can cause the text to show in the profile icon)

Sorting BBS Threads by Last Updated post and also if possible show the date in the thread view

Attempting to send mail after sending a guild-mail causes the server to disconnect the player with code 6054

Hi guys,
Thank you so much for all your work !
I'm trying to run the server but idk why it doesn't work.

Basically :

• I'm importing the DB.sql in my local database
• Adding the DB credentials and IP address in FragmentServerWV_Core\hibernate.cfg.xml
• In the same folder, editing the settings.txt by adding my PC IP
• Doing the same in root settings.txt file
• Running buildRelease.sh with Git Bash
• Then trying to "sh runRelease.sh" but nothing appears

I hope it's the good place for asking some help.

Actually I think this might screw over people who host on ports other than 20000, but it might be nice to have an option in the config file for this so that people aren't sitting around trying to connect to their AS over and over again and wondering why they can't connect to it?

Change the Character Limit for the Player Name in the BBS from 15 to 16

as there are some legit player names that are cut off

[Player name should be "Clementine Quark"]

Area Server Bookmarks not working

when Player Transition to AS, the Lobby takes a long time to remove the player from the room

need to check the OPCode for entering AS

I've titled it a refactor but this is meant to capitalize on redoing how opcodes in general are processed.

Right now, GameClientAsync is solely responsible for the managing and handling of opcodes. This is less than ideal and means that GameClientAsync remains as this sort of God object. This will eventually become a nightmare to extend and handle debugging. Plus, if we get more than two people working in this codebase, merge conflicts will suck. So the purpose of this issue is to provide a way to document and track the overall migration efforts to a new system.

I know @Zackmon has started doing a bit of a demonstration on how this would look. I'm working on one now inside a separate branch on my forked repo that will follow something like this:

Packet Handling

For starters, there will be several newly defined classes:

1. IOpCodeProviderService
2. IOpCodeHandler
3. RequestContent
4. ResponseContent
5. OpCodeAttribute
6. OpCodeDataAttribute

IOpCodeProviderService

This service is responsible for the dynamic discovery and mapping of IOpCodeHandler instances. In addition, it will include reportable information, such as available OpCodes, and some reporting statistics.

    /// <summary>
    /// A service provider that's responsible for the discovery and management of the various <see cref="IOpCodeHandler"/> instances
    /// </summary>
    public interface IOpCodeProviderService
    {

        /// <summary>
        /// Gets a collection of <see cref="IOpCodeHandler"/>s but as their defined type
        /// </summary>
        IReadOnlyCollection<Type> Handlers { get; }

        /// <summary>
        /// Handles processing the incoming <see cref="PacketAsync"/>
        /// </summary>
        /// <param name="gameClient">The <see cref="GameClientAsync"/> that submitted the request</param>
        /// <param name="packet">The <see cref="PacketAsync"/> to handle</param>
        Task<ResponseContent> HandlePacketAsync(GameClientAsync gameClient, PacketAsync packet);

    }

IOpCodeHandler

One or more OpCodes will be handled by an implementation of IOpCodeHandler. A RequestContent object comes into it and a ResponseContent object will be returned. The classes are all assuming async/await behavior by default and the interfaces have been designed accordingly.

    /// <summary>
    /// Defines a lightweight interface who is responsible for handling incoming packet requests
    /// </summary>
    public interface IOpCodeHandler
    {

        /// <summary>
        /// Handles the incoming <see cref="PacketAsync"/> instance
        /// </summary>
        /// <param name="request">The incoming <see cref="RequestContent"/></param>
        /// <returns>A promise to handle the packet asynchronously</returns>
        Task<ResponseContent> HandleIncomingRequestAsync(RequestContent request);

    }

RequestContent

A small wrapper that deconstructs the incoming request down into the OpCode, Data Packet, and Client that is being processed.

    /// <summary>
    /// Defines a particular request that was sent via a connected client
    /// </summary>
    public sealed class RequestContent
    {

        /// <summary>
        /// Gets the <see cref="GameClientAsync"/> that has submitted this request
        /// </summary>
        public GameClientAsync Client { get; private set; }

        /// <summary>
        /// Gets the OpCode that was submitted by the <see cref="Client"/>
        /// </summary>
        public ushort OpCode { get; private set; }

        /// <summary>
        /// Gets the optional Data OpCode that was submitted by the <see cref="Client"/>
        /// </summary>
        /// <remarks>
        /// If <see cref="OpCode"/> does not equal <see cref="OpCodes.OPCODE_DATA"/> (or 0x30) then this will be NULL
        /// </remarks>
        public ushort? DataOpCode { get; private set; }

        /// <summary>
        /// Gets the data payload that was submitted by the <see cref="Client"/>
        /// </summary>
        public byte[] Data { get; private set; }

}

ResponseContent

A small wrapper that contains all the necessary information to submit data back to the Client.

    /// <summary>
    /// Defines the response object for a particular request
    /// </summary>
    public sealed class ResponseContent
    {

        /// <summary>
        /// Gets the <see cref="RequestContent"/> that generated this <see cref="ResponseContent"/>
        /// </summary>
        public RequestContent Request { get; }

        /// <summary>
        /// Gets the responding OpCode
        /// </summary>
        public ushort OpCode { get; private set; }

        /// <summary>
        /// Gets the responding byte array of content
        /// </summary>
        public byte[] Data { get; private set; }

        /// <summary>
        /// Gets the responding checksum
        /// </summary>
        /// <remarks>
        /// If Checksum is NULL, the response type is ASSUMED to be a Data Packet response (meaning the <see cref="RequestContent"/> OpCode was <see cref="OpCodes.OPCODE_DATA"/>)
        /// </remarks>
        public uint? Checksum { get; private set; }

}

Things like proper encryption / decryption are to be handled automatically. For example, PacketAsync already handles properly decrypting the incoming data. The assumption would be that ResponseContent would handle encrypting the payload (including checksum calculation) since the RequestContent class includes the Client, therefore exposing the necessary encryption keys.

This also means that each implementation of IOpCodeHandler can narrow their access scope to only classes they need to care about. Additionally, it is assumed that IOpCodeHandler instances will be created on-the-fly via Dependency Injection, removing any worry or concern about shared resources (provided implementations and dependencies in the class itself behave).

@Zackmon feel free to assign this to me.

Perhaps leftover of testing but it make it that you enable to run the program if it is not the machine ip

./runRelease.sh
1:51:00 PM:Server started on 192.168.86.167:49000

1:51:00 PM: Log Size = 100000

1:51:00 PM: Ping Delay = 5000ms

1:51:00 PM: Proxy Mode = False

Unhandled exception. System.Net.Sockets.SocketException (99): Cannot assign requested address
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at System.Net.Sockets.TcpListener.Start(Int32 backlog)
   at FragmentServerWV.Server.MainThread(Object obj) in /home/dash/dev/FragmentServer_netCore/FragmentServerWV_Core/Server.cs:line 74
   at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
./runRelease.sh: line 3: 2987321 Aborted                 (core dumped) ./FragmentServerWV_Console/bin/Release/netcoreapp3.1/FragmentServerWV_Console

Changing the IP to 0.0.0.0 resolve the issue

diff

diff --git a/settings.txt b/settings.txt
index c525097..6ebc743 100644
--- a/settings.txt
+++ b/settings.txt
@@ -1,9 +1,9 @@
 #edit to your local ip
-ip = 192.168.86.167
+ip = 0.0.0.0
 port = 49000
 
 #"is alive"-ping delay in ms
 ping = 5000
 
 #maximum log text length
-logsize = 100000
\ No newline at end of file
+logsize = 100000