What is this?
It's all about presentation and reception. This is a guide of sorts, for mod makers, on how to make a mod, it's config file and it's thread in a way that users will love, written from the perspective of those users. This is in hopes as to point out the things that will make ours and your own life easier when we approach using your mods.
Why did you bother writing this? For the last month, I've been putting together a Modpack to run my own personal server for family and close friends. And while doing so I have come across some mods that add some wonderful things, but how they are handled on the forum, and in their own internal coding and sometimes lack of config files, makes them difficult to use properly, and compatibility issues crop up, but not in the normal way you may think. The "play style" is effected by some mods and it becomes an issue where mods you add to get cool features, also make the game to hard, or too easy, when all you wanted was a new type of tree, or monster in your modpack, but get stuck with a mob that is 10 times more powerful than any other in your pack, or a tree that drops too many fruit and makes finding food way too easy. Sure you could just not use the mod...but this guide will suggest ways to make your mod cater to everyone.
Why should I take your advice? Firstly, you don't have to follow any of this advice... it's just something for you to think about. But do you want to cut down on the feature requests you get in your thread, and lower the number of posts you have to read every day when you log in? Then please, follow this guide, and suggestions on how to formulate, present and control your mod. Who better to point out that your mod thread is hard to understand, or navigate, than someone who actually has to do it daily. You, yourself may look at your thread and think it's fine, but you also know everything under the hood without having to have it described to you. As a member of this forum and a user of many of the mods presented here, I, as well as many others, have opinions on what we like to see when we approach a thread, a mod, and a mod maker. I will be updating this original post to include any suggestions other forum goers have as to what they would like to see in the 'Status Quo' of house a Mod is created and handled, so it won't be just my own thoughts I am putting here.
Now, I know many mods have already been created, and offering these suggestions is pointless as most of you will not be going back to re-write your mod from scratch. And please do not, as many of the best Mods on this forum have been handled perfectly, but this is a suggested guideline for those moving forward and/or creating new mods.
One Mod or Many?
Firstly, you need to sit back and ask yourself, are you making this mod as a 'pack' of features, or do each of your added features seem separate and do not need to be put all in one mod.
This question is an important one, as many people who may look at your mod may want features a, b, and c, but d and e are pointless to them and they don't want them. If you put all of the added features into one mod, you are forcing everyone to have a larger file-size, and perhaps even a longer load time, etc, just because you didn't separate your added features into different mods. It's best to categorize your mod additions into the following.
Base Mod Function : This is what you are adding to your mod, that will be necessary for your mod to perform the functions you wanted to add. (Example : These are the new mobs you are adding, themselves.)
Child Mod Function : Requires the base mod function even tho it's not directly related. (Example : The items your mobs will drop, while not necessary, are related to the base mod function and therefore need to be in the same mod.)
Separate Mod Function : This is something that doesn't need to be in the same mod as the other items, as it is not a base function nor a child of another function. (Example : A block you thought would be cool to add to the game, but it does not use or require any items dropped by your mobs.)
But I'm Building a Themed Pack!
Let's say you are building a mod that is called "The Deserts of Blah Blah"
In the mod you are adding new mobs, a new dimension, weapons, and items, all of which follow the same theme.
What is the motivation for you to make 4 separate mods? For you, none. For us, those that may download your mod, I'll tell you why we hope you will anyway. Mob adding mods are high in demand, especially for adventure map makers, and server hosts, as this is the one thing that really changes how Minecraft feels, So for example, as an adventure map maker, I will download a themed pack, and never put a way in my map for players to go to the dimension you've put effort into making, but I WILL use a custom mob spawn control system to bring the mobs you've created to my maps default world. So now I have a technically "useless" part in your mod taking up space and load time on my adventure map, and possibly even my server, just so I can get your mobs.
Besides, it's easy enough to make four downloads, and then make a fifth that simply contains all of them together and call it "blahblahcomplete.zip" for an easy install of your "themed pack" as a whole.
As for the weapons and Items... these could easily just be by themselves as items to craft and find, and you can include a config file for your mobs that has drop configs to have the mobs be set to drop those items and weapons.
So in the end, from your perspective, it is true that there is less incentive to make separate mods, unless you want to make life easier for those who will use your mod, beyond what you envisioned it for.
The best way to approach creating anything is... "how will this be used..." not ... "how do I want this to be used". People love options.
Update in Pieces
Another reason this might be a good way to approach building a mod, is the ability to update your mod quickly when Minecraft gets a new version. Let's say instead of one large mod, you have 4 Separate smaller mods, and each adds something different. Then, Minecraft updates, and you have to go into your mods and update each. The four mods as a whole would take the same amount of time to update as doing one large one... however, when you finish one, you can post the update for it, without being held back by the other three still needing to be updated.
Let's say you don't separate your mod features and it is all in one mod, and then Minecraft updates. As a user, if I like mod feature B in your "one mod for all features" mod, and you post "Updating this will take a while because feature C changed a lot in the base code of minecraft"... I, the user, will be waiting for a while for feature B, just because something I don't use anyway is taking a while. This is partly why "Update to X.x.x please!" posts start appearing (annoying are they not??), as larger mods take a looooong time to go through and update. But if people had parts they could get to appease themselves while they wait for the rest, things will be less urgent. Again this only makes sense if the parts can work fine alone, and do not require the others to work.
CONFIG FILES
The Glory of CONFIG files. Many mod makers have discovered how config files can open their mod to a lot of customization for players to use and change how their mod works, without having to make many different versions of the same mod. If your mod doesn't have a config file, you may want to think about adding one.
First, lets go through and list off a few things each mod type should include in their config files as a general rule.
ALL MOD TYPES
ID controls. - This is only valid for pre 1.7.2 mods. This is the most important reason to have a config file. Every mod before 1.7.2 may have compatibility issues with ID numbers, be them Item, block, entity, biome, or even liquid ID's. If your mod adds any of these, be sure to include a way to adjust them so your mod doesn't get dropped by users because they can't get it working alongside their other favorite mods.
Commented out Defaults for every setting and ID. This way, a user doesn't have to delete the entire config file to revert one items ID to its default later on, after having changed them all. To comment out a line, add a # before it.
Commented out Descriptions of every function, and perhaps even examples. Explain every config option as best you can so people don't have to ask you what it does. Again, just because you get what it does, doesn't mean everyone else will too.
Server Debug Text Toggle - When you run a server, its nice to have an option to turn off some or all text that is printed to your server log by a mod. Some mods have so much text that, it all flies by and make it impossible to see other important information that may be happening on the server. If yours is a mod that shows a lot of information in the server cmd window...allow us to turn some, or all of it off.
Mob Adding Mods
Use Different Spawn System : true/false - A setting that lets the user disable the normal spawn code you put into your mod, so they can use a different mob spawner system if they so desire. This will prevent the need for them to go through what could be a long list of every mob and setting their spawn frequency to 0. An overall toggle is a godsend. Perhaps even a separate toggle for despawn control, as some spawn control mods let you control despawn, and some others rely on the default one.
Spawn Frequencies, chance weights, and Biome controls. Let us choose how often, when and where a mob spawns.
Mob Drops Control - So you've added your new mob to the game, and you also have it dropping a super strong sword at a 1% chance. Awesome, but giving a user the ability to control that chance, or even change the sword to something else, or even add other items it can drop, is a great feature to see in mob adding mods. This allows us to control our worlds more, and prevent overpowered items from dropping during an adventure map we have created.
Mob Health and Damage Control - Lets say your mod adds a cool boss with 300 health that can kill a player in two hits. But we server runners want to use it as a regular mob because it's so cool looking, a credit to your modeling skills. But we don't want our poor players getting ganked by him when he spawns into the regular plains Biome. A setting that lets us change its health value to a more reasonable 20-30 is awesome. And damage as well of course.
Machine Adding Mods (Furnaces, Crushers, Etc.)
Editable Compatability Lists : A way to add non-same-mod, non-vanilla ores/items for use in this machine. Sometimes a mod will add a cool furnace that smelts 10x faster, but doesn't recognize another mods, lets say, unicorn meat , as a valid food that can be cooked. Having a config option that lets you put [UNICORN-MEAT-ID],[COOKED-ID],[FUEL-COST] to add the new meat to the usable list for that furnace would be awesome. The same goes for machines that let you repair, or effects only weapons, etc. Well, what constitutes a weapon? Let us add the weapons ID to a list in your config so it will work. We don't mind taking the time doing the work to get it to work with our other mods... just give us the ability to do so.
More on this later... (depending on what people suggest in this thread)
Your Forum Thread
So you've created your mod, and now you wish to share it with the world.
The best place to start when it comes to easy access and understanding, is with the first thing people see when they are perusing the forum.
The Title of your Thread
When looking for a specific mod, many of us get overwhelmed by the lack of, or unnecessary excess of information in thread titles.
An example of a good Thread Title...
[1.5.x][Forge] Jurassic Age Mod [Ver 1.5.x.C] Updated Jan 5, 2013
An example of a Bad Thread Title...
Jurassic Age Mod by Blue001 Tired of not having dinosaurs? Adds 20 Dinosaurs!!! and 10 of them you can ride! [Fixed that annoying tooth bug]
Yes... there are actually mods out there with such long thread titles... and no, sorry, this mod doesn't exist, it was just an example. XD
What should be in your thread title, are these following things, in this order.
Version of Minecraft your Mod was first usable on (only include versions that you still have listed for download), followed by what version it is 'currently' usable on. This is usually seen in [ ] brackets. So an example would be. [1.2.5 ~ 1.5.2]. It is perfectly fine to have just the newest version listed by itself like [1.5.x], but if you support and list multiple version downloads in your thread, its better to show that for those who may be still using an older version.
The Type of Mod Loader support you used. I can't tell you how many times I've seen people try to get a mod and say "this doesn't work!" and only because they didn't read the whole post (their fault right?), but why not nip it in the bud and just pop [Forge] or [Bukkit] in the thread title.
Single Player, LAN, or Server? Simply put, does your mod work ONLY in one or two of these? The words [SSP ONLY],[LAN ONLY] or [SMP ONLY] work just fine. Add these only if there is a restriction for your mod. listing all of them if you use all of them, is just unnecessary. Also doing the reverse works as well [No SMP] says just as much as [SSP and LAN ONLY] but is shorter and takes up less space in your title.
The Name of your Mod, of course is the most important thing, but please name it something that states what it does as simply as possible... not just arbitrarily lists its features and functions. "More Diverse Bricks" is a far better name than "More Bricks, adds 25+ new bricks, slabs and stairs." all being shoved into the title. If someone is looking to get more bricks, they will already be clicking to view the thread... so there is no need to state it in the title. If they don't want new bricks then all the extra information is pointless anyway.
Your Mod Version, Important for those who want to know if they have the most recent version of your mod. When it comes to how to handle your version numbers, people do it a lot of different ways and in the end, this part is up to you... Personally, I find version numbers for Mods based on the version of the game they work on to be the best method, so you can kill two birds with one stone. So using [1.5.x.A] is easier to understand as the first version of your mod usable on Minecraft 1.5.x, than say, [3.4] is. Also, sometimes, some mod makers do update older versions of their mod with new features so those using older Minecraft versions can get some new goodies too. Updating your versions based om MC versions allows you to not confuse anyone when you update older versions at the same time you update your new ones. So you can updated your old 1.4.7.F to 1.4.7.G while not interfering with 1.5.x.D as well.
Updated Date, For those that are using your Mod, it makes it much easier to tell if your mod was updated recently. The date format is important, because please remember that many people use different date formats as the internet is a worldwide phenomenon, and so is Minecraft. putting 3/5/13 is all well and good. but... does it mean, March 5th? or May 3rd? To prevent the question and not try to say who is right in how they list their dates, the best way to counter the confusion is to use the month abbreviation instead of its number. So whether your use Mar/5/13 or 3/May/13, they are both easy to understand, no matter the order. Pointless detail? You'd be surprised...
Things NOT necessary to include in your thread title.
Your user name. Its listed as the thread poster anyway. Sure its nice to have people read your username and it feeds to some kind of need for attention (no I'm not saying bad things about you, it's just a psychology thing. Everyone wants to be known for something good.) but if your mod get's popular, they will know your name anyway as they will look for your posts in the thread for updates, responses to questions, etc. Putting it in the thread will ONLY make sense if there are multiple mods that add the same kind of feature. Like, "Jammy Furniture", for example. He put his user name to differentiate his mod from the other furniture mod that is on this forum as well. This make sense, but if your mod is the only one to be adding this kind of feature, please don't put your name as part of the thread title, it's not necessary. If you plan on using your name as part of the Mod name, don't include your user name's numbers... do it like "Blues Land Extension". This sounds ok, but "Land Extension by Blue001".. is too long and you don't need the "by". Besides what's the chance any other "Blue" is making a mod called Land Extension.
Change Log Features. If someone has never used your mod before, change log information is useless to them. So listing [new chairs in this update!!!] in your title, does them no good, as everything in your mod is new to this person anyway. As for those who already have your mod, beyond the fact that they use your mod because the like what you have done already and don't need more incentive to update, I'm sure they will be looking at your change-log anyway, especially if they saw the "Updated Mar/3/13" in your title and its say, Mar/4/13.
A Statement. If you have done your job and named your mod in a way that is easy to understand what it does, there is no need to toss in a random statement like "Add more exploration to your world!" or "Looking for more mobs?"
The Thread OP
This is where you are going to be putting all the pertinent information about your mod. So let's make sure everything people may want to know is there and easy to understand.
Some general rules to follow.
An Update to your mod means you should re-read your own thread and make sure all information is still accurate. If you change something in your mod and then don't update your thread... you will be confusing a lot of people and causing a lot of questions to be coming your way.
Don't assume something is "easy to understand". Ask a few people who use your mod if your post is easy to understand and if there is anything you missed or should add to make life easier on those who visit your thread.
RED always gets read. Have something important to say? Don't just make it bold, make it red.
Important notes for OLD versions should not be deleted unless you no longer offer that version to dl. If you do, don't leave those notes in the main part of the post, as they will cause clutter. Move them to a spoiler near the download link for that version the note is for.
Speaking of spoilers USE THEM. In most cases, anything besides the main description of the mod and its most recent "version" information should be in a spoiler. Old information that is still pertinent, old version download links, change-logs, screenshots, videos. All of these should be in spoilers.
Make sure you have a Mirror link to download the newest version of your mod from a different web host (drop box, media fire, 4shared). Sometimes your main link will break and because you aren't on the forum 24/7 (who is...) you may not realize for days and people will start crying foul ...or just start crying. (Hands them a tissue. poor souls.) You should only need a mirror/backup for your newest version, but if you want, having mirrors for old ones too, is nice.
If you have a website that has all this information. Don't just focus on updating your website and leave your thread in the dust, update both... as people may not bother with a site outside of the Minecraft forums as this is their 'go to location' for mods.
If you have more than one unrelated mod, you may want to have a separate thread for each. As when you have many mods on one thread, you get many many more thread posts per day reporting bugs, asking questions, for each mod. Sometimes it gets hard to sort out which mod a report is for, or an important question or good suggestion gets lost in the multitude of posts for so many mods.
The following are things that should be in every mod post.
A Cool Header Image for your Mod - As a header to your thread, a cool image that shows off the idea of your mod is a good idea. Not a full image that will take up a lot of space, but one that is short and long, like a title banner. See the WILD CAVES 3 thread for a good example. This is a good way to show people what your mod does before they have to read, and may even get them to read on when they normally wouldn't have.
Description - The overall idea of the mod and why it's useful, why you made it, etc.
What it Adds - A Generalized List. Not details for every item but instead... things like X New Blocks, X New Mobs, X New Weapons, etc. So you can give people a quick idea of what they are getting.
Your newest STABLE download link and its version information. This is best to have bigger and bolder than all the other links, and does not need to be in a spoiler. I can't tell you how confusing it gets sometimes when there is a list of DEV versions mixed in with the current recommended stable versions.
Old Version DL's [In a spoiler] A list of links for old and DEV version downloads. Just because you updated your mod and don't want to deal with the older versions anymore. keep at least the newest version for old versions of Minecraft available. This is due to the fact that many players still use old versions of MC, and if you just drop your mods old versions from your page, you may rob them of the chance to add this mod to their game. As for Dev versions... make it clear, VERY clear, that those builds may be unstable. Always put these off to the side and not near the main dl link, so they don;t get mixed up.
Instructions and tutorials on how to install, and use the mod.
A Changelog - [In a spoiler] Sure you've updated, but it's nice to know why I should take the time to update, and give me a heads up on new items, features, and things I may need to look at in a config file. Don't just say the change log is in the download, We want to know before hand.
Requirements - Does this need Forge? Bukkit? And what version? List these near the download links themselves so they are noticeable and seen before someone tries to use it. This also means you should keep old requirements info near old download links. I can say... when you look at most threads that have downloads for older mod versions, none have any forge version info next to them except the most recent version. Simply putting "Requires forge 7.2.x or higher" next to all old downloads will help out a poor 1.4.7 or 1.5.0 user who wants to use your older .5 version and may not know what version of forge was out back then.
Compatibility - [In a spoiler] Know your mod is having issues with other mods? Even something as simple as ID conflicts? List them here. Since they are in a spoiler, you can put as many as you want without making your thread 50000 lines long. Its also good to list, what ID number range your mod even uses. So people can see it before hand. And don't worry about going out and testing every mod along side yours to find out. People will report to you about what works, and when an ID conflict arises in mods for any version before 1.7.2 (even if you include a way for them to change ID's and fix it themselves), Trust me, people love to point things out.
Screenshots - [In a spoiler] You don't need to show every part of your mod, but its good to try. People like seeing before they try. A mod without screenshots is like a blind date... you never know what you are getting.
Videos - While it would be great if you were to make one yourself to show off things in your mod, it may not be necessary. If your mod takes off, others will make a video spotlight for you. Keep the NEWEST video in the main thread, outside of the video spoiler, but the rest, any older ones, should all go into a spoiler. But only if it is for the current version.
Future Ideas/Plans - [In a spoiler]Listing your ideas for future updates will prevent people from suggesting things you may already have thought of. Also, if you really don't want to add a feature, put that in there as well under "Never Going In" or something... this way people may not try and suggest it to you.
Known Issues - List all known bugs and crashes, as well as the causes, or any temp fixes you know of until you can fix it on your end.
Recipes and ore Detailed explanations of everything added. - Make sure to do this in a spoiler, but its always best to explain how to obtain everything in your mod, and what each thing does. Have a wiki? Link it.
Config Help, and examples. - Unless you have added commented out lines in your config on how to use your mods config file(s) and what each option does, be sure to explain it in detail. Sometimes things are not as obvious as you think. If your config is extensive, and requires a lot of user generated input to get working with other mods, perhaps you can provide default compatibility config set ups for users to DL and use.
Addons and Texturepacks Support - Other forum goers may make content that works in conjunction to your mod. Link their threads, or provide the dl's yourself, either way, finding it all in one place is really nice. And of course... thank them for making your mod even more popular. :]
Thanks for taking the time to read this. i hope it offered some insight into what users such as myself are looking and hoping for in a mod, its config files and its thread.
If you have anything you would like to see added to this, please feel free to suggest it in this thread. And please remember, this is all just to suggest ways of approaching how their mod is put together, and how to best offer information on their mod so it is seen and presented as nicely as possible. I do not think they NEED help, as many of them have created mods that we all use and love. I just want to offer an outside perspective that they may not have thought of themselves.
A message to the mod makers, THANK YOU! We do so appreciate the time and effort you put into your mods.
The old forum was a pain in regards to editing a thread OP and title, which can explain why such stuff can be old and confusing for newcomers. Also text in spoiler would add to the post size, it was not ignored by the forum software (note i didn't test if that changed).
You have some good ideas in there, though. For config files, i think "acceptable values" could be nice too.
-insert whiny comment about users not reading mod description-
It's all about presentation and reception. This is a guide of sorts, for mod makers, on how to make a mod, it's config file and it's thread in a way that users will love, written from the perspective of those users. This is in hopes as to point out the things that will make ours and your own life easier when we approach using your mods.
Why did you bother writing this?
For the last month, I've been putting together a Modpack to run my own personal server for family and close friends. And while doing so I have come across some mods that add some wonderful things, but how they are handled on the forum, and in their own internal coding and sometimes lack of config files, makes them difficult to use properly, and compatibility issues crop up, but not in the normal way you may think. The "play style" is effected by some mods and it becomes an issue where mods you add to get cool features, also make the game to hard, or too easy, when all you wanted was a new type of tree, or monster in your modpack, but get stuck with a mob that is 10 times more powerful than any other in your pack, or a tree that drops too many fruit and makes finding food way too easy. Sure you could just not use the mod...but this guide will suggest ways to make your mod cater to everyone.
Why should I take your advice?
Firstly, you don't have to follow any of this advice... it's just something for you to think about. But do you want to cut down on the feature requests you get in your thread, and lower the number of posts you have to read every day when you log in? Then please, follow this guide, and suggestions on how to formulate, present and control your mod. Who better to point out that your mod thread is hard to understand, or navigate, than someone who actually has to do it daily. You, yourself may look at your thread and think it's fine, but you also know everything under the hood without having to have it described to you. As a member of this forum and a user of many of the mods presented here, I, as well as many others, have opinions on what we like to see when we approach a thread, a mod, and a mod maker. I will be updating this original post to include any suggestions other forum goers have as to what they would like to see in the 'Status Quo' of house a Mod is created and handled, so it won't be just my own thoughts I am putting here.
Now, I know many mods have already been created, and offering these suggestions is pointless as most of you will not be going back to re-write your mod from scratch. And please do not, as many of the best Mods on this forum have been handled perfectly, but this is a suggested guideline for those moving forward and/or creating new mods.
One Mod or Many?
Firstly, you need to sit back and ask yourself, are you making this mod as a 'pack' of features, or do each of your added features seem separate and do not need to be put all in one mod.
This question is an important one, as many people who may look at your mod may want features a, b, and c, but d and e are pointless to them and they don't want them. If you put all of the added features into one mod, you are forcing everyone to have a larger file-size, and perhaps even a longer load time, etc, just because you didn't separate your added features into different mods. It's best to categorize your mod additions into the following.
Let's say you are building a mod that is called "The Deserts of Blah Blah"
In the mod you are adding new mobs, a new dimension, weapons, and items, all of which follow the same theme.
What is the motivation for you to make 4 separate mods? For you, none. For us, those that may download your mod, I'll tell you why we hope you will anyway. Mob adding mods are high in demand, especially for adventure map makers, and server hosts, as this is the one thing that really changes how Minecraft feels, So for example, as an adventure map maker, I will download a themed pack, and never put a way in my map for players to go to the dimension you've put effort into making, but I WILL use a custom mob spawn control system to bring the mobs you've created to my maps default world. So now I have a technically "useless" part in your mod taking up space and load time on my adventure map, and possibly even my server, just so I can get your mobs.
Besides, it's easy enough to make four downloads, and then make a fifth that simply contains all of them together and call it "blahblahcomplete.zip" for an easy install of your "themed pack" as a whole.
As for the weapons and Items... these could easily just be by themselves as items to craft and find, and you can include a config file for your mobs that has drop configs to have the mobs be set to drop those items and weapons.
So in the end, from your perspective, it is true that there is less incentive to make separate mods, unless you want to make life easier for those who will use your mod, beyond what you envisioned it for.
The best way to approach creating anything is... "how will this be used..." not ... "how do I want this to be used". People love options.
Update in Pieces
Another reason this might be a good way to approach building a mod, is the ability to update your mod quickly when Minecraft gets a new version. Let's say instead of one large mod, you have 4 Separate smaller mods, and each adds something different. Then, Minecraft updates, and you have to go into your mods and update each. The four mods as a whole would take the same amount of time to update as doing one large one... however, when you finish one, you can post the update for it, without being held back by the other three still needing to be updated.
Let's say you don't separate your mod features and it is all in one mod, and then Minecraft updates. As a user, if I like mod feature B in your "one mod for all features" mod, and you post "Updating this will take a while because feature C changed a lot in the base code of minecraft"... I, the user, will be waiting for a while for feature B, just because something I don't use anyway is taking a while. This is partly why "Update to X.x.x please!" posts start appearing (annoying are they not??), as larger mods take a looooong time to go through and update. But if people had parts they could get to appease themselves while they wait for the rest, things will be less urgent. Again this only makes sense if the parts can work fine alone, and do not require the others to work.
The Glory of CONFIG files. Many mod makers have discovered how config files can open their mod to a lot of customization for players to use and change how their mod works, without having to make many different versions of the same mod. If your mod doesn't have a config file, you may want to think about adding one.
First, lets go through and list off a few things each mod type should include in their config files as a general rule.
ALL MOD TYPES
So you've created your mod, and now you wish to share it with the world.
The best place to start when it comes to easy access and understanding, is with the first thing people see when they are perusing the forum.
The Title of your Thread
When looking for a specific mod, many of us get overwhelmed by the lack of, or unnecessary excess of information in thread titles.
An example of a good Thread Title...
An example of a Bad Thread Title...
Yes... there are actually mods out there with such long thread titles... and no, sorry, this mod doesn't exist, it was just an example. XD
What should be in your thread title, are these following things, in this order.
The Thread OP
This is where you are going to be putting all the pertinent information about your mod. So let's make sure everything people may want to know is there and easy to understand.
Some general rules to follow.
Thanks for taking the time to read this. i hope it offered some insight into what users such as myself are looking and hoping for in a mod, its config files and its thread.
If you have anything you would like to see added to this, please feel free to suggest it in this thread. And please remember, this is all just to suggest ways of approaching how their mod is put together, and how to best offer information on their mod so it is seen and presented as nicely as possible.
I do not think they NEED help, as many of them have created mods that we all use and love. I just want to offer an outside perspective that they may not have thought of themselves.
A message to the mod makers, THANK YOU! We do so appreciate the time and effort you put into your mods.
The old forum was a pain in regards to editing a thread OP and title, which can explain why such stuff can be old and confusing for newcomers. Also text in spoiler would add to the post size, it was not ignored by the forum software (note i didn't test if that changed).
You have some good ideas in there, though. For config files, i think "acceptable values" could be nice too.
-insert whiny comment about users not reading mod description-