feat: Api to display inventory to remote player

[OldManYells]

This PR exposes a cleaner interface to allow displaying inventories remotely

Please review and let me know if this functionality should be placed some other place.

[Garsooon]

While I think this is a cool feature I don't know if features that are traditionally added by most major server eco/moderation plugins should be getting added to the server jar when it can be done via plugins.

Additionally if this does get added, the command should fall under a /poseidon subcommand, see this PR for context.

[OldManYells]

While I think this is a cool feature I don't know if features that are traditionally added by most major server eco/moderation plugins should be getting added to the server jar when it can be done via plugins.

Additionally if this does get added, the command should fall under a /poseidon subcommand, see this PR for context.

This PR atm only exposes through Bukkit what otherwise is only called by server internal code, the actual feature/command would be added in a plugin or as you mentioned in /poseidon. Not sure if you mean something else or you are referring to a previous commit that also added the command.

[Garsooon]

While I think this is a cool feature I don't know if features that are traditionally added by most major server eco/moderation plugins should be getting added to the server jar when it can be done via plugins.
Additionally if this does get added, the command should fall under a /poseidon subcommand, see this PR for context.

This PR atm only exposes through Bukkit what otherwise is only called by server internal code, the actual feature/command would be added in a plugin or as you mentioned in /poseidon. Not sure if you mean something else or you are referring to a previous commit that also added the command.

Yeah I figured the PR was a draft of some kind going off of it's previous title talking about adding it as a command.

[OldManYells]

@Garsooon how would you like to go about on this?

[Garsooon]

Up to @RhysB, however when we were talking about it briefly in both forms (api/command) it probably wouldn't be needed since B1.7.3 plugins already can and have accessed inventories using NMS among other things.

[OldManYells]

Yes. The point is exposing it clearly to the API. As an exempla the only current plugin that allows an OP to check a player inventory is a "read only" functionality(afaik and what is used in rmc). With this clearly exposed is easy to understand that not only is possible but it's easy to create a plugin that allows operators to directly edit a players inventory.

[OldManYells]

@RhysB 🥺

[zavdav]

one thing i have to say here: it is generally bad practice to expose nms internals in the bukkit api. in #148 i attempted to backport the inventory api from modern bukkit to beta, which wraps these internals around craftbukkit classes in order to expose them to bukkit cleanly.

[tacf]

one thing i have to say here: it is generally bad practice to expose nms internals in the bukkit api. in #148 i attempted to backport the inventory api from modern bukkit to beta, which wraps these internals around craftbukkit classes in order to expose them to bukkit cleanly.

What was the reason to close that PR?

Tbh i would like just to start rewritring the whole nms out of the equation, I've been doing functions wrappers any time i change anything in nms just for that reason. I don't see why at this pois shouldn't we start just dropping nms (keeping a compat layer for now to provide plugin migration time) and go all in into a custom implementation. It seems to me that at this point there's a small subset of groups working on this project and even Bukkit probably is not useful in itself as having out own api (or if it really matter to port modern plugin we should just move to a "craftbukkit" independent implementation.

What are your thoughts on this ?

I've even started compiling my plugin with SDK17 (targeting 1.8) to make sure we can have an easier time moving to newer versions of Java .

[zavdav]

one thing i have to say here: it is generally bad practice to expose nms internals in the bukkit api. in #148 i attempted to backport the inventory api from modern bukkit to beta, which wraps these internals around craftbukkit classes in order to expose them to bukkit cleanly.

What was the reason to close that PR?

Tbh i would like just to start rewritring the whole nms out of the equation, I've been doing functions wrappers any time i change anything in nms just for that reason. I don't see why at this pois shouldn't we start just dropping nms (keeping a compat layer for now to provide plugin migration time) and go all in into a custom implementation. It seems to me that at this point there's a small subset of groups working on this project and even Bukkit probably is not useful in itself as having out own api (or if it really matter to port modern plugin we should just move to a "craftbukkit" independent implementation.

What are your thoughts on this ?

I've even started compiling my plugin with SDK17 (targeting 1.8) to make sure we can have an easier time moving to newer versions of Java .

• i don't think anyone in the legacy minecraft community has the time and sheer willpower to write a complete reimplementation of the b1.7.3 minecraft server. of course, we would not have to worry about licensing anymore, however it would simply take wayyy too much effort to do this.
• the entire community is relying on the bukkit api to create new plugins and maintain legacy plugins. i don't think the majority of people would be a fan of having to learn a new api and porting all of their plugins to this api.

i have been communicating internally with @RhysB and we are planning a poseidon v2 which will be compiled with java 25 and above, and which will significantly rewrite/redesign poseidon internals.

[OldManYells]

one thing i have to say here: it is generally bad practice to expose nms internals in the bukkit api. in #148 i attempted to backport the inventory api from modern bukkit to beta, which wraps these internals around craftbukkit classes in order to expose them to bukkit cleanly.

What was the reason to close that PR?
Tbh i would like just to start rewritring the whole nms out of the equation, I've been doing functions wrappers any time i change anything in nms just for that reason. I don't see why at this pois shouldn't we start just dropping nms (keeping a compat layer for now to provide plugin migration time) and go all in into a custom implementation. It seems to me that at this point there's a small subset of groups working on this project and even Bukkit probably is not useful in itself as having out own api (or if it really matter to port modern plugin we should just move to a "craftbukkit" independent implementation.
What are your thoughts on this ?
I've even started compiling my plugin with SDK17 (targeting 1.8) to make sure we can have an easier time moving to newer versions of Java .

* i don't think anyone in the legacy minecraft community has the time and sheer willpower to write a complete reimplementation of the b1.7.3 minecraft server. of course, we would not have to worry about licensing anymore, however it would simply take wayyy too much effort to do this.

* the entire community is relying on the bukkit api to create new plugins and maintain legacy plugins. i don't think the majority of people would be a fan of having to learn a new api and porting all of their plugins to this api.

i have been communicating internally with @RhysB and we are planning a poseidon v2 which will be compiled with java 25 and above, and which will significantly rewrite/redesign poseidon internals.

I was kinda doing it for fun 😅