Drop it in your /steamapps/common/Team Fortress 2/tf/custom folder!
Currently version 1.04 - 1/11/2019
Mann vs. Machine (MvM) is a co-op game mode released in The Mann vs. Machine Update. In this game mode, a team of up to six players attempts to prevent a horde of AI-controlled robots from escorting a bomb to a drop-point located in a Mann Co. facility. During the game, players can purchase upgrades for their weapons and various abilities (resistances, movement speed, regeneration, etc.) using currency obtained by killing the robots, called credits.
All purchased upgrades will last for the duration of the game, or until the player resets their abilities at an Upgrade Station. If a player leaves the game for any reason their upgrades will be retained, providing they reconnect, as well as any credits the player has spent and/or has remaining.
Mann vs. Machine mode currently has five separate difficulty levels: Normal, Intermediate, Advanced, Expert, and Nightmare.
More details here: https://wiki.teamfortress.com/wiki/Mann_vs._Machine
SCG Mvm isn't too different! However, our MVM mode allows for up to 10 players, and the overall difficulty scales per player. It scales backwards for smaller games, and harder for fuller games.
[size=14pt]What is it?[/size]
GScramble is the scrambler / balance system SCG uses, ours however is specially modified to fix a few different issues. This plugin is designed to help balance the teams, and scramble player order whenever stacking / steam rolling is detected. It also has blocks in place that stops players from stacking , should they want to do so.
[size=14pt]Commands[/size]
[color=orange]!prefrence - Allows you to select a team you prefer when the server does a scramble. This does not guarantee that you will be sent to this team.
votescramble / scramblevote / sausage - Chat triggers to indicate you want to vote for a scramble.
[/color]
[size=14pt]How it works[/size]
The following are written explanations of various settings we have. They are not in any order so sorry for the randomness of their arrangement. These are the settings that can be voted on to be changed if you disagree with their set up! Don't be afraid to speak up!
[size=12pt]When a scramble can occur[/size]
When a team has won twice in a row.
When one team has failed to ever capture a koth point during a round.
When the frag ratio is greater than or equal to (2.0)
When a round has ended in less than (2 minutes)
When a the average score difference is (10)
When the average domination difference is (5)
The following round after a vote to scramble has passed.
[size=12pt]Scramble settings[/size]
If a scramble happens during round setup, medics will have their ubers recharged.
If a scramble happens during round setup, the timer will reset.
No one is immune to scrambles.
When a scramble occurs, it will scramble the teams by class composition to create a better mix of teams.
Scrambles will not happen unless there are 8 or more people in game.
Vote scrambles are possible with 6 or more people in game only.
Vote scrambles that pass will happen when the current round is over.
[size=14pt]Balance settings[/size]
Players who have capped a point / intel within 60 seconds of balance will be ignored.
Players dueling will be be ignored.
Engineers with buildings will be ignored.
If an imbalance (2 player diff) is detected, the teams will balance within (10) seconds.
If a strict imbalance (4 player diff) is detected, the teams will auto balance immediately.
Teams are auto balanced at the start of each round.
[color=orange]SCG ONLY : The auto balance will balance by LOWEST SCORE. Meaning if you have the lowest score on your team, you will be pushed to the other if you have to. This was put in by special request by me and done by our own Dr.Krunklehorn. I wanted this after noticing many occasions where random and often very loyal players on a team were kicked off to a team they may of been spending a whole round killing.[/color]
[size=14pt]What is it?[/size]
The AFK manager is exactly what it sounds like. It's a manager tool designed to regulate and deal with AFK players. Before this, the way AFK handleing worked as anyone AFK for 3 minutes would be kicked. This lead to a lot of complaints about afk players on a team causing natural imbalances. If these players were kicked, many times they'd rejoin with harsh words about being afk for only a few moments or as one person put it to me "not allowed to get up for a glass of water".
So now, this AFK system will push you to spectate after being AFK for a minute. Then after two minutes of being in spectate, you are then kicked. Meaning, you still have 3 minutes to be AFK. But only a minute to actually stay on your team. I feel this is a better option as it allows you to deal wit hwhatever while not mucking up your team.
Let's get this out of the way, this is not a pay for play / pay to win / pay anything whatever thing. This is entirely based on credits you earn while playing on SCG servers!
The SCG Loyalty Store allows you to set your name color, chat color, and species tag for use in the server!
Exactly as the name implies, it's the color of your player name!
Ditto. But this time your chat color!
This lets you set a species tag prefix in your name. For example, mine is [Crux]. Your species not on the list? Let me know!
| Command | Description |
|---|---|
| /store | Opens the store menu |
| /inv | Opens the inventory menu |
Protocol Override is a difficulty mod for the SCG MVM servers that adjust the game's overall difficulty for games with 7 or more players.
The problem with hosting a 10 player MVM server is that the extra four people often make games far too easy. Even on the harder missions, the extra help tips the scales in favor of the humans. This plugin aims to change that. The difficulty of the game is adjusted into tiers based on groups of two players.
| All Robots |
|---|
| All robot movement speed is reduced by 20% |
| All robot crits become mini crits |
| There is a 3 second delay before a robot with the bomb will begin to jump in the silo. |
| All Robots |
|---|
| All robot movement speed is reduced by 10% |
| All Robots |
|---|
| Everything here is totally normal, no adjustments have been made at all. |
| Giant Robots |
|---|
| Giant Robot speed is not adjusted |
| 5% Damage Bonus while half dead |
| 40% Health Boost |
| Mini Boss Robots |
|---|
| Boss Robot speed is not adjusted |
| 5% Damage Bonus while half dead |
| 33% Health Boost |
| Robots |
|---|
| 20% Speed Bonus |
| 25% Damage Bonus while half dead |
| 40% Health Boost |
| Giant Robots |
|---|
| Giant Robot speed is not adjusted |
| 10% Damage Bonus while half dead |
| 75% Health Boost |
| Mini Boss Robots |
|---|
| Boss Robot speed is not adjusted |
| 10% Damage Bonus while half dead |
| 67% Health Boost |
| Robots |
|---|
| 40% Speed Bonus |
| 50% Damage Bonus while half dead |
| 75% Health Boost |
Robots that are teleported are adjusted differently, they are slightly less powerful than traditional bots. If the bomb is near the final point, teleported bots have much less of a speed boost and are weaker than their normally teleported counterparts. Teleported bots are only adjusted in the 7-8 and 9-10 player tiers.
Spy bots never have speed bonuses attached to them regardless of size.
Donating to SCG grants you a bunch of little cosmetic things on our Team Fortress 2 servers, they are cosmetic only, no pay to win garbage!
The end of round sprite is exactly as it sounds, you can select a little sprite to show up above your head at the end of a round!
Hello! This post is dedicated to the assorted plugins, commands, tools and features you'd find on SCG that aren't large enough to be split into individual threads!
| Command | Usage |
|---|---|
| /hug <name> | Hugs a player |
Hello friends.
Today I come to you with a very important announcement...and a story. This is probably the most ... important thing that has happened in quite some time...
We, Fraeven and I, believe we have isolated and fixed the infamous payload cart bug. If you're a SCG regular of any age, you'd know about it. The bug is pretty simple :
Occasionally a round of payload will start and the hud reports an incorrect placement of the cart, the cart often is unable to reach the end of the track leading to either a crash or simply an unwinnable scenario.
An example can be found here :
The bug appears to have been caused by poor programming in the donator recognition plugin's donator array being offset and deleting entities entirely at random when trying to delete donator sprites at the end of rounds/games. Through debugging, we caught the following instances of incorrectly deleted events.
Debug - T name : zz_red_koth_timer, C name : team_round_timer
Server cvar 'mp_timelimit' changed to 25
[SCG] A fatal error has occured with the KOTH timers, the round was reset to prevent a crash!Debug - T name : minecart_path_146, C name : path_track
Debug - T name : minecart_path_153, C name : path_trackDebug - T name : , C name : logic_auto
Debug - T name : , C name : tf_wearable
By deleting entities randomly, this is what has caused numerous map issues. Most notable here is the first example in which the zz_red_koth_timer prop is deleted and triggers the band-aid koth timer fix plugin.
After extensive research, this bug as been found to be related to a number of issues.
A fix has been developed and installed on both Chocolate and Rainbow that should prevent anything but the donator sprites being deleted properly.
Now you may be wondering? Why is this so important exactly? It's happened before, you guys just reset the round correct? This is important because this is the oldest bug SCG has ever had. It has followed us through server installs, host switches, and has been around for almost the entirety of SCG.
In the earlier days, it used to crash the server if left unchecked, this doesn't happen anymore because whenever it happens we've just immediately reset the round. This bug is similar to that of the koth timer problem, a problem I was able to "fix" by writing a plugin that detects a broken koth clock and resets the round automatically, then restores the time left. But due to the random occurrence, I never had much to go on nor could I dedicate too much time to it.
Fast forward to today, Fraeven was wanting to help understand and fix the problem, or at least develop a similar band aid to find broken payload carts. Over the last couple weeks, we've been doing tests here and there; pouring through Valve wiki pages and copies of the TF2 source code to try and understand where things go wrong.
Our first goal was to try and recreate the bug consistently, during Friday night gaming and other nights of playing when it'd happen, I had tools running to check and see what TF2 was doing. We attempted to see what maps were causing it, what conditions, etc.
Trial and error led to some interesting discoveries but ultimately nothing useful. Very quickly I was able to rule out it being a hardware problem, as well as a configuration problem. SCG servers have always had this problem be it Windows or Linux. I compared the server settings against a Valve stock server and found no major differences that would cause any sort of issues.
In our core tests, we've been running chocolate with an elevated timescale with and without bots on all sorts of payload maps to attempt to make the bug happen. Nothing would ever happen until last night, when we finally saw it happen by ourselves. It's actually a funny story even, we almost missed it entirely. I wasn't paying attention to my screen and caught it at the last moment during the waiting for players screen on pl_halfacre. With coffee in my mouth I made a silly noise and slammed down on my screenshot button :
This was big news, we made it happen finally among ourselves. Soon after, we learned how to reproduce it! And here is where things get weird...
We know the following details.
While not super precise, our method wound up being this.
While playing on koth_arctic_b3 (With two players), winning one round then forcing a map change (With the use of mp_timelimit 1 and mp_match_end_at_timelimit 1) to pl_halfacre causes the screenshot above during the waiting for players screen.
We did a few other small tests and found different results :
koth_arctic_b3 -> pl_upward : Cart is broken around 45% mark on the track (Also the bug persisted through waiting for players and reached a point on the track where it would no longer move)
koth_arctic_b3 -> pl_thundermountain : No problems found
koth_lazarus -> pl_upward : No problems found
koth_sawmill -> pl_upward : Cart is broken around the 10% mark on the track
Now that we had a way to accurately reproduce this problem (occurrence rate was almost 100% of each test with a factor of 3 tests per scenario per each variation in study (teams used, etc)) it was time to find out what was causing it. Very quickly we narrowed it down to a problem explicitly on SCG with Sourcemod turned on.
The sheer entropy of the bug has always made this difficult to fix. I have toyed with the possibility of a plugin causing it before but have never discovered any glaringly wrong coding problems with any of them that would lead me to think oh yes, this is the one!
Ultimately after removing plugins and re-adding them until we narrowed it all down, the culprit was one of the donator plugins. Specifically, the one that puts sprites above people's heads at the end of a round. Removing this plugin stopped all of our tests from working. Adding it back in with the sprite code stripped out did the same.
It makes sense really. The plugin is old, one of the oldest ones inside of SCG. May even be pre-SCG! It's not a commonly used one, and it isn't up to modern Sourcemod standards. The bug being random also aligns with the random number of donators on at a given time.
While reading through the thread, I found this post
"hmm. i know its been a while since anybody's posted, but i have a persistent map bug that seems to only effect payload and doomsday maps. im searching for the problem plugin, and only have about 4 donor plugins and all the Sourcemod plugins i need running."
I will admit, it's overwhelmingly embarrassing to have to talk about this with my tail between my legs. Something so annoying under my nose this whole time and never having been able to fix it. Then suddenly...fixed! Almost a decade of this nonsense...
I want to give a big thanks to Fraeven as well as anyone else who has ever attempted to pitch ideas or help me test this over the last decade. I'll have more news for you soon but I'm just gonna take a moment to relax haha
--Rowdy
Super Zombie Fortress, or SZF, is a Team Fortress 2 game mode that pits a group of humans in a fight for survival against a group of zombies. The human team must survive for a set time or in some cases, complete a trial or objective.
The zombie team consists of Scouts, Spies, and Heavies; the human team are the rest of the remaining classes.
(! / sm) zf_menu - Brings up the Zombie Fortress help menu
(! / sm) zf - Ditto
AI Director - tweaks everything based on survivor performance
Advanced Music system - plays L4D2 music appropriate for your situation. Be it intense or calm.
Frenzy system revamped - It now depends entirely on how the AI director judges survivor performance
Advanced Zombie Spawn system - When zombies are 'frenzied', they spawn faster, and close to the survivors (much like Left 4 Dead).
Goo Balls - Scouts are armed with the sandman. When hit by a baseball, a cloud of goo appears which will hurt anyone nearby. Basically the equivalent of L4D2's Spitter.
Backstabs no longer instantkill - Instead, they stun the victim for 5 seconds and puts them down to 10 hp. This allows victims to recover from a backstab if they have a good team, but if they're surrounded by zombies, they're fucked.
No knockback for Heavies - They're unstoppable! (almost)
Tanks - Survivors might need to fight a strong, powerful Heavy!
Last Stand - The last survivor gets 100% crit chance in his stand to survive until the time limit.
More zombies - Zombies are generally more common
Overpowered weapons removed - This includes: Sticky/Rocket jumper and Katana.
... not to mention all features of vanilla (Perkless) Zombie Fortress!
Note : This is the last public 1.05 version, you may be used to more up to date versions of this mod that we do not have. That said, suggestions for improvements are welcome and we encourage feedback!
Super Zombie Fortress was created by Mecha the Slag, who credits this as a modification to the original TF Zombie Fortress by Dirtyminuth, who credits his version to the following
Sirot, the original developer of ZF. None of this would be possible without his original work!
SnarfyBobo, for general brainstorming, alpha testing, and analysis!
The Crazy GFL (especially Tony, Wander, Adjo, Fat Elvis, and ArmysDeath), an excellent ZF community that has provided invaluable amounts of feedback!
intox Gaming (especially cLutch), another great ZF community!
AlliedMods, for managing this excellent website and development community!
Mann vs. Machine (MvM) is a co-op game mode released in The Mann vs. Machine Update. In this game mode, a team of up to six players attempts to prevent a horde of AI-controlled robots from escorting a bomb to a drop-point located in a Mann Co. facility. During the game, players can purchase upgrades for their weapons and various abilities (resistances, movement speed, regeneration, etc.) using currency obtained by killing the robots, called credits.
All purchased upgrades will last for the duration of the game, or until the player resets their abilities at an Upgrade Station. If a player leaves the game for any reason their upgrades will be retained, providing they reconnect, as well as any credits the player has spent and/or has remaining.
Mann vs. Machine mode currently has five separate difficulty levels: Normal, Intermediate, Advanced, Expert, and Nightmare.
More details here: https://wiki.teamfortress.com/wiki/Mann_vs._Machine
SCG Mvm isn't too different! However, our MVM mode allows for up to 10 players, and the overall difficulty scales per player. It scales backwards for smaller games, and harder for fuller games.
[size=14pt]What is it?[/size]
GScramble is the scrambler / balance system SCG uses, ours however is specially modified to fix a few different issues. This plugin is designed to help balance the teams, and scramble player order whenever stacking / steam rolling is detected. It also has blocks in place that stops players from stacking , should they want to do so.
[size=14pt]Commands[/size]
[color=orange]!prefrence - Allows you to select a team you prefer when the server does a scramble. This does not guarantee that you will be sent to this team.
votescramble / scramblevote / sausage - Chat triggers to indicate you want to vote for a scramble.
[/color]
[size=14pt]How it works[/size]
The following are written explanations of various settings we have. They are not in any order so sorry for the randomness of their arrangement. These are the settings that can be voted on to be changed if you disagree with their set up! Don't be afraid to speak up!
[size=12pt]When a scramble can occur[/size]
When a team has won twice in a row.
When one team has failed to ever capture a koth point during a round.
When the frag ratio is greater than or equal to (2.0)
When a round has ended in less than (2 minutes)
When a the average score difference is (10)
When the average domination difference is (5)
The following round after a vote to scramble has passed.
[size=12pt]Scramble settings[/size]
If a scramble happens during round setup, medics will have their ubers recharged.
If a scramble happens during round setup, the timer will reset.
No one is immune to scrambles.
When a scramble occurs, it will scramble the teams by class composition to create a better mix of teams.
Scrambles will not happen unless there are 8 or more people in game.
Vote scrambles are possible with 6 or more people in game only.
Vote scrambles that pass will happen when the current round is over.
[size=14pt]Balance settings[/size]
Players who have capped a point / intel within 60 seconds of balance will be ignored.
Players dueling will be be ignored.
Engineers with buildings will be ignored.
If an imbalance (2 player diff) is detected, the teams will balance within (10) seconds.
If a strict imbalance (4 player diff) is detected, the teams will auto balance immediately.
Teams are auto balanced at the start of each round.
[color=orange]SCG ONLY : The auto balance will balance by LOWEST SCORE. Meaning if you have the lowest score on your team, you will be pushed to the other if you have to. This was put in by special request by me and done by our own Dr.Krunklehorn. I wanted this after noticing many occasions where random and often very loyal players on a team were kicked off to a team they may of been spending a whole round killing.[/color]
[size=14pt]What is it?[/size]
The AFK manager is exactly what it sounds like. It's a manager tool designed to regulate and deal with AFK players. Before this, the way AFK handleing worked as anyone AFK for 3 minutes would be kicked. This lead to a lot of complaints about afk players on a team causing natural imbalances. If these players were kicked, many times they'd rejoin with harsh words about being afk for only a few moments or as one person put it to me "not allowed to get up for a glass of water".
So now, this AFK system will push you to spectate after being AFK for a minute. Then after two minutes of being in spectate, you are then kicked. Meaning, you still have 3 minutes to be AFK. But only a minute to actually stay on your team. I feel this is a better option as it allows you to deal wit hwhatever while not mucking up your team.
Let's get this out of the way, this is not a pay for play / pay to win / pay anything whatever thing. This is entirely based on credits you earn while playing on SCG servers!
The SCG Loyalty Store allows you to set your name color, chat color, and species tag for use in the server!
Exactly as the name implies, it's the color of your player name!
Ditto. But this time your chat color!
This lets you set a species tag prefix in your name. For example, mine is [Crux]. Your species not on the list? Let me know!
| Command | Description |
|---|---|
| /store | Opens the store menu |
| /inv | Opens the inventory menu |
Protocol Override is a difficulty mod for the SCG MVM servers that adjust the game's overall difficulty for games with 7 or more players.
The problem with hosting a 10 player MVM server is that the extra four people often make games far too easy. Even on the harder missions, the extra help tips the scales in favor of the humans. This plugin aims to change that. The difficulty of the game is adjusted into tiers based on groups of two players.
| All Robots |
|---|
| All robot movement speed is reduced by 20% |
| All robot crits become mini crits |
| There is a 3 second delay before a robot with the bomb will begin to jump in the silo. |
| All Robots |
|---|
| All robot movement speed is reduced by 10% |
| All Robots |
|---|
| Everything here is totally normal, no adjustments have been made at all. |
| Giant Robots |
|---|
| Giant Robot speed is not adjusted |
| 5% Damage Bonus while half dead |
| 40% Health Boost |
| Mini Boss Robots |
|---|
| Boss Robot speed is not adjusted |
| 5% Damage Bonus while half dead |
| 33% Health Boost |
| Robots |
|---|
| 20% Speed Bonus |
| 25% Damage Bonus while half dead |
| 40% Health Boost |
| Giant Robots |
|---|
| Giant Robot speed is not adjusted |
| 10% Damage Bonus while half dead |
| 75% Health Boost |
| Mini Boss Robots |
|---|
| Boss Robot speed is not adjusted |
| 10% Damage Bonus while half dead |
| 67% Health Boost |
| Robots |
|---|
| 40% Speed Bonus |
| 50% Damage Bonus while half dead |
| 75% Health Boost |
Robots that are teleported are adjusted differently, they are slightly less powerful than traditional bots. If the bomb is near the final point, teleported bots have much less of a speed boost and are weaker than their normally teleported counterparts. Teleported bots are only adjusted in the 7-8 and 9-10 player tiers.
Spy bots never have speed bonuses attached to them regardless of size.
Donating to SCG grants you a bunch of little cosmetic things on our Team Fortress 2 servers, they are cosmetic only, no pay to win garbage!
The end of round sprite is exactly as it sounds, you can select a little sprite to show up above your head at the end of a round!
Hello! This post is dedicated to the assorted plugins, commands, tools and features you'd find on SCG that aren't large enough to be split into individual threads!
| Command | Usage |
|---|---|
| /hug <name> | Hugs a player |
Hello friends.
Today I come to you with a very important announcement...and a story. This is probably the most ... important thing that has happened in quite some time...
We, Fraeven and I, believe we have isolated and fixed the infamous payload cart bug. If you're a SCG regular of any age, you'd know about it. The bug is pretty simple :
Occasionally a round of payload will start and the hud reports an incorrect placement of the cart, the cart often is unable to reach the end of the track leading to either a crash or simply an unwinnable scenario.
An example can be found here :
The bug appears to have been caused by poor programming in the donator recognition plugin's donator array being offset and deleting entities entirely at random when trying to delete donator sprites at the end of rounds/games. Through debugging, we caught the following instances of incorrectly deleted events.
Debug - T name : zz_red_koth_timer, C name : team_round_timer
Server cvar 'mp_timelimit' changed to 25
[SCG] A fatal error has occured with the KOTH timers, the round was reset to prevent a crash!Debug - T name : minecart_path_146, C name : path_track
Debug - T name : minecart_path_153, C name : path_trackDebug - T name : , C name : logic_auto
Debug - T name : , C name : tf_wearable
By deleting entities randomly, this is what has caused numerous map issues. Most notable here is the first example in which the zz_red_koth_timer prop is deleted and triggers the band-aid koth timer fix plugin.
After extensive research, this bug as been found to be related to a number of issues.
A fix has been developed and installed on both Chocolate and Rainbow that should prevent anything but the donator sprites being deleted properly.
Now you may be wondering? Why is this so important exactly? It's happened before, you guys just reset the round correct? This is important because this is the oldest bug SCG has ever had. It has followed us through server installs, host switches, and has been around for almost the entirety of SCG.
In the earlier days, it used to crash the server if left unchecked, this doesn't happen anymore because whenever it happens we've just immediately reset the round. This bug is similar to that of the koth timer problem, a problem I was able to "fix" by writing a plugin that detects a broken koth clock and resets the round automatically, then restores the time left. But due to the random occurrence, I never had much to go on nor could I dedicate too much time to it.
Fast forward to today, Fraeven was wanting to help understand and fix the problem, or at least develop a similar band aid to find broken payload carts. Over the last couple weeks, we've been doing tests here and there; pouring through Valve wiki pages and copies of the TF2 source code to try and understand where things go wrong.
Our first goal was to try and recreate the bug consistently, during Friday night gaming and other nights of playing when it'd happen, I had tools running to check and see what TF2 was doing. We attempted to see what maps were causing it, what conditions, etc.
Trial and error led to some interesting discoveries but ultimately nothing useful. Very quickly I was able to rule out it being a hardware problem, as well as a configuration problem. SCG servers have always had this problem be it Windows or Linux. I compared the server settings against a Valve stock server and found no major differences that would cause any sort of issues.
In our core tests, we've been running chocolate with an elevated timescale with and without bots on all sorts of payload maps to attempt to make the bug happen. Nothing would ever happen until last night, when we finally saw it happen by ourselves. It's actually a funny story even, we almost missed it entirely. I wasn't paying attention to my screen and caught it at the last moment during the waiting for players screen on pl_halfacre. With coffee in my mouth I made a silly noise and slammed down on my screenshot button :
This was big news, we made it happen finally among ourselves. Soon after, we learned how to reproduce it! And here is where things get weird...
We know the following details.
While not super precise, our method wound up being this.
While playing on koth_arctic_b3 (With two players), winning one round then forcing a map change (With the use of mp_timelimit 1 and mp_match_end_at_timelimit 1) to pl_halfacre causes the screenshot above during the waiting for players screen.
We did a few other small tests and found different results :
koth_arctic_b3 -> pl_upward : Cart is broken around 45% mark on the track (Also the bug persisted through waiting for players and reached a point on the track where it would no longer move)
koth_arctic_b3 -> pl_thundermountain : No problems found
koth_lazarus -> pl_upward : No problems found
koth_sawmill -> pl_upward : Cart is broken around the 10% mark on the track
Now that we had a way to accurately reproduce this problem (occurrence rate was almost 100% of each test with a factor of 3 tests per scenario per each variation in study (teams used, etc)) it was time to find out what was causing it. Very quickly we narrowed it down to a problem explicitly on SCG with Sourcemod turned on.
The sheer entropy of the bug has always made this difficult to fix. I have toyed with the possibility of a plugin causing it before but have never discovered any glaringly wrong coding problems with any of them that would lead me to think oh yes, this is the one!
Ultimately after removing plugins and re-adding them until we narrowed it all down, the culprit was one of the donator plugins. Specifically, the one that puts sprites above people's heads at the end of a round. Removing this plugin stopped all of our tests from working. Adding it back in with the sprite code stripped out did the same.
It makes sense really. The plugin is old, one of the oldest ones inside of SCG. May even be pre-SCG! It's not a commonly used one, and it isn't up to modern Sourcemod standards. The bug being random also aligns with the random number of donators on at a given time.
While reading through the thread, I found this post
"hmm. i know its been a while since anybody's posted, but i have a persistent map bug that seems to only effect payload and doomsday maps. im searching for the problem plugin, and only have about 4 donor plugins and all the Sourcemod plugins i need running."
I will admit, it's overwhelmingly embarrassing to have to talk about this with my tail between my legs. Something so annoying under my nose this whole time and never having been able to fix it. Then suddenly...fixed! Almost a decade of this nonsense...
I want to give a big thanks to Fraeven as well as anyone else who has ever attempted to pitch ideas or help me test this over the last decade. I'll have more news for you soon but I'm just gonna take a moment to relax haha
--Rowdy
Chatroom
Discord
