Control and item fixes for spectators AND env_screenoverlay patch

[MyGamepedia]

When a player join spectators:

• Fired ForceDropOfCarriedPhysObjects input to fix stucked in air physics objects and controlled func_tank like entities.
• Called RemoveAllItems() for cases if they're not removed (somehow).

Added env_screenoverlay patch that solves #284:

• Input hooks for custom logic.
• New inputs "StartOverlaysForEveryone" and "StopOverlaysForEveryone".
• Globals to control overlay values for each player.
• Enable/disable an env_screenoverlay on cllient connect/disconnect (NOT TESTED).
• New methods in CBaseEntity methodmap: getter and setter to response context, getter and setter for texture frame index.
• Added new methodmap CEnvScreenOverlay.
• Includes ENTPATCH_ENV_SCREENOVERLAY macro.

IMPORTANT:
env_screenoverlay path needs few tests with real players (2 or more).

[MyGamepedia]

Hope this is the last thing I forgot.

[Alienmario]

I’ll begin with some general recommendations. Once those are addressed, we can move on to the concrete implementation. I hope this is understandable.

• Try to keep comments concise and to the point. If the code is self explaining (i.e by names or strings), then comments are usually not necessary.
• Try to keep separate PRs for individual issues or enhancements.
• Try to maintain consistent formatting, mainly this if( to if (.
• Rename ForEveryone postfix to All for consistency with other modified entities.
• Instead of hijacking entity datamaps for custom properties, GetUserData*, SetUserData* methods from CBaseEntity methodmap may be used.
• srccoop_api and any classdefs in it are meant to used by independent plugins. Any plugin variables added there will not be 'synced'. Move patch functionality to core plugin space.
• using MAX_PLAYERS over MAXPLAYERS is going to be confusing to anyone who's been making SM plugins for a long time. Do you have a significant reason for doing this?

[Alienmario]

Use .IsValid() method

[Alienmario]

timer is always non-null

[MyGamepedia]

using MAX_PLAYERS over MAXPLAYERS is going to be confusing to anyone who's been making SM plugins for a long time. Do you have a significant reason for doing this?

I noticed that with MAXPLAYERS the array size is going to be 101 always, while bms supports only 33 players at once, so basically the version for bms will take tones of memory that could be used for other things, and I think it's generally not okay to take memory that is never used.

I used MAX_PLAYERS for now cuz it's the shortest name i could give for it.

Rename ForEveryone postfix to All for consistency with other modified entities.

That was in my original plan (cuz it's short), but i renamed both cuz (it seemed to me) ForEveryone is a more intuitive name, I'll rename it.

srccoop_api and any classdefs in it are meant to used by independent plugins. Any plugin variables added there will not be 'synced'. Move patch functionality to core plugin space.

But I'm also using some custom inputs in the methodmap, should I just use a macro for them?

[Alienmario]

I noticed that with MAXPLAYERS the array size is going to be 101 always, while bms supports only 33 players at once, so basically the version for bms will take tones of memory that could be used for other things, and I think it's generally not okay to take memory that is never used.

That's like a raindrop in a river - not significant enough to sacrifice readability.
Memory is not a limiting factor on Source dedicated servers anyways.

But I'm also using some custom inputs in the methodmap, should I just use a macro for them?

Macros will not help here.
You can keep input calling and game-backed (datamap, sendprop) properties.
Plugin-backed properties ought to be moved out of the public api, imo.
Maybe create a CEnvScreenOverlayCustom extension in include/srccoop/entity/ ?

[MyGamepedia]

I noticed that with MAXPLAYERS the array size is going to be 101 always, while bms supports only 33 players at once, so basically the version for bms will take tones of memory that could be used for other things, and I think it's generally not okay to take memory that is never used.

That's like a raindrop in a river - not significant enough to sacrifice readability.
Memory is not a limiting factor on Source dedicated servers anyways.

@ampreeT give me your opinion on this before I will do any changes.

[ampreeT]

@ampreeT give me your opinion on this before I will do any changes.

All of the default plugins that SourceMod ships with uses MAXPLAYERS so we should stay with MAXPLAYERS. In this case, saving ~0.25 KB (68 entries * 4 bytes) of globally initialized memory will not give us a measurable performance boost.

[Alienmario]

Macros will not help here.
You can keep input calling and game-backed (datamap, sendprop) properties.
Plugin-backed properties ought to be moved out of the public api, imo.
Maybe create a CEnvScreenOverlayCustom extension in include/srccoop/entity/ ?

Actually, if you're able to convert all variables into 'entity user data' calling methods, it may not be necessary to create the extra file. We may just be able to implement cross-plugin sharing since those are backed by a single IntMap.