Add Config GUI info to blog post (#51)

content/news/21.0release.md

@@ -120,7 +120,7 @@ This is the first event of the damage pipeline. Most modifications to the incomi
 This event can be used to decide whether the entity is actually blocking the damage through the shield, and if so, how much of the damage is blocked.
 
 ### `LivingDamageEvent.Pre` (formerly `LivingDamageEvent`)
-This event is the lastest point at which the final damage may be modified, or reduced to 0. However, the event is not cancellable as by when it is fired, armor and shield durability loses have already occurred.
+This event is the lastest point at which the final damage may be modified, or reduced to 0. However, the event is not cancellable as by when it is fired, armor and shield durability losses have already occurred.
 
 ### `LivingDamageEvent.Post` (formerly `LivingHurtEvent`)
 This is the last event of the damage pipeline. It indicates that all damage has been applied to the entity, and can only be used for reacting to the damage being applied (i.e. to reduce custom hunger or thirst values).
@@ -143,6 +143,19 @@ And the `SpecialPlantable` block tag now lets Farmer Villagers detect and plant
 ## ToolActions renamed to ItemAbilities (renamed in NeoForge 21.0.40-beta)
 To help promote the usage of our `ToolActions` system, it has been renamed to `ItemAbilities` to help show that it can be used for more than just tools and more than just representing actions. This system is a special alternative to tags for when mods need to do itemstack sensitive checks where an item can be in many different states and have different abilities. It is a good for cross-mod compatibility that is itemstack sensitive without needing to add compile-time dependencies. The NeoForge provided ItemAbilities for vanilla tools are still in place such as `shears_dig` to verify the itemstack used is supposed to allow shearing for modded stuff.
 
+## Config GUI returns! (Added in NeoForge 21.0.110-beta)
+After many years, we now again have a default configuration GUI in NeoForge. It isn't quite as capable or pretty as some of the mods/libraries for this, but it is built-in and available for all mods all the time. And it is completely optional. You can still use your favorite library for your configuration UI or write your own. It is also extendible, so you can tweak how it works easily (But do note we may do internal changes to it over time to improve it).
+
+For a mod to opt into having this screen show up in mod list, you only need to add one line to your mod's client-entry-point: `modContainer.registerExtensionPoint(IConfigScreenFactory.class, ConfigurationScreen::new);`
+
+Also, if you use lists in your config, you need to add a new parameter to your `defineList()` calls so the UI knows how to add a new element to those lists. The new param is the default value to use when a player clicks new entry for the config list in the GUI. This is not a breaking change, but the old calls without the new (nullable) parameter may be removed in the future.
+
+And lastly, be sure to add translations for your configs! If you visit all your config screen pages and then back out to the mod list, all untranslated config entries encountered will be printed to the console to make it easier to know what to translate and what the translation keys are.
+
+Special thanks to Henry Loenwind for all the work put in to bring this back!
+
+**Note:** There is a small breaking change with IConfigScreenFactory#createScreen method’s params.
+
 ## Experimental Gradle Plugin
 We're currently developing a new experimental Gradle Plugin, focused on simpler buildscripts and improved caching. You can find information on its usage [here](https://github.com/NeoForged/ModDevGradle), and support is provided in the [thread](https://discord.com/channels/313125603924639766/1239579489617580072) on our [Discord server](https://discord.neoforged.net).