The CLI module manager will kind of work in the same way as a package manager. The module manager will contain all whitelisted modules from Evo's module page, and will make the process of adding external modules to the EvoSC# core easy as nothing.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
The private message inbox should contain all recieved private messages from any users in the current server.

Async methods should use the async naming convention, that is ending with Async. So for example, if you have a method called MyMethod but it is async, it should be called MyMethodAsync.

ref: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model#BKMK_HowtoWriteanAsyncMethod

We should improve the overall code quality by eliminating some issues on Codacy. In addition, we should make use of some of the new features introduced in C#11 like Required Members, which can simplify the code.

Personal best tracking.

    Future improvement; also add the possibility to send in your own connection string.

Originally posted by @AtomicLiquid in #47 (comment)

To allow for live enabling/disabling of plugins during runtime, the PluginSystemBase needs to be slightly rewritten. This can be achieved by for example adding onEnable and onDisable events in both the core and the plugin itself. Which again means we should extend the IPluginFactory interface to contain these events.

File & in-memory support.

• Controller file template (event/command/manialink)
• Migration file template
• Plugin project template (internal/external)
• Middleware file template (player chat/action)
• Permissions file template
• Settings file template

Also needs shortcuts for defining chat commands. For example in PHP EvoSC, this is done extremely easily: https://github.com/EvoTM/EvoSC/blob/master/core/Modules/Votes/Votes.php

Plugin that handles everything related to maps, such as adding new maps, removing maps and more.

The map karma is a system that should allow the players to give feedback on how good they think a map is. This is currently implemented in EvoSC PHP by allowing the player to type up to three + or three -.

A module that provides a way to edit and manage permissions for groups and players ingame.

To allow translations in the future, and to also have a cleaner way of altering chat- and manialink text, localization should be added to the project.

The player service is responsibly for general player management. It should support managing player data in the database, fetching of offline and online players, deleting player info etc.

The player service is used both in the core and by modules to do various things on players.

The voting system should contain the possibility to vote for a map, extending time/point limit for current map and skip a map.

The ranking system should contain a list of all players based on their played time and win rate. Rank #1 is the best player etc...

DB Provider Implementation - EF should be inserted in the project and we should replace the current FluentMigrator for EF to enable support of even more DBs.

A way to unload modules from memory during runtime will allow the possibility to completely manage modules while the controller is running. The goal is that we don't need to restart the controller when installing or uninstalling modules.

Foundational implementation of the command-line interface used to control EvoSC.

1. Setup listeners for all dedicated server events example
2. Make PlayerManger hook on the event (Maniaplanet.PlayerConnect)
3. Glue events from client to the manager.

• XMLRPC main Callbacks
• Gamemode script Callbacks

The migration file name should be named yyyyMMddHHmm_MigrationAction.cs where:

• yyyy the current year (e.g. 2022)
• MM the current month (e.g. 05)
• dd the current day (e.g. 06)
• HH The current hour in 24h format (e.g. 15 or 03)
• mm The current minute (e.g 58 or 08)

The time & date should be in UTC+0 in order to keep time and date consistency across time zones.

Migration version should be in the UNIX timestamp format. Number of seconds of the current epoch since 01.01.1970. The version is set in the attribute of the migration.
For example: [Migration(1666859869)]

Integrate chat routing into the controller with extensibility points to it.

The current exceptions used within the map service and the map module is too generic. These should be replaced with more well-defined exceptions to give a more accurate description of what has failed.

The Matchsettings manager [...]

• Module namespaces
• Template engine
• User interaction actions for controllers

Template engine: https://github.com/EvoTM/ManiaTemplates

Create documentation for:

• End-users
• Module developers
• EvoSC developers

If the main configuration file config/main.toml does not exist, the application should create this file with all the default option values.

The bug

There appear to be an issue when activating services that depend on services from other service providers.

For example, if a service, Plugin1Service, from Plugin1 depends on a service, Plugin2Service, that is registered from Plugin2. The plugin system will create a PluginServiceProvider that contains the core's service provider, Plugin1's service provider, which contains Plugin1Service and Plugin2's service provider, which contains Plugin2Service. And, Plugin1Service uses the DI system, and gets Plugin2Service passed in it's constructor.

Now, imagine you have a command that a user calls. This command requires Plugin1Service and uses DI in it's constructor to get this service. When the command is called, the DI system will attempt to activate Plugin1Service. However, since Plugin2Service does not exist in Plugin1's service provider, the activation fails.

The problem

The problem here is that the different service providers within the same PluginServiceProvider has no knowledge of any of each other's services.

To visualize the problem here is a diagram:

Because the way service providers works, there is no way to provide this knowledge dynamically during runtime after the ServiceProvider has been built.

Consequences

What this means is that it breaks the entire dependency system. Plugins have no way to communicate with eachother, access eachother's services. The problem becomes even bigger because a plugin's services can't even access the core services (eg. no database access, rpc access etc.)!

Describe the solution you'd like
The Chat command system should be extended with the possibility to easily enforce regex on the input the user types based on the given chat command. An idea could also be to have an enum or a set of constants which are commonly used regexes.

The bug

When services are registered in the Setup method of a plugin, and you require it through DI in a commands class. The commands class fails to activate as the service is not found.

The reason for this is because the commands activator is only using the core service provider instead of the plugin's service provider.

The commands system needs to be integrated into the plugin system and this requires some changes to how commands are registered.

To reproduce

Define a service:

public class MyService { }

Create the commands class:

public class MyCommands : ChatCommandGroup {
    public MapsChatCommands(MyService myService)
    {
    }
}

In the plugin class, register the command class and the service:

public class MyPlugin: EvoSCPlugin
{
    public MyPlugin(IChatCommandsService commands)
    {
        commands.RegisterCommands<MyCommands>();
    }
    
    public static void Setup(IServiceCollection services)
    {
        services.AddTransient<MyService>();
    }
}

The issue & potential fix

The offending line in the code that causes this bug should lie here: https://github.com/EvoTM/EvoSC-sharp/blob/a41ad03af683b4cc8e3f1b96dacd1eb6e78e1689/EvoSC/Core/Commands/Generic/CommandsService.cs#L125

The plugin's service provider must be passed to the command invoke method instead of the core service provider.

Another solution is to keep track of the plugin's service provider in the command info object and use that in the invoke method instead of passing it to the invoke method from the outside. However, the disadvantage from that is that you now leave out of the ownership of the service provider, and can no longer directly control which services are available for the command.

Getting player info from the remote (eg. GetPlayerInfoAsync, GetDetailedPlayerInfoAsync) is slow and should be optimized.

Some ideas:

• Use multicall.
• Track player states in memory, update them when ManiaPlanet.PlayerInfoChanged is called, then use cache to retrieve information. This might require some synchronization to avoid race conditions.

• #173
• #229
• #172

Widget at the top of the screen which keeps track of users fastest times on each checkpoint. Unsure if it should be stored in memory or in database.

The PlayerManagerService.CreatePlayerAsync method will throw an error if it cannot find the player to create to be present on the server. We need to figure out how we can create players in the database with default configuration. This is useful when adding maps to the server, where the author of the map is required to be created as a player.

Chat message formatter utilities and helpers to simplify sending messages and responding to user actions.

• Implement permissions from current EvoSC
• Implement Permission Groups / User groups

Implement an audit system where all actions made by players/mods/admins get logged to the server. Logs should be saved in the database for easy access and view from in-game.