Total War: WARHAMMER II

Total War: WARHAMMER II

Not enough ratings
Modding Etiquette & Guidelines
By Cryswar
Rather than a guide on learning how to mod, this is more about learning how to mod /well/, covering naming conventions, compatibility-minded design, and some common pitfalls.
   
Award
Favorite
Favorited
Unfavorite
Table Naming
I'm not going to do a full guide on submodding/compatibility mods; Cataph already has a fantastic guide here[tw-modding.com] that goes into it in great detail. Instead, let's talk about the basics of naming tables to minimize problems.

For starters, don't leave a table named data__ unless you are know what you are doing, aka you are data coring because you have to. Not renaming the table at all means its contents are COMPLETELY overwriting the vanilla table rather than just adding to it or overwriting specific rows.

While it's less of a crashy trainwreck than it used to be, you still don't want to share a table name with another mod if you can help it (ESPECIALLY dual data cores); it can lead to crashes, bugginess, or just one mod's version of the table getting ignored entirely.

It is highly recommended you use a unique prefix, like part of your username or part of the mod's name. The table name doesn't have to be unique within the pack (you can have both land_units and main_units named crys_mymod without issues), but having a reasonably unique table name like crys_specializations almost totally spares you from having to worry about that stuff.

Cataph's guide goes into this far more than I intend to here, but as a very short summary, if you ARE doing a mod that needs to load with high priority, using symbols, especially ! before the mod or table name will help. DO NOT do this unless you actually need to and know what you're doing, load order can be finicky and VERY important for some mods.
Key Naming
I've seen more than my fair share of key naming schemes that make me kinda want to deepthroat a cactus, and anyone who does much submodding or compatibility stuff is likely to see the true horrors of the deep, things that make the Chaos Gods look like the good guys. So let's talk key naming! It might not see that important, but for both your sake and that of others, I personally think it's one of the most underrated subjects out there in modding.

So first, let's talk about the mechanical side of things. Your key's name, for the most part, doesn't matter. Some tables have special rules, but in general, shark_boobies is just as valid as an agent subtype name as a character skill node key or a land_unit key or building key. You DO NOT need to prefix the key with the table name; a character skill node key doesn't need skill_node_key at the start. That accomplishes nothing but making your key uglier, harder to read, and more effort to type.

What matters really come down to the following: unique, accessible, and easy to read. Let's talk about what each of those means;

  • Unique means it doesn't clash with a vanilla or another mod's key. Commonly done by adding a unique modifier at the start, like crys_unitname, but you can add it at the end or middle too if you want.
  • Accessible is subjective, but to me, that means that you can autofill it in easily, find it easily, and remember it easily. If you prefix your skill node set with wh_main_skill_node_set like many vanilla entries do... congrats! Now you have to type in 5 friggin' words just to get to the unique part, and idk about you, but I can't remember that exact progression super easily either. Instead, consider something like identifier_lord_name, ex. crys_skoroth or skoroth_crys; if you consistently use that pattern it will be easy to remember, easy to autofill, and easy to recognize for other people as well.
  • Easy to read is both selfish and selfless at the same time. Your primary reason for doing so is simple - to help yourself. If you've ever gone back to change something in a mod a year later, it can be a HUGE pain to read through ancient, crappy naming schemes trying to figure out why something stopped working. It also helps other people; newbie modders trying to learn how to make a skill from your mod, submodders trying to make your units balanced for SFO, etc. If your land unit key is called crys_skoroth, and they're named Skoroth ingame, it's very easy for me to figure out what they're supposed to be. If the key is crys_chslordevil, and your mod adds multiple chaos lords... I have no idea what the hell I'm supposed to be looking for. I've done some crappy unit names myself, especially on existing mods it can be very difficult to change keys without causing crashes or campaign breaks for subscribers, but if you start with good names, you won't have to worry about them in the future!

My PERSONAL preference is to use one unique key for as many aspects of the lord, unit, skill, etc as possible. For example, if I'm working on the chaos lord Skoroth, his agent subtype, node set, land unit, main unit, etc. are all probably gonna be named crys_skoroth or at least start with it. That makes it easy to autofill and find regardless of which aspect of the lord I'm actually working on. Your mileage may vary though.

Please note that whether or not you can easily fix keys later varies wildly between tables. Effects can be renamed and edited on demand with no issues; changing skills and tech keys mid-campaign will tend to break or remove the skill/tech; changing something like a land unit or building key will probably brick the entire campaign. You have no way of controlling when your mod's subscribers are mid-campaign and would be unhappy to find out their game broke because you wanted to fix a spelling error in a key.

So try your best to catch errors, typos, and poor key names EARLY rather than later.
Planning for Compatibility
There's really no escaping the fact that people are going to use mods together in ways you didn't expect. The most common issue is going to be SFO/Radious compatibility, but there are countless other examples of other mods that don't play nice together, and it will automatically be YOUR problem and YOUR fault when some angry guy starts yelling at you in your comments section to make your stuff work with mod X.

So, let's talk about how to avoid that!

First of all, decide from the start how much you actually care about compatibility. This is important because if you genuinely do not care about anyone trying to run your mod with SFO, that's fine, but you want to start from there rather than getting there later. Realistically, some mod concepts and some changes can only be done in certain ways, and there's no feasible way to establish widespread compatibility; if you mod involves data coring effect_bundles_to_effects_junctions for some reason, you are just... not going to be able to do compatibility with a huge number of other mods. You're also probably using an unnecessary data core or just a jerk for data coring that table, seriously what the actual fsteak, but anyways.

Secondly, try to be aware of your options for making a mod. For example, let's say you want to add Wallbreaker to all large monsters. Well, Wallbreaker is an attribute, so the default answer is to go to land_units and change the attribute group of every large monster in the game. You'll have to make at least one custom attribute group, probably more, but it'll do the job fine. It will also make sure your mod doesn't work with SFO/Radious/CTT/Lucky's/any other overhaul, or any other mod that touches the same land_units rows. It will ALSO ensure that any time DLC hits and changes any large monster's land_unit entry in any way (and it may not be listed in patch notes...) you have to update your mod for it.

That may be OK with you, and that's fine, or maybe you would want to use an effect to grant that attribute to a certain unit set, maybe using a faction effect bundle if you just want to give every Chaos unit Unbreakable, or campaign handicaps on all difficulties+human/AI if you want to give all trolls Terror.

Depending on the table, you may have other options. If you just wanted to give all trolls your new ability, you can do it just fine via land_units_to_unit_abilities, OR via effects; in most situations it really doesn't matter since neither of them is going to break other mods. If you want to add a new skill to Karl Franz... well, you really don't have any other options than adding a new skill node, which isn't a big deal, usually, but we'll get to that more in the next section.

When in doubt, see if you can do it via effects, and if so, consider using an existing faction or lord effect bundle, or the versatile campaign_difficulty_handicap_effects_tables table. Please keep in mind that if you want to make changes for both players and AI on all difficulties, you'll need 10 rows there; 5 with the 'human' box checked from -3 to 1, and 5 for the ai from -1 to 3. I personally like to arrange it something like below, but it honestly doesn't matter as long as you have all of the difficulties covered.

Compatibility - The Numbers, Mason!
There are a number of places in the game where numerical IDs or keys must be unique or bad juju happens. Two skills cannot share the same character node without one of them disappearing. If two building_units_allowed entries have the same numerical identifier, one of them will cease to exist. Same goes for building_superchains_to_slot_templates, armed citizenry (garrisons), etc. These are USUALLY pretty obvious; if a table has 6-8 digit numerical IDs, they're probably incredibly important to the table functioning at all.

This can cause extremely pernicious issues with mod compatibility, stuff that would not come up during even reasonable compatibility testing. Probably the most common to come to mind for me is skill nodes, looooots of people notice that Alarielle's indent 0 tier 9 is free, so... I'll just add my skill there! Hey, no judgement, I've done that kinda thing myself as well. But it preeeeeeetty much guarantees that down the road, you're gonna run into issues with another mod that did the same thing, and while some tables will let you change that ID just fine with 0 issues, character skill nodes... doesn't. If you change it for an ongoing campaign, that skill point will be lost forever, screwing over anyone who had been using the mod previously.

So... for everyone's sake, but mostly your own sanity, I highly suggest NOT halfassing it. Take some time to come up with good IDs / tiers. Use a number below 2.1 billion, which is when IDs tend to break down. Come up with a reasonably unique number in that range, and use Excel, Google Spreadsheets, or RPFM's built-in cell manipulation regex stuff to make that list from 177013 to 177210 do itself instead of typing out all 200-ish entries. I would generally recommend something in the 8-10 digit range; large enough to avoid any possibility of interaction with vanilla entries or lazy modders, small enough to never run into overflow issues.

If you're a skill modder, it's worth knowing that tiers can pretty much go as high as you want since the game is VERY smart about arranging them readably; if a skill is indent 0 tier 5000, it isn't going to spawn 5000 empty space to the right, it'll show up just to the right of the next highest tier skill in that indent. So to reuse that Alarielle example, if you use tier 5000 for the new skill, ingame it'll look the exact same as if you had used tier 9 - but if another mod adds a skill in tier 9, yours will just show up to the right of it, without anything breaking.

I will confess that I have seen some weird behavior using skill tiers of 6+ digits, so in general I would try to pick something UNIQUE in the 3 or 4 digit range. Going for 1000 just means that you're probably going to have an issue with the next lazy guy to also pick tier 1000. 1764 on the other hand is.... VERY unlikely to ever clash with anything.
Custom or Stock Effects?
There are a LOT of useful effects in vanilla, enough that often times you can do what you want to do just by reusing an existing effect. It may take some work to find due to CA's... interesting... naming choices, but usually doable.

Should you, though?

Depending on the scope of your mod, this is often completely fine. If you're adding a new skill to Archaon that adds +10 armor to his entire army, you can just find an existing force armor effect and use it. You're not going to run into any compatibility issues regardless of how many other mods are loaded, it minimizes the work you have to do, and will probably be fine forever.

That said, actually finding that effect can be... a struggle sometimes, and CA does occasionally change effect names, sometimes for good reason, sometimes because ????????. Sometimes they just remove effects. This can easily lead to bugs or outright crashes in your mod after a DLC and create more work for you. And realistically, the most limited or specific your idea is, the higher the chance there just isn't a vanilla effect that adds armor, but only to Chaos Trolls and Shaggoths.

So even if you don't NEED to create a custom effect, it can be a valid option to make one anyways to ensure that aspect of the mod is futureproofed and will never need to be fixed. I know some modders tend to have a set of default effects they carry between mods, since they have the same name AND IDs it's not a compatibility issue and minimizes how much work they have to do each time.

Especially if you're using campaign handicaps for your mod, it's very possible that using a vanilla effect, especially a common one like the default upkeep effect, may lead to unforeseen issues down the road. If you add -50% upkeep to the player on every difficulty with that effect... congrats, you just overwrote the vanilla player upkeep penalties/bonuses depending on difficulty. Maybe that is a good thing! Maybe it isn't. Depending on your mod it can be either, and it's smart to think about that early.

Thankfully, effects are very easy to rename, change values/scopes of, etc. without breaking ongoing campaigns so this is all easily fixable at any time if you aren't happy with how you handled it originally.
Intellectual Property and You
If you just want to edit the downloaded version of a mod, you can do whatever you want, no biggie. Want to change that unit cap from 1 to 3, or infinite? Go for it. You can just edit the packfile if you want, no one's going to arrest you.

Uploading derivative mods is another story. If you upload someone else's mod with a few changes, even with credit, you're probably still a jerk. You're generally much better off making a submod, which Cataph covers in excellent detail here[tw-modding.com]. It's still generally considered to be good etiquette to ask the modder, though.

And PLEASE don't upload someone else's mod and take credit for it, that can lead to your ripoff getting taken down and /possibly/ worse consequences.

------

While some past Total Wars have been known for their wide variety of mods, some of the ah, wider spreading ones are... TECHNICALLY illegal, or at best skirting the barrier of legality or acceptability as far as the relevant companies are concerned. This isn't an issue unique to TWW2 (3k and other TW steam workshop EULAs tend to be very clear on the subject), but TWW2 is especially harsh on this due to the fact that Games Workshop owns the franchise and is famously lawyer-happy. Even other Sega games have had issues with modders adding stuff, like the recent-ish Manchester issue.

So to put it simply, do not add anything that is from another franchise or game into TWW2, or your mod will likely be removed very quickly and may cause you or even CA legal troubles. That includes other Games Workshop licenses, like Age of Sigmar or Warhammer 40k, but it VERY much includes Lord of the Ring, Game of Thrones, etc. as well - even other historical Total War games, like Troy or Medeival. If you're uncertain if something from another Warhammer Fantasy game is acceptable, like with a Vermintide character, it's best to ask a CA member; to my knowledge the easiest way to contact one is via the Modding Den discord.

Adding other Warhammer Fantasy content that isn't unique to another game, like one of the many Chaos lords who were the biggest bad in the world and then died 30 minutes later, that is fine and doesn't cause any issues.
< >
1 Comments
Bart4huis Sep 25, 2020 @ 10:29am 
i will never mod but still thank you for making it easier to mod so i can have cool mods