This repository has been archived by the owner on May 27, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7
Configuring Custom Entities
Daniel Voznyy edited this page Sep 2, 2020
·
1 revision
This process may change significantly in the future, and will differ depending on whether you are working with YAML, JSON, etc...
Create a new file under your mob config directory (see Registering Custom Entity Addons).
Name it mobname.[yml | json | etc...]
. In the future, the plugin will automatically figure out what serializer to use based on your file format.
A config showcasing these in action can be found below.
-
baseClass
: The registered mob class to base this mob on.- Ex:
mobzy:passive
,mobzy:hostile
,mobzy:flying
,someaddon:custompig
- Ex:
-
creatureType
: The type of creature. Currently this uses NMS' EnumCreatureType, which the spawning system uses to limit spawns of that type.- Possible values:
CREATURE
,MONSTER
,MISC
,WATER_CREATURE
, perhaps more I am forgetting. These will likely change to Bukkit's equivelent.
- Possible values:
-
staticComponents
: A list of components which will be shared between all mobs of that type. To specify the component type in yaml, we do!<plugin:component>
. Only use static components for components which never have changing values, such as the mob's model id. -
components
: A list of components which will be unique to each entity. This would be useful for components that have cooldowns, or something like a theoreticalowner
component which stores a pet's owner. Currently these do not persist when entities get unloaded, but in the future we will use Story to store these components directly on the mob. -
targets
: A list of priorities for different target selectors. These are compatible with Minecraft's target selector system, but they require a serializable wrapper class to work. That's the coders' job! -
goals
: Similar to targets, except for Minecraft's PathfinderGoal system. More wrappers will be made for vanilla goals in the future. The GOAP system will also fit into these. You will be able to define a priority for your GOAP goal, and specify which actions it is allowed to take, then the goal will figure out in what order to take those actions (it's totally super cool, I promise :p).
There will likely be a document holding a list of all components you may use. For now your best bet is looking around the ecs.components
package and finding the @SerialName
and parameters required for components.
Currently we have some mobs in our AbyssalCreatures
repo, but here's a specific example:
benikuchinawa.yml
baseClass: mobzy:flying
creatureType: MISC
staticComponents:
- !<mobzy:model>
id: 32
- !<mobzy:attributes>
maxHealth: 50
followRange: 25
attackDamage: 5
flyingSpeed: 4
width: 4
height: 2
- !<mobzy:death_loot>
minExp: 13
maxExp: 16
drops:
- item:
type: POPPED_CHORUS_FRUIT
display-name: §rSplitjaw Scales
minAmount: 2
maxAmount: 3
- item:
type: SHULKER_SHELL
display-name: §rSplitjaw Shell
dropChance: 0.15
- item:
type: SLIME_BALL
dropChance: 0.5
- !<mobzy:sounds>
ambient: entity.llama.ambient
death: entity.llama.death
hurt: entity.llama.hurt
targets:
1: !<mobzy:target.attacker>
range: 100
2: !<minecraft:target.nearby_player> {}
goals:
1: !<mobzy:behavior.flying_damage_target> {}
2: !<mobzy:behavior.flying_dive_on_target>
diveVelocity: -0.03
minHeight: 3
maxHeight: 5
3: !<mobzy:behavior.fly_towards_target> {}
4: !<mobzy:behavior.idle_fly> {}