[BAILOPAN]

Today's public discussion on SourceMod ended very well. I appreciate the people who took the time to join, ask some great questions, and give their support to the project.

A log of the chat is attached to this news post.

We decided to hold a public vote on the continuation of the project. The problem is that we don't like any of the existing programming languages. Only Small has a perfect blend of amazing speed, simplicity, and our own support code. On the other hand, Small is quite lacking. The code is very old and difficult to maintain. We came up with two options:

• Delay SourceMod, and all of the big design considerations we wanted to solve and perfect. Spend the next year writing a new language and codebase, then restart SourceMod with our new codebase.
• Restart SourceMod using AMX Mod X code. That is, the important language pieces such as the debugger, compiler, VM, JIT, and the various modules it has.

This poll is not about choosing a different language. This poll is about the fact that if we're going to relearn a new compiler+VM+JIT from scratch, we want it to be one we write to be perfect. So, we'll either spend the time writing something new, or just use the old cruft from AMX Mod X.

It's important to realize in this poll, that either way, SourceMod is not a magical answer to Source. Certain things, like HUD Messages and mod-compatible menus, are simply impossible to do without Valve reversing their own decisions. AMX Mod X plugins would not be backwards compatible without modification because of Source's limitations.

[Dag]

There is no point in putting out something that isn't what you really want. Always make something the best it can be, and if that means a delay, then so be it.

[Spectral]

I agree i would be much more satisfied with a product that i enjoy working with. Hold it off until you feel it meets yours and the communities needs. Plus i would like to have a new scripting language

[bOoya]

As it stands, if people want a really customized server. they have to install a bunch of different plugins. Mani or beeteles for admin features, statsmeminimum for psychostats capabilities and stats announcements, matties mod for event hooking and all that jazz.

As a server admin and support technician for one of the largest CS:S server providers in the US, it's a nightmare to support all of these.

With amxmodx, everything for the most part is standardized. Most plugins are very simple to install, and I can handle people saying "I want this and this and this and this...".

Therefore, while I am intrigued by the benefits that a new language could provide, I think that the other option is better for now, and maybe the new language could be developed over the next year+.

[ObyWonkyKnobby]

The longer things are delayed, the bigger interim plugins become, e.g. mani's plugin has grown from a few hundred KB to 2MB in size. These plugins are also not very modular, I can't currently choose to have voting & kicking but not have say, noclip and stats loaded into memory, granted they can be disabled, but they're still in memory.
As more and more features are added to these plugins, the bigger they'll get and the more resources they'll consume.
There's also no solid way to add extra functionality, without using something like Matties event scripts, which again adds another plugin to the mix and yet more resources used than are strictly necessary.
IMHO, the sooner there's an amxmod/adminmod like plugin the better.

[devicenull]

Originally Posted by booya As it stands, if people want a really customized server. they have to install a bunch of different plugins. Mani or beeteles for admin features, statsmeminimum for psychostats capabilities and stats announcements, matties mod for event hooking and all that jazz.

There is nothing wrong with that.. in fact that's the way I prefer. You modularize all your plugins, so you can install what features you want, rather then having one uber plugin with every single feature in it..


What I had tried to start, but it never caught on (perhaps because the interface sucked), was each plugin providing fairly simple functions for other plugins to use.. so you could say have 10 different ways of loading admins, and you would choose one and install it.. And to switch to another method, you would just unload the first and load another. Thats the way that I see things working the best.

[bOoya]

Originally Posted by devicenull There is nothing wrong with that.. in fact that's the way I prefer. You modularize all your plugins, so you can install what features you want, rather then having one uber plugin with every single feature in it..

Right, I don't want one single plugin to rule them all and in the darkness bind them. I just want one platform, and then individual plugins to do different tasks. With mani and mattie right now, they're so different. And then the MM:S plugins... its just a big pain.

Im saying we need something to bring them all together, eg. amxmodx for cs1.6.

Of course I realize thats the goal of Sourcemod, I'd just rather have it sooner than later. ;)

[devicenull]

MMS seems to be doing a pretty good job of providing a platform for plugins..

[bOoya]

Originally Posted by devicenull MMS seems to be doing a pretty good job of providing a platform for plugins..

Yeah, a lot of the other plugins like mani are beginning to convert over to MM:S, and that will make things easier.

[rACEmic]

While #1 would be ideal, it seems that CS 1.6 still trounces all Source mods handily in player traffic. That said, is it really worth spending the energies developing a superior codebase for a smaller audience?

Deriving SourceMod from AMXX code is a simpler solution that will hopefully jumpstart the community faster. Although an elegant solution would be nice, it seems like a marginal gain for the effort expended.

The best argument I can think of for #1 is if it would provide plugin authors with expanded tools (i.e. entity manipulation, event hooking) that cannot be done with #2, but it seems that's beyond the capacity of this project and only in Valve's hands...