I've just noticed after the lunar argo mission that EnableContractsTakeTime true can somehow repeat the mission after the debriefing dialogue. Instead of going to the Leo screen, it returns to the deploy one. Otherwise, I still like and will use this setting together with the Pilot Fatigue mod. I'm glad I could figure it out so quickly with so many other mods installed. It's always a good idea to make last-turn saves in story missions. Let's see how this setting acts with other story debriefing scenes.
PS: did a simple Recovery mission afterwards with that Weldry priority popup after mission completion. Game soft-crashed again with that day-progress setting true right before returning to the Leo screen. Repeated it after turning it off, what worked this time. Maybe it works better in career mode, but not recommended in campaign one.
PPS: I've taken the Contract Time mod by Clinton Mead from the XAI mod which worked fine with the last-turn saves of my two crash-issues above.
Hey Mad, I have a mod called Quality of Life and have been asked if I can roll some of this into it. Based on your permissions I can't do this without permission. So I'm here, asking for that permission :)
Edit: I see this is MIT on Github so awesome, still will credit you for it.
"FixCombatHUDPortraitRightClick" -- You sir are a saint, and a scholar! This one was bugging me in vanilla and most of the major overhaul mods.
"EnableAdjustedMechPartCost" -- Can you explain this one a little more? I went digging through the dll with dnSpy but still couldn't make sense of how (or where, buy or sell?) it's affecting prices. Is this making mech parts bought from stores cheaper based on the sliding game difficulty, with 0.8 as a base for Normal? Does this 0.8 make mech parts cheaper to buy, sell, or both? One of my biggest issues with the game is it's WAY cheaper to buy 3 mech parts than a complete mech, even if it comes unequipped. Even if you're playing 5 parts per mech, it's still cheaper. This discrepancy doesn't go away in vanilla until you start playing 6/7/8 parts per mech, then the parts will begin to get close to buying the mech outright (minus equipment, but close).
Is there a way we can utilize this 0.8 variable to customize our game so that, say, if we're playing 5 parts per mech we can tweak that value to be positive (1.0+) and end up with mech parts that are more expensive and actually divide closer to the total cost of buying a mech outright? For example, if a Locust is 2.2m C-Bills and I'm playing 3/3 parts to create one, I'd ideally like the parts to cost ~666k each. I believe the normal price for them is ~200-300k unmodded.
Could we use this variable you've included to double those part costs by making the var positive (like 2.0+ in my Locust example above)? Would this break sell prices or have any effects I'm not considering?
--------
BTW thank you so much for your work man, your Bourbon Vanilla package is the quintessential Vanilla+ mod on the whole of Nexus and deserves more endorsements.
Hi Kornstalx, Thx for your feedback! It's been a while since i coded that stuff but afair it's exactly like you describe. MechPart cost depend on your difficulty setting (as opposed to beeing static in vanilla, yes). The 0.8 is a simple multiplier meant as a discount so that it is still cheaper to buy Mechs via parts (because you have to travel and salvage a lot to get Mechs assembled, at least with higher settings...) In theory if you set EnableAdjustedMechPartCostMultiplier = 1.0 Mechs via Parts should be same price as Mechs as a whole. I think i didn't test setting it > 1.0 but looking at the code it should work too.
Thank you! Setting it to 1.0 got the exact results I was looking for!
Regardless of number of mech parts set in the game difficulty, the prices for a complete chassis is almost perfectly divisible by the same price of the parts individually, minus the actual modules loadout. I'm aware the game calculates armor values into the price along with some other fluff, but this single variable you introduced addresses everything I was looking to tweak.
Thanks again for your work, your github repo is the golden standard of how BT should be modded. I even prefer your Simple Ejection system much more than PanicSystem. Also the QoL UI changes you've made and things like extended info in the right-click pilot TacUI is incredible. So many kudos!
- Randomize the 'Mechs fielded for missions "Training Day" and "B-Team" - Especially helpful under circumstances where these missions spawn with a very high difficulty - At least one Urbie is preserved of course
I only test against ModTek, as all other loaders aren't reliable enough. This mod *could* work with vanilla loader but i haven't tested, i'd appreciate feedback though. To answer your question: Probably yes. Compatibility is irrelevant as ModTek is the loader, not a mod to be compatible with. Best regards, Mad
Not sure what's the issue with the latest release (downloaded from GitHub rather than here at NexusMods, though)...
But after a single offline SP Skirmish, the LittleThings.log file was a whopping ~24 MB in size; just looking near the top of the log file has these ominous lines:
[LittleThings @ 7/6/2020 5:50:16 PM] FAILED to override the DebugLevel and/or the LogLocation for Mod: LittleThings [LittleThings @ 7/6/2020 5:50:16 PM] CONTINUING to log in this file with the default LittleThings.DebugLevel: 1
Forgot to add an option to disable debugging, did ya? :p
Hi NeoSeether, No, the mentioned output is related to a custom setup on my machine where i override debug settings so i don't need to enable/disable logging all the time when i update the mod. So that's normal... but 24MB is not normal, could you give an excerpt of the contents that follow? Thx, best regards, Mad
A single round of combat in the default 'Arena - River Crossing' Skirmish map lead to a ~4.67 MB-sized LittleThings.log file, with a LOT of repetitions (4349!) of the following: ---------------------------------------------------------------------------------------------------- [LittleThings @ 7/7/2020 12:07:24 AM] EXCEPTION: Message: Input string was not in a correct format.<br/> StackTrace:at System.Number.ParseSingle (System.String value, System.Globalization.NumberStyles options, System.Globalization.NumberFormatInfo numfmt) [0x00083] in <d7ac571ca2d04b2f981d0d886fa067cf>:0 at System.Single.Parse (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00000] in <d7ac571ca2d04b2f981d0d886fa067cf>:0 at System.Single.Parse (System.String s, System.IFormatProvider provider) [0x0000c] in <d7ac571ca2d04b2f981d0d886fa067cf>:0 at LittleThings.Patches.Coil+CombatHUDWeaponSlot_GetWeaponCOILStateColor_Patch.Postfix (BattleTech.UI.CombatHUDWeaponSlot __instance, UnityEngine.Color& __result, UnityEngine.Color fallbackColor) [0x00017] in <e865c8e3334b49f29d9c330ed5cbbea1>:0 ---------------------------------------------------------------------------------------------------- I DO make use of the latest GitHub build of Custom Ammo Categories (because it also integrates an up-to-date build of the Attack Improvement Mod), as part of the CustomBundle package.
Sorry about the delayed reply, been a long morning/afternoon.
On the one hand, the number of instances of a near-identical error is FAR smaller (only 596 instances, and a log size of ~620 KB), but that was only after a single round of combat.
After the full skirmish, LittleThings.log balooned to multiple megabytes, just not into the double-digit range.
The repeated output is nearly identical:
---------------------------------------------------------------------------------------------------- [LittleThings @ 7/7/2020 5:50:42 PM] EXCEPTION: Message: Input string was not in a correct format.<br/> StackTrace:at System.Number.ParseSingle (System.String value, System.Globalization.NumberStyles options, System.Globalization.NumberFormatInfo numfmt) [0x00083] in <d7ac571ca2d04b2f981d0d886fa067cf>:0 at System.Single.Parse (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00000] in <d7ac571ca2d04b2f981d0d886fa067cf>:0 at System.Single.Parse (System.String s, System.IFormatProvider provider) [0x0000c] in <d7ac571ca2d04b2f981d0d886fa067cf>:0 at LittleThings.Patches.Coil+CombatHUDWeaponSlot_ShowTextColor_Patch.Postfix (BattleTech.UI.CombatHUDWeaponSlot __instance, BattleTech.Weapon ___displayedWeapon) [0x0002c] in <3e7808aa0106474c97b567c239c3c15b>:0 ----------------------------------------------------------------------------------------------------
Found another, updated to: https://github.com/mad2342/LittleThings/releases/tag/1.9.1-009R
Just to clarify, the cause of the problem still lies within the custom bundle, i assume AIM does weird stuff to dmg texts in the weapon panel (but the actual source of the bundle isn't accessible so i can't verify). In vanilla there are no logs at all with a loglevel of 1. Either way i hope the current release can circumvent that problem for you.
Please cite the exact contents of the injury floaties as vanilla shows simple ones by default too *and* there are other mods that add injury-related floaties (if you're using any others). I'll check next time i play too. Best regards, Mad
I just tested and have no problems with the mentioned setting. My code isn't even executed with the setting on false. If the problem persists please state the ModTek-Version and attach the output_log.txt from the game (location depends on OS/Platform, see https://forum.paradoxplaza.com/forum/threads/needed-support-logs-save-locations.1133621/) Best regards, Mad
Thx @Dragon32, To explain: - "FixInterleavedDropouts" fixes a vanilla bug with the game leaving/re-entering turn-based mode when convoy extracts (See https://forum.paradoxplaza.com/forum/index.php?threads/battletech-escort-mission-opfor-gets-free-movement-turn-after-ai-trucks-evac.1290586/) - "ExpandStatTooltipDurability" adds the base stability value of the Chassis to the "Durability"-Tooltips *and* takes into account the BSC of the Anni. - "AdjustMechPartCostMultiplier" is explained in the Description/Readme.
I updated the desc here on nexus (i tend to forget as github is the dev-friendly place for these kinds of mods) As for a changelog, yes i agree that a changelog is nice, but i simply cannot maintain changelogs for all of my mods... Not enough time to spare, sry.
29 comments
-
1
-
2
JumpOtherwise, I still like and will use this setting together with the Pilot Fatigue mod.
I'm glad I could figure it out so quickly with so many other mods installed. It's always a good idea to make last-turn saves in story missions.
Let's see how this setting acts with other story debriefing scenes.
PS: did a simple Recovery mission afterwards with that Weldry priority popup after mission completion. Game soft-crashed again with that day-progress setting true right before returning to the Leo screen.
Repeated it after turning it off, what worked this time.
Maybe it works better in career mode, but not recommended in campaign one.
PPS: I've taken the Contract Time mod by Clinton Mead from the XAI mod which worked fine with the last-turn saves of my two crash-issues above.
Edit: I see this is MIT on Github so awesome, still will credit you for it.
Glad to have helped.. :-)
Is your mod on Github too? Drop me a link, i'm interested!
Best regards, Mad
Should have been off by default though
"EnableAdjustedMechPartCost" -- Can you explain this one a little more? I went digging through the dll with dnSpy but still couldn't make sense of how (or where, buy or sell?) it's affecting prices. Is this making mech parts bought from stores cheaper based on the sliding game difficulty, with 0.8 as a base for Normal? Does this 0.8 make mech parts cheaper to buy, sell, or both? One of my biggest issues with the game is it's WAY cheaper to buy 3 mech parts than a complete mech, even if it comes unequipped. Even if you're playing 5 parts per mech, it's still cheaper. This discrepancy doesn't go away in vanilla until you start playing 6/7/8 parts per mech, then the parts will begin to get close to buying the mech outright (minus equipment, but close).
Is there a way we can utilize this 0.8 variable to customize our game so that, say, if we're playing 5 parts per mech we can tweak that value to be positive (1.0+) and end up with mech parts that are more expensive and actually divide closer to the total cost of buying a mech outright? For example, if a Locust is 2.2m C-Bills and I'm playing 3/3 parts to create one, I'd ideally like the parts to cost ~666k each. I believe the normal price for them is ~200-300k unmodded.
Could we use this variable you've included to double those part costs by making the var positive (like 2.0+ in my Locust example above)? Would this break sell prices or have any effects I'm not considering?
--------
BTW thank you so much for your work man, your Bourbon Vanilla package is the quintessential Vanilla+ mod on the whole of Nexus and deserves more endorsements.
Thx for your feedback!
It's been a while since i coded that stuff but afair it's exactly like you describe. MechPart cost depend on your difficulty setting (as opposed to beeing static in vanilla, yes). The 0.8 is a simple multiplier meant as a discount so that it is still cheaper to buy Mechs via parts (because you have to travel and salvage a lot to get Mechs assembled, at least with higher settings...)
In theory if you set EnableAdjustedMechPartCostMultiplier = 1.0 Mechs via Parts should be same price as Mechs as a whole. I think i didn't test setting it > 1.0 but looking at the code it should work too.
Thx again, best regards, Mad
Regardless of number of mech parts set in the game difficulty, the prices for a complete chassis is almost perfectly divisible by the same price of the parts individually, minus the actual modules loadout. I'm aware the game calculates armor values into the price along with some other fluff, but this single variable you introduced addresses everything I was looking to tweak.
Thanks again for your work, your github repo is the golden standard of how BT should be modded. I even prefer your Simple Ejection system much more than PanicSystem. Also the QoL UI changes you've made and things like extended info in the right-click pilot TacUI is incredible. So many kudos!
That's good to hear!
To answer your question: Probably yes. Compatibility is irrelevant as ModTek is the loader, not a mod to be compatible with.
Best regards, Mad
But after a single offline SP Skirmish, the LittleThings.log file was a whopping ~24 MB in size; just looking near the top of the log file has these ominous lines:
[LittleThings @ 7/6/2020 5:50:16 PM] FAILED to override the DebugLevel and/or the LogLocation for Mod: LittleThings[LittleThings @ 7/6/2020 5:50:16 PM] CONTINUING to log in this file with the default LittleThings.DebugLevel: 1
Forgot to add an option to disable debugging, did ya? :p
No, the mentioned output is related to a custom setup on my machine where i override debug settings so i don't need to enable/disable logging all the time when i update the mod. So that's normal... but 24MB is not normal, could you give an excerpt of the contents that follow?
Thx, best regards, Mad
----------------------------------------------------------------------------------------------------[LittleThings @ 7/7/2020 12:07:24 AM] EXCEPTION:
Message: Input string was not in a correct format.<br/>
StackTrace:at System.Number.ParseSingle (System.String value, System.Globalization.NumberStyles options, System.Globalization.NumberFormatInfo numfmt) [0x00083] in <d7ac571ca2d04b2f981d0d886fa067cf>:0
at System.Single.Parse (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00000] in <d7ac571ca2d04b2f981d0d886fa067cf>:0
at System.Single.Parse (System.String s, System.IFormatProvider provider) [0x0000c] in <d7ac571ca2d04b2f981d0d886fa067cf>:0
at LittleThings.Patches.Coil+CombatHUDWeaponSlot_GetWeaponCOILStateColor_Patch.Postfix (BattleTech.UI.CombatHUDWeaponSlot __instance, UnityEngine.Color& __result, UnityEngine.Color fallbackColor) [0x00017] in <e865c8e3334b49f29d9c330ed5cbbea1>:0
----------------------------------------------------------------------------------------------------
I DO make use of the latest GitHub build of Custom Ammo Categories (because it also integrates an up-to-date build of the Attack Improvement Mod), as part of the CustomBundle package.
Let's see if that helps, best regards, Mad
On the one hand, the number of instances of a near-identical error is FAR smaller (only 596 instances, and a log size of ~620 KB), but that was only after a single round of combat.
After the full skirmish, LittleThings.log balooned to multiple megabytes, just not into the double-digit range.
The repeated output is nearly identical:
----------------------------------------------------------------------------------------------------[LittleThings @ 7/7/2020 5:50:42 PM] EXCEPTION:
Message: Input string was not in a correct format.<br/>
StackTrace:at System.Number.ParseSingle (System.String value, System.Globalization.NumberStyles options, System.Globalization.NumberFormatInfo numfmt) [0x00083] in <d7ac571ca2d04b2f981d0d886fa067cf>:0
at System.Single.Parse (System.String s, System.Globalization.NumberStyles style, System.Globalization.NumberFormatInfo info) [0x00000] in <d7ac571ca2d04b2f981d0d886fa067cf>:0
at System.Single.Parse (System.String s, System.IFormatProvider provider) [0x0000c] in <d7ac571ca2d04b2f981d0d886fa067cf>:0
at LittleThings.Patches.Coil+CombatHUDWeaponSlot_ShowTextColor_Patch.Postfix (BattleTech.UI.CombatHUDWeaponSlot __instance, BattleTech.Weapon ___displayedWeapon) [0x0002c] in <3e7808aa0106474c97b567c239c3c15b>:0
----------------------------------------------------------------------------------------------------
https://github.com/mad2342/LittleThings/releases/tag/1.9.1-009R
Just to clarify, the cause of the problem still lies within the custom bundle, i assume AIM does weird stuff to dmg texts in the weapon panel (but the actual source of the bundle isn't accessible so i can't verify). In vanilla there are no logs at all with a loglevel of 1.
Either way i hope the current release can circumvent that problem for you.
Best regards, Mad
I'll check next time i play too.
Best regards, Mad
Temporarily deleting the mod folder immediately took these away; putting it back added them in again, even with the setting on False.
Best regards, Mad
New settings:
"ExpandStatTooltipDurability": true,
"FixInterleavedDropouts": true,
Changed settings:
"AdjustMechPartCostMultiplier": 0.7,
to
"AdjustMechPartCostMultiplier": 0.8,
I don't really know what those differences mean, however.
To mad234269:
Not sure about anyone else but I for one always appreciate a changelog, could that be something you add? Thanks :)
To explain:
- "FixInterleavedDropouts" fixes a vanilla bug with the game leaving/re-entering turn-based mode when convoy extracts (See https://forum.paradoxplaza.com/forum/index.php?threads/battletech-escort-mission-opfor-gets-free-movement-turn-after-ai-trucks-evac.1290586/)
- "ExpandStatTooltipDurability" adds the base stability value of the Chassis to the "Durability"-Tooltips *and* takes into account the BSC of the Anni.
- "AdjustMechPartCostMultiplier" is explained in the Description/Readme.
I updated the desc here on nexus (i tend to forget as github is the dev-friendly place for these kinds of mods)
As for a changelog, yes i agree that a changelog is nice, but i simply cannot maintain changelogs for all of my mods... Not enough time to spare, sry.
Best regards, Mad
-
1
-
2
Jump