Making Protections

The reasons:

Protections are a big part of the MyTown2 project and is something incredibly difficult to maintain due to the everchanging environment of Minecraft and its modding community.

There are two reasons we have created the current protection system:

1. The difficulty of maintaining a protection system that takes into account basically any mod.
2. Not many people know how to program in Java (at least not in the Minecraft community). This system requires minimal knowledge of Java.

Introduction:

The protection system is based on reading a set of files, each file representing a protection "dictionary" for a mod, we'll call those protections or protection files.

Each of the file is broken down into, so called, segments. Each segment represents something in the mod (entity, tile entity, item, block etc.). The segments tell the protection system what each thing does.

Example: a segment can tell the system that the Creeper from vanilla Minecraft is a hostile mob that will attack the player when it sees it. The system can use this information to control exactly which mob can spawn in Towns or Plots.

Protection files:

• Each protection file is in json format (more information about the format can be found HERE) and needs to be saved as (any_name).json
• There are only three elements that are needed in each of the protection files:
  • modid (of type STRING) is the unique identifier of the mod you want to protect against
  • version (of type STRING) is the minimum version to which this mod is compatible. The system simply performs a startsWith check against the mod version.

Example: if the version that is specified is 0.1 and the mod's actual version is 0.1.10b the protection will initialize, but if the mod's version is 0.2.20 it will not because 0.2.20 does not start with 0.1. * segments (of type ARRAY) which represents an array of all the segments.

Segments

Generic elements for all types of segments:

• class (of type STRING) represents the class to the object you want to protect against. If the object is an item or block you can use the command /ta debug itemClass while holding it to find its class.
• type (of type STRING) represents what this segment is supposed to protect. This can have the values: entity, tileEntity, item or block
• flag (of type STRING or OBJECT) represents what flag is the segment supposed to check against.

Example: let's say the object we want to protect against is a block breaker in which case the most reasonable flag to set to is modify

  * this can also be defined as an object with the elements:
      * `name` as the name of the flag
      * `denialValue` as the value of the flag which should deny the object's actions.

Example: let's say the object we want to protect against is a giant zombie in which case the most reasonable flag to set to is mobs, although only setting that is not enough, the system needs to know what value the flag needs to have for it to be denied, in this case it should be passives

Elements for entity segments: