[Downtown1]

Additional L4D/L4D2 Approval Guidelines

• 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.
  
  
• Your plugin should be inert when it's on an unsupported gamemode
  • Reason: If a gamemode breaks your plugin in unpredictable ways, then it shouldn't be doing anything on that gamemode. Simply hook the mp_gamemode convar change and disable your plugin if it's not a gamemode you expect.
  
  
• 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.
  
  
• 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.
  
  
• mp_gamemode cvar should not be changed back and forth
  • Reason: Changing this cvar rapidly breaks the game in unpredictable ways. It is only meant to be used before changing the level.

These are meant to bring a higher level of consistency and compatibility between future L4D(2) plugins. Feel free to suggest further requirements.

[Mr. Zero]

Originally Posted by Downtown1 Feel free to suggest further requirements.

How about we discuses the ones you just rapidly added to the list?

Originally Posted by Downtown1 Your plugin should not load outside of L4D/L4D2 if it doesn't support other mods. Snippet[list][*]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'm sorry, say what?

Since when do I have to check if a "less competent" user can't read my label that clearly reads "L4D2 NO WITCH HUNTING"?
If the user can't ready the topic title to start with... then why should I even consider trying to block the plugin from loading?
He wound then proceed to post in my topic saying: "hey man, ure plugin is brok3n wont load in css. helps!1".

I'm sorry but I fail to see the reason for this. But alright if so, then I request all TF2 and CSS plugins is being blocked from being loaded onto L4D. I might miss read the clear label in the top saying for with game its for.

You know... this one: Plugin Game: Left 4 Dead

Originally Posted by Downtown1 Your plugin should be inert when it's on an unsupported gamemode[list][*]Reason: If a gamemode breaks your plugin in unpredictable ways, then it shouldn't be doing anything on that gamemode. Simply hook the mp_gamemode convar change and disable your plugin if it's not a gamemode you expect.

Again, I clear write ONLY SUPPORTS VERSUS, even friendly enough to provide a cvar for turning the plugin on and off without having to unload/reload the plugin and then you tell me I have to check HIS SERVER for HIS GAMEMODE, to see if he have been an idiot and load it into coop?

No. I won't. If people can't read what I write, then I here from declare all my plugins "ONLY FOR PEOPLE WHO CAN READ AND UNDERSTAND INSTRUCTION ON HOW TO USE".

Originally Posted by Downtown1 All cvars should be prefixed with l4d_ or l4d2_.[list][*]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.

Granted, cvar should imply what they are used and for what game.

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.

Jesus chist. You do know how many plugins a single modded server runs sometime? 30+? Could be a guess. Now lets say they run for example my ghost tank plugin. I change the AI tanks rock throw range. Imagine another plugin changes this aswell? First I store the current value which could be vanilla value. Then I set mine value, the other plugin sees that and change it back to its own. Now my plugin is fucked, as it is still assuming its own value. Now I revert the cvar to vanilla again, fucking the other plugin over.

You are talking about reducing conflicts. If anything this can only increase + it adds unnecessary code. If people have problem with 2 plugins, they can, ohh I don't know, maybe try post in the topic of the plugin, implying a possible conflict of plugins?

Originally Posted by Downtown1 mp_gamemode cvar should not be changed back and forth Reason: Changing this cvar rapidly breaks the game in unpredictable ways. It is only meant to be used before changing the level.

Eh? So... my forced spawn begone plugin, before it became obsolete... I gotta say, I never ever experienced this "game breaking" thing. Can I see some prof of this?

Nothing happens if you do it in L4D, L4D2 the server becomes unresponsive for a few seconds but I have already contacted Chet about this.

Originally Posted by Downtown1 These are meant to bring a higher level of consistency and compatibility between future L4D(2) plugins.

These are meant to bring some conversation on the table on why the hell should I do all these things when I do this in my sparetime + of own free will + willing to share these plugins/source for free.

I'm sorry but all these just adds insane amount of code to a small plugin that's maybe only 100 lines long.

As long I write CLEAR instruction on how to or write down known problems, it shouldn't be my job to make sure users have actually reads it.

/nottryingtobeadick

However I am rather pissed about how you can come and dictate how my plugin needs all these checks, granted it is "your sandbox" and not a demographic website, still whatever. sooo... unapprove all my plugin asap...?

[Downtown1]

Plugins that are approved already don't need to adhere to any of these new guidances (though it would be nice to add them after the fact, it's not required). We will not be unapproving L4D(2) plugins for each new guidance we decide to add.

Now lets say they run for example my ghost tank plugin. I change the AI tanks rock throw range. Imagine another plugin changes this aswell? First I store the current value which could be vanilla value. Then I set mine value, the other plugin sees that and change it back to its own.

Feel free to suggest something that would work better when multiple plugins set the same CVAR.

These are meant to bring some conversation on the table on why the hell should I do all these things when I do this in my sparetime + of own free will + willing to share these plugins/source for free.

Nobody is forcing anyone to do any of this. People who don't adhere to these approval guidelines won't have their new plugins approved. Since 3/5 of the approval guidelines have snippets that can be copied and pasted, we don't think it requires that much time investment.

However feel free to distribute SourceMod plugins outside of these forums where you are unbound by any approval guidelines. For example EVOL's most popular L4D Hunter Games mod was entirely distributed on http://www.huntergames.org/

Of course keep in mind, you still have to distribute the source code when you are distributing the SMX or you will be in violation of the GPLv3 license.

[berni]

The l4d(2) guidelines are nonsense.
And why are there suddenly specific guidlines for l4d2 and not for TF2/CSS or other games ? Guidelines shouldn't be game specific, but general.
And in my opinion srcds cvars shouldn't be set by plugins at all, but in server.cfg. setting cvars back OnPluginUnload doesn't really fix anything, it's a cheap workaround.

[Mr. Zero]

Originally Posted by Downtown1 Feel free to suggest something that would work better when multiple plugins set the same CVAR.

I can't. Why? Because there is multiple writers, with multiple writing styles, making it impossible. This is where I play the "users can post conflicts with other plugins in the topic" card again.

Originally Posted by Downtown1 Nobody is forcing anyone to do any of this. People who don't adhere to these approval guidelines won't have their new plugins approved. Since 3/5 of the approval guidelines have snippets that can be copied and pasted, we don't think it requires that much time investment.

Not forced? Then why the hell am I posting it here? If my plugin gets unapproved people cant search for it.
Might not be forced but indirectly affects the plugin, as it will not be visible through a plugin search.

I'm not talking about time, I'm talking about size and execution time. If a modded server runs about lets just say, 10 plugins what ALL checks first for gamemode, then save all the cvars they are changing (where they all can collide), set their own and then begin.

I would say it would be faster with this plugin.
If a plugin provides an enable/disable cvar (which most does plugin does for l4d), it can be added to config file that get executed as such.

And as berni himself puts it: "its a cheap workaround".

Originally Posted by Downtown1 However feel free to distribute SourceMod plugins outside of these forums where you are unbound by any approval guidelines.

However as most people, I don't have a drone network nor a lot of people to spam a URL for one plugin.
Which is why I post it here, as most people know this is a place where you can view a collection of plugins.

Originally Posted by berni The l4d(2) guidelines are nonsense. And why are there suddenly specific guidlines for l4d2 and not for TF2/CSS or other games ? Guidelines shouldn't be game specific, but general. And in my opinion srcds cvars shouldn't be set by plugins at all, but in server.cfg. setting cvars back OnPluginUnload doesn't really fix anything, it's a cheap workaround.

This is what I'm talking about.

There have never been for other games but suddently for L4D2 which, if I recall correctly, you are producing plugins for?
Any reasons behind this madness called "plugin compatible", as apparently all other games/plugins run fine?

[psychonic]

I don't have time atm to go into detail, but I generally agree with berni's and Mr. Zero's above points.

[pvtschlag]

The big thing I agree with on the new guide lines is the checking for the proper game. Not so much to check that a L4D plugin shouldn't be loaded on TF2, but for the fact that people may try to load a L4D2 plugin on L4D1 where it may not work correctly.

Sure you may put a L4D2 label in the topic title. However, the info of the plugin still says "Plugin Game: Left 4 Dead", and when you search for a plugin they are all under the "Left 4 Dead" category. This may be misleading to some people.

Although I think the best solution to that would be to just add Left 4 Dead 2 as an option to choose when submitting a plugin.

For the cvars conflict it would be nice if there was a way to tell if another plugin has already modified a cvar, and then throw a warning or something to the end user.

As for the checking for gamemode, I would think it would just be good practice to make sure your code only runs under the proper conditions. Don't know if it should be required though. It is kinda like saying #pragma semicolon 1 is required. It is just a writing style. Some people like to do it, and others don't.

[DontWannaName]

Allowing plugin authors to choose multiple games supported is an ongoing issue.

[Hawkeye-]

Pvt Shlag has a point on the Left 4 Dead / Left 4 Dead 2 issue, but I don't think a programming requirement is realistic, when we can simply add something to the drop down.

If any rules are made, it should apply to all mods and not any one specific mod, otherwise were going to have so many sets of rules it going to be a royal pain to keep straight what I need to do to get something approved. The initial rules by Bailopan seem fine. FZero and berni have good points so not much more I can add, just wanted to state my thoughts.

[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.