[Mayor Gamer]

Originally Posted by ddhoward No, I mean the server operator who wants to have no respawn effect for regular users can make the cvar blank on his end.

Ah couldn't understand what you meant in the last post. Yeah, you can do that. Leaving the CVAR blank would just spawn no particle at all. Do the same with sound. Haven't tested it tho.

[Smiley123]

tempary thirdperson view for client as he/she respawns would be nice

[Mayor Gamer]

Originally Posted by Smiley123 tempary thirdperson view for client as he/she respawns would be nice

Use a non-cheats thirdperson plugin like the one seen here.

Players who died having Third Person on will respawn with it on.

[Smiley123]

Originally Posted by Mayor Gamer Use a non-cheats thirdperson plugin like the one seen here. Players who died having Third Person on will respawn with it on.

Yes I understand but I mean temporary thirdperson only while they respawn so they can better see the effect (as in when one taunts)

[Nanochip]

Hey nice plugin!

Some tips:

• Add a version convar so that you can track how many servers use your plugin and/or see what version they're using. Here's an example:
  
  PHP Code:

  #define PLUGIN_VERSION    "1.8"

public Plugin:myinfo = {
    name        = "Nanobot (Dodgeball Bot)",
    author        = "Nanochip",
    description= "Play dodgeball against a bot!",
    version    = PLUGIN_VERSION,
    url            = "https://forums.alliedmods.net/showthread.php?p=2286346"
};

public OnPluginStart()
{
    CreateConVar("sm_nanobot_version", PLUGIN_VERSION, "Nanobot Version", FCVAR_PLUGIN|FCVAR_SPONLY|FCVAR_UNLOGGED|FCVAR_DONTRECORD|FCVAR_REPLICATED|FCVAR_NOTIFY);
} 

• You don't need to define a MAX_CLIENTS variable, sourcemod already has these global variables: MAXCLIENTS and MAXPLAYERS.
  
  PHP Code:

  // Original
new NewTeam[MAX_CLIENTS];

//Replace it with:
new NewTeam[MAXPLAYERS+1]; // the +1 is just for safety, accounting for a possible SourceTV or Replay (this seems to be a tradition here). 

• The last tip would be to try and transition to the new 1.7 traditional syntax. It's not a big deal if you don't, I haven't transitioned my older plugins, however it looks more sleek & closer to java/c# syntax.

[ddhoward]

You do NOT want to use FCVAR_REPLICATED on that cvar. The cvar doesn't exist on the client, it only exists on the server.

FCVAR_PLUGIN has never done anything, and using it will now cause warnings when you compile.

FCVAR_NOTIFY is only necessary if, for some reason, you want to inform all clients in the chat that you updated the plugin.

The only one that you actually might want to use is FCVAR_DONTRECORD and that's only if you're using AutoExecConfig in your plugin.

PHP Code:

new NewTeam[MAXPLAYERS+1]; // the +1 is just for safety, accounting for a possible SourceTV or Replay (this seems to be a tradition here). 


That is not why. This is important to do even on games that don't even have SourceTV or Replay.

Client indexes are numbered from 1 - MaxClients. MAXPLAYERS is the maximum value of MaxClients allowable by the engine; Sourcemod has this hardcoded to 65.

So let's assume that we have the biggest possible server size: a 65 slot server. The possible client indexes would be 1 - 65.

If we declare an array with an array index for each player, such as your NewTeam array, and we specify that the array size is 65... then the array indexes range from 0 - 64.

We have a problem. There are the same number of array slots as player slots, but the numbers don't match up! The last player to connect to the server and make it full would cause the plugin to generate runtime errors, as data would be written to NewTeam[65] which doesn't exist.

For this reason, we declare all arrays like that with a +1 at the end. This means that there is one array index ( [0] ) which is not used, but that's fine.

[Mayor Gamer]

Originally Posted by Nanochip Hey nice plugin! Some tips: Add a version convar so that you can track how many servers use your plugin and/or see what version they're using. Here's an example: PHP Code: #define PLUGIN_VERSION    "1.8" public Plugin:myinfo = {     name        = "Nanobot (Dodgeball Bot)",     author        = "Nanochip",     description= "Play dodgeball against a bot!",     version    = PLUGIN_VERSION,     url            = "https://forums.alliedmods.net/showthread.php?p=2286346" }; public OnPluginStart() {     CreateConVar("sm_nanobot_version", PLUGIN_VERSION, "Nanobot Version", FCVAR_PLUGIN|FCVAR_SPONLY|FCVAR_UNLOGGED|FCVAR_DONTRECORD|FCVAR_REPLICATED|FCVAR_NOTIFY); }  You don't need to define a MAX_CLIENTS variable, sourcemod already has these global variables: MAXCLIENTS and MAXPLAYERS. PHP Code: // Original new NewTeam[MAX_CLIENTS]; //Replace it with: new NewTeam[MAXPLAYERS+1]; // the +1 is just for safety, accounting for a possible SourceTV or Replay (this seems to be a tradition here).  The last tip would be to try and transition to the new 1.7 traditional syntax. It's not a big deal if you don't, I haven't transitioned my older plugins, however it looks more sleek & closer to java/c# syntax.

Pushed a small update thanks to this. Thank you for pointing out!

[ddhoward]

Here's some suggestions! Really like the concept of this plugin, and as I stated before, I love how you checked for donator status properly using an override rather than GetUserFlags + a cvar, or some other nonsense.

• As I touched on in my previous post, those FCVAR flags should probably be removed from the version cvar. REPLICATED will just cause error messages on your clients. SPONLY doesn't do anything on purely server-side cvars, which is the only kind of cvar that Sourcemod can create. NOTIFY isn't necessary unless you actually want it printed in the chat that the version has changed (in the event of an update), and neither is DONTRECORD unless you're using AutoExecConfig().
  
  
  PHP Code:

  CreateConVar("sm_respawnsfx_version", PLUGIN_VERSION, "Respawn Effects version. Don't touch this!");
//or
CreateConVar("sm_respawnsfx_version", PLUGIN_VERSION, "Respawn Effects version. Don't touch this!", FCVAR_NOTIFY|FCVAR_DONTRECORD); 

  You may also want to look into hooking the cvar and having the plugin actually actively prevent changes to the value. It's up to you though.
  
  
  
• The NewTeam array doesn't seem to do anything, so you can safely remove both its declaration at the top of the plugin, as well as its use at the end of the spawn hook.
  
  
  
• Since the plugin is exclusively for TF2, you have the option of using TF2_GetClientTeam(), which returns a TFTeam value. This will allow you to not have to hard code team values.
  
  
  PHP Code:

  #define SPEC    1 //these three lines can all be removed
#define TEAM1    2
#define TEAM2    3

//...

        switch (TF2_GetClientTeam(user))
        {
            case TFTeam_Red: 
            {
                AttachParticle (user, hRedPart, 2.5);
                EmitSoundToClient(user, hSound);
            }
            case TFTeam_Blue: 
            {
                AttachParticle (user, hBluPart, 2.5);
                EmitSoundToClient(user, hSound);
            }
        }

//... 

  Also, apparently the spawn event is also called shortly after OnClientPutInServer, even though he hasn't actually spawned, so you might want to throw an IsPlayerAlive() check before the call to CheckCommandAccess().
  
  
  
• When using timers on players or entities, you should not be passing its entity index. You should instead be passing the user ID (in the case of clients) or the entity reference (in the case of non-players.) This way, you gurantee that you run your timer's code (in this case, deleting the entity) on the correct entity, as entity indexes are reused. You already do a basic check by seeing that the classname is the same, which is a step in the right direction, but there's an easier, more efficient, and more guaranteed way to ensure that we don't delete the wrong entity.
  
  
  PHP Code:

          CreateTimer(time, DeleteParticles, EntIndexToEntRef(particle));

//...

public Action:DeleteParticles(Handle:timer, any:particle)
{
    if (EntRefToEntIndex(particle) != INVALID_ENT_REFERENCE)
    {
        AcceptEntityInput(particle, "Kill");
    }
} 


[Mayor Gamer]

Originally Posted by ddhoward Here's some suggestions! Really like the concept of this plugin, and as I stated before, I love how you checked for donator status properly using an override rather than GetUserFlags + a cvar, or some other nonsense. As I touched on in my previous post, those FCVAR flags should probably be removed from the version cvar. REPLICATED will just cause error messages on your clients. SPONLY doesn't do anything on purely server-side cvars, which is the only kind of cvar that Sourcemod can create. NOTIFY isn't necessary unless you actually want it printed in the chat that the version has changed (in the event of an update), and neither is DONTRECORD unless you're using AutoExecConfig(). PHP Code: CreateConVar("sm_respawnsfx_version", PLUGIN_VERSION, "Respawn Effects version. Don't touch this!"); //or CreateConVar("sm_respawnsfx_version", PLUGIN_VERSION, "Respawn Effects version. Don't touch this!", FCVAR_NOTIFY|FCVAR_DONTRECORD);  You may also want to look into hooking the cvar and having the plugin actually actively prevent changes to the value. It's up to you though. The NewTeam array doesn't seem to do anything, so you can safely remove both its declaration at the top of the plugin, as well as its use at the end of the spawn hook. Since the plugin is exclusively for TF2, you have the option of using TF2_GetClientTeam(), which returns a TFTeam value. This will allow you to not have to hard code team values. PHP Code: #define SPEC    1 //these three lines can all be removed #define TEAM1    2 #define TEAM2    3 //...         switch (TF2_GetClientTeam(user))         {             case TFTeam_Red:              {                 AttachParticle (user, hRedPart, 2.5);                 EmitSoundToClient(user, hSound);             }             case TFTeam_Blue:              {                 AttachParticle (user, hBluPart, 2.5);                 EmitSoundToClient(user, hSound);             }         } //...  Also, apparently the spawn event is also called shortly after OnClientPutInServer, even though he hasn't actually spawned, so you might want to throw an IsPlayerAlive() check before the call to CheckCommandAccess(). When using timers on players or entities, you should not be passing its entity index. You should instead be passing the user ID (in the case of clients) or the entity reference (in the case of non-players.) This way, you gurantee that you run your timer's code (in this case, deleting the entity) on the correct entity, as entity indexes are reused. You already do a basic check by seeing that the classname is the same, which is a step in the right direction, but there's an easier, more efficient, and more guaranteed way to ensure that we don't delete the wrong entity. PHP Code:         CreateTimer(time, DeleteParticles, EntIndexToEntRef(particle)); //... public Action:DeleteParticles(Handle:timer, any:particle) {     if (EntRefToEntIndex(particle) != INVALID_ENT_REFERENCE)     {         AcceptEntityInput(particle, "Kill");     } }

Pushed another update for this. Thanks a lot ddhoward! Helped me a lot ;)

[MaloModo]

Hey there...just testing out your plugin...works as advertised with donator sounds/effects etc.

It would be cool if people could choose from a list of particle effects and sounds that they could set themselves. Further to this, if possible, having a config file that the server operator could edit to add/create "the list".

Cheers.