Skip to content

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

Closed
pontaoski opened this issue Apr 20, 2024 · 2 comments · May be fixed by #10462
Closed

API for controlling new mob behaviours #10443

pontaoski opened this issue Apr 20, 2024 · 2 comments · May be fixed by #10462
Labels
type: feature Request for a new Feature.

Comments

@pontaoski
Copy link
Contributor

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 returning false

@pontaoski pontaoski added status: needs triage type: feature Request for a new Feature. labels Apr 20, 2024
@pontaoski
Copy link
Contributor Author

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
tasks in general are a bit weird from an API perspective because they're just subclasses that you instantiate individiually, and they have varied parameter types that preclude some sort of createTask(Tasks.WALK_TO_POSITION) method a la spawnEntity
i mean i guess you could have Task1, Task2, Task3, Task4, etc. etc. tuple classes to encapsulate task parameters?

@pontaoski
Copy link
Contributor Author

one thing i'm not sure about is if an API should be LivingEntity#getBrain with all of the methods similar to the minecraft implementation, or exposing the sensor/task methods on the entity itself the same way spigot did with LivingEntity#getMemory/LivingEntity#setMemory

pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 27, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue Apr 28, 2024
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.
@PaperMC PaperMC locked and limited conversation to collaborators Apr 28, 2024
@kashike kashike converted this issue into discussion #10487 Apr 28, 2024
pontaoski added a commit to pontaoski/Paper that referenced this issue May 8, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue May 8, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue May 10, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue May 10, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue May 10, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue May 19, 2024
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.
pontaoski added a commit to pontaoski/Paper that referenced this issue May 19, 2024
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 →

Labels
type: feature Request for a new Feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants