obsidianmc / obsidian Goto Github PK

Since IPluginClass.cs has ProjectUrl we should make use that in /plugins, therefore best place to put it in is to make each plugin item clickable.

During November this year (11/2021), new version of .NET will get released. We should update to make use of its performance improvements, new features and LTS.

• Update all project files net5.0 → net6.0
• Update project description (About, README, csproj...) .NET 5 → .NET 6
• #125
• #126
• #173
• #174

In an effort to streamline and standardize DI, logging, and the lifetime of the bot, I would like to propose changing to a GenericHost.

Items to discuss:

• Replace Dependency Injection with Microsoft.Extensions.DependencyInjection
• Design server runtime around a GenericHost
  • Use Console Lifetime (naturally handles CTRL+C or SIGTERM and calls IHostApplicationLifetime.StopApplication() to gracefully stop the bot as well as unblocking asynchronous runtimes). Works very well with systemd's service management on the Linux side as well.
  • Lifetime managed by IApplicationLifetime and CancellationTokens
• Use Microsoft.Extensions.Logging base (compatible with existing logging library).
• App Configuration (environment variables, appsettings.json, UserSecrets)

For those unfamiliar, the GenericHost is based off the WebHost class from ASP.NET Core. However, this has the web-specific features removed in favor of a more generic long-lived service lifetime. The HostBuilder provides a set of utilities for configuring the host, such as reading configuration items, setting up database connections, and registering services. The Obsidian server itself is registered as a BackgroundService which is responsible for handling startup (database migrations and so forth).

public override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    // Set up server

    Console.WriteLine("Obsidian started successfully!");

    stoppingToken.WaitHandle.WaitOne(); // Wait for a stop to be requested by the `IApplicationLifetime`.

    Console.WriteLine("Obsidian shutting down...");

    // Tear down

    Console.WriteLine("Obsidian stopped.");
}

If we decide to move forward with this, I would be more than happy to be responsible for developing this and submitting a PR (or several).

Edit: I should point out that this will likely be a disruptive change since it involves redesigning the core of the bot as well as its lifetime management. However, I do believe that this will result in aiding future development and promote contributions by providing a well-known DI system.

Adding this feature was decided by a discord poll. Nullable annotation should be enabled in the whole solution.

Add sky light and block light arrays. These are present but commented out. Add the NBT tags to chunk section de/serialization.
REF: https://minecraft.gamepedia.com/Chunk_format

Adding this will allow the server and client to be version independent, making sure that packets will have the same outcome. (referencing the different id shifts and changes in https://wiki.vg/)

uh yeah can we stop using MinecraftStream.ToArray()?

Similarly to #18, it would be interesting to see a feature which brings support for forge mods as well, not just bukkit/spigot plugins.

Now while those are in most cases, direct modifications of the codebase, perhaps it would be possible to bring support for features like RefinedStorage.

I request this feature because of the implications of a C# server being capable of being optimized far more than java. Which would give better garbage collection, and therefore less memory usage.

Client crashes when sent a declaration of certain command. Command with no parameters (except for CommandContext) works fine. Adding one int parameter causes this behavior.

Reproduce by adding to MainCommandModule:

[Command("oops")]
[CommandInfo("This should work, but doesn't!", "/oops <value>")]
public async Task OopsAsync(CommandContext context, int value)
{
}

• Create class
  • Figure out what's the most efficient way of implementing them (plain bytes or data classes)
• Implement minecraft:brand ("null" -> "obsidian" server branding in MC)

Depends on #66.
https://wiki.vg/Protocol#Update_Light

After reviewing a large chunk of files, I've noticed that summary tags are not present to enable natural understanding and reduce the likelihood of open interpretation when working with objects, properties or methods. I would like to propose that summary tags be added to:

• User-Defined Types
• Properties
• Methods

Additionally, if exceptions can be thrown from within methods or the get/set methods of properties then the appropriate exception tags should also be added.

At a minimum, these tags should be present, even if empty to consider this issue completed. This is because having the tags present will help encourage developers that have an understanding of the area they're working in, to add documentation for intellisense to pick up on. It also enables the ability to generate living documentation for the API project.

Depends on #62.

When a chunk is loaded with a load type 31 and below, entities should be ticked. Otherwise, entity ticking will stop.

Commands.TestCommandExec() fails with an exception:

❌ Obsidian.Commands.Framework.Exceptions.InvalidCommandOverloadException : No such overload for command pong

It seems that command groups are not registered properly.

During playtesting, moving an item around inventory, an exception was thrown.

Location

Player.GetHeldItem can return null, but the method's return type is not marked as nullable (even though Inventory.GetItem which it wraps around has nullable return type). heldItem being null then causes an exception, as its properties are being accessed.

This should be an easy fix, but I would also like to note that we clearly haven't fully used the nullable notation and we should. Perhaps we could set nullable warnings as errors (<WarningsAsErrors>Nullable</WarningsAsErrors>) to enforce null-safety? Related: #98

Builds generated by GitHub produce some warnings. these need to be fixed. Check the actions tab for output. Any xmldoc issues that nag about non-existant docs can be ignored for now.

https://minecraft.gamepedia.com/Chunk#Tickets

This feature should be worked on after 1.12.2 has been implemented. Leaving this open for discussion etc.

https://minecraft.gamepedia.com/Player.dat_format

Saved in <worldname>/playerdata/ as <uuid>.dat.
Compatible w/ Minecraft player.dat files.

For a first round, serialize/deserialize gamemode (playerGameType), store spawn location.

Currently, if a plugin is unloaded, its dependencies are not informed. Unexpected or undocumented behavior may occur when attempting to interact with the unloaded plugin.

When a plugin unloads itself for whatever reason, all dependent plugins should be immediately informed so they may handle the situation as is appropriate.

• Send list of all player on login
• Send implement properties (no information AFAIK)
• Send changes of players that left
• Send changes of players that changed their gamemode
• Send changes of players that changed their ping
• Send changes of players that changed their display name

An idea that might be interesting for plugins is adding support for interrupting packets.

My idea of how to implement such a thing:
events. We could have an event that the packet handler passes packets through before sending them, where plugins can choose to modify some values.

Original discussion from #82 (comment)

Commands will be able to be tagged with an IssuerScopeAttribute attribute, which takes an enum of following values:

• None Command is basically disabled (probably remove this?)
• Client Command sent by a player
• Console Command typed into the native server console
• RemoteConsole Command sent by remote console like RCON
• Plugin Command executed by plugin
• Any Flags of all values above

By default, if a command doesn't specify a scope, it will be able to be executed by any issuer (player, console, plugin).

To not force our opinions on what should be executable or not, the config should be able to configure what scopes commands have.

A checklist of packets that are yet to be implemented on master (ordered as on wiki.vg):

Clientbound

• #222
• Spawn Painting
• Statistics
• Block Entity Data
• Server Difficulty
• Set Cooldown
• Explosion
• Tab Complete
• Window Property
• Disconnect
• Entity Status
• Open Horse Window
• Effect
• #67
• Map Data
• Trade List
• Vehicle Move
• Open Book
• Open Sign Editor
• Player Abilities
• Combat Event
• Face Player
• Player Position And Look
• Remove Entity Effect
• Resource Pack Send
• Respawn
• Entity Head Look
• Multi Block Change
• Select Advancement Tab
• World Border
• Camera
• Held Item Change
• Update View Distance
• Attach Entity
• Set Experience
• Update Health
• Set Passengers
• Teams
• Time Update
• Title
• Entity Sound Effect
• Stop Sound
• NBT Query Response
• Advancements
• Entity Properties
• Entity Effect
• Declare Recipes

Serverbound

• Query Block NBT
• Query Entity NBT
• Set Difficulty
• Client Status
• Tab Complete
• Edit Book
• Interact Entity
• Generate Structure
• Lock Difficulty
• Player Position And Rotation
• Player Movement
• Vehicle Move
• Steer Boat
• Player Abilities
• Steer Vehicle
• Set Recipe Book State
• Resource Pack Status
• Advancement Tab
• Select Trade
• Set Beacon Effect
• Held Item Change
• Update Command Block
• Update Command Block Minecart
• Update Jigsaw Puzzle
• Update Structure Block
• Update Sign
• Spectate
• Use Item

Login

• Login Plugin Request
• Login Plugin Response

Remove Newtonsoft.Json dependency in favor of System.Text.Json.

Windows hooks.

I was watching a FitMC video about jeb_ being griefed because some custom server indexer found the server he was playing on. This made me think it might be a good idea to add a "privacy" mode next to the whitelist, where the server will not return online player names after being queried.

Video in question:
https://www.youtube.com/watch?v=fvbVnT-RW-U

This is just an idea, but I think it might be nice to have. Maybe even a super private mode that wouldn't even return queried server info, whatever. I just think it would be nice and interesting. Let me know.

Provide a set of completions, warnings, fixes etc. for plugin developers working with Obsidian.API. For certain code actions, making an extension might be needed (I don't think that analyzers can provide completion for example). This might need additional research and probably will be postponed until Obsidian.API is complete and polished.

Currently we load assets at runtime upon server start. This could be changed so that assets are parsed at compile time and injected into code with a source generator. Startup would be faster and assets wouldn't be included in the build.

I've already tried to implement this, but there is an issue where System.Text.Json is not found during compilation. There may be a workaround of having the dll compiled and referenced directly in the project. Another consideration is using Newtonsoft.Json, even though I tried to move away from it in favor of System.Text.Json. However since it'd be used at compilation time, it wouldn't be a big problem.

Since I already have some experience with source generation, I will assign myself.

When instantiating objects and setting members simultaneously, it can be seen that there are two ways of doing this (sometimes in the same file:

var x = new Something() { Foo = 3 };
var y = new Something { Foo = 3 };

Both are perfectly acceptable, but mixing and matching should be avoided.

This is especially useful for automatically generating API Documentation.

Assigning myself, but any help is welcome.

Our codebase has entities stored with the region and tile entities stored in the chunk. Minecraft stores both in the chunk. Make a decision on how to proceed and implement.

https://github.com/ObsidianServer/Obsidian/blob/master/Obsidian/WorldData/Region.cs#L179

Depends on #62.

When a chunk is load type level 34 and above, the chunk should be flushed to disk and removed from memory.

As stated by @Seb-stian on Discord:

 — Today at 4:26 PM
Roxxel's algorithm is great, but I would change the stuff around
[4:26 PM]
Right now it returns list of hit positions, which is not ideal for performance
[4:26 PM]
And also convenience in many cases
[4:27 PM]
But I will definitely include it at some point

Might be worth looking into it further.

In the future, it may be timeworthy to look into different GC settings. Server garbage collection in particular looks appealing. It should be significantly faster, but also consume more resources (great for dedicated servers?). Needs more research & runtime profiling (when Obsidian creates more garbage).

Workstation vs. Server GC (MSDN)

The new System.Text.Json source generator can

• increase serialization throughput
• reduce start-up time
• reduce memory usage
• help with app trimming

We can already use this feature via a NuGet package, but we may want to wait for .NET 6, where it gets shipped.

This issue depends on #121

Obsidian should randomize seeds when generating a new config. This should be a simple issue to fix.

The current console does not support user input. I don't think we'll ever implement this, because we run multiple servers on one console. A different option is implementing Minecraft's RCON protocol, so we can communicate with one specific server remotely.

https://wiki.vg/RCON

Hacktoberfest edit: welcome! Feel free to tackle this issue if you feel like it. The RCON protocol would have to be it's own class that is able to accept connections and interact with the console in/output from Obsidian. Good luck!

In .NET 6, these new methods were added:

• SinCos
• ReciprocalEstimate
• ReciprocalSqrtEstimate

We should identify places where these methods can be used and use them. For example Entity.GetLookDirection.

Since GPL license is dissalows closed-source projects, GPL license may cause inconvenience for developers that make private projects, and this may affect on Obsidian's popularity. So, please, change Obsidian's license to MIT.

Networking can be made a lot faster and more clients can be handled. The idea is to use SocketAsyncEventArgs, pure TCP Socket and a custom lightweight buffered stream.

Resources:
https://github.com/chronoxor/NetCoreServer/blob/master/source/NetCoreServer/TcpServer.cs
https://www.codeproject.com/articles/83102/c-socketasynceventargs-high-performance-socket-cod
https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socketasynceventargs?view=net-5.0#examples
https://github.com/ObsidianMC/Obsidian/blob/experimental/Obsidian/Net/NetWriteStream.cs

Assigning myself for now

Allow Obsidian plugins to have nuget dependencies. They should be correctly:

• detected
• checked for duplicity
• downloaded
• loaded

There might be a problem with versioning?

Related StackOverflow post
MSDN

Currently the logger shows all messages, this will be annoying as end product of Obsidian, as future server maintainers won't find debug information useful.

Implement flow fields for entity pathfinding. There are some cases, where A* is not the best choice:

• If the graph that needs to be traversed is dense (A common example would be a grid-based graph) ✔️
• If you have hundreds of units attempting to path to the same location ✔️
• If the environment is highly dynamic ✔️
• If there is a constant need to change the position of units ✔️
  (source)

Flow fields can be of great benefit for us. Some things to consider:

• Implementation may be difficult to get right (eg. caching fields)
• We may want to toggle between A* and Flow fields depending on distances and entity count
• Different entities may need somewhat different vector fields (eg. zombie x spider)

For now, A* should do just fine, but I would like to see this implemented in the future.

Another discussion issue, discussing how we should write code.

The server uses a lot of memorystreams to convert data.

Perhaps its a good idea to dispose of these after they get used (to prevent memory leaking) as said by @Craftplacer