• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.

ClintonM

Sergeant
Nov 11, 2018
74
0
Mod can be downloaded from https://www.nexusmods.com/battletech/mods/347.

This mod makes a few changes to weight classes to give some love to mechs that are hit hard by being just over weight class thresholds, despite being as agile as their lighter cousins.

The guidelines are (based on tabletop speeds):

1. Any mech with walk speed 7 (190m) or above is classified no heavier than light.
2. Any mech with walk speed 5 (150m) or above is classified no heavier than medium.
3. Any mech with walk speed 4 (120m) or above is classified no heavier than heavy.

Note this doesn't go the other way. A Panther is not now a heavy mech, and an Urbanmech is not now an assault mech!

The reason for these guidelines is that mechs with these speeds and above these weight classes generally have no more or even less tonnage available, so are actually comparable in firepower to their lighter cousins.

Based on these guidelines, the following changes have been made:

1. Cicada: Medium -> Light
2. Dragon + Quickdraw: Heavy -> Medium
3. Banshee + Battlemaster + Victor + Zeus: Assault -> Heavy

All stability thresholds for these mechs have been reduced to their new weight class, except for the Cicada-2A, which, with less free space for armour and weapons than a Locust, I thought needed all the help it could get. Generally speaking though the increased initiative will more than compensate for the reduced stability I suspect. In addition, mediums and lights are harder to hit, so mechs moved into these categories get further bonuses to compensate for a stability loss.

Note I haven't been able to change the Cyclops as being a DLC mech it doesn't seem to appear as an XML file in the "chassis" directory. Arguably the battle computer variant shouldn't get a boost as it already gives itself an initiative boost but probably the non battle computer variant could use some help.

These changes do not affect how mechs spawn in the OpFor, with two exceptions: Cicadas will now be classed as lights for spawn purposes and Quickdraws as mediums. This is as both of these are designs with low melee damage and their stock designs are outclassed by other mechs in the weight class below them.
 
I am running a mod that adds the charger.
Some variants are 4/6 and some are 5/8.

How would thus mod effect it.

Also....have a mod that adds the 3/5 banshee would it still be reclassified as a heavy?
 
I am running a mod that adds the charger.
Some variants are 4/6 and some are 5/8.

How would thus mod effect it.

Also....have a mod that adds the 3/5 banshee would it still be reclassified as a heavy?

The actual mod doesn't have the guidelines coded into it, it's only a JSON mod, not a DLL mod. I've just given the guidelines here so people can understand the decisions I've made.

So this mod only works on the stock variants that I've set, so additional variants won't be affected.

That's probably good for your 3/5 Banshee, but maybe not good for your 5/8 Charger, which will still be classified as an assault mech.

But adding your own variants to the mod should be fairly simple, just add entries to the "StreamingAssets/data/chassis" folder, and add a dependency in "mod.json" to your mod as discussed here. https://github.com/janxious/ModTek/wiki/The-mod.json-Format.

Unfortunately I won't be able to merge that change into my mod proper, as whilst a dependency would be required to ensure this mod loads after others, putting any particular dependency in my mod would stop it loading for players who don't use those mods.

If I made this a DLL mod I could be far more flexible on this, as it happens at runtime when all the mechs are loaded so I can deal with a variety of mods at that point.

I'd still probably want people to be explicit about the weight classes, as it would be perhaps a bit OP to whack a Kodiak in the heavy weight class even though it has walk speed 4. The whole mod is balanced around standard engine sizes so applying an automatic rule to all sorts of mod based mechs could be problematic.
 
Interesting idea - though there are a couple of things.

You could just add the Light tag to the Cicada - in effect allowing the light and medium lists to pull it (though I believe the logic on a contract that excludes lights but includes mediums would exclude the Cicada)

Another issue you may encounter is that using the truncated merged files may not play nice with other mods.

If the mod uses the straight StreamingData path configuration (where you just drop the Mods/MyCoolMod/StreamingAssets/Data/chassis folder structure in place and let ModTek decide what to do), then it will merge with the base game files. But it won't merge with mods that are setup folder specific (Mods/MyCoolMod/chassis).

Also, if 2 mods replace tags, then it is last in wins. Once again, something like Tags, it doesn't merge your new tags with existing tags, it just replaces them. So if you have 2 (or more) mods that adjust the tags, then the last one will be the one that is actually applied.
 
Last edited:
Interesting idea - though there are a couple of things.

You could just add the Light tag to the Cicada - in effect allowing the light and medium lists to pull it (though I believe the logic on a contract that excludes lights but includes mediums would exclude the Cicada)

Another issue you may encounter is that using the truncated merged files may not play nice with other mods.

If the mod uses the straight StreamingData path configuration (where you just drop the Mods/MyCoolMod/StreamingAssets/Data/chassis folder structure in place and let ModTek decide what to do), then it will merge with the base game files. But it won't merge with mods that are setup folder specific (Mods/MyCoolMod/chassis).

Also, if 2 mods replace tags, then it is last in wins. Once again, something like Tags, it doesn't merge your new tags with existing tags, it just replaces them. So if you have 2 (or more) mods that adjust the tags, then the last one will be the one that is actually applied.

I only actually change the tags on two mechs, namely the Cicada and Quickdraw, so I don't really mind if these are clobbered. The main thing I change is the weight and stability in the chassis files. I (or others via a PR) could add modded mechs to my chassis files. However my main concern is what happens in the following cases:

1. What happens if a my mod loads before a mod of a modded mech.
2. What happens if I have a modded mech in my files but the user doesn't have the mod.

I can fix 1 by putting a dependency on the mod but I believe that would break the mod in case of 2.
 
I had downloaded and saw the changes, and just wanted to alert you for troubleshooting purposes - those sorts of things drove me NUTS :p

Was also mentioning that you could do multiple weight tags (not changing the "weightClass" - just the mechdef tags) which would make the Cicada appear in both categories, but be eliminated anywhere that excluded either category. Options :)

In your examples:
1 - Depends. If both mods are done the same way (both using the Mods/MyMod/StreamingAssets/Data/chassis folder or both using the Mods/MyMod/chassis with the JSON telling it what to do with the folder) then it will happily merge or overwrite (depending on the settings you chose or the default behavoir) If they are different types, and it is a merge, then the merge won't happen. If it is different types and it is overwrite the whole file, it will be the last one loaded.

So, if a mod that matches your structure loads their own version of the Cicada model in your mod, giving it alternate armor/weapons, then your mod should just overwrite the tags and the both will be merged together (you can see it in the Mods/.modtek folder). This will still be in load order though, so if you overwrite the base file and then another mod overwrites your overwrite, then the last in will be the one you see.

If a mod uses the other method, then it may cause you problems.

2 - I would put those extra files in a secondary folder, this is where the other mod method comes in handy.

I am working on updating a mod of mine from way back that 'fixes' all the star system coordinates to match Sarna's (which match up better with the source books). But I also have 16 new star systems that can be added to this region. To give the player a choice of just adding in the Coordinate Adjustment and not use the new Star Systems (which could cause issues if they are missing from a campaign you once had them in) I use the other method of telling ModTek exactly what to do with a folder/file.

"Manifest": [
{ "Type": "StarSystemDef", "Path": "starsystem", "ShouldMergeJSON": true, "AddToDB": false },
{ "Type": "StarSystemDef", "Path": "JK_starsystems", "AddToDB": true }
]


The mod has 2 sub-folders, starsystem and JK_starsystems.

The first line in the Manifest will merge the starsystem files in my mod with the core game starsystemdefs - which will only change the coordinates (x & y).

The second line will look in the JK_starsystems and add them into the game.

If someone doesn't want to use those, they delete that line out.

I'm a bit tired, so please let me know if I am being convoluted / confusing or over explaining :p

Really, the best way to test is to try it out with your extra stuff, then remove those other mods and see what happens.

In doing my Rarity mod, I found that the merges stopped once they hit a folder that didn't have anything to merge with (as in that mod wasn't loaded), so that JSON just stopped that mod from loading anything else after it and it moved on to the next mod folder.
 
Instead of classing Cicada as a light is there a way to give them a +1 initiative similar to the Cyclops?
What do you have to edit in the json files for that to work?