Skip to content

Instantly share code, notes, and snippets.

@ErichDonGubler

ErichDonGubler/0.9.5 changelog.md

Created July 20, 2011 20:50
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ErichDonGubler/1095903 to your computer and use it in GitHub Desktop.
Save ErichDonGubler/1095903 to your computer and use it in GitHub Desktop.
Download ZIP
0.9.5 new wiki pages
Raw
0.9.5 changelog.md

0.9.5

Changes:

  • For what should be the last time, major syntax changes have occurred in MD. Gone now are the strange nodes - ModDamage is now entirely conditionally driven. The new configuration scheme is like follows:
Event:
    - SOME.ROUTINE
    - PERHAPS.A.CONDITIONAL:
        - SOME.ROUTINE
    - EVEN.A.SWITCH:
        FIRSTCASE:
        SECONDCASE:
        ANOTHERCASE:
These routines are run every time the relevant event is fired - conditional evaluations are now necessary for situational dynamics.

  • Modified $entity$op syntax in conditionals to be split with a period - syntax reference has been updated accordingly in the tuts and reference on the wiki

  • Renamed "MobHealth" to "Spawn".

Fixes:

  • Fixed events throwing NPEs when Permissions was not present. Oops.

  • Fixed EntitySetOnFireTicks routine not working.

  • Fixed EntityReflect (now renamed to EntityHurt) causing explosions, instead of hurting entities magically.

  • Changed EntityExposedToSky conditional to ignore more blocks. Current list:

    • Air

    • Torch

    • Ladder

    • Fire

    • Lever

    • Button

    • WallSign

    • Glass

  • Fixed ArmorSet comparisons to work as intended - I know there are some edge cases out there that suffered because of this. :(

  • Added an "empty" ArmorSet so it's possible to determine whether a player is wearing any piece of armor or not. This is literally the string "EMPTY", case-insensitive.

  • Removed the EntityTargetedByOther routine - this seemed a very limited-application routine.

  • Changed the Binom base routine to operate as a Conditional statement.

  • Changed the Set base routine to operate as a Calculation.

New features:

  • Added "switch" statements. Switch statements are the final step in effectively replacing the Offensive/Defensive paradigms and DET configuration with a more dynamic model that should be more intuitive and simple to use - see above and/or the wiki.

  • Drastically modified configuration reports ingame and on the console - characters are now counted for proper line output, and the entire configuration is essentially read back, including colored error/warning strings. Much more functional than the last config checking.

  • Tweaked Conditionals syntax - they can now use basic boolean operators, though operation is strictly linear. There are no plans for parenthetical encapsulation. See the new tutorial for more details!

  • Aliasing for the following:

    • Armor sets

    • Biomes

    • Entity types

    • Groups

    • Items

    • Message - see the Message routine for more details [here].

    • Worlds

  • Added the following routines:

    • AddItem (Effect, aliasable)

    • DropItem (Effect, aliasable)

    • HasRangedElement (Conditional)

    • SetItem (Effect)

    • PlayerSleeping (Conditional)

    • PlayerSneaking (Conditional)

    • WorldEvaluation (Conditional, aliasable)

  • Added sub-elements for Spider: Spider_Jockey and Spider_Riderless.

  • Added Death and Food events. :D

  • Changed the Elements hierarchy to have a "Living" and "Nonliving" category - the former including mobs, animals, and humans, while the latter covers everything else.

The following were suggested by lucent (thanks!):

  • Added the "fishingrod" ranged damage element.

  • Added states for certain mobs (Slime size, Wolf angry/wild/tame, Creeper normal/charged, Human NPC/Player) - refer to wiki for more information.

  • Added EntityX and EntityZ comparisons - for consistency, EntityAltitude has been renamed to "EntityY".

The following were suggested by TheSquishyDitto. Thanks!:

  • Added the "trap" generic MD element and "dispenser" as a child element.

  • Changed configuration so that single-property configuration works in those cases you don't want to use another line. :D

Raw
0.9.5changelog.md

0.9.5

Changes:

  • For what should be the last time, major syntax changes have occurred in MD. Gone now are the strange nodes - ModDamage is now entirely conditionally driven. The new configuration scheme is like follows:
Event:
    - SOME.ROUTINE
    - PERHAPS.A.CONDITIONAL:
        - SOME.ROUTINE
    - EVEN.A.SWITCH:
        FIRSTCASE:
        SECONDCASE:
        ANOTHERCASE:
These routines are run every time the relevant event is fired - conditional evaluations are now necessary for situational dynamics.

  • Modified $entity$op syntax in conditionals to be split with a period - syntax reference has been updated accordingly in the tuts and reference on the wiki

  • Renamed "MobHealth" to "Spawn".

Fixes:

  • Fixed events throwing NPEs when Permissions was not present. Oops.

  • Fixed EntitySetOnFireTicks routine not working.

  • Fixed EntityReflect (now renamed to EntityHurt) causing explosions, instead of hurting entities magically.

  • Changed EntityExposedToSky conditional to ignore more blocks. Current list:

    • Air

    • Torch

    • Ladder

    • Fire

    • Lever

    • Button

    • WallSign

    • Glass

  • Fixed ArmorSet comparisons to work as intended - I know there are some edge cases out there that suffered because of this. :(

  • Added an "empty" ArmorSet so it's possible to determine whether a player is wearing any piece of armor or not. This is literally the string "EMPTY", case-insensitive.

  • Removed the EntityTargetedByOther routine - this seemed a very limited-application routine.

  • Changed the Binom base routine to operate as a Conditional statement.

  • Changed the Set base routine to operate as a Calculation.

New features:

  • Added "switch" statements. Switch statements are the final step in effectively replacing the Offensive/Defensive paradigms and DET configuration with a more dynamic model that should be more intuitive and simple to use - see above and/or the wiki.

  • Drastically modified configuration reports ingame and on the console - characters are now counted for proper line output, and the entire configuration is essentially read back, including colored error/warning strings. Much more functional than the last config checking.

  • Tweaked Conditionals syntax - they can now use basic boolean operators, though operation is strictly linear. There are no plans for parenthetical encapsulation. See the new tutorial for more details!

  • Aliasing for the following:

    • Armor sets

    • Biomes

    • Entity types

    • Groups

    • Items

    • Message - see the Message routine for more details [here].

    • Worlds

  • Added the following routines:

    • AddItem (Effect, aliasable)

    • DropItem (Effect, aliasable)

    • HasRangedElement (Conditional)

    • SetItem (Effect)

    • PlayerSleeping (Conditional)

    • PlayerSneaking (Conditional)

    • WorldEvaluation (Conditional, aliasable)

  • Added sub-elements for Spider: Spider_Jockey and Spider_Riderless.

  • Added Death and Food events. :D

  • Changed the Elements hierarchy to have a "Living" and "Nonliving" category - the former including mobs, animals, and humans, while the latter covers everything else.

The following were suggested by lucent (thanks!):

  • Added the "fishingrod" ranged damage element.

  • Added states for certain mobs (Slime size, Wolf angry/wild/tame, Creeper normal/charged, Human NPC/Player) - refer to wiki for more information.

  • Added EntityX and EntityZ comparisons - for consistency, EntityAltitude has been renamed to "EntityY".

The following were suggested by TheSquishyDitto. Thanks!:

  • Added the "trap" generic MD element and "dispenser" as a child element.

  • Changed configuration so that single-property configuration works in those cases you don't want to use another line. :D

  • The following were suggested by Ranzear - much obliged!

  • Added the EntitySpawn Calculation.

Raw
config-reference.md

TABLE OF CONTENTS:

  • Before You Read

  • ModDamage-specific Elements

    • Event elements

    • Ranged elements

  • Section A: Events reference - "What Damage-related Events Can I Change With ModDamage?"

  • Section B: Routines - "How do I tinker with these damage events?"

    • [B.01]: Base calculation strings

    • [B.02]: Conditional calculation strings

    • [B.03]: Effect calculation strings

    • [B.04]: Routines: Exhaustively Listed Here

  • Section C: FAQs - Coming soon!

Before You Read

Some of the syntax in individual routine entries may not necessarily be intuitive - it is necessary, then, to clarify what certain parts of MD routine syntax mean. An exhaustive list is as follows:

  • $armorsetalias - an armor/equipment set interpreted by ModDamage, or an alias comprised of armorsets. See the [second tutorial] for more information.

  • $biomealias - a valid Biome according to the * Bukkit enum, or an alias comprised of these.

  • $comparison - a comparison operator for a conditional. Possible values are:

    • equals

    • greaterthan

    • greaterthanequals

    • lessthan

    • lessthanequals

    • notequals

  • $elementalias - a valid string that corresponds to a type of entity in ModDamage. See the * [first tutorial][2*] and the config reference for more information.

  • $environment - a valid Environment according to the * Bukkit enum (see the bottom of the page).

  • $groupalias - a group defined in a Permissions implementation outside of ModDamage, or a group alias comprised of these. Currently, only support for Permissions 2.0 and higher exists - perhaps you could suggest your preferred plugin on the Bukkit thread?

  • $itemalias - a valid Material according to the * Bukkit enum.

  • $logical - a logical operator for a conditional. Possible values are:

    • and

    • nand

    • nor

    • or

    • xor

  • $messagealias - a valid Message alias reference, or a single message string. If using the latter, it's recommended to use double-quotes instead of single quotes around your Message routine to ensure that your message is read properly.

  • $worldalias - a valid world name in your Bukkit server, or an alias comprised of these.

ModDamage-specific Elements

Entity Elements Tree

  • Living

    • Animal - Animals are all creatures that serve to benefit the player by either slaughter or taming.

      • Chicken

      • Cow

      • Pig

      • Sheep

      • Wolf - These have several states that can be used.

        • Wolf_Angry - AKA "hostile" Wolves. The ones complete with all-new growling and red-eye features.

        • Wolf_Tame - A Wolf whose loyalty has been declared to a player (with the "soft" eyes).

        • Wolf_Wild - Wolves. As nature built them.

    • Human - Your favorite pink squishies.

      • NPC - These are "monster" type humans that are spawned in some plugins. Most MC players don't ever see them.

      • Player - What does it sound like?

    • Mob

      • Creeper - Lovable suicidal shrubs. These have two states.

        • Creeper_Charged - A Creeper that's activating its Limit Attack?!...err...no. Charged Creepers have been struck by lightning, and have a blue glow effect surrounding them.

        • Creeper_Normal - Just an ordinary Creeper.

      • Ghast

      • Giant

      • Skeleton

      • Slime

      • Spider

        • Spider_Jockey - SKELETON CAVALRY! D:

        • Spider_Riderless - A bareback Spider.

      • Zombie

      • ZombiePigman

  • Nonliving

    • Nature - These can be delightfully confusing, and shall be annotated.

      • Burn - See "fire". And maybe Webster's for "screwed".

      • Cactus - Pokey pokey.

      • Drowning - Swimming along, you run out of air...is it all over?

      • Explosion - Works for TNT, not entirely sure about something like fireballs.

        • Explosion_Block - The only time this seems to be used as of build 1060 is when an explosion is directly generated by a plugin.

        • Explosion_Entity - Used basically everywhere else.

      • Fall - ModDamage - 9001, Gravity - 0

      • Fire - "fire" is exposure to a fire block..."burn" is damage taken after you survive that exposure.

      • Lava - Lava's a different story altogether. But still blocky.

      • Lightning - crackBOOOOOM. It should be noted that a lot of fire damage is associated with lightning strikes.

      • Suffocation - Differs from drowning because this is block-based (sand/gravel)

      • Void - Bottomless pits are so original.

    • Trap

      • Dispenser

Ranged Elements

Ranged Elements are used to denote that a ranged item was involved (usually in a Damage or Death event). Valid Elements are:

  • Arrow - fired by a Skeleton or a human.

  • Egg - thrown by a human.

  • Fireball - Usually seen being spat by a Ghast.

  • FishingRod - the "hook" of a fishing rod?

  • Snowball - self-explanatory, I hope.

SECTION A - "What Damage-related Events Can I Change With ModDamage?"

A.01 - Damage

Damage is an event fired whenever...well...whenever something living takes damage! Manipulating this event is simple. Use routines to alter the event's value.

Damage events are demonstrated from the [very beginning] of the MD tutorials.

A.02 - Death

Death routines are also self-explanatory. Unlike the Damage event, there's no way to change the outcome of this event - the entity's going to die, no matter what value-manipulation routines you use. The most useful routines here will likely be Message or Calculation routines that do something interesting to the last attacker or the event's world.

A.03 - Food

Food routines are fired whenever a player uses a food item to heal themselves. The event value is manipulable, like the Spawn and Damage event. Resulting values less than or equal to 0 cancel the event.

[A.04] - Spawn

Spawn routines are fired when a living creature spawns - animals, mobs, or humans. This event value is manipulable, and resulting values of 0 or less will cancel the event.

A.05 - Miscellaneous configuration

This briefly describes each of the single-property configurations in ModDamage.

  • "debugging" changes how verbose your console output when using ModDamage (primarily for loading/reloading information). There are three modes:

    • "verbose" is for people who don't want to talk to ModDamage's very active dev, or like wading through lots of probably useless information. By the same token, if you're truly determined to figure out what's going wrong with your configuration without external support, this is the way to go.

    • "normal" prints out each valid configuration node that is found upon load/reload. This is on by default, since new users that have not configured this will likely want to be able to see this input (i.e., they have an unrecognized node name)

    • "quiet" suppresses all but critical errors and warnings that ModDamage might be thrown. When you're sure you've got the configuration you want on your server, it's suggested you use this to stop spamming your console with information that you already know.

  • "negativeHeal" is far and away the least likely configuration an admin might use, and is currently being considered for removal. Any negatively-resulting damage events will heal the target when this is enabled.

SECTION B - "How do I tinker with these damage relationships?"

[B.01] - Calculations

Uses a value calculated from nested routines to do something.

- 'targeteffect.explode': '9001' #Don't actually do this.

All value-manipulating routines do NOT affect the event's value if they are nested under a Calculation routine.

[B.02] - Conditionals

The primary control branch in ModDamage. Use Conditionals to control whether or not the nested routines will execute. See the [second tutorial] for more information on Conditionals.

- 'if condition':
    - 'routine'
    - 'if another.condition':
        - 'another.routine'
- 'if_not firstcondition and secondcondition': #If_not inverts the entire conditional.
    - 'yet.another.routine'
- 'if condition_one or condition_two or !condition_three': #Condition_three is inverted.
    - 'umpteenth.routine'

[B.03] - Switches

Similar to switches in Java, these are used for more refined control branching than simple conditionals. With Switches, cases are checked sequentially until either a match has been found, or there are no cases left to evaluate. Only the matched case's routines are executed.

- 'switch.something':
    CaseOne: 'single.routine'
    
    CaseTwo:
        - 'nested.routine'
    
    [...]

    LastCase:
        - 'another.routine'
        - 'yet.another.routine'

Some switches uses aliases as cases - see [[B.04] - Routines: Exhaustively Listed Here] for more details.

[B.04] - Routines: Exhaustively Listed Here

###Routines by Category

Event Value

[Set World Time (Calculation)] (https://github.com/KoryuObihiro/ModDamage/wiki/Calculation:-Set-World-Time)

Entity/Mob

Player

World

[Set World Time (Calculation)] (https://github.com/KoryuObihiro/ModDamage/wiki/Calculation:-Set-World-Time)

Server

###Routines by Type

Base

Calculated Effect

Conditional

[Group (aliasable)] (https://github.com/KoryuObihiro/ModDamage/wiki/Statement:-Group)

Switch

Raw
tutorial-1.md

ModDamage tutorial, part 1: The Basics of MD

Introduction

Welcome to the ModDamage tutorial! If you're looking to start messing with damage mechanics in Minecraft, you've come to the right place!

So. First things first. This tutorial is intended to be an interactive, hands-on experience. If you don't already have ModDamage downloaded and placed in your Bukkit plugins folder, it's recommended you do so now.

Got that all done? Okay. Here goes.

ModDamage, by itself, does nothing upon installation. You may have noticed this if you just dropped the ModDamage JAR into your server plugins folder without a configuration...and nothing happened. This is because ModDamage configuration doesn't have any routines defined in its configuration (which, if this is a fresh installation, should have generated automagically for you)! Without routines, ModDamage can literally do nothing - it's up to you to put everything you want into ModDamage. ModDamage will never do anything you do not explicitly tell it to. Thus, our first question for this tutorial is: "how do we configure ModDamage?"

Note: The sample configurations in this tutorial should be easily pastable into ModDamage, though in some cases you may have to adapt them to fit your setup. If you're wanting to tinker with one, you can use this online YAML parser to sanity-check your config files when you write your own configuration. Just sayin'.

The Tutorial

Routines: MD's Configuration Basis

Base Routines

To begin, we present the concept of routines. These are string patterns written into the config.yml that ModDamage interprets as...well, routines to be executed for the relevant event that is fired. Routines serve as extensions of game mechanics themselves, and the most effective way to demonstrate them is with example. That said, consider the following configuration in ModDamage:

Damage:  '2'

A simple integer string applies the Addition base routine - that is, it will add its value to a damage event's current value when the routine is executed. In this sample configuration, ALL damage events will have their damage values raised by a value of 2. Contrast with this next configuration:

Damage: 'set.2'

This is another base routine called "Set". It literally sets an event's value to the specified value whenever executed. Both Add and Set routines are examples of "base" routines in ModDamage - which require no instructive components besides themselves. The ModDamage routine library has a handful of base routines that permits most simple math and simple pseudo-random calculations, some of which will be discussed in later parts of this tutorial.

Conditional Routines

As base routines are otherwise fairly self-explanatory, we shall now discuss routines that are used in conjunction with other routines, or "nested" routines. The most immediately useful of these are Conditional routines. Conditionals control the flow of routine execution by virtue of simple propositional logic that most people are familiar with - again, explaining this is best done by virtue of demonstration. Consider the following configuration with a single Conditional routine:

Damage:
    - 'if attacker.type.Creeper':
        - 'set.200'
        - 'if target.group.Admin': 'set.0'

The value of any damage event involving an attacking Creeper will always be 200, the max health possible in any LivingEntity in Minecraft - unless the target is a member of the group Admin, in which case damage will be set to 0. Therefore, only Admins could possibly survive MC's favorite suicidal shrubs on this server.

Retrospectively it's easy to see the use of the "attacker.type" conditional in Minecraft. With the deprecation of the Elements trees that were used in early releases of ModDamage, the EntityType conditional is a crucial part of any reasonably complicated configuration. Those who are new to ModDamage should become acquainted with the ModDamage Elements hierarchy, an internal interpretative structure used by ModDamage. This hierarchy can be found at the [[config reference|Configuration Reference]] - it's strongly recommended you take a look at the relevant section if you plan on doing any tinkering with Type control routines.

Here's another example of the Entity Type conditional put to use, this time with multiple statements in the routine:

Damage:
    - 'if attacker.type.human': 
        - 'set.4'
        - 'if attacker.group.Admins and target.group.Default': 'mult.2' # Same-line configuration. :D
    - 'if target.group.Default': '2'

Note: single-line configuration can only be done with a single BASE routine string - nested routine types MUST be formally placed underneath and indented..

The characteristics of this configuration can be readily summed up in English:

1. All humans have a base attack damage of 4, regardless of item in hand.

2. Any member of the group Admins deals (base_damage * 2) to any member of the group Default, which in this case is 8 (a hefty four hearts!).

3. Any member of the group Default takes an additional 2 damage from any human.

So, if a member of the group Admin were to attack a member of the group Default, then it would be calculated as (4 * 2 + 2) = 10. Likewise, if a member of any other group attacked a member of Default, the calculation would simply be (4 + 2) = 6 damage.

With the introduction of control branching it is very important to note here that the order of operation for MD configuration is exactly in the order you place it.

Switch Routines

Switch routines complement Conditional statements with a different method of control commonly referred to as "branching". Switches are designed to work very similarly to switch statements in Java, have relatively simple syntax:

- 'switch.something':
    FirstCase:
        - SOME STATEMENTS
    SecondCase:
        - SOME STATEMENTS
    #...etc.

We shall also introduce the Spawn event node into our MD repertoire with yet another example. The Spawn configuration controls event values for creature spawn events - and this works for players too.

#Sample Spawn config
Spawn:
    - 'switch.target.type':       # You can use "attacker" in this EntityType conditional without complaint, 
                                  #   but semantically you'll always want to use "target" for Spawn.
        Pig: 'set.200'
        Creeper:
            - 'set.0'
            - 'range.3.7'         # A simple equation that defines an upper and lower bound that randomly assigns
                                  #   a value between that range. In this example, Creepers now spawn with 
                                  #   health between 3 and 7.
                                  
        Ghast: 'set.0'            # If a nonpositive result is calculated for spawning, then it simply cancels the event. :D
        
        Human: 'set.12'           # Wee power boost. :)
		
		Player: 'set.22'

There is a problem with this configuration - that is, the Player case never gets executed! If you refer to the ModDamage Elements table in the [[config reference|Configuration Reference]], you'll notice that Player is a subcategory of Human - and thus any Player would get caught by the Human case. Be wary of these types of mistakes as you configure MD.

Calculations

Calculation routines are not control-type routines - rather, they use nested routines to calculate an input value for the effect. Functionally, they are similar to base routines in usage - however, they differ in the respect that subroutines do not directly affect event values. The routines that may be of immediate interest in this tutorial shall, as usual, be demonstrated by example:

Damage:
    - 'switch.attacker.group':
        RedWizards:
            - 'switch.attacker.wielding':
                Book:
                    - 'targeteffect.heal': '2' # Heal any ol' schmuck for 1 heart. Note that single-line nesting can be done here too.
                Bookshelf: 
                    -'switch.target.group':
                        RedTeam:             # Multigroup is awesome this way - only allow this to heal teammates.
                            - 'targeteffect.heal': '6'
                Coal:
                    -'if_not target.group.RedTeam and !target.onfire':
                        - 'targeteffect.addfireticks': 'range.3000.5000' # Sets the target on fire, though this is a fairly random number. :D

There are two Calculations used here - the Heal Calculation, and the AddFireTicks Calculation. This configuration allows for RPG-type healing and, more importantly, lets players of the RedWizard group set people outside of that group on fire.

Wrapping It All Up: Testing Your Configuration

ModDamage has some included debugging features that can be very useful for troubleshooting your syntax. Understanding how to use these can save you a lot of time and frustration when you've got a large, untested MD configuration written out - which is precisely what was in mind when MD was written. Configuration debugging can be done both from the console and ingame - it's really a matter of preference. If you use Linux or a frontend like [Crafty], which highlights log messages according to their severity, you may find it easier to debug your configuration from the Bukkit console. If not, MD also offers the same functionality ingame. Debugging is done with the the /moddamage check command (/md c, for short).

Console Debugging

From the console, simply type "md c" and the entire configuration will print to the screen.

Ingame Debugging

Using the Check command ingame is a relatively streamlined process. When you first type "/md c", an overview screen is displayed, similar to below:

[*2] SCREENSHOT KTHX - 1

In this example, we're using the current config:

Damage:
    - 'switch.event.world':
        world:
            - 'message.target.world'
        world_nether:
            - 'message.target.world_nether'
debugging: normal

We can demonstrate ingame Check command usage by inserting the following mistake:

Damage:
    - 'switch.event.world':
        world_nether:
            - 'messagetarget.world_nether'
debugging: normal

SHOT 2

SHOT 3

Typing /md c 1...

SHOT 4

A complete reference to ModDamage routines is available at the [[Configuration Reference page|Configuration Reference]]

That about sums it up for this first tutorial. With these basics alone, you should be able to configure ModDamage to suit your needs. Ready for more advanced, applied examples? Hit the [[next page of the tutorial]]!

Raw
tutorial-2.md

Aliasing

Our first example for Aliasing in this tutorial will be a redux of the configuration we used for Calculations in the first tutorial. Remember this?

Damage:
    - 'switch.attacker.group':
        RedWizards:
            - 'switch.attacker.wielding':
                Book:
                    - 'targeteffect.heal': '2' # Heal any ol' schmuck for 1 heart. Note that single-line nesting can be done here too.
                Bookshelf: 
                    -'switch.target.group':
                        RedTeam:             # Multigroup is awesome this way - only allow this to heal teammates.
                            - 'targeteffect.heal': '6'
                Coal:
                    -'if_not target.group.RedTeam':
                        - 'targeteffect.setfireticks': 'range.3000.5000' # Sets the target on fire, though this is a fairly random number. :D

Now let's say you wanted to implement a class of sword-wielders, too, which have some common skills. We'd use aliasing to reduce the volume of our configuration, like so:

Damage:
    - 'if attacker.group.Wizard':
        - 'switch.attacker.wielding':
            Book:
                - 'targeteffect.heal': '2' # Heal any ol' schmuck for 1 heart. Note that single-line nesting can be done here too.
            Bookshelf: 
                -'switch.target.group':
                    RedTeam:             # Multigroup is awesome this way - only allow this to heal teammates.
                        - 'targeteffect.heal': '6'
            Coal:
                -'if_not target.group.RedTeam':
                    - 'targeteffect.setfireticks': 'range.3000.5000' # Sets the target on fire, though this is a fairly random number. :D

Aliases:
    swordies:
	    - 'Red'
		- 'BlueWizard'

Now, we'll provide with a much more complex example, which also serves to demonstrate the flexibility and power of MD to change Minecraft. Suppose that there's a server with two factions: nether dwellers called Firebreathers, and those of the overworld called...well, the Overlanders. :P

Damage:
    - 'switch.environment':
        nether:
            - 'switch.attacker.type':
                Human:
                    - 'set.0'
                    - 'roll.7'
                    - 'if event.value.greaterthanequals.4': 
                        - 'binom.30': 'set.0'
                    - 'switch.attacker.group':
                        FireBreathers:
                            - 'if attacker.wielding._sword':
                                - '2'
                                - 'if attacker.wielding.DIAMOND_SWORD': '3'
                            - 'if target.group.Overlanders': '3' # PvP bonus against the Overlanders. :D
                        Overlanders:
                            - 'if target.group.FireBreathers': 'div.2' # Divide by 2.
                Ghast:
                    - 'set.4'
                    - 'roll.4'
                    - 'binom.20': '2' # Binomial calculation - define a percentage chance of executing 
                                      #   another calculation string, here it's '2'
                ZombiePigman:
                   - 'set': 'roll.12'# The 'roll' function gives an even probability distribution 
                                     #   all positive output values <= the specified value (12)
                                     # It's also worth noting that "set" is also a calculated routine here - more on this later.
            - 'switch.target.group':
                Firebreathers:
                    - 'switch.attacker.type':
                        burn: 'set.0'
                        fire: '2'
                        lava: '4'
                                              
        normal:
            - 'switch.attacker.group':
                Overlanders:
                    - 'binom.5': '10'         # Basically a 5% chance for a 5-heart hit. D:
                    - 'if target.type.mob or target.type.animal': '1'
                    - 'switch.attacker.wielding':
                        _farmtool: '2'        
                FireBreathers: '-4' # Pretty bad debuff. :<
            - 'switch.target.group':
                Firebreathers: '1' # Another mean debuff, but not so bad.
                
Aliases:
    item:
        axe:
            - 'WOOD_AXE'
            - 'STONE_AXE'
            - 'IRON_AXE'
            - 'GOLD_AXE'
            - 'DIAMOND_AXE'
        hoe:
            - 'WOOD_HOE'
            - 'STONE_HOE'
            - 'IRON_HOE'
            - 'GOLD_HOE'
            - 'DIAMOND_HOE'
        pickaxe:
            - 'WOOD_PICKAXE'
            - 'STONE_PICKAXE'
            - 'IRON_PICKAXE'
            - 'GOLD_PICKAXE'
            - 'DIAMOND_PICKAXE'
        spade:
            - 'WOOD_SPADE'
            - 'STONE_SPADE'
            - 'IRON_SPADE'
            - 'GOLD_SPADE'
            - 'DIAMOND_SPADE'
        sword:
            - 'WOOD_SWORD'
            - 'STONE_SWORD'
            - 'IRON_SWORD'
            - 'GOLD_SWORD'
            - 'DIAMOND_SWORD'
        farmtool:                # You can use other aliases to define aliases - just make sure all dependent aliases
            - '_axe'             #   you're using are defined above, since aliases are read sequentially.
            - '_hoe'
            - '_pickaxe'
            - '_spade'

Some syntax here may not be completely obvious - [*1]

First and foremost is that for most conditionals with a wide variety of possible comparison values, switch statements have been implemented

A full analysis won't be broached here, but rough basis of the configuration is as follows:

  • A FireBreather is much more powerful in the Nether - an Overlander attacked by a FireBreather with a diamond hoe would be killed instantly (with normal player health settings). Resistance to fire-based damage is also a bonus.

  • FireBreathers have significant negative buffs associated with being in the world "normal".

  • An Overlander wielding a farming tool (spade, hoe, pickaxe) has a definite offensive advantage in the "normal" (non-Nether-type) world, and a slight defensive bonus against mobs when in world "normal".

  • Overlanders in the world "normal" have a 5% chance for a critical-type strike in which they deal 10 damage (5 hearts).

With this in mind, one can see how quickly a relatively small configuration can vastly orient damage relationships in Minecraft in different directions. And there are still two more major configurations in ModDamage to go! :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment