Deprecate legacy functions

[Trojaner]

Many events and methods used in RocketMod are no longer required and have been replaced by official implementations. I suggest to add a Obsolete attribute with a description that refers to the official implementation.

[SDGNelson]

Which ones do you have in mind? Off the top of my head the console IO classes are stubs in the RocketMod code now *and would be good to mark obsolete.

[Trojaner]

Most of the events which are only wrappers now. https://github.com/SmartlyDressedGames/RocketMod/blob/master/Rocket.Unturned/Events/UnturnedPlayerEvents.cs
and here: https://github.com/SmartlyDressedGames/RocketMod/blob/master/Rocket.Unturned/Events/UnturnedEvents.cs

Redunant wrappre classes like these:
https://github.com/SmartlyDressedGames/RocketMod/blob/master/Rocket.Unturned/Chat/UnturnedChat.cs
https://github.com/SmartlyDressedGames/RocketMod/blob/master/Rocket.Unturned/Effects/UnturnedEffectManager.cs

Maybe even the whole UnturnedPlayer class, as it just provides shortcuts and causes bugs (for example, various NRE's when the player is offline):
https://github.com/SmartlyDressedGames/RocketMod/blob/master/Rocket.Unturned/Player/UnturnedPlayer.cs

Console IO classes could be removed completely as they were only used internally and were not meant for plugins. The launcher should also be removed imo.

RocketMod should only focus on its core, which is loading plugins, handling commands, managing configurations, etc. It should not create wrappers for everything.

[SDGNelson]

If there is one thing I have learned these past years with plugin devs, it is that just because something should not be used does not mean it is not being used. :)

I agree with you about RocketMod's core functionality, and that wrappers for everything is undesirable. That said, I am not sure about going so far as to make huge components like UnturnedPlayer obsolete (obviously while also ensuring all needed functionality is available in the base game) because so many plugins are already built around them.

While they are essentially wrappers, it seems to me that these examples do provide at least some value for the meantime. For example:

• UnturnedPlayerEvents has actually quite a few events that are not nicely exposed yet, and has both per-object and global events for each with an object context (whereas the base game provides no context). Most recently on this front the base game added functions for modifying life values server-side nicely, but I would like to also add these events to the base game.
• UnturnedEvents handles wrapping the players in UnturnedPlayer objects which if we mark them obsolete I suspect a lot of plugin developers would just do with the built-in events. Until UnturnedPlayer is obsolete these are still useful in my opinion. onShutdown could be marked obsolete though.
• UnturnedChat deals with wrapping long strings into multiple messages. Once the base game UI is reworked to UIElements whenever that's (stable?) it should be easy to support client-side wrapping and longer messages.
• UnturnedEffectManager while simply a wrapper I can see being useful. Create the event data once, and then cleanly call myFireEffect.Trigger. It may as well be added to the base game, and admittedly the sendEffect functions are confusing with all the overloads.
• UnturnedPlayer is a bit of a mixed bag... I think we can gradually make it obsolete, but some of the base game APIs should be made easier first.

Leaving this issue open for further discussion and because it ideally will be gradually addressed.

[Johnanater]

In my experience, UnturnedPlayer is quite convenient. It provides a lot of shortcuts that I mostly use for getting the player's Steam64 and a player's different names instead of using player.channel.owner.blah.blah. It's also really handy for parsing player names/ids.

[GazziFX]

Rocket OnPlayerConnected event is very useful, because if you try to give items in Provider.EnemyConnected event you'll get null reference exeption because inventory initializes in Start()