• 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.
Before I go too much further into this, I'm trying to figure out if I can create my own milestone files, but I'm not having any luck. I duplicate 114, rename it 115 and set the value inside it to 115 and change the previous milestone to point at 115 instead of 114 and it doesn't load.

I mean, I can just keep kludging and overwriting existing milestones, but it'd be cleaner to not do that. If I can figure out how to do that I can just dump my sandbox milestones in the folder and switching between my sandbox and the story campaign is as simple as replacing one file instead of several.

[edit] Also having trouble figuring out how to use the milestones to tell a system to swap between different versions of itself (used to flip the Aurigan systems from Directorate to Restoration). Again, if I can figure that out, I can just create my own versions of systems and tell the game to swap to those at the start.
 
Last edited:
Modders take note.
Ok, this is a good place to put this info, because I think it's important for modders to see, but I don't want to start a wave of complaints to HBS on the matter.

Be very careful about deploying mods.

The issue I've found while working on my mods is.. best describe with the following:

1. Say you worked out the necessary to introduce a new mech or a new weapon into the game. It works and you can see it in the Skirmish game, and can use it to equip other mechs in the Mechlab. You make up a whole bunch of new mech builds and saves them in the game.

2. A few days later, you decide to rework some aspect of the mod, and for some reason, needed to remove the mech/ weapon. You code up your new work perfectly and loads up the game, and try to go into Skirmish or MechLab.

3. The game goes into stunlock. Checking the logs, you see things like this:

Data.DataManager [ERROR] LoadRequest for THI_WD_Weapon_LaserPulse_Medium of type WeaponDef has an invalid manifest entry. Any requests for this object will fail. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Data.DataManager [ERROR] LoadRequest for THI_WD_AmmunitionBox_LBX10C of type AmmunitionBoxDef has an invalid manifest entry. Any requests for this object will fail. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

4. Try as you might, you can't get the game to go into Skirmish/ Mechlab. You are now faced with the option of a reinstall, which will wipe your campaign progress.

The reason for this (IMO) potentially dangerous behaviour is that when you modify a mech build and save it, the game save it into the internal DB or some save file that we don't currently have any idea where it is. That isn't bad, it's a good thing. It lets us save our favorite broke builds to repeatedly bring up to beat people over the head with.

The bad thing, and unknown to most of you, is that whenever Skirmish or Mechlab starts up, it does a basic verification check against ALL saved builds, and start generating warnings such as the above when they find mech builds that doesn't work. The worse part is that it doesn't ignore these, but goes into stunlock.

Since these builds are not in JSON and is actually likely in a DB somewhere, we can't manually remove these entries. The solution I went with (since it's my mods and I know what the heck I did), was to reinstate the missing entries that the system is complaining about, and try the Skirmish and Mechlab. Once those are working, I go through the entries and delete any that contains the bad material. And then I can remove the unwanted Manifest entries. If that sound like a lot of work, yes it is.. well actually not that bad since I have certain habits. But that's because I know the crap that I'm working on.

But imagine if you are a basic user who heard of this great mod and you download but found it not as great as you felt it to be. You remove the mod and then the whole game locks up on you. You reinstall and lose all progress in the main game. How'd that make you feel about the mod creator?

Also, bear in mind MP Skirmish needs both clients to be on the same basis. That usually implies players would add/ remove mods regularly.

I know putting this up can have a chilling effect on mods, but you guys do need to know this before too many mods are released and people start having games that freeze up on them. So think carefully how you want to handle a case when your mod has to be removed from an installed game.
 
Ok, this is a good place to put this info, because I think it's important for modders to see, but I don't want to start a wave of complaints to HBS on the matter.
[...]
Can you make a mention of this in the first post, just so new people won't miss it? Not everyone looks at the threadmarks (though they should), and this is possibly the most important information in this thread right now.
 
Thank you for that warning!

I had something similar happen to me - but instead of a reinstall, I did a 'Validate Files' in steam, followed by reapplying my modified VersionManifest.csv, and I was still able to continue with my campaign saves.

Though your edits sound much more in-depth.

Then again, maybe I just got lucky...

Maybe if we just delete the 'Mechs using the modified equipment before deleting the relevant files from the mod files?
 
Maybe if we just delete the 'Mechs using the modified equipment before deleting the relevant files from the mod files?
That'd be ideal, though two situations will throw it off.

1. A lot of mod users won't do that.

2. I have no idea what mod stuff is out there that could get saved by the sim game. I can't go at what I don't know.
 
Also fair enough - we only know what we know ;)
 
If we get a mod manager, it may need to be able to run queries against the DB to remove anything referencing the mod files? Have it as a checkbox, so balance mod removal has the option to not remove all of your saved loadouts, which would still work in vanilla (assuming no tonnage/slot changes, of course).

Seems like a lot of work.
 
Looking for some help on a couple things that were not clear on the modding wiki.

Looking to go TT heat on movement. Either 3 or 6 on walking heat (thinking 6 as you are technically always running), and 9 for sprinting. Would like to set it to 3 heat per jump jet, minimum heat of 9, but when it comes to jumping it gets a bit more complicated. Default values are,
Code:
        "JumpHeatUnitSize": 6,
        "JumpHeatPerUnit": 1,
        "JumpHeatMin": 5,

Using a Griffin 1N and a 4 Guts Pilot, I can jump max distance, and fire a TT 30 heat PPC for 5 turns without shutting down. So 150 heat for the PPC by itself over 5 turns. If the jump jets produced 5 heat that would give me 125 heat over 5 turns, or 275 total with the PPC firing. 12 heat sinks would dissipate 36 heat, or 180 heat over 5 turns. This would leave me at 95 heat. This is just below shutdown which is what it looked like on the heat bar. 6 heat per jump would give me 150 heat, 300 total with the PPC, and leave me at 120 heat and supposedly shut down.

Now after some more testing...

Reducing only "JumpHeatUnitSize" to 3 I built up heat to about 1/4 of the heat bar from just jumping. ???

Reducing only "JumpHeatMin" to 3 I had the same exact results as if it was still set at 5. So no visible change at all.

Increasing only "JumpHeatPerUnit" to 3 put me at just under the heat threshold from just jumping, or more than half the bar. Guessing this is a multiplier for one of the other 2 values.
:confused:



Now onto my other problem.

Trying to implement all 3 range brackets, and have already changed all of the weapons to reflect this. I also changed the values for range modifiers, i.e "ToHitMediumRange", to short=0, medium=3, and long=6, just for testing purposes. Where I am stumped, is with the below 2. At least they are what I think I am looking for. Just do not know what I should add to make them work to get a medium range.

Code:
     "ToHitStepThresholds":
     [
            0,
            10
     ],
     "ToHitStepValues":
     [
            0.05,
            0.025
     ],
 
Last edited:
IIRC, the dB is a SQLite dB file. It would be unfortunate for modders if database migrations are needed for modding beyond json file tweaks. It would really make a mod manager a necessity, not just useful.

I’m interested in whether/when/how the game discovers and loads (Unity) components. For instance, a useful ‘modding mod’ might be one that merges JSON fragments into their respective docs at runtime. Mods would then only have to supply the JSON data for what that mod wants added/updated/removed from any given game data file. This makes mods more robust and less likely to break each other or the core game.
 
Now onto my other problem.

Trying to implement all 3 range brackets, and have already changed all of the weapons to reflect this. I also changed the values for range modifiers, i.e "ToHitMediumRange", to short=0, medium=3, and long=6, just for testing purposes.
Just as a commentary, someone else tried this in the Beta too. Basically the opinion then was that it didn't really add much to the gameplay experience. It made the % more varied, but it boils down to the same tactics in game.

EDIT: Also, just to note, when you implement the three range bands for weapons, it does make the UI much more cluttered. I'm used to it -- my mod weapons all have the range bands -- but some people may dislike the clutter.
 
I haven't experimented with those settings, but keep in mind that detailed information on what is happening with heat is in the log files...
See here: http://btmodding.warriorsblood.com/index.php?title=Extending_the_Log_Settings

(Although I don't know if anyone has experimented with that except in the beta, either.)
Some have successfully gotten the logs to dump to Dumpbox if the Discord channel can be believed. I've managed to activate to go to the Outputs file, but that's messy to go through. I need to spend some time to figure out how to send it to a nice correct place.
 
Just as a commentary, someone else tried this in the Beta too. Basically the opinion then was that it didn't really add much to the gameplay experience. It made the % more varied, but it boils down to the same tactics in game.

EDIT: Also, just to note, when you implement the three range bands for weapons, it does make the UI much more cluttered. I'm used to it -- my mod weapons all have the range bands -- but some people may dislike the clutter.

Not too worried about the clutter. I can just turn different weapons on or off to see what I am looking for range-wise.

As for gameplay, it is more of a preference for things TT than anything else, not really concerned with what it adds or not. :rolleyes:
 
Ok I'm scratching my head here. :confused:

With the 3 default values for Jump Heat I got the following over 3 turns trying to jump as far as it will go.
Code:
CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 30 heat from jumping

CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 29 heat from jumping

CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 27 heat from jumping

I modified "JumpHeatUnitSize" and "JumpHeatMin" to 3 and 2, from 6 and 5. o_O
Code:
CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 58 heat from jumping

CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 59 heat from jumping

I then returned the above 2 values to default, and then modified "JumpHeatPerUnit" to 0.5 instead of 1.
Code:
CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 5 heat from jumping

CombatLog.Heat [LOG] Mech Griffin (ec9d2280-ca9a-4d90-8a20-963d8a4c0a39.0) gains 5 heat from jumping
 
Curiosity: how did you get the combat logs to work?

From the wiki page ronhatch posted above. By the way thanks for that.

BattleTech_Data\StreamingAssets\data\debug\settings.json, at the beginning of the file. Outputs to BattleTech_Data\output_log.txt

Code:
"loggerLevels" : [
   {
         "k" : "*",
         "v" : "Error" <------------Change this to "Log"
      }
   ],



Hmmm, setting "JumpHeatPerUnit" to 0.5 changed total heat from jumping to 5, but setting it to 0.75 or 0.9 did nothing. 30 heat per jump with those numbers.
 
Last edited:
I was afraid you were going to say Output_logs.txt. I have that set up, I just hoping for the next clean dumpbox format from Beta.

I'd tackle that first, then see if I can swing around back to take a look at the jump heat issue.
 
Hehe, yes it is a bit of a pain to look through. Simplified it a bit by using find to search for "Team Player 1 becoming active" to skip through what the ai is doing.
 
2 questions for the Mod-Savants ;)

1 - When my Dragon DRG-1G loads into the Mech Lab it tosses up an error in the debug screen:

WARNING GetComponentPrefabName failed to find a prefab name for unit dragon and component Weapon_Laser_MediumLaser_0-STOCK, ideal match name was: chrPrfWeap_dragon_righttorso_laser_eh, falling back to default item

My assumption is that this is due to there not being a laser asset defined for the RT (much less ANY weapon assets defined for the RT) in the Dragon asset bundle. Yes?

If that is the case, is it doable to mod the LT Laser assets over to the RT? If so, any of you interested in doing so? As I think that may be beyond my meager skills :p

2 - Anyone figure out how to mod in new Star Systems onto the map? Adding them to the VersionManifest is easy enough. Editing them into the SQL db also seemed to be doable - including duplicating the tags and such. I am guessing I must be missing something somewhere, as I don't see the system appear on the map though.

Thanks - in advance - on either or both :)