Source2mod

Where to contribute ?

We're currently still getting the sdk ready. Head over to hl2sdk and contribute towards the efforts.

What is this issue about ?

This issue aims at summarizing and compiling the answers given on both github and discord, regarding the direction in which the project is headed.

Will Sourcepawn be a supported language ?

Yes.

Why not extend VScript instead ?

No, most agree that VScript is

• unsuitable for server operating needs
• would tie the project too closely to valve's internal implementation
• its current state is unknown, and we're waiting on cs2 release to know more

What is the main scripting language ?

Sourcepawn is the main scripting language. Javascript/Typescript seem to be desired, but will not be explored until reasonable arguments have been made as to why we should.

Plugin Scripting API

Nothing has been decided yet.

What is the main scripting language ?

Why not instead embed WASM runtime as VM. I think wasmtime, wasmedge, wasm3 all can be embedded in an app. With some SDK magic you can provide interface to VM that can be called from any language.
At this point it doesn't matter what's the scripting language because you can use any language that can be compiled as WASM/WASI.

I would love to see javascript / typescript this would lower entry for everyone to start code their own plugins and contribute since pawn is barely known. Hopefully this will be reconsidered :) new engine new start…

Javascript/Typescript seem to be desired, but will not be explored until reasonable arguments have been made as to why we should.

JavaScript/TypeScript are pre-established high level / user friendly languages. I think it'd make contributing to CS2 plugins appeal to a much wider audience than the existing SourcePawn implementation. Another good thing about using JavaScript/TypeScript is that it would potentially allow the exploration of packages / libraries for CS2 plugins installed via NPM. I wonder if it'd allow us to install plugins onto a server via NPM (or potentially a custom package management solution) rather than the old rather non-standardised way? My question would be what would the ideal JavaScript/TypeScript solution look like, and what is really possible?

TL;DR A JavaScript/TypeScript implementation makes it easier for newcomers, and opens the door for a more sophisticated server plugin management which utilises Semantic Versioning further down the line.

If the implementation will depend on V8 as in NodeJS to work in rantime. Then we can start buying RAM for servers with a large number of plugins. (30Mb per plugin = 3GB per 100 plugins (average statistical server).

you won't be initializing the runtime more than once. You will probably have a ("plugin manager","cordinator","orchestrator" -- insert whatever fits in here) that will loop through the plugins and call the relevant code/events w/e.

For me it would make more sense to be able to write C++ modules for SourceMod with the ability of adding a language support. Basically leave the flexibility on the community to expand on the language support. I would personally be interested on creating a module for C# by embedding the CoreCLR.

I understand that might make the ecosystem of plugins... difficult to moderate, but i'm confident with a proper discussion we can probably solve all of the problems.

I would personally be interested on creating a module for C# by embedding the CoreCLR.

Hello, I'm trying to do this, but I'm not experienced in CS modding/scripting, you can add me in discord Gazzi#6131 if you want to discuss or contribute

I would personally be interested on creating a module for C# by embedding the CoreCLR.

I have a project doing exactly that: https://github.com/roflmuffin/CounterStrikeSharp

What is the main scripting language ?

Why not instead embed WASM runtime as VM. I think wasmtime, wasmedge, wasm3 all can be embedded in an app. With some SDK magic you can provide interface to VM that can be called from any language. At this point it doesn't matter what's the scripting language because you can use any language that can be compiled as WASM/WASI.

The prospect is certainly enticing, as it would allow for the utilization of practically any native language capable of being compiled into WASM, while also maintaining support for SourcePawn. The implementation might require a considerable investment of effort, though.

The implementation might require a considerable investment of effort, though.

Is there any particular reason why this might be the case? I would expect WASM to actually be equally easy or far easier to implement than wiring up a JavaScript runtime interpreter. Not to mention it would probably be far lighter internally to do so.

There's also ways to run JavaScript in a WASM environment, so we wouldn't even have to worry about fighting for which languages we want to support!

The implementation might require a considerable investment of effort, though.

Is there any particular reason why this might be the case? I would expect WASM to actually be equally easy or far easier to implement than wiring up a JavaScript runtime interpreter. Not to mention it would probably be far lighter internally to do so.

There's also ways to run JavaScript in a WASM environment, so we wouldn't even have to worry about fighting for which languages we want to support!

Good to know. Honestly, I'm not completely familiar with the internals of SP.