Public Vote, Discussion Log
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:
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. |
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.
|
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 :D
|
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+. |
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. :D |
Quote:
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. |
Quote:
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. ;) |
MMS seems to be doing a pretty good job of providing a platform for plugins..
|
Quote:
|
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... |
All times are GMT -4. The time now is 12:08. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.