CS:GO and moving forward (Plugin developer input) Aug 26, 2017 09:48

So as you may have noticed in the last CS:GO update it took us much longer to fix SourceMod than normal so I'll give a brief view of what happened. CS:GO code on launch had much of the same code as CS:S making it really easy to port the cstrike extension over to CS:GO and make plugins for one work for both for the most part but this has changed heavily over the years as they strip old code out. What happened in the last update is they moved away from weaponids and removed item script files and merged everything into items.games. In doing so they removed functions SM used or are no longer used in the same way (or inlined on windows). This caused our update time to take much longer due to having to find ways to replicate the previous functions/forwards.

When the extension was finally finished we considered it a temporary fix since it isn't very maintainable. Looking forward we want to phase out/remove WeaponID's for CS:GO and switch to item definition indexes. However, doing this will cause some minor breakage/change in behavior for old plugins.

So here is the approach currently being discussed. The id's for the weapons that are currently in the enum will be mapped to itemdefs so internally we will use itemdefs but plugins will see it as the old id's. Anything currently not in the weapon ids enum will use the itemdef index. This will require us to update the include with new itemdef indexes when they are added thus plugin recompiling if they want to use the new values.

This change will break certain weapons as well, currently the extension does some assumptions for weapons that aren't default (cz75a, usp-s, m4a1-s, revolver). Currently it passes the weaponid for the item that it replaces. However, in the case of the cz75a this has been broken forever due to them having different default items on CT/T. So those weapons will be added to the enum separately.

So this thread is for plugin developers to provide input on the solution (perhaps a better one) and also suggestion for new natives that they may want WITHIN REASON. The natives for the most part should be ones that interact with the new CCSWeaponData class or CEconItem(View/Definition). I have final say if they are added or not.
.: by Dr!fter 3 comments

Development Roundup and More! Apr 29, 2017 19:31
It's been quite a bit of time since our last news post, so not only do you get a development roundup, but some other related news spliced in as well!

Metamod:Source stable branch (1.10)

Not much exciting is going on with development of the stable branch of MM:S. However, like SM about 1.5 years ago, MM:S is now officially on a rolling release cycle as of two days ago.

There will be no more "final" releases of MM:S. As with SM, people looking to update their servers after a breaking game update would often grab the latest release rather than a snapshot build, not realizing that they might need something a bit more fresh. In addition to now avoiding that confusion with MM:S, we've also revamped its builds download page, adding similar revision information and source links to what you see on the SM builds download page, and adding support for HTTPS to all downloads.

SourceMod stable branch (1.8)

Similar to the stable branch of MM:S, there's nothing too exciting going on with this. We're continuing to provide many, many game compatibility updates as needed, including updated gamedata files. Additionally, multiple bugfixes have made their way in since this was tagged as the new stable branch a bit over a year ago.

On the note of bug fixes, after weighing the pros and cons, we've decided to switch to GitHub Issues moving forward for future bug reports and feature requests for SourceMod. While this requires users to have a GitHub account to report an issue, many didn't know that the previous bug tracker existed, let alone that they could log in with their forum credentials. (It also unintuitively took forum email address, rather than username). There are numerous stagnant issues there, many that are no longer relevant or that have just been requiring more information for years. This will give us a fresh start. The old tracker is still available, but set to no longer accept new SM bug reports. As before, it will not be for general support or help. The forums are better suited for that.

Metamod:Source development branch (1.11)

Some highlights:
  • Added support for compiling on newer toolchains, such as Visual Studio 2015 and 2017 on Windows.
  • Removed the old v1.4 plugin API.
  • Added v1.6 API support for "ep1" games (The Ship and Source SDK 2006 mods).
  • Re-added support for Dota 2. (This includes initial support for Source2 and x64 dedicated servers!).

On the note of Source2, there has been some stir lately due to rumors that CS:GO will be ported to it in the future. That obviously solicited many questions from people, wondering if SourceMod would continue to work with it.

While we don't foresee CS:GO moving to it anytime soon, having MM:S work on the newer engine was the first step and had been in the works for over a year. There are now four Source2 releases, but Dota 2 is the only multiplayer one, and is more lobby-based than relying on dedicated servers. That's part of the reason that it's a bit too early to say what SourceMod's fate will be on Source2. On the server side, the differences are somewhere between jumping from an older Source variant to a newer one, and the jump from GoldSrc to Source. And similarly to when Source debuted, there is no SDK; we're flying blind.

We've not settled on anything yet, but one of the following three approaches is likely.
  • Add Source2 support to SourceMod. Some whole sets of API just won't work on Source2 or may act a bit differently. Some new Source2-exclusive ones would be added. Our code would become (more of) a mess, but scripts that don't rely on engine functionality would continue to work as-is. Many scripts would still need to be updated.
  • Create one or more new MM:S plugins that just extend the VScript scripting API that already exists in the engine, exposing an admin API and whatever other functionality is missing. No existing scripts would work, but the base of the scripting API is a first-class citizen and would have a much smaller chance of breaking with a game update, as Valve would be maintaining the bulk of it.
  • Create "Source2Mod", porting SourceMod to Source2, dropping support for Source(1) in that copy. Clean up APIs and make Source2 a first-class citizen. The majority of scripts would break, but the familiar SourcePawn language and non-engine APIs would stay the same.

We're not necessarily asking for input yet, just sharing some ideas we're tossing around. They involve differing amounts of work required, and we still have plenty of reverse-engineering left to do to figure out the full extent of what we can do.

SourceMod development branch (1.9)

Some highlights:
  • Added support for Counter-Strike: Classic Offensive and Alien Swarm: Reactive Drop.
  • Added the ability to trigger an entity output directly.
  • Added the ability to get and set entity output variables.
  • Added a native and extended the Database methodmap to allow safe, escaped SQL query value string formatting.
  • Added support for having multiple public and multiple private chat triggers, (such as having both ! and / as private, with no public triggers).
  • Changed the "ep1" builds (used by The Ship and Source SDK 2006 mods) to use the newer MM:S v1.6 plugin API (requiring MM:S v1.11 or later).
  • Added support for compiling on newer toolchains, such as Visual Studio 2015 and 2017 on Windows.

And unrelated to any of that...

Some users have recently expressed interest in having an AM or SM Discord, Slack, or other chat provider set up. While we have no plans to split the community across multiple chat services, I'd like to remind everyone that there is still an active community for SourceMod on IRC (irc.gamesurge.net). The #sourcemod channel exists for anything related to SourceMod - installation help, plugin development questions, and more. There is also an #am-announce channel for those that want to follow development live. All git pushes, issue and pull request openings/closings, and most game updates get announced there as they occur.

For those that don't have an IRC client installed, there are also multiple web chat clients available.
.: by psychonic 16 comments

SourceMod 1.8 Now Stable Jun 05, 2016 10:33
The SourceMod 1.8 branch has now been declared the new stable branch. We will however still provide gamedata updates to the 1.7 branch for at least the near future.

Below is a list of what's new in the 1.8 branch since the last Development Roundup post. Check that out if you haven't yet as the below list is just an addendum.

As always, we'd like to thank the community members that have aided the SourceMod development team by contributing changes this period, including VoiDeD, Powerlord, Peace-Maker, GoD-Tony, FlaminSarge, Tsunami, stickz, splewis, pheadxdll, Benoist3012, 02m, TheCreeper, iNilo, galeksandrp, and Kailo


  • Updated GetMapDisplayName to to match game on Windows. (Uses backslashes)
  • Fixed some crashes in the new File Transfer hooks.
  • Fixed funcommands attempting to use some non-existant sounds on CS:GO.
  • Fixed crash on failing to load dependent extensions.
  • Fixed long-standing crash with late or incorrect calls to TR_GetEntityIndex.
  • Fixed incorrect extension name being printed when dependent extension is unloaded.
  • Fixed potential crash on plugin load when a required library is not found.
  • Fixed potential crash or other side effects with GameRules_Set* natives.
  • Fixed compile errors with plugins that used old [noparse]NormalS[ound]Hook[/noparse] prototype.
  • Fixed all varint sendprops being treated improperly in CS:GO and gamerules sendprops in Black Mesa.
  • Fixed SourceTV bot detection on Source SDK 2013 mods and Black Mesa.
  • Fixed function symbols for static libraries being exported. (On Linux, this caused conflicts with other modules that use libprotobuf).
  • Fixed potential issues on Linux when running on a filesystem that uses 64-bit inodes (such as XFS).


  • Added FireToClient to Event methodmap, for sending events just to a specific client.
  • Added ability for plugins to block entity outputs from firing.
  • Added GetServerAuthId and GetServerSteamAccountId natives.
  • Added CanBeAutobalanced hook type in SDKHooks for games that use the SDK implementation (TF2, FoF).
  • Added new HasEntProp function to easily check an entity for the existence of a property.


  • Clarifed documentation for GetMaxEntities, GetEntityCount, IsValidEntity, and IsEntNetworkable.
  • GameRules_Set* natives now network changes by default, similar to SetEntProp* natives.
  • Returning Plugin_Changed in event hooks now behaves like Plugin_Continue rather than Plugin_Handled.
  • Added warning print when gamedata is loaded from the "custom" folder to make issues easier to diagnose.
  • Converted all SourceMod includes and more base plugins to use the Sourcepawn Transitional Syntax.
  • FindSendPropOffs and FindDataMapOffs have now been deprecated in favor of FindSendPropInfo and FindDataMapInfo.
  • Removed support for compiling SourceMod against old Source 1 Dota 2 SDK.

The Stable Builds download page now points to 1.8 builds, although 1.7 ones are still available and linked there. The Dev Builds page now points to the brand new 1.9 branch.
.: by psychonic 100 comments

Recent CS:GO "GSLT" bans and SourceMod Mar 02, 2016 18:29
Most Counter-Strike: Global Offensive server operators are aware of Valve's relatively new server "guidelines" that have been posted on the CS:GO website, http://blog.counter-strike.net/index.php/server_guidelines/. However, there are still some users that are finding themselves having their accounts' Game Server Login Tokens banned without understanding why.

To try to help avoid users unintentionally triggering the rule-breaking detection in CS:GO, we have added a new opt-out feature that will block plugin behavior that we know to be triggering this. We probably haven't caught everything, and detection can change in future game updates, but we feel that this is a good place to start. It's also possible for plugins to bypass this intentionally or otherwise, but it covers the most common cases and we do plan to make it more robust with future revisions. This feature, controllable by the new "FollowCSGOServerGuidelines" option in SourceMod's core.cfg file (default "yes") is available in SourceMod builds, and later. If you really desire to put your account in jeopardy, you can also disable it right in the cfg file with minimal hassle. None of the logic is active for games other than CS:GO.

With the "FollowCSGOServerGuidelines" option enabled, when a plugin attempts to use functionality that we know to be red-flagged, an error will be thrown. As with any native errors thrown in SourceMod, execution of the function will be halted and an error recorded to console and the error log. The error will give details on what specifically was done to trigger it.
.: by psychonic 39 comments

SourceMod Development Roundup (1.7.2 - 2015/11/03) Nov 03, 2015 08:44
This covers all commits to 1.7 since the release of 1.7.2.
Now that we're on a roling release cycle, I'd like to do a roundup like this semi-regularly (depending on interest and commit frequency) to replace the old release changelogs.

  • The normal set of gamedata updates for numerous games.
  • Worked around a case where client connections could desynchronize, causing authentication information to persist across players.
  • Fixed a rare crash in the TF2 extension due to a missing IsFree() check.
  • Fixed cases where IsCharAlpha/IsCharNumeric/IsCharSpace/IsCharUpper/IsCharLower could return incorrect data.
  • Fixed ConVar.*Value property setters not working correctly.
  • Fixed mouse movement values in OnPlayerRunCommand for TF2/CS:S/DoD:S/HL2:DM.
  • Change default path ID to "GAME" instead of NULL for valvefs-using filesystem natives.
  • Fixed SQL_SetCharset potentially misbehaving when used with threaded operations.
  • Improve allocation policy for datapacks to save memory.

SourcePawn Fixes (Need to recompile plugins for these)
  • Fixed an issue where some unary operators could return incorrect data.
  • Corrected oversight with view_as<>(...) where it could compile with missing parenthesis.
  • Fixed a compiler crash with invalid array initializers.
  • Fixed parameter list of DBResultSet.IsFieldNull.

New Features
  • Added support for Modular Combat.
  • Added support for setting string_t Prop_Data fields (such as "m_target") to SetEntPropString.
  • Added array support to SetEntPropString.
  • Include datapack memory allocation in handle dump.
  • Added new condition / holiday constants to tf2.inc.
  • Added FindMap native.
  • Added GetTeamEntity native.

As always, I'd like to thank the SourceMod team and members of the community contributing changes this period - including Powerlord, FlaminSarge, Thordin, WildCard65, and PeaceMaker.

Most interesting development takes place in the development branch (1.8) and I am currently working on a roundup of that (there is a lot!) - so hold on to your hats!

As for what is coming in the future...
This is all 1.8 changes since forking off 1.7 (also everything already listed above).
There have been a lot of commits moving around SM internals to facilitate future work.
Some stuff may have been missed, some stuff may have snuck in that is in 1.7.x before 1.7.2 - future updates will be a lot easier to compile.

  • Corrected buffer sizes for player and map names in numerous base plugins.
  • Corrected numerous spelling mistakes throughout the config files and API documentation.
  • Fixed methodmap chaining using the wrong value when used as a default parameter.
  • Fixed "sm plugins refresh" not reloading changed plugins.
  • Fixed a misleading error message from "sm config".
  • Increased buffer sizes for PrintTo*All stocks.
  • Fixed FindFlagChar returning false when given custom6 flag.
  • Notify plugin listeners of SetFailState'd plugins on unload.
  • Pause dependent plugins on SetFailState.
  • Fixed an issue with asynchronous queries potentially completing after plugin unload.

  • Added support for Black Mesa.
  • Added SetClientName native.
  • Populate MaxClients before OnPluginStart is called.
  • Added support for listening to, blocking, changing, and faking ClientCommandKeyValues.
  • Introduced a datapack position tag to avoid common mishaps with SetPackPosition.
  • Added GetMapDisplayName native to assist working with workshop maps.
  • Added EmitSoundEntry native and updated AddNormalSHook with support for newer engine features.
  • Added File Transfer hooks to SDKTools.
  • Updated convar flags to match modern engines.
  • Added offset printing to datamap dumps.
  • Include date information in property dumps.
  • Changed map history storage limit to be configurable (sm_maphistory_size).
  • Added TE_SendToAllInRange native.
  • Added GetEntityRenderColor stock.

  • Updated large swathes of the API to use methodmaps.
  • Removed methodmap native binding syntax.
  • Moved the git revision to the 4th version number component.
  • Removed lots of unused gamedata.
  • Killed off the INativeInvoker extension API.
  • Enable SDK independence with MM:S enabled extensions.
  • Huge amount of refactoring moving code from Core to Logic (smaller download, faster builds).
  • Huge amount of refactoring to SourcePawn VM internals:
    • Faster, safer, easier to maintain plugin loading and unloading.
    • New error handling model with better stack traces.
    • All functions can now be used as callbacks.

.: by asherkin 35 comments

1 2 3 ... 30
© Copyright 2004-2024 SourceMod Dev Team