• 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.
For all whose wonder, here is the exact formula, thanks to Denadan's kindness:
Code:
public static void CalculateCBillValue(MechDef mechDef, ref float currentValue, ref float maxValue)
{
    currentValue = (float)mechDef.Chassis.Description.Cost;
    float num = 10000f;
    float num2 = 0f;
    num2 += mechDef.Head.AssignedArmor;
    num2 += mechDef.CenterTorso.AssignedArmor;
    num2 += mechDef.CenterTorso.AssignedRearArmor;
    num2 += mechDef.LeftTorso.AssignedArmor;
    num2 += mechDef.LeftTorso.AssignedRearArmor;
    num2 += mechDef.RightTorso.AssignedArmor;
    num2 += mechDef.RightTorso.AssignedRearArmor;
    num2 += mechDef.LeftArm.AssignedArmor;
    num2 += mechDef.RightArm.AssignedArmor;
    num2 += mechDef.LeftLeg.AssignedArmor;
    num2 += mechDef.RightLeg.AssignedArmor;
    num2 *= UnityGameInstance.BattleTechGame.MechStatisticsConstants.CBILLS_PER_ARMOR_POINT;
    currentValue += num2;
    for (int i = 0; i < mechDef.Inventory.Length; i++)
    {
        MechComponentRef mechComponentRef = mechDef.Inventory[i];
        currentValue += (float)mechComponentRef.Def.Description.Cost;
    }
    currentValue = Mathf.Round(currentValue / num) * num;
}

In short - it takes value from mechdef, sums all the armor points and multiplies by CBILL_PER_ARMOR_POINT, and then adds cost of all equipped stuff. Just as suspected, but these code is a hard and ultimate proof.

Excellent investigation job!

However I think we are still missing some variable in the formulas as, according to the shown code lines the Highlander HGN-732b's standard (i.e. 100%) purchase price should be 16.820.000 C-Bill, while both the following screenshots seem to point to a much higher inferred standard purchase price of 21.960.000 C-Bills, courtesy respectively of

@Shameless:
upload_2019-6-4_17-34-58.png


and @Wayward Son 5:
upload_2019-6-4_17-35-23.png


There seem to be some kind of consistency in the Highlander HGN-732b’ purchase price, i.e.:
20.682.000*100/95=21.960.000 C-Bills
19.764.000*100/90=21.960.000 C-Bills

Moreover, even this slim consistency (i.e. the Highlander HGN-732B’s inferred 100% price as of 21.960.000 C-Bills) seems to be completely wrong whenever compared to the adjusted Highlander HGN-732B’s inferred 100% price based on the 10.000% price increase reputation due to being loathed by Pirates at -100 Reputation with them, shown in the following screenshot, courtesy of a fellow MechWarrior whose call-sign I currently don’t remember, i.e.: 2.147.483.648/10.000%*100%=21.474.836 C-Bills:
upload_2019-6-4_17-36-41.png
 
However I think we are still missing some variable in the formulas as, according to the shown code lines the Highlander HGN-732b's standard (i.e. 100%) purchase price should be 16.820.000 C-Bill, while both the following screenshots seem to point to a much higher inferred standard purchase price of 21.960.000 C-Bills, courtesy respectively of
Doesn't reputation with the selling faction impact sale price?
 
For all whose wonder, here is the exact formula, thanks to Denadan's kindness:
Code:
public static void CalculateCBillValue(MechDef mechDef, ref float currentValue, ref float maxValue)
{
    currentValue = (float)mechDef.Chassis.Description.Cost;
    float num = 10000f;
    float num2 = 0f;
    num2 += mechDef.Head.AssignedArmor;
    num2 += mechDef.CenterTorso.AssignedArmor;
    num2 += mechDef.CenterTorso.AssignedRearArmor;
    num2 += mechDef.LeftTorso.AssignedArmor;
    num2 += mechDef.LeftTorso.AssignedRearArmor;
    num2 += mechDef.RightTorso.AssignedArmor;
    num2 += mechDef.RightTorso.AssignedRearArmor;
    num2 += mechDef.LeftArm.AssignedArmor;
    num2 += mechDef.RightArm.AssignedArmor;
    num2 += mechDef.LeftLeg.AssignedArmor;
    num2 += mechDef.RightLeg.AssignedArmor;
    num2 *= UnityGameInstance.BattleTechGame.MechStatisticsConstants.CBILLS_PER_ARMOR_POINT;
    currentValue += num2;
    for (int i = 0; i < mechDef.Inventory.Length; i++)
    {
        MechComponentRef mechComponentRef = mechDef.Inventory[i];
        currentValue += (float)mechComponentRef.Def.Description.Cost;
    }
    currentValue = Mathf.Round(currentValue / num) * num;
}

In short - it takes value from mechdef, sums all the armor points and multiplies by CBILL_PER_ARMOR_POINT, and then adds cost of all equipped stuff. Just as suspected, but these code is a hard and ultimate proof.

So, it is basically :

(Total Armor Points * Armor Per Point Cost) + chassis cost + each weapon cost rounded to the nearest ten thousand ?

Next question - how do we figure the base chassis cost ? :D
 
So, it is basically :

(Total Armor Points * Armor Per Point Cost) + chassis cost + each weapon cost rounded to the nearest ten thousand ?
Yep, indeed.

Next question - how do we figure the base chassis cost ? :D
From chassisdef_<mechname>.json data file:
Code:
    "Description" : {
        "Cost" : 3600000,
        "Rarity" : 1,
        "Purchasable" : true,
        "Manufacturer" : "",
        "Model" : "",
        "UIName" : "Hatchetman",
        "Id" : "chassisdef_hatchetman_HCT-3X",
        "Name" : "Hatchetman",
        "Details" : "The Hatchetman -3X further indexes on the stock design's close combat role, adding more armor and replacing its AC10 for an array of SRMs, Lasers, and Anti-Personnel weapons. This is the ultimate melee brawler.",
        "Icon" : "uixTxrIcon_hatchetman"
    },
 
@MasterBLB - Heh, let me rephrase that question (though you did answer it accurately to what I asked ;) )

How do they arrive at that base Chassis cost value?

So, if I want to port in the Raven 1X, what is that base Chassis?

When I look at the (3) Locust variants, they all have different Chassis Values.

The 1M and 1S are very similar in Hardpoints

S has:
  • RA/LA : 2 Missiles each
  • CT : 1 Energy & 1 AP
  • Cost 1,800,000
  • Armor : 240
M has:
  • RA/LA : 1 Missile each
  • CT : 1 Energy & 2 AP
  • Cost 1,700,000
  • Armor : 80
V has :
  • RA/LA : 1 Ballistic & 1 AP each
  • CT : 1 Energy & 1 AP
  • Cost 1,600,000
  • Armor : 320
Let's look at the S v M first

Arguably, it would be rare that the 1S would even fill those 4 Missile Hardpoints, instead just upgrading the version of the SRM or LRM on each arm. So the 1M is a superior 'Mech at a better price (as it could realistically mount 1 more AP weapon over the 1S). So, for an extra Missile hardpoint in each arm and 1 less AP in the CT, you pay 100,000 more

Now if we remove the common variables (the 1 Energy & 1 AP on each), that leaves us with

S:
  • 4 Missile

M:
  • 2 Missile & 1 AP

V:
  • 2 Ballistic & 2 AP

So, it isn't just pure # of hardpoints, as the S and V both have 4. So there must be values based on the type or location of HPs.
 
In short - it takes value from mechdef, sums all the armor points and multiplies by CBILL_PER_ARMOR_POINT, and then adds cost of all equipped stuff. Just as suspected, but these code is a hard and ultimate proof.
Hmm... I wonder if the value listed in the mechdef is being used at all... or only for skirmish. In the beta, I found that the mechdef value didn't match up exactly with the chassisdef value + component values, and the discrepancy only made sense if the mechdef values had been computed from chassisdef values BEFORE they had gotten rounded off. That routine only has access to the game files, which obviously are after rounding off... so if that routine is being used for the value of stock mechs in shops, the mechdef values could end up different from the shop price by the amount of rounding.

(And hopefully it's possible to follow that, 'cuz I'm done re-wording it regardless. ;))
 
Hey all, been a long while since I've posted on here. I'm the (crazed?) person that cooked up our internal sheets that we use for calculating value for 'Mechs etc. I'll see what I can do about making an example copy available for you to look at - it's a bit tricky because it's not a single sheet but a networked set of sheets that reference engine values, weapon values, constants, etc. that works via ID references in Google Drive. If that proves too difficult, I'll see if I could spend some time to write a more thorough description of this process (the steps are fairly involved).

On a broader note though, your suppositions are correct. The core chassis is constructed mostly using the TT construction rules but with different cost tunings that I felt made certain outlier 'Mechs more balanced. Chassis costs are then further varied based on the type and number of hardpoints, with each hardpoint having a different weighting calculation. There's a fair amount of rounding that happens throughout since we decided on a UX level that we didn't want to deal with significant numbers of less than $100k c-bills.
 
Moreover, even this slim consistency (i.e. the Highlander HGN-732B’s inferred 100% price as of 21.960.000 C-Bills) seems to be completely wrong whenever compared to the adjusted Highlander HGN-732B’s inferred 100% price based on the 10.000% price increase reputation due to being loathed by Pirates at -100 Reputation with them, shown in the following screenshot, courtesy of a fellow MechWarrior whose call-sign I currently don’t remember, i.e.: 2.147.483.648/10.000%*100%=21.474.836 C-Bills:
View attachment 486993
2,147,483,647 is the maximum value for a 32bit signed integer. The price is hitting the integer limit and rolling over as a maxed negative value. I wouldn't infer anything from it.
 
2,147,483,647 is the maximum value for a 32bit signed integer. The price is hitting the integer limit and rolling over as a maxed negative value. I wouldn't infer anything from it.
Thanks for the tip, @Timaeus , I appreciate it very much!
This might mean that, at least with reference to the Highlander HGN-732b, its 100% purchase Prince inferred from its 90% and 95% purchase prices might indeed be correct, apparently.
 
Hey all, been a long while since I've posted on here. I'm the (crazed?) person that cooked up our internal sheets that we use for calculating value for 'Mechs etc. I'll see what I can do about making an example copy available for you to look at - it's a bit tricky because it's not a single sheet but a networked set of sheets that reference engine values, weapon values, constants, etc. that works via ID references in Google Drive. If that proves too difficult, I'll see if I could spend some time to write a more thorough description of this process (the steps are fairly involved).

On a broader note though, your suppositions are correct. The core chassis is constructed mostly using the TT construction rules but with different cost tunings that I felt made certain outlier 'Mechs more balanced. Chassis costs are then further varied based on the type and number of hardpoints, with each hardpoint having a different weighting calculation. There's a fair amount of rounding that happens throughout since we decided on a UX level that we didn't want to deal with significant numbers of less than $100k c-bills.

That would be awesome to get some insight on that, and thank you (in advance) for your help on this @HBS_RedMenace !
 
Just an update on this: I've got a sheet cleaned up for public consumption but need to run it through the proper distribution channels. Wanted to let you know I hadn't forgotten about this ;)
 
Dear @HBS_RedMenace , how about a solution based on available to us .jsons only? Is it possible?

The sheets I'm wanting to give you can be inspected to see the sets of formulas and steps used to create the final value, and then you can adapt that knowledge to whatever form you like. There's no in-game code-math that's currently happening to determine the cost dynamically; chassis are static and defined by this sheet and then exported into the game, so I figured this would be the most useful?
 
The sheets I'm wanting to give you can be inspected to see the sets of formulas and steps used to create the final value, and then you can adapt that knowledge to whatever form you like. There's no in-game code-math that's currently happening to determine the cost dynamically; chassis are static and defined by this sheet and then exported into the game, so I figured this would be the most useful?
Any bit of knowledge is valuable.
 
@HBS_RedMenace - For me, that would be perfect :D Thank you!
Absolutely.

I was perfectly willing to take another stab at reverse-engineering it... but since we can't generate new mechs and see what cost they end up with, the odds of there just not being enough information to figure it out were always extremely high.
 
Any bit of knowledge is valuable.


Absolutely.

I was perfectly willing to take another stab at reverse-engineering it... but since we can't generate new mechs and see what cost they end up with, the odds of there just not being enough information to figure it out were always extremely high.

I was trying to figure it out using algebra on the 3 Locust variants and limiting the variables. But it was still driving me nuts...
 
Dev data
Hey folks, sorry about the delay. This opened up a broader conversation about how we might best share info with modders going forward, it needed to run through our proper IT channels, etc.

For now there's now a temporary "Modding Support" folder with shared link access here: https://drive.google.com/open?id=1vr6gO8IYSsRm0-fYGCF0VXwm6q5lgbE1

Inside you'll find two Google Sheets documents that connect to each other and should show the formulas used for chassis calculations that you can backwards engineer to see the totality of the process. If you've got any questions I'm happy to help answer them! The sheet should be up to date as of the 1.6 / Urban Warfare release (and even helped me spot a few bugs as I was cleaning it up for you).

Note: this doesn't currently list the part cost that is reflected in the campaign play, nor the value of the fully-equipped 'Mech. This is a product of Base Chassis Value + (Weapons Value + Equipment Value + Armor Value).
 

Good to know...And knowing is half the battle!
(the other 25% is Blue Lasers, and the remaining 25% is Red Lasers)



P.S. Maybe I should start calling libraries, 'Ammunition Dumps' :p