I'm a user. I don't make my own mods. I use yours. I make modpacks for my family's private server, we play on them for a while, and then try something else. I probably spend as much time getting mods to work together without griping at each other as I do playing minecraft. I am NOT a coder. I am NOT a modder. But I do have experience with the frustration of using mods.
With that in mind, I thought maybe the modding community could benefit from a few tips.
Everything here comes straight from the perspective of the people you're presenting your mods to. They are suggestions, not rules, but if you follow them your mod will be MUCH more user-friendly for those of us putting the mods into groups and using them in minecraft.
So here's my list:
1. When you make a mod, provide multiple texture sizes. Some of us can use 128x texture packs, and appreciate the quality of the graphics. Some of us can only manage 16x, and really need the extra memory to run things. Some like the middle ground, minimizing their trade-offs in both directions. The community has even shown willing to help modders do this, and there are some good artists out there. Suggested numbers? Provide a 16x, a 32x, and either 64 or 128 for the highend. The more you do, the more likely your mod will be to 'fit in' with others' texture packs.
2. Use shifted item id codes. I don't know what it means exactly, but it shifts the numbers on items (not blocks) by 256, and most modders do it. If you don't, changing your item ids results in wonky conflicts. I'll have something at 2400, and something at 2656, and they'll still conflict because one of them isn't shifted! Shifting your item ids makes it far easier to USE the config files. Speaking of which:
3. Generate and utilize config files. If we cannot shift or even READ your id's, in many cases your mod will be skipped in favor of one where we can. Seriously, it's not _that_ hard to include a changeable config file that generates from your assigned ids and allows those ids to be changed. I've seen new modders do it on their first mods. And it's well worth the effort!
4. Do not modify base class files. There are passionate folks on either forge or modloader's side, but you should use at least one or the other, if not both. If you can only use one, I advise forge, because more mods use it, more packs use it, and as a result, more people will use your mod. Changing the base class files is conflict-heavy and not worth the effort.
5. Don't use IDs 4090-4095 and 31500-31750. I include this one half-laughing, because in a community of 'individual thinkers', it's amazing how many of them do the same thing. Of 50 mods I chose at random, 20 of them used these id's, whether because they put all their ids there or just to throw one or two up there while everything else was elsewhere. What's with these numbers? Are they magical? Don't use them, please. Sometimes, what everyone else is doing really isn't the best thing.
6. Don't conflict with Minecraft's vanilla id's. I'd think this one would go without saying, but I've seen it often enough to add it. Vanilla id's change occasionally as new things are added - it's best to avoid being right near them, so you don't have to change the ids in later versions. For some weird reason, vanilla uses the 0-500 or so, but also those 2200 disc id's (no idea why they're separated like that but hey). My advice is to avoid 2000-2400 in block ids on top of the pre-256 ones, and avoid the first couple thousand item ids as well, just in case (stay above 6k or so).
7. Use api's. When I load up a mod that adds (for example) a new sort of fuel, I love to see it already set up to work with buildcraft, ic2, forestry, railcraft, etc. Most of the big mods out there have api's so you can hook into their mods for not only fuels, but items as well. Compatibility sells.
8. CHECK your entity and biome ids. Most folks using mods know about block and item ids, but entities, biomes, and dimensions can also conflict. The first time I loaded up Twilight Forest, for example, I got weird trees all over the place in the overworld! I had one of the biome-adding mods, and Twilight Forest's biome ids conflicted. It was a strange experience. Please, please, add the biome, entity, dimension, and so on to your changeable config files. Even when someone doesn't understand what they mean, the impulse is to make sure the numbers aren't the same as other mods' versions, so it helps.
9. Use damage values. This is getting more popular, but is still worth saying. If you have a statue block, for example, and you have 13 variations of the statue, you DO NOT need 13 block ids for it! Use one, use damage values for the others, and boom - one block id, 13 statues. The exception to this is things with charge, of course, or actual damage - those need the damage values to represent fuel and hit points.
10. Update within a week of Minecraft's new versions. Yeah, it's not always possible - life gets in the way. But if your mod is so complicated that it takes longer than that, you should probably break it up into smaller mods and do them one at a time (offering a complete single pack only when they're all updated, but the smaller ones asap).
Allow people to PLAY with your mod installed! If we can't use it when all the others are done updating already, it will be dropped. I stopped trying to include certain large mods a few versions ago, since they just don't bother to update enough. If you love your mod, feed it.
11. Consider breaking it up anyway. To use Red Power as an example: My husband likes the tubes. I like the microblocks. We could care less about the rest of the junk Elo adds (in fact, we wouldn't even download bluetricity portions). If she included only certain things in frequently-updated mini-mods, we'd be able to still use parts of her pack.
Giant, over-reaching megamods are hard to keep updated and frequently add more than the users really want. So if you have a lot of different styles of items in your pack, consider breaking it up and offering one big pack (with everything) and a bunch of smaller ones (easier to keep up with).
A positive example of this? Go check MaxtressVigil's Pam's mods. Flowers are separate from crops are separate from worldgen, etc. And Harvestcraft has a giant mega-download for all the modules, so no need to click a thousand links if you want all the crops.
12. Test it thoroughly. Ok, this is a problem all coders seem to have. They're confident that their code works, so they can release. But that's not how reality works. Please, test your mods - check how they function on different forge versions, play with them ingame a little before releasing them so you can see any wonky behaviors. You can't predict everything, but some major bugs can be caught pretty easily.
13. Love your mod. Two examples here, both fictional:
Mod 1 releases a set of new fences. They utilize wool and wood colors, and work fairly well Modder 1 likes it, but when minecraft updates, he's gone off to play other games and forgotten it.
Mod 2 releases around the same time. They utilize wool and wood colors to make new fences. They work fairly well, just like Mod 1. Modder 2 thinks this is so much fun, he starts adding in new lampposts to match. Then he adds new lamps, because you can't have posts without them. Then he figures out that he can code in redstone, so he changes his lamps to turn on and off. THEN he learns he can use redstone to open and close his fence gates... you see where it's going. He loves the codiing, and the mod he's working on. By the time Minecraft updates, Modder 2 is doing it for fun. He updates (it takes a week and a half - he updates the fences the first day, the lamps by the third, and other stuff later).
Which mod would you rather see?
14 Release your code. I have no right to demand it, but these are suggestions. There are multiple reasons for it:
- New modders learn from old mods' code.
- ALL mods are made by decompiling Minecraft's code, so really, your work is derivative and should be available anyway.
- The openness makes you look better - not all of you will care, but it's a fact.
- You CAN benefit from suggestions from other coders, whether your ego gets bruised or not.
- See 15.
15. If you stop loving the mod, pass it on. Everyone gets bored. It happens. Or they move on. Or life gets busy and they don't have time anymore. The community understands this, we really do! If you can't maintain your mod, or keep it updated, please allow others to do it for you. The community has shown a distinct willingness to return it to you, should you ever come back to it, and if we love the mod, it will go on. You'll leave a legacy behind, and be remembered for it.
We still remember Nandonalt, many of us fondly. So please, allow us to keep the mods going when you can't.
16. Do the new, or do the old - but do it better, not over-again. There are a LOT of farming/botany mods out there. There are LOADS of electricity-based ones. There are mods that mine for you, or make new tools and armor. There are so many copies of 'sapphire', 'ruby', 'copper' or 'tin' that forge had to add hooks to keep them all working together.
Instead of just another set of armor and tools, try doing unique things. Play around. Throw things together in new ways. Check out what's already out there, and fill a void you've found in your own playing of minecraft. Chances are, you're not the only one who's found this to be missing. Add modular statues, or mutate something. Make a Dutch Oven to cook things in. Do something DIFFERENT.
The exception, of course, is for brand-new modders. Everyone starts somewhere, and making a 'newbie mod' where you simply add a bit of armor or new tools is fine. Present it as such. People will download to test your code and help you out a bit, and offer suggestions. It's worth doing. But if you're going to give us a great mod, do something new.
17. Above all, stay humble. Coders tend to be egotistical and arrogant. It's just part of creating the worlds people play in, and the competitive nature of a mostly-male profession. Even the females in that world can't avoid it completely. But remember - you're a person, everyone else is a person. Users are people too. We may not live in your world of numbers and states and shifts and strange punctuation, but we play the game. Treat us well, and we will love you.
These are useful, but for some you're asking too much of a person. Most modders aren't a team, they're an individual having fun developing for a game they love.
I truly, TRULY agree with you on some of these, and as a modder myself I'll give a little insight on why we do what we do:
1: Multiple texture sizes are unnecessary. In my opinion, by default they should be 16x, and it is up to the user or texture pack maker to upscale/do as they please. Textures should fit in with vanilla minecraft as well, as most of the population uses it/it makes sense.
2: This is a good one and makes configuring IDs easier for the user and it literally one line of code
3: Always a must for configs nowadays if you're serious. More configs are ALWAYS better than less configs. See Gregtech; that mod has the biggest and most configs of any mod out there. You can configure almost 100% of that mod, so almost everyone who changes his configs ends up with a different, tailored product to their taste. Hardcore? Sure. Ezmode? Got it too.
4: A must as well. In my opinion, modloader is depreciated software, and Forge should be used in almost every case. It's far more powerful and has far more flexibility. If you can't do it in Forge, you probably can't do it in the Minecraft engine.
5: This one is funny but true; most people think "nobody uses these! I will for compatibility!"
6: People do this?
7: Fuels (in this case) should work in every instance of a fuel-burner except ones that have custom heat values (railcraft boilers). Unless compatibility really needs this, I find this one to be a little further than some modders will go, myself included. I don't want to have to package tons of APIs or use reflection just for the small chance someone wants to do that instance. Mods, by default, usually fit in well with other mods in one gigantic puzzle of mods, unless you're doing something crazy like TFC but that's designed to change everything. But you're right, compatibility DOES sell more.
8: Agree, see 3
9: Increasing in popularity, but for smaller mods or new modders this (was) an advanced concept, but now it's easier than ever, and is recommended in Forge itself. (Registering a non-meta block is now depreciated)
10: This isn't always possible. Apis change, Forge changes, Minecraft changes, and life gets in the way. For 1.3 and 1.5, these were two especially hard updates.
11: I agree. This partially reaches back to the configs, if someone doesn't like this part they can turn it off. The stigma surrounding "if you don't like it don't use it" is completely untrue; it's still there if it isn't turned off. This one just reaches at the huge mods that include multi part submods (RP is the perfect example you used.) I JUST want Eloraam's logic gates and bundled cable. I could care less about the microblocks. (Immibis does them better, even. His work on TE conduits, BC pipes, and much more.)
If the user doesn't want it there, and it can't be turned off/seperated, you're just making the mod user waste block and item IDs. With more and more mods being created, these are getting very precious.
12: I don't understand why some coder's don't test at LEAST with a few possibilities in vanilla. I understand cross-mod unwanted interaction, but your mod is to be expected to have as little bugs as possible in the confines of just vanilla. All computers are different, and so are a few java installations, but a problem that is global that causes your new bow to crash whenever you hit an enemy is completely unpolished and untested. If you don't have time, put it out for open beta! Many people would love to test it for you to get their hands on a new copy of something in the process.
13: This is almost a given, but I'll also say that some modders are (sadly enough) only in it to impress 'certain' people to join a 'certain' server. Tip guys like that: your mod is your baby; you have to love it to make it see impressive, interesting growth. Railcraft was once a small mod that added a few new rails: now it's one of the huge mods that adds rails, trains, a whole signalling system, interesting blocks that remind you of the 1800s industrial era. It's a whole, whirling, polished machine. If you've watched Covert's videos, you can tell he loves his mod.
14: True, but this is a matter of one's level of comfort. There was once a time where I wouldn't show anyone my code because of my lesser understanding and the fear of being told I had code. I can understand if someone isn't comfortable in theirs, either. On the better side, there ARE people to learn from (and very good too). Pahimar's EE3 code is extremely readable and working.
15: This is also a matter of comfort, to a greater extent. Life gets in the way, things happen, but you want to continue your mod that you gave to someone for a while, and now it's a completely different mod that you had planned. If you reboot it, you'll fall under the 'MFFS' syndrome.. (There are like, 5 iterations of that mod now).
I would never want to see Redpower in the hands of someone else. Eloraam has a grand vision for her mod that was never completed, and things were added in to reach that vision. Only she sees that. No amount of explaining would get the vision across.
16: I agree. There isn't much to say in this case, but if you want to 'do it again', do it in your style. If you add a 'diamond furnace', don't just make it smelt faster or some garbage; maybe make it run off of nearby mob kills! Maybe the fuel efficiency is determined by the moon phase! (Or only works at night or in the Nether)
I'm not trying to promote myself here, but I've added Gravity Boots to my mod that have thrust determined by the gravity of the dimension you're in. They don't work in the Nether, they work OK in the Overworld/Twilight Forest/Other, and they work extremely good in the End. An interesting concept I've never seen before. There is a config that lets you add dimensions to the low/medium/high list as well.
17: This is true for anyone that produces content, youtubers and modders alike. You're a person, and your viewers/users are people just like you.
I greatly respect your opinions, and hope you take all that I've written here as my own opinion, too.
As a modder with programming background I do agree with most of your points
The one I disagree with is the texture one, getting different sized textures will have to be something for later or if an artist is found whom is willing to help out
Anyways I really liked your notes and I do hope many of the coders here gets to view and understand the importance of this post.
Nice - a well thought-out and insightful list. I agree with pretty much all your points, but on the other hand, modders are just people, often just doing this for fun. While anyone who is planning on releasing a mod with the intent that a large number of people will use it should certainly follow your advice, I think many mod-makers, myself for example, don't start out planning to have a huge release or even release at all, so taking the trouble to include other mods' APIs or an advanced config file aren't exactly high on the priority list.
That being said, I think many of your points are just good coding practice and many mods could certainly be made better by following your suggestions. It's always just a matter of time - coding takes a lot of it
I've found coders to be quite rude and annoying to deal with,
but programmers tend to be quite different.
Although that depends on how you approach them, I mostly find programmers to be friendly and nice people who eagerly answers questions and helps out, if they have the time :=)
But that depends on how you ask, any man can be an if you ask like a jerk