[Dygear]

This is to the devs.

Source Mod is now a 7 year old project and with everything you have learned what would you have done different if you had the chance to do it all again? I'm talking about anything that has bothered you over the past 7 years, what have you learned, what turned out to be a great idea, and what turned out to be a bad idea.

I ask, because I have a project that is similar to SourceMod and I want to learn from your mistakes and successes. I want to know what was a great idea, and what was a terrible idea because that's how we all learn.

[sinblaster]

Wouldn't you be able to get a good idea from looking at the changelogs for each version change. They would clearly state what was removed and in some cases state why. etc ..

[zeroibis]

I do not think he means the type of thing that would appear in a change log. He is trying to find wisdom not knowledge.

[Dygear]

Originally Posted by zeroibis I do not think he means the type of thing that would appear in a change log. He is trying to find wisdom not knowledge.

Thank you, that was my point.

[BAILOPAN]

I have trouble labeling anything as a "mistake," because by and large, we didn't know what we were doing. We just knew what we didn't like about AMX Mod X and somewhat managed to solve those specific problems. As you said, these projects are evolutionary and each iteration you approach something you're a little happier with.

If I were to do SourceMod over again, the biggest thing I would change is dropping Pawn for a dynamically typed language.

• Most important, the interaction between plugins and Core is bad. The interop layer is expensive. We did a lot of work to optimize it in SourceMod but really what's needed is a new, more expressive language, with a less CPU-ish bytecode and a JIT that understands foreign functions. Right now we can't do SDKHooks sanely without having a mess of Handles to close. Plugins also have to jump through insane hoops to act as "libraries" and provide shared functionality.
• Self-hosting SourceMod, entirely. That is, writing the Core as scripts. This is surprisingly important for a number of reasons. It makes it much easier to ad-hoc support new games. Right now, per-OS, we're shipping around 7 builds of Core (that's like 2MB) each with basically a few tiny changes to account for the different interface layouts. Alternately, we could have factored out engine stuff early on, but it's hard. FFI can be fast and a self-hosted Core would let us distribute updates and take community patches much easier. Builds would be like 10X faster too.
• Pawn is unsafe and has no heap. Type errors are easy and can lead to crashes or memory corruption. People want composite types (records, structs, whatever) and sane dynamic arrays.
• Static typing makes it difficult to express the HL2SDK variations. It ends up being verbose.
• The compiler produces binaries, which makes it much easier to lose your source. We've also seen people slide backdoors in or violate the GPL.

Who knows, these ideas could end up being sub-optimal too. But I have a feeling we would be better off.

[Dygear]

Thank you BAILOPAN, it's something to think about.