Roadmap to CS# Version 2

[roflmuffin]

CounterStrikeSharp 2 Roadmap

As some of you may be aware, CS# was originally based on a proof of concept project to embed .NET into CS:GO. While this concept was a success at the time, it was never intended to be consumed by a wider audience and was essentially a toy project.

For better, or worse, that project morphed into what CS# is today, and as a result, has a variety of issues it has inherited in part due to my personal lack of experience, as well as a rapidly hardening API surface due to immediate uptake on CS2's release.

Therefore, I would like to plan towards a new major version of CS# to incorporate fixes for a lot of the major issues that plague the platform, and invite feedback and ideas from collaborators.

This is not an exhaustive list, but feel free to provide any feedback & ideas in the discussion. There are already some changes being made against the release/v2 branch, so feel free to take a look.

Vector

Vectors, QAngles and other native struct types are currently implemented as native objects which is just plain bad in a variety of ways. The plan for these types of objects would be to use plain old struct types (like System.Numerics.Vector3 and System.Numerics.Vector2) or create those when missing (such as QAngle). This allows for better marshalling across the managed/native boundary as well as for more predictable data lifetimes.

Schema System

Primitives

The schema system currently provides ref accessors for primitive types, which I think personally creates more memory access ambiguity (is the float I just retrieved the float in server memory, or a copy?). With the change to native structs, this leads to even more confusion when using Vectors, as you might expect the access of a Vector3 to be a copy of the server memory but would actually be a ref.

To simplify this process and bring it more in-line with existing game engines, all primitive types would be exposed with get/set backed properties. This means that your Vector sets/gets would need to set the entire object due to struct modification rules evident in C#. This experience is similar to one in something like Godot, for example:

player.AbsOrigin = player.AbsOrigin with { X = 500 };

Network Updates

I would like to code-generate PropertyChanged() methods for each networkable property on an entity. This means that rather than having to know a property's underlying schema name to mark it as changed, you can modify the property and invoke its changed method. For example:

pawn.Health = 200;
pawn.HealthPropertyChanged();

While it would be possible to have this happen automatically during the setter for each property, I think there may be some situations where you do not want to trigger a network update when updating a property so this would be the safer option.

Virtual members

All of the properties/methods on current schema classes would become virtual, allowing for unit tests to mock these objects effectively.

Centralized Event Bus

Currently CS# exposes "Listeners" as a way to hook CS# fired events. Listeners are generally badly named/scoped and hard to find, and do not have their own class structure so are prone to breaking compatibility.

I would like to move the listeners to a centralised eventing system similar to those used in modding frameworks such as Neoforge for Minecraft. This would mean managing and creating more hooks on the native side for common modding use cases and creating abstractions on the managed side for uses in places where Valve is prone to making changes. These events would regularly not be cancellable unless the event has explicitly allowed cancellation (such as take damage).

A good example of this would be creating a dedicated damage pipeline, with its own damage container types that would ideally not be changed from release to release based on Valve changes, and would remove the necessity for all plugins to hook the TakeDamage method.

Mods could also be given an event bus where they can publish their events for inter-plugin interoperability.

Script Context

I have heard concerns raised with regard to the ScriptContext system that CS# uses to marshal data between native & managed. This system could theoretically be swapped out for a regular P/Invoke implementation, though I'm not really sure the benefits outweigh the code churn/effort required to facilitate this change. While a little hard to reason about, the Script Context does provide some benefits. From what I can gather:

Pros:

• Easier native exception throwing
• Natives can be created at runtime (though they aren't currently)
• Single native code execution path, which can be used to run central code (like the main thread checking code) and possibly provides P/Invoke a way to optimize aggressively.

Cons:

• Nested Script Context scopes are not very feasible or hard to understand
• Marshalling into the shared memory must be explicitly handled
• Maximum argument count of 32 (though this could easily be increased)

Static to DI Conversion

Replace the static classes/methods to access engine/server/player information with DI service versions that can be injected into the plugin, for example: IEngineService.GetCurrentTick().

I would also like to implement some stateful services for things like a player list, that maintains an up-to-date cached list of connected players for performance reasons to prevent the use of GetPlayers() everywhere.

[frederikstonge]

Really promising! Good job so far with your project, you made development of CS plugins much easier, and this new version will enhance it even more.

[imi-tat0r]

Your project single-handedly transformed CS2 Server modding to the amazing landscape that it is right now.
Major Versions mean breaking changes so that is gonna suck but I can only imagine what you learned so far and seeing that in a v2 of CS# would be amazing.

Keep up the amazing work