You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently 2 tiers of scripting for entities: a script, one-off and specific for a single entity; and behaviors shareable/configurable chunk of code.
The use case for composite behaviors is the following:
I have 3 types of town guard: gate guard, tower archers, and cityguards. I want all guards to wander, I want them all to attack any npc from a different area that is currently attacking an npc in this area or a player. The wander configurations differ between the archers and the cityguards but regardless they both wander, but the "aggro" behavior config is the same between them and quite complex.
Currently to accomplish this I would have to copy and paste the behavior configuration for each guard. Hence the need for "composite behaviors".
Currently behaviors live in behaviors/<entity type>/<name.js> a new file would need to be created in `behaviors//composites.yml"
Composite behaviors should be able to be recursive: so a composite behavior can be a collection of composite behaviors as long as there is no circular dependency.
Composite behaviors should not share a name with an existing behavior of the same entity type. NOTE: There is likely currently a bug where if two bundles define a behavior with the same name weird shit will happen.
Composite behaviors should be able to be used exactly like standard behaviors such that when using a composite behavior one should be able to override the configurations.
Example composites.yml file:
# name of composite behaviorranvier-guard:
# list of behavior configurations (essentially exactly what you would otherwise put in the `behaviors` setting for a single entityranvier-wander:
areaRestricted: trueranvier-aggro:
players: false# attack any NPC that is not from this area that wanders into it (unless it is a follower of a player)areaDefender: true# attack anything attacking an npc with the entityRef in this list, i.e., they are teammates with these npcsteammates: [ "somearea:cityguard", "somearea:archer-guard", "somearea:gateguard" ]
When using this composite behavior it would be like any other behavior, example in npcs.yml
- id: cityguardname: Cityguardbehaviors:
# cityguard doesn't need any extra configuration on top of ranvier-guardranvier-guard: true
- id: archer-guardname: Tower Archerbehaviors:
# the tower archer wanders only along the tower wallranvier-guard:
ranvier-wander:
restrictTo: [ "somearea:towerwall-1", "somearea:towerwall-2", "somearea:towerwall-3" ]
- id: gateguardname: City Gate Guardbehaviors:
# the gate guard doesn't wander from their roomranvier-guard:
ranvier-wander:
disabled: true
The text was updated successfully, but these errors were encountered:
Hmmm, If I recall correctly I suggested something similar to this behavior with mob type inheritance. SO You could have a basic guard mob with the aggro, wander and the guard behaviors. Then you just clone the basic guard three times as the archer, city and gate guard, it comes with the basic stats and behaviors already assigned to basic guard as that would be it's prototype/parent. Then just change the wander areaRestricted on the archer.
@samjaninf this could technically be done right now with no changes necessary by using YAML anchors but I'd rather have it codified than depend on a YAML feature
There are currently 2 tiers of scripting for entities: a script, one-off and specific for a single entity; and behaviors shareable/configurable chunk of code.
The use case for composite behaviors is the following:
I have 3 types of town guard: gate guard, tower archers, and cityguards. I want all guards to wander, I want them all to attack any npc from a different area that is currently attacking an npc in this area or a player. The wander configurations differ between the archers and the cityguards but regardless they both wander, but the "aggro" behavior config is the same between them and quite complex.
Currently to accomplish this I would have to copy and paste the behavior configuration for each guard. Hence the need for "composite behaviors".
Currently behaviors live in
behaviors/<entity type>/<name.js>
a new file would need to be created in `behaviors//composites.yml"Example
composites.yml
file:When using this composite behavior it would be like any other behavior, example in npcs.yml
The text was updated successfully, but these errors were encountered: