This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API for controlling new mob behaviours #10443
Comments
looking at the implementation of the brain system across versions, it seems stable enough that short of mojang nuking the system out of nowhere in a future update, there's not much risk in doing a mostly 1:1 exposure of the API? the one (1) thing that concerns me is that the set of available tasks tends to fluctuate a decent amount, but mostly in the direction of adding tasks/splitting existing tasks into multiple flavours |
one thing i'm not sure about is if an API should be |
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
Would fix PaperMC#10443 if done. This is a rough proposal for abstracting over the brains AI system for mobs for plugins to make use of, similar to the Goals API. I don't think it's feasible to attempt to make the new AI conform to the old interfaces. At the moment I understand the rough skeleton and arteries of the system, though I'm still trying to piece together what does what in user-facing terms. 'get the mob to walk somewhere' has been unsuccessful so far. As far as API stability concerns, as long as the exposed set of tasks isn't too 1:1 with what Mojang has, then we should be fine (until the next Big Rewrite:tm: whenever that is) considering the general stability of the system across versions since its introductions. There are still some unanswered questions in the API design: - do events make sense to have here? I'd say no considering the amount of lambdas in the Minecraft implementation that make any real introspection API unfeasible. - do we care to expose sensors/make them modifiable? It could probably be done in a followup PR to make custom tasks & sensors a thing, as I'm mostly concerned about exposing what exists in Vanilla at the moment. - is the arrangement of the entrypoints to the new API sensical? Test plugin is included in PR to ease testing of the new API until it's ready to ship.
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Is your feature request related to a problem?
Probably related to #10442.
Related to #6862.
As Minecraft moves into the future, more and more of the new mobs are mostly controlled via the new systems instead of the old ones that the current Bukkit Goals API abstracts over, and the inability to control them from the Paper API is more glaring.
Describe the solution you'd like.
A new abstraction (or perhaps retrofitting the existing one) for controlling mob behaviours
Describe alternatives you've considered.
Using NMS in order to prod at the underlying Minecraft stuff myself. Whilst doable, NMS usage makes cross-version support an individual plugin issue instead of a communal solution in Paper
Other
I guess it would be nice to have some sort of indicator in the existing API docs for what they don't support currently, maybe a
UnsupportedOperationException
to make failures easier to catch instead of silently not working/only returningfalse
The text was updated successfully, but these errors were encountered: