Bukkit

@destroyer4017 I feel so dirty when I have to use YAML :)

Also uploaded Beta16dev, which is identical to Beta16 but built with Bukkit 1.4.2-R0.2.

Beta 16 is up (links on the tutorial page).

Changes

• Added three new events - hour_change, night, leaves (see below)
• Added a new subcommand - /ro force
• Fixed wickersty's issue below
• Fixed repeating_outcomes being activated at the same time
• Lots of backend changes/optimizations that no-one will ever see :)

First, Mobs now needs a library plugin installed as well. It's actually a part of Mobs that was split off and made into a separate plugin to keep it cleaner and allow other devs to use it.

This plugin contains all the non-Bukkit events I made for Mobs, and this way Mobs just listens for them instead of creating them itself.

I also added some more settings to the other plugin so it's now possible to customize how close a player must be to a mob to cause the approaches, near, and now leaves event. See this page for more info.

Hour_change happens every hour (at the Minecraft equivalent of :00).

Night happens at 12500, or slightly after dusk. Day is the same as dawn so I didn't add it.

/ro force [name] makes the repeating_outcome(s) activate without checking any conditions. /ro activate [name] checks conditions first so it can be used for more realistic testing. Both ignore whether the outcome is disabled or not.

@wickersty That looks like it should work. I'll check tonight and find out what's going on.

@Beatkidz When the config loads, the plugin calculates the total ratios for each element.

So when it sees five values with no ratio it makes the total 5. Then, when it's time to grab one of these values it picks a number from 1 to 5.

When any (or all) of the ratios are higher, the total is higher. If you had three values, two with no ratio and one with 99 ratio, the plugin would divide them into 1/2/101. Then, the random number would be between 1 and 101.

If the random number picked is 1, the plugin selects the first value. If it's 2, the second, and anywhere from 3 to 101 the third. In this way the third value has a much bigger chance of being picked. Consequently, it doesn't matter in which order the values are put.

As for an API, everything is stored in metadata. See here for more.

@wickersty You were pretty close. It used to work like your example but I had to change it to make my life easier in the future. It now looks like this:

<outcome>
  <actions>
    <drop_item>
      <item>
        <id>
          <value>367</value>
          <value>347</value>
          <value>345</value>
          <value>339</value>
          <value>373</value>
        </id>
      </item>
    </drop_item>
  </actions>
</outcome>

Ratios all default to 1 so unless you want to make one value more likely you don't need to set it.

@ultracasual Thanks <3

It would look like this

<mobs>
  <dies>
    <outcome affected_mobs="spider">
      <actions>
        <target>
          <aux_mob/>
        </target>
        <set_money>1 to 3:+</set_money>
      </actions>
    </outcome>
  </dies>
</mobs>

This only works from Beta15, though. here's a direct link.

Beta15 is up (direct link on the tutorial website).

Changes

• Added a new target - aux_mob
• Made it so that worlds and targets can be placed at a higher level and used by child elements

aux_mob is a good one. Many events involve two mobs - the one receiving something and the one doing something. In the hit event, for example, it's the mob attacking and the mob being attack. In the tamed event it's the mob being tamed and the player taming.

The self target (or no target) always refers to the receiving mob, and the aux_mob always refers to the other mob (if applicable).

<approached>
  <outcome affected_mobs="cow">
    <actions>
      <target>
        <aux_mob/>
      </target>
      <send_message>You're getting near a cow!</send_message>
    </actions>
  </outcome>
</approached>

This example also illustrates the other change. world and target elements can now be placed inside event elements, outcome elements, actions elements, conditions elements, action elements, and condition elements. In other words, anywhere at all.

When a condition or action needs to be done, it will look back up the hierarchy until it finds the world and/or target. Closer target/worlds take priority over further ones so they can be overridden.

<repeating_outcomes>
  <world>world</world>
  <outcome...>
  </outcome>
  <outcome...>
  </outcome>
</repeating_outcomes>

All outcomes will use world for their conditions and actions now.

@Xikage I'll look into it, although it will be very difficult :(

@Xikage I'll look into that today.

Do you mean enderman taking drowning damage?

@Beatkidz It hasn't been added back yet. Will be soon though.

@crowbars82 I'm going to add a separate action (safely_spawn_mob or something) which will check the block is appropriate (water for water mobs, not inside a wall, etc.) which will offer the choice of the slower method for smaller areas or the quicker method when you know the area is safe anyway.

You have a couple of problems with the other actions.

When a mob is autospawns it looks like this:

autospawner adds a mob -> spawns event is called -> autospawner gets the new mob back.

What this means is that the spawns event (even from other plugins) can interfere with the mob, so what I advocate as the preferred method is to use the autospawner to only add the mob, and not change it in any way. If the mob is meant to be unique, or part of a subgroup, give it a name.

Then, in the spawns event, change the mob however it's required. Use the name condition if necessary to filter this (type of) mob.

Your max_life and burn actions need to go inside a spawns outcome actions. Max_life is set in seconds, though, so setting it to 1 means the mob will disappear almost instantly after spawning.