SBL is open to pull requests and always looking for contributions of custom behaviours, sensors, and memory types. The more we can build up from the community, the more that will be available to other users.

Breaking change-PRs may not be implemented and may instead be recreated in development branches, if required. If your PR does not need to be a breaking change, it should be designed as an in-place change instead (such as by using and documenting deprecated annotations)

Note that custom implementations should follow the same style as the existing ones, so take a look at existing similar classes before submitting your PR.

• Code Style
• New Behaviours
• New Sensors
• New Memory Types

Line-ending curly braces

public static void method() {

}

4-space tabs/indents

public static boolean method() {
    if (myCheck()) {
        if (myOtherCheck())
            doThing();

        return true;
    }

    return false;
}

Braceless single-line if statements

public static void method() {
    if (myCheckHere())
        return;

    if (myOtherCheck()) {

    }
    else {

    }
}

Guard Clauses

public static void healIfOnServer(Level level, LivingEntity entity) {
    if (level.isClientSide())
        return;

    entity.heal(entity.getMaxHealth());
}

Use FastUtil collections

List<Entity> entities = new ObjectArrayList();
Int2ObjectOpenHashMap<Entity> entityIdMap = new Int2ObjectOpenHashMap();

Avoid streams

List<LivingEntity> livingEntities = new ObjectArrayList();

for (Entity entity : myEntityList()) {
    if (entity instanceof LivingEntity livingEntity)
        livingEntities.add(livingEntity);
}

SBL tries to include as many generic behaviours as possible, so that users need to create as few custom behaviours as possible. To that end, it welcomes contributions of new behaviours, under the following requirements:

1. The behaviour should be generic enough that it is viably useful for more than one entity.
2. The behaviour should be designed to fill one function only. A behaviour that finds a new position to walk to should not also start walking there, for example.
3. The behaviour should, at a minimum, extend ExtendedBehaviour, or one of its sub-classes.
4. The behaviour class should be code-documented to explain what it does and any defaults for configurable settings. Configuration methods should be documented to explain what they are configuring. It is not required to document the actual functioning code of the behaviour.
5. The behaviour should be placed into one of the sub-packages of the api/core/behaviour/custom package

SBL tries to include as many generic sensors as possible, so that users need to create as few custom sensors as possible. To that end, it welcomes contributions of new sensors, under the following requirements:

1. The sensor should be generic enough that it is viably useful for more than one entity.
2. The sensor should be designed to fill one function only.
3. The sensor should not perform any actions on the entity besides settings/clearing/checking memories.
4. The sensor should, at a minimum, extend ExtendedSensor, or one of its sub-classes.
5. The sensor class should be code-documented to explain what it does and any defaults for configurable settings. Configuration methods should be documented to explain what they are configuring. It is not required to document the actual functioning code of the sensor.
6. The sensor should be placed into the api/core/sensor/custom package
7. The sensor should be registered in SBLSensors

1. The memory module should be generic enough that it is viably useful for more than one entity.
2. The memory module should be plainly named, and avoid using shortcut/contracted words.
3. The memory module should not replace an existing suitable memory module present in MemoryModuleTypes or SBLMemoryTypes.
4. The memory module should be registered in SBLMemoryTypes