[pRED*]

Moved this discussion here to keep the rules list clear.

Originally Posted by Downtown1 [*]Your plugin should not load outside of L4D/L4D2 if it doesn't support other mods. Snippet Reason: It's confusing to have a plugin randomly fail because someone tried to load it on their TF2/CSS/etc server. Use GetGameFolderName and SetFailState if the mod isn't L4D/L4D2.

I don't see the point in making this a requirement for approval, people should be capable of reading the original thread.
It's probably a good idea for plugins, but seems to be a solution to a problem we don't have to enforce it.

Originally Posted by Downtown1 [*]All cvars should be prefixed with l4d_ or l4d2_. Reason: Some plugins currently use a mix of sm_ and sm_l4d_ prefixes. sm_ implies cross-game functionality when L4D plugins typically don't work on other games. sm_l4d_ is just a longer way of l4d_. Also note that L4D2 itself does not have any public CVARs starting with an l4d_ prefix so it wouldn't be conflicting with existing game CVARs.

Anything but this...

sm_ only implies that it's a cvar created by SourceMod or a SM plugin. Theres no reason to try create new confusing naming rules especially when most l4d plugins won't even run on other games (your words).

Originally Posted by Downtown1 [*]Any cvars that aren't your plugin's that are changed should have their old value remembered. Reason: L4D has more game/hidden CVARs than other games, many times plugins change their values and conflict with each other. By remembering their values we take one easy step forward at reducing conflicts. [*]Any cvars that aren't your plugin's should have their values restored if a plugin is unloaded Snippet Reason: Plugins should be able to cleanly unload and restore their state as before they were loaded.

As soon as multiple plugins touch the same cvar this will probably only make things worse. Without ridiculous stack based tracking of changes or cvar ownership this isn't solvable.

Sounds like it will create as many problems as it will solve.