--== | **UPDATE 1.9.30** | ==--
There have been MANY major changes and NEW features added to this version. Please let us know if you encounter any issues with this new update.

-- **Supported Minecraft Versions** --
1.13.X, 1.14.X, 1.15.X, 1.16.X, 1.17.X, 1.18.X, 1.19.X

-- **More Version Support** --
A little while ago we updated Heroes to Java 16, which was actually unnecessary. We have now reverted Heroes to be compiled on Java 8, what this means is that once again ALL versions from 1.13 and onwards are now supported by Heroes! Due to the overwhelming amount of changes to Heroes as well it is **REQUIRED** that you redownload ANY and ALL skill packs as previous versions of skills may cause major errors. More details on skill updates below.

-- **Full Translation Support** --
Attention all, drum roll please - Heroes now has **FULL TRANSLATION SUPPORT**. Pretty much every single message in Heroes is now translatable via a file created by the plugin called `translations.yml`! The only exceptions is that some commands are not translatable, the majority of the most used ones are! We will be finishing off the rest of the commands in future updates to come! This was a major undertaking, with the translation file featuring literally over 400 messages which used to be hard coded into Heroes, so understandably there may be some small typos or errors - please let us know if you come across any!

When ** configuring** the translations. There are few little tricks you can do to further customize Heroes;
- For many translations, mainly those which are sent to the player as a message, if you configure the translation such that `some-translation: ''` (such that it's empty), this will mean that the message simply will not be sent! This means for example for those of you which don't use races or don't use secondary classes, you can simply set those options to an empty string and then those messages won't be sent. For example, see the below translations which are used mainly for the /hero info command.

*Default*
```
commands:
player-summary: '{level} {primary}&r, {level} {secondary}&r, {race}'
class-summary: '&aClass {primary}$mastered-primary$ &7| &aProfession {secondary}$mastered-secondary$'
race-summary: '&aRace &7- {race}'
```

*Modified*
```
commands:
player-summary: '{level} {primary}&r'
class-summary: '&aClass {primary}$mastered-primary$ &7'
race-summary: ''
```
As such, removing the messages for races and secondary classes will mean the message is not sent to the player.

- Another thing you may have noticed is the use of {level}. The curly brackets will tell Heroes to look for another translation in the same section as where it is used. In the above examples, the `player-summary` is in the `commands` section, using {level} will look for a translation with the path commands.level and will automatically fill it with that value. By default, it will fill it with 'Lv. &6$lvl$'. Additionally you can specify a translation from another section just by doing {section.message} for example.

- In many of the translations, we use placeholder values such as $lvl$, $1, $2 etc. In some instances those values will be replaced with levels, a Hero's name or whatever else in relation to the specific translation. If you don't wish to use these values you don't have to, however you can't add your own placeholders (unless it's through Placeholder API) to these messages.

- As you'd expect we support using chat colours as well, any character of & will be interpreted as a chat color so keep that in mind.

- If you want things to be formatted correctly, it's recommended to try keep the spaces in translations as what is written if you want things to be displayed properly.

-- ** Optimizations** --
For many years, Heroes has relied on an external library/plugin called EffectLib, it WAS necessary in the past that this plugin was installed for many of Heroes skills to work. However, we have now shaded the library into Heroes itself so you will no longer require to install that plugin separately! Additionally, EffectLib's EffectManager USED to be created pretty much every time a skill was cast, this meant unnecessary memory overhead and was just incredibly inefficient. As such, NOW, Heroes has one EffectManager of which ALL skills have been updated to use. **This is another reason why it is REQUIRED that you update all of your skills from the available skill packs**.

--- **Miscellaneous** --
- Fixed bug in MMOItemHandler
- Added option for damage scaling where mobs will only be scaled if the player is higher than their level.
- **ALL COMMANDS** in Heroes now should have automatic tab completions. This was done somewhat automagically so it can be a little buggy, remember, if you ever get confused about a hero command just type the command with a question mark after it.
- A player's Hero is no longer unloaded twice when they quit the server
- Added an option to attributes to allow an initial allocation point amount when the player is at level 1.
- Made the majority of log messages such as ("Class does not have pvp-item-multiplier set") and alike as debug messages ONLY. Therefore, simply enable debug mode if you wish to see these messages. This has made the Heroes boot sequence a lot cleaner
- Enabling debug mode on config.yml will no longer mute normal log messages
- Added a mana and stamina condition to be injected with MythicMobs
- Mobs are now able to hit themselves (this was causing issues with plugins such as MythicMobs)
- If an equipped item is broken, then it's armour value will not be considered during custom mitigation.
- Update the list of what is considered a transparent block for versions 1.16-1.19
- The MythicMob item roll option now has an optional default role setting.
- Fixed a major bug where skills did not heal in combat.
- Fixed a potentially major issue causing an infinite loop regarding party members leaving.
- Combat enter and leave messages have been moved to translations.yml. This should be done automagically.

-- **Developer Updates** --
- When using Heroes.getCharacterManager().getHero(), this has been changed so that it will NO LONGER load a Hero if the Hero is not loaded. This was to prevent weird issues where a Hero was loaded even after they were offline. If you attempt to getHero() when they are not loaded then an exception will be thrown. To avoid this, basically do NOT call getHero() from a PlayerJoinEvent pretty much ever, always run a delayed task or find another way to accomplish whatever it is you wish to do.
- The Messaging class which has been deprecated for a while now has been removed. If you're using this, just don't. Use ChatComponents if you really need.
- When using a Hero object, using .getHeroClass(), .getSecondaryClass(), or .getRaceClass() will now NEVER be null. This is how it's always been, but for some reason these methods were marked as Nullable
- For skill developers, if you wish to use the shaded effect lib you can use the protected static final variable called 'effectLib', or you can get an instance of the plugin and call .getEffectLibManager(). Please NEVER dispose of this manager as it is used by all skills and is not disposed of.
- The latest public repository available is now 1.9.30-RELEASE. Maven example is below;
```
<repository>
<id>heroes-repo</id>
<url> https://nexus.hc.to/content/repositories/pub_releases/</url>
</repository>

<dependency>
<groupId>com.herocraftonline.heroes</groupId>
<artifactId>Heroes</artifactId>
<version>1.9.30-RELEASE</version>
<scope>provided</scope>
</dependency>
```


-- **The Future of Heroes** --
Our next major plan for Heroes, as we have mentioned is to essentially rewrite the entire damage handler. Over the many years of Heroes life, this damage handler has been an intertwined mess of spaghetti code. The problem, is that damage events are called constantly, multiple times a second, and therefore because this code is incredibly inefficient - this is most likely the main cause of any 'lag' generated by Heroes. My goal is to rewrite it from the ground up, refactoring it so that various checks are only made if those options are enabled for example. This will improve both the efficiency and hopefully will fix the magnitude of bugs generated by the spaghetti code damage handler. I'm currently aware of issues regarding enchantment damage and protection, where both values tend to not scale correctly at all. For example, right now - apparently damage over time effects such as bleed stack with sharpness. To fix issues such as these will require the full damage rewrite.
By improving the damage handler you should expect a significant performance improve across the board.