[rhelgeby]

Background info

SourceMod is a really cool framework with a nice API and simple scripting language. In the past two years I and Greyscale have worked on a pugin that's gets bigger and more complex. Now it's complex enough that I feel limited by the SourcePawn language. We could just use C++ and write it as a extension or Metamod plugin, but for some reasons I don't like that:

• Metamod plugins/extensions are running on the bare metal. Mistakes may cause catastrophic outomes (usually crashes the server). Programmers are humans, and humans do make mistakes - and some mistakes are not fun to debug. SourceMod plugins go through a layer of abstraction with SourceMod's API. Theoretically a plugin cannot crash the server because the plugin is isolated from the server and the API validate data in native calls. Yes, there are exceptions, but then you have to mess with objects in the engine and set invalid values (entities, etc.), even those could have validation.
  
• Server updates may break compatibility so the extension/Metamod plugin has to be fixed and recompiled against SDK changes. What's nice about SourceMod is that only SourceMod itself is affected by this, where most of the plugins work fine after SourceMod is updated. Offsets and function signatures may break plugins, but updated game data files fixes that.
  
• SourceMod plugins are platform independent, extensions and Metamod plugins must be compiled once for each platform.

What I like about SourceMod is its API and the easy access to common stuff in the game engine. Since it's also a server administration plugin it makes it easy to restrict features in plugins for certain players, or do other kinds of authorization.


Using Java instead of (or in addition to) SourcePawn

I wonder how it would be if SourceMod would support plugins programmed in Java. As with SourcePawn there would be a API to access SourceMod and the game engine. The API would be a bridge to the Java language.

It would be nice to make plugins in a object oriented language with interfaces, inheritance and polymorphism - and without worrying about coding mistakes in C++ that would crash the server (isolated from the server, but still communicating with it).

Would this be technically possible, and is it "easy" to implement (provided that the new class API is already made)? Obviously, the plugin would need to run in a separate process on the JVM. SourceMod must some how be able to communicate with the Java program to handle native calls and send forwards.

So, what it's all about is SourceMod controlling a Java program, and a Java program being able to do stuff in SourceMod and the game engine. How would something like this work out?

Is anyone else than me interested in programming plugins for Source servers in Java?

[Powerlord]

Disclaimer: I currently work as a Java Developer.

I can see a few problems with this:

1. SourcePawn runs from an interpreter within SourceMod. You'd either need to embed a Java VM into SourceMod itself or arrange some sort of IPC mechanism.
2. If you do embed a Java VM, you end up having to embed a bunch of the Java class library as well.
3. IPC has its own set of problems depending on how you do it. The first of which is that Java would be running as a separate process and would still be running when the server shuts down. Now, if you're talking back and forth through Sockets, you'd be able to tell when the other end shuts down, but things like shared memory (SHM segments and the like) you wouldn't.

Seriously, though, why Java? There are other languages that would likely be easier to embed... Python maybe?

[rhelgeby]

It would be with IPC where the Java plugin is separate from SourceMod, I'm not talking about embedding JVM into SourceMod. And I used Java as an example because I already know it. Other languages would work too, but I like the Java language.

I'm interested in ways for implementing this without forking or embedding stuff, just updating SourceMod to use external programs as plugins.

The Java plugin would have some kind of main method where SourceMod remotely trigger a call to that method. In the plugin it could make one or more listener objects for events and forwards.

SourceMod would provide some natives in Java that plugins use to communicate with sourcemod.

I'm not sure how they would be able to communicate. Local sockets would be one way, but I'm sure there's other ways too. If it's general enough SourceMod could in theory have multiple plugins in different languages - and still be able to exchange data between each other through SourceMod.

[GoD-Tony]

Ideally, everything that is available to sourcepawn should have an interface for extensions (especially SDKTools). Then you would still be running through SourceMod, and your extension wouldn't break on updates, much like pawn.

I think it's a more realistic solution rather than implementing another language, and it would allow large pawn plugins to be transferred to extensions with ease if necessary.

[rhelgeby]

That would be cool too, but doesn't all extensions get direct access too all natives too (without need for casting between cells and other types)?

I forgot to mention the Viper extension that makes it possible to make plugins in python. This is almost the same as with Java plugins, but without JVM or anything being embedded.

As you've mentioned, a common interface for extensions would be more useful. Then extensions could be made as a bridge to other languages.

[asherkin]

Originally Posted by GoD-Tony Ideally, everything that is available to sourcepawn should have an interface for extensions (especially SDKTools). Then you would still be running through SourceMod, and your extension wouldn't break on updates, much like pawn.

Extensions are meant to provide features (natives and forwards) to plugins.
They are meant to extend what SourceMod provides for developers, not provide user-facing functionality.
That's how the API is designed and meant to work.
Yes, people do actually do other things (like implement everything in the extension), but that's outside of the design scope.

Originally Posted by rhelgeby That would be cool too, but doesn't all extensions get direct access too all natives too (without need for casting between cells and other types)? [...] Then extensions could be made as a bridge to other languages.

Things such as INativeInvoker exist for exactly this purpose, so that extensions can implement a whole new language.
Viper does exactly this, not sure what the issue is here? Everything you need to write plugins in Java (or any other language) can be made entirely in an extension and integrate flawlessly with both extensions and plugins in other languages.

[GoD-Tony]

Originally Posted by asherkin Extensions are meant to provide features (natives and forwards) to plugins. They are meant to extend what SourceMod provides for developers, not provide user-facing functionality. That's how the API is designed and meant to work. Yes, people do actually do other things (like implement everything in the extension), but that's outside of the design scope.

When I thought of extensions, I thought "C++ SM plugins", but what you said clears it up. I guess I should have taken the name more literally.

[DeaD_EyE82]

Sorry for raping your Thread, but I think Python-Support for SourceMod is a musthavefeature. The good thing is, there are many developers which are using Eventscriptsython at the moment. Python will give us an better understandable code and object-oriented programming.

So before you are thinking about java, do first realize the python support, wich will give us much more developers.

[BAILOPAN]

We are not going to use JVM or Python, ever. JVM is too bloated and as a language is dead and verbose. It also requires serious, complex technology to deal with the GC performance problems. Python is a nice language but its implementation too slow and has an unreasonable threading and isolation model. Mattie has given talks about how painful it is.

I am strongly against embedding multiple languages in SourceMod because it dilutes the local ecosystem while making support, compatibility much more difficult. There are other paths forward. The answer to, "why not embed X?" will simply be "no" - it's a waste of time for me to argue and I'll just risk offending someone. (And I do have candidate ideas for languages we could migrate to, but this is all extremely hypothetical, and contingent on having certain features in place.)

If there are specific things you're looking for in SourcePawn, or a specific language feature, please make a thread or bug report and we can talk about it there. There are paths forward other than throwing away everything we have.

EDIT: Also, I don't want Snoracle suing me for using Java.

[BAILOPAN]

It's also worth noting that the work required to embed a new language is enormous. There's just no way any one person is going to do it. It took two years, a team of developers, and lots of community contribution to get SourceMod+Pawn to where it's at now.

Adding a new language, you'd end up with an entirely separate project and community. I think that's the best way forward for experimenting with new languages in Source - SourceMod's extension system can be used to abstract some things, but it's just not worth it as those APIs aren't really what you want. You really want a clean slate to tightly couple the language style with the way you interact with Source. There are other paths, like EventScripts 2.0 which supports two languages, but the economics of EventScripts are very different (reasons are out of this scope but I can talk about them if needed).

In terms of fixing things in SourceMod, I'm very much use-case driven. If there are specific problems, certain language features that would make things easier, that's where we should look. Changing SourceMod is ultimately easier than reimplementing the whole thing - easily over 100KloC