Open ColinHDev opened 1 year ago
While writing this, I came up with the following as an extension of the first idea:
CommandExecutor
class: A class that represents any command sender (console, player, etc.) and has all required methods for that use case, e.g. sendMessage()
but not sendTitle()
.(Player)Session
class extending from the CommandExecutor
class, which contains all player-related properties and methods like sendTitle()
.@supercrafter333, since you are the only person I know of, who worked with custom subcommand classes, I would especially be interested in your opinion.
I think the first idea (and your Extension for it) is the best. Your second idea would be bad in production and your last idea would be a bit annoying for developers.
Alright, thank you!
Currently, it is a big pain to send messages to players due to the complicated language system.
The idea is to introduce a
Session
class for each online player that handles all the weird logic forsendMessage()
,sendTitle()
, etc. This should improve the API and remove a bunch of lines of boilerplate code.The problem is the following: Not all (sub)commands are sent by players, some like
/p generate
can also be run by the console. There are some ideas that came to my mind over the last few days:PlayerData
, another level of differentiation betweenPlayerSession
s and others would be needed. Therefore theSession
name also would probably not suit any longer.Session
class could implement theCommandSender
interface.$sender instanceof Player
to verify that a command is run by a player. Now they would have to do that with another class, although the method in the subcommand class would look the same as any other in a normal command class.SessionManager::get($sender)
.Input towards this is highly encouraged, so that I don't end up implementing an inferior API design just because of missing input. 👀 Any opinion is welcome! ^^