Raised This Month: $32 Target: $400
 8% 

Plugin Approval Rules Discussion


Post New Thread Reply   
 
Thread Tools Display Modes
Downtown1
Veteran Member
Join Date: Mar 2004
Old 01-17-2010 , 21:13   Re: Plugin Approval Rules Discussion
Reply With Quote #21

I tend to believe people know how to copy and paste snippets that are clearly linked to.
Downtown1 is offline
Mr. Zero
Veteran Member
Join Date: Jun 2009
Location: Denmark
Old 01-18-2010 , 02:02   Re: Plugin Approval Rules Discussion
Reply With Quote #22

Again.

Sure I could add those 20 extra lines to my otherwise small 100 line script.
But there is no need to as long the user can read what the hell he is installing. It shouldn't be my job making sure he reads it.

"You're trying to fight a user reading comprehension issue by requiring extra code. " - What this topic is pretty much about. Granted we need a L4D2 drop down option (why is it again we don't have it?).

#5 (plugins changing cvars)
There is no elegant way to do this. It will just cause more troubles and add a lot of unnecessary code.
Mr. Zero is offline
Hawkeye-
Senior Member
Join Date: Jan 2009
Old 01-18-2010 , 02:33   Re: Plugin Approval Rules Discussion
Reply With Quote #23

Quote:
Originally Posted by Downtown1 View Post
I tend to believe people know how to copy and paste snippets that are clearly linked to.
All I would honestly anticipate, is rather then "I installed this L4D plugin in L4D2 and it doesn't work since x and y are broken" we will now have "I installed this plugin in L4D plugin in L4D2 and it does nothing.."

I don't anticipate anything really changing by requiring the extra code..
Hawkeye- is offline
Bigbuck
Senior Member
Join Date: Jul 2009
Old 01-19-2010 , 16:58   Re: Plugin Approval Rules Discussion
Reply With Quote #24

Hawkeye is on to something. While I put the SetFailState code in, it just happened to be in the plugins I learned from, there really isn't a good reason for having it. Plenty of times with my plugins I have people ask stupid questions, like the example Hawkeye has above, that would easily be solved by either READING the plugins OP or their logs.
Bigbuck is offline
Downtown1
Veteran Member
Join Date: Mar 2004
Old 01-20-2010 , 13:52   Re: Plugin Approval Rules Discussion
Reply With Quote #25

Ok, so how about this:

Remove #1 requirement. Let users be dumb and use the plugin on TF2 if they want to

#3 relaxed so that plugins have some prefix in their CVARs?

For #4 it sounds like we should have a more thorough snippet with either CVAR stacks or CVAR ownership since it's a real problem that just won't go away if we ignore it long enough. If you guys know what plugins change CVARs and for how long, post here so we can think about this.

Same goes for #2, there is no easy way to disable a plugin on another gamemode (using a game mode config loader and adding 'sm plugins unload' is putting the onus on the user where the developer should've disabled his mode in the first place).

#5 plugins should cleanly unload (that includes resetting CVARs, but also removing any effects e.g. godmode on players you might've added), that's a given considering people unload plugins all the time in configs like confogl or cevo. Should be trivial with #2, since you would just disable yourself essentially the same way as in #2 in OnPluginStart.

#6 mp_gamemode cvar shouldn't be changed back and forth, should be another given since Zero brought up that it freezes the server for a few seconds.

Last edited by Downtown1; 01-20-2010 at 13:55.
Downtown1 is offline
Hawkeye-
Senior Member
Join Date: Jan 2009
Old 01-20-2010 , 18:35   Re: Plugin Approval Rules Discussion
Reply With Quote #26

My general thoughts would be, these are guidelines but not a requirement, If you see something change a built in CVAR, ask if there is any other way the author could have done it before approval, or things of that nature.
Hawkeye- is offline
Powerlord
AlliedModders Donor
Join Date: Jun 2008
Location: Seduce Me!
Old 05-13-2011 , 20:22   Re: Plugin Approval Rules Discussion
Reply With Quote #27

I know this topic is somewhat old, but I had a new question about plugin guidelines.

Antithasys listed this under "Most common mistakes": "You create a public cvar without FCVAR_NOTIFY"

So, essentially, all cvars should be marked either FCVAR_NOTIFY or FCVAR_PROTECTED?

However, none of the core SourceMod modules appear to mark public cvars as FCVAR_NOTIFY. As one of the two plugins I'm working on now is a modification of mapchooser.sp, I'm wondering if I'm expected to mark all the MapChooser cvars with one of them, or if this is some rule that's just mainly ignored.
__________________
Not currently working on SourceMod plugin development.
Powerlord is offline
Peace-Maker
SourceMod Plugin Approver
Join Date: Aug 2008
Location: Germany
Old 05-15-2011 , 08:34   Re: Plugin Approval Rules Discussion
Reply With Quote #28

You aren't asked to add the FCVAR_NOTIFY flag to all convars your plugin creates, but only to the convar holding the version number normally. You may add the flag to other convars like an _enable one to be able to filter which server has your plugin actually in use, but beware, that every convar with that flag is added to a A2S_RULES query response generating unnecassary data load.

The reason for the default sourcemod plugins not having a public convar each is the fact that they're default. You can assume they're on the server, when there's a sourcemod_version convar around. When releasing a modified version, you have to rename the file and have an own public convar.
__________________
Peace-Maker is offline
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 13:54.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode