Hello Terrarians! As the tModLoader community reaches closer to offering tModLoader 1.4.4 as the default, we'd like to take this chance to outline how this is all going to work. tModLoader 1.4.4 is a big update with major code changes incompatible with existing 1.4 mods. It marks the start of a new generation of mods, just as the change from 1.3 to 1.4 did before. For those that remember the change from 1.3 to 1.4 - it was quite a big event. There were lots of moving parts and we've all learned a lot from the process. We've kept 1.3 alive and running in the Steam Betas, and will be doing the exact same with 1.4.3.

Localization provides the ability for a mod to be played and enjoyed by users who speak a language different from the language the mod author uses. Every piece of text that a user might see while playing a mod is contained in text files called localization files. For example, ExampleMod has an item called "Paper Airplane" in English, but "Бумажный самолётик" in Russian. Through the use of localization, Russian users can understand and enjoy the content of ExampleMod without learning English. These localization files are easy to work with, allowing users without technical skills to translate mods. These translations can then be provided to the mod author or published as a new mod, allowing more people to enjoy the mod. This wiki page will cover localization topics intended for a mod developer. If you are interested in localizing an existing mod, or providing localization to tModLoader itself, please read the Contributing Localization wiki page. Migrating from 1.4.3 to 1.4.4 Beginning in tModLoader v2023.01, all localization is now done completely in the .hjson files. Declaring translations in code is no longer supported. This change will greatly streamline localization management and make mod translations easier to create. See the Major Localization Changes feature proposal if you are interested in more of the rationale for these changes. If you are not using Git or some form of version control, it is recommended that you make a backup of your mod's source code folder before continuing.

Notes on the guide: "Custom Localization Keys" Should probably call this "Overriding Content Localization Keys" and move it below the "Substitutions" heading. Language.GetText is not recommended unless you don't want auto registration of the key, so it shouldn't be in that spot Should have a link to the "Custom Fields" section below (see <link> for how to add extra localizations to your content, beyond the default properties provided by tML) "Substitutions" I've been thinking it would be nice to do some sort of scoping/relative pathing for key references. Should be easy. That way you'd just need Common.SomeSharedTooltip for eg "Adding Content" Should have a mention to the above proposed added section about how to define your own localization keys in code to be exported to the files (and the need to retrieve them at least once during load) "Prefix"

Prefixes are currently not very modder friendly. With 1.4.4 changes, we can fix this as we adapt the modded prefix code to the new 1.4.4 code. The current design emphasized small changes to ensure that our patch approach wouldn't cause vanilla changes to be mistakenly lost in updates, but now that the ItemIDs in each prefix category and the prefixes in those categories are stored separately, larger changes can be made without this fear. Pain points Custom Prefix Categories - Currently difficult to implement and verbose Currently, you have to use PrefixCategory.Custom and ItemLoader.ChoosePrefix Other mods can't add to your category

Goals In order of importance: Maintaining translation files is too hard. Translation files shouldn't require any effort to start using for normal content. There is no process to generate them from existing content There is no process to update them with new content Migrating to using them to support localization is a large endeavor Contributing translations or making a translation mod is hard:

Please use code blocks via back-ticks everywhere possible. You have them somewhere, but not others Proposed Implementation 1. "This will require a mod build and reload to start localizing, but there is no suitable alternate for this due to dynamic content." Lets be clearer here. What will happen exactly, for who? Eg "The first time (how do we detect this?) a mod is loaded after being built, after loading the english localisation files, we will scan the mod for all instances of ILocalizedModType and build a list of all translation keys from the values of any fields or properties with the type LocalizedText . For each key which does not have a mapping in the loaded translations, we will find a .hjson file in the mod to add it to. If a mod has no .hjson files nothing will happen. The .hjson file selected will be ..., we will update the file by doing .... "If an existing key has a value that conflicts with the loaded value…(what should we do? why would that happen? Dynamic localization value registration?)" What does this mean anymore? Can we remove it? What about text which doesn't have a category? (Eg Mods.OtherMod.Category or a replacement translation? Are we mandating that all translations in a mod have to start with Mods.MyMod? "Entries will not be populated by dynamic values assigned via SetFallback" Why? "All entries within a category will be alphabetized. All categories within a file will be alphabetized."

This Guide has been updated to 1.4. If you need to view the old 1.3 version of this wiki page, click here This guide will attempt to help users fix many common issues. Please search through this document for the error you are experiencing. If you can't find anything relevant, please try all the suggestions in Generic Troubleshooting Steps. Do note that this guide mostly concerns issues with tModLoader itself. If you have an issue with a specific Mod or combination of Mods, see Mod Troubleshooting Steps Note on tModLoader 64 bit Please do not attempt to install "tModLoader 64 bit" into tModLoader, it is no longer useful and will prevent the game from launching correctly. If you have previously installed it and are experiencing issues, your first troubleshooting step is to do a fresh install. Note on Piracy If you pirated Terraria, we can't help you. tModLoader won't work. Please don't bother us by asking how to get it to work.

code: [i][u] [/u][/i] Simple fix template: [b]:[/b] [url=][/url] Feature or big fix template: [h3][b][url=URLHERE]TITLEHERE[/url][/b] by [b]AUTHORHERE[/b][/h3] [quote]•

This Guide has been updated to 1.4. If you need to view the old 1.3 version of this wiki page, click here Recipes can be added to the game in 3 places. In Mod.AddRecipes, ModItem.AddRecipes, and ModSystem.AddRecipes. Where you add your recipes is up to your organizational preferences, but do note that the CreateRecipe method used in code below has different behavior depending on where you use it. Recipes consist of Ingredients (Items consumed to craft the result), Tiles (Tiles you need to stand by), and Results (Item created). Basic Recipe Structure Required Using Statements First, make sure that you have the following using statements in the .cs file. These using statements will let us access recipe related functions:

twitter: https://twitter.com/tModLoader Our first post! Also, after years of work, tModLoader will now default to the 1.4 version on Steam from now on, we look forward to playing and creating all the new and exciting mods! steam and discord: We are happy to announce that tModLoader will now default to launching the 1.4 version Today we are changing the default tModLoader on Steam to the Terraria 1.4+ version. As you might know, we have had 1.4 tModLoader as an option on the Betas menu for quite some time as we've worked on new features to make modding and playing on 1.4 tModLoader a pleasant experience. The current 1.3 version will still be available on Steam, you'll just need to select 1.3-legacy in the steam betas menu. We expect many of you will want to use this option until you finish your current playthrough of the game.

This Guide has been updated to 1.4. If you need to view the old 1.3 version of this wiki page, click here We can use sounds in many places in tModLoader and this guide will educate you on how tModLoader organize and use sounds. Sound Basics There are 2 concepts to be aware of. The first is the actual sound asset. This correlates with a specific sound file, such as a .wav file. The second concept is the SoundStyle, which is an object representing a sound asset and associated playback settings. Sound Assets Sound assets can be found in your ModSources folder and in the Terraria install directory. Sound assets can be many different sound file formats including .wav, .ogg, .mp3, and .xnb. For example, ExampleMod has an ExampleGun.ogg file found in ExampleMod\Assets\Sounds\Items\Guns\ExampleGun.ogg. In your Terraria install folder, you'll find hundreds of sound files in the C:\Program Files (x86)\Steam\steamapps\common\Terraria\Content\Sounds folder. These files are .xnb files, which is a special format that you can't listen to directly by double clicking. To listen to these sounds on your computer, see the Extract section below.

A "Sprite" refers to 2D graphics typically found in 2D games. For example, the Gold Bar item sprite, Item_19.png, looks like this: . When making mods, you'll typically need to make a sprite for each bit of visual content you add to your mod. This guide will teach you the basics of spriting and how sprites work in relation to tModLoader. Sprite Frame Many sprites have several "frames" within a single image - usually referred to as spritesheets. These are typically used for animation or variation. For example, the GiantBee projectile looks like this: You can find this texture in your extracted copy of the vanilla textures by finding Projectile_566.png. The game was told by the programmer that this sprite has 4 frames in it, so the game knows to split the 96 pixel high texture into 4 equally sized 24 pixel high sections. The game cycles between these 4 frames as the game draws this projectile Some sprite frames are for variety. Here is the Metal Bars sprite, Tiles_239.png, this sprite is shared between all metal bar tiles:

World Generation World Generation is the act of programatically placing and removing tiles from the world. World Generation is done in two places, during world creation and in-game. The vast majority of this guide will focus on world generation during world creation, but in-game considerations will also be detailed. World generation is a fairly complex topic, and a good understanding of many topics is required to work effectively. It is recommended to familiarize yourself when the following sections before jumping stright into the code. In addition, using an IDE with edit and continue support like Visual Studio is highly recommended. Table of Contents Terminology Prerequisite Knowledge