Mods and "respect_setting" parameter

[Firebrand]

The Problem

As it stands, some of the balance mods achieve their goals by manually white-/blacklisting entities by their ids. For example, the Mundane Zombies mod blacklists a whole number of zombie types, including zombie animals, as well as some Lovecraft-esque non-zombie things; while the No Medieval Weapons mod blacklists a number of (mostly metal) old-style melee weapons.

This creates an inflexible system of modding that’s more easily prone to errors due to misspelling or modder’s oversight (we’re all human; it tends to happen) and requires additional maintainance if new entities were to be added later.

Suppose there’s a new type of a zombie added with later updates: that would need to be added to the Mundane Zombies mod, and if you forget, it’s just not going to appear. Not a big deal, but it’s a mistake that doesn’t have to be made.

This already creates scenarios where a user may want to certain subset of blacklisted entities removed from the black list because to the user, their presence doesn’t break the conceptual issues the mod aims to rectify.

For example, No Medieval Weapons blacklists katanas and other traditional Japanese melee weapons. Who doesn’t want to have katanas in their game? Maybe a whole lot of you, but I do, and I’m sure I’m not alone.

Another example would be the No Antique Firearms mod, which blacklists M1 and the Thompson SMG, among other fairly-modern definitive classics of the American firearm culture. Antique? Come on! They’re barely 60 years old at this stage. The game still has M1911, in the meantime. (Yes, I know, the description says the mod removes black-powder and pre-Cold War weapons. Naming issue, that’s all.)

Or, for a more specific example: when I use the No Medieval Weapons mods, the game flashes error messages at world generation and, I believe, loading because it can no longer locate the item the crafting recipes are supposed to produce. It’s a good thing the game fails gracefully for those types of errors, but it would be best if they couldn’t have been made to begin with.

Now. Could I make a mod of my own, with all the lists set to my preference? Sure, if I have an idea of how JSON works. I don’t think I should be expected to handle it on my own, though, 'cause how many people that play Cataclysm have any experience with JSON and its data structure? And sure, deleting lines is simple enough, but – again, I don’t think I should be expected to do this.

The Proposed Solution

Add the respect_setting parameter to JSON files or to the in-game settings menu, so that instead of manual color-listing of numerous separate entities, the mods would be able to remove not just the entities themselves, but also those connected to them – like martial arts books for removed martial arts, or magazines and ammo types for removed guns – based on the concept those entities represent.

For example: suppose you’d like to enjoy a more grounded, realistic experience of Cataclysm, and would like not to see any of the sci-fi gimmicks or other, crazier exploits. Maybe you’d like to have more conventional firearms from mods, but not the sci-fi ones, like laser rifles or magical-infinite-ammo revolver. With the respect_setting: "realism" setting on, any mod you add to your world will not include or spawn non-conventional, or in other ways irregular, firearms, because the mod’s entity declarations recognize the setting and, well, respect it.

Or maybe you don’t want morningstars or halberds in your game, but you do want katanas, naginatas, wakizashis, and tantos, because you’re a nipponophile – or, really, just that type of a geek. With respect_setting: "japanese_weapons" on, you’ll still see those cool, foreign blades, but not the boring European maces and spears. (Of course, you can put the setting into negative and never see those cool, foreign blades, if that’s what you’re into.)

Or – zombies. Maybe you’re okay with zombified bears and mooses, but skeletal juggernaus and necromancers just don’t cut it for you. Maybe you want a couple more zombie types in the “mundane” type – like the scientist, or the technician, or the survivor, or the armored zombie. respect_setting: "mundane_zombies", respect_setting: "zombie_animals", and respect_setting: "extended_mundane_zombies".

This could also mean that Cataclysm could have its desired sci-fi content up by default – like the Internal Furnace CBM – but hidden behind respect_setting: "realism" or something. No additional mods required: just a flick of the switch.

But Couldn’t This Be Achieved with More Mods?

Sure, it’s possible to get the same thing with a multitude of different versions of the same mod – which then have to be managed, and chosen from – and before that, crafted with just the right precision so as to appeal to the widest possible audience…

In order words, the same idea is unfeasible with merely a selection of the same mod’s versions. It’s gonna take too long, and the modder is probably gonna end up being stuck in a loop where they have to support the versions of the mod they no longer like or enjoy working on, which will just drain them and make them abandon the whole endeavor.

Modding is an act of passion and is often thankless, in that it requires putting out a lot of effort into a thing of diminishing returns. There’s no need to make it more difficult on the people who already do the work.

The Proposed Implementation

The idea behind respect_setting parameter is make it easier to customize game and mod settings, for players, modders, and developers in the long run, even if it will take writing a few dozen more lines right now. The goal is to propose a simple, more future-stable system for managing different aspects of the game, while minimizing the amount of manual code required to apply those settings.

Ideally, it could also afford expanding or radically-changing the game experience – say, by only allowing zombie animals, or by removing any weapon that isn’t a rifle, or by limiting entity spawns to those that fit within the image of the game area as it would’ve been in the 1950s (suits, dotted dresses, tommy guns, lots more coins, older cars…).

Existing code architecture – like item groups – could be utilized in the implementation of certain respected settings in the short term.

In the long term, the connections between entities are best compiled on world generation, both as a measure of reduction of manual coding and as a way to control entity spawn within the confines of respected settings. This should be achieved by ascribing types and categories to entities (that’s the “hundred lines now” aspect) while using weighted probabilities instead of chance for commonness control, and associating those on connections compilation.

This dissociation with item groups seeks to adhere to the respected settings for cases where items from the same semantic group would be separated by an in-game or a mod-imposed setting. For example, if all but Japanese-origin medieval weapons are excluded, the remaining weapons would still be spawned with respect to their weighted probabilities, and would still be considered a part of the melee_weapons group, and any other group they would otherwise belong to.

There is also, of course, the issue of the missing connected entities – such as between crafting recipes and their resulting items (like in the No Medieval Weapons example at the beginning), or books and the martial arts they teach. Ideally, removing the target entity (the result of the recipe, or the martial art taught) should also remove the referencing entity (the recipe, or the book), so as to not invoke errors that may or may not cause issues for users down the road.

Finer details of the implementations are best left to those of proficiency with code. This is an outline of what I think would be a good addition to the game’s codebase that would allow for finer control over content, more customizability for users, and easier ways of making mods.

[Zhilkin]

You are suggesting to add new attribute to existing json objects. Forgetting to add this attribute to new objects is just as much possible as forgetting to update blacklist mods with these new objects, but you also need to add these attributes to all of existing objects.

Moreover, this attribute (let’s call it category or theme) should be not a single value, but actually a list of several values as objects can belong to several categories/themes (e.g. katana can belong to categories japanese, weapon, blade, eastern, metal, sharp, cutting, piercing, etc).

Making list of categories and assigning them to existing objects is burdensome. What if we decide we need more categories? It is same amount of additional work.

It is much easier just to add items to blacklist as wr do now.

[Firebrand]

You are suggesting to add new attribute to existing json objects. Forgetting to add this attribute to new objects is just as much possible as forgetting to update blacklist mods with these new objects

I’ve always assumed that those who create new entities end up consulting some sort of a guideline on which values are possible, necessary, and obsolete. If that’s the case, one consultation (because surely nobody knows the object structure without one from the get-go) should be enough to familiarize themselves with the notion that respect_setting is a thing that’s worth considering.

Even if it’s not the case: assuming modders would end up looking through the /json/ folder to find out how the native game objects are formatted (because, again, how else would you know?), surely they would see another field to include.

Moreover, this attribute (let’s call it category or theme) should be not a single value, but actually a list of several values as objects can belong to several categories/themes (e.g. katana can belong to categories japanese, weapon, blade, eastern, metal, sharp, cutting, piercing, etc).

It would be a list, sure, but not as long as you propose, as many qualities are already present in the object’s notation. Having “sharp” damage value implies that it’s able to cut – therefore, it’s reasonable to assume that it has an edge of some sort. Having any damage means it could be a weapon within the game’s understanding. Having the material of “metal”, or “leather”, or “wool”… You get the idea.

What you need here is a list of things that distinguish the entity from others. japanese and eastern are good examples for a katana. It is also a sword, rather than a polearm (naginata) or a knife (tanto), although polearm could be implied from melee weapons that have reach. All firearms that produce laser or plasma as a projectile (which is separate from just having a firearm use UPS) are sci-fi by default. Etc. etc…

My point is: it’s not going to be as extensive as you imagine. Is it gonna take effort? Sure, as I’ve mentioned. Probably a few days’ worth of editing the existing objects alone, nevermind coming up with the categorization. I’m not saying it’s a spit in a bucket.

What if we decide we need more categories?

If you wanted to change a handful of objects – say, to adjust their collective status – you’d still have to go through each one and add properties to them. There’s no way around this – hence the “hundred lines of code”. You’d have to do this for every minor change to the object structure anyway.

(I reckon it’s possible to devise an app that would build the connections as per given world conditions, and filter the entries you want to edit, and edit those via GUI. That’s more work, right?

The comfort of refactoring the game core is beyond the scope of this suggestion, as the idea is for the benefit of mods and their authors.)

What respect_setting is supposed to do is make some mods potentially timeless. Mundane Zombies would be one of those. I mean, imagine being able to use the same basic set of mods throughout most of your games, despite updates, engine changes, and content explosions, because that’s how much the devs give a shit.

It’s not urgent, it’s not groundbreaking – strictly speaking, this isn’t even necessary. Maybe you can come up with something better, which would be great. This is just my take on how make mods easier to write and basically unnecessary to maintain.

[Casio]

It seems to me it would be easier than one might think. Start with the current content mods, and put them through the wringer for each, giving each mod it’s own personal tag. The No More Fungal Zombies mod has everything tagged as fungal/humanoid, have all the Mundane Zombies tagged as Normal/Humanoid, etc. That’s also something that could be done (I imagine, I dunno) where instead of blacklisting singular tags, you could make it so combinations of tags are white/blacklisted instead, allowing people to more easily have only certain subsets of items in the game (I.E the katanas, eastern weapons, and other weapons discussion from before. ) Each of these “pre-existing” blacklistable items/creatures is marked as such that they have already been categorized, and then you go down the list of remaining items which I imagine would be significantly smaller. Of course, someone would also have to go through the content addition mods and do this, but it would still be relatively easy if boring.

One idea is a custom blacklist mod app. It could be packaged with the current version of the game, and it scans all the files in the current version and their tags. It then would give the player a list of tags that they would have control over when it comes to blacklisting/ whitelisting items. Have one list of items that comes up when a certain tag/set of tags are entered into a search bar, and you could potentially just pick and choose what you want from a list of chosen items. I suck at design, but I am positive someone could make a good enough menu for something like this.