Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug fix and improvements for calculateContractDifficulty() #5064

Merged
merged 1 commit into from
Oct 19, 2024

Conversation

Setsul
Copy link
Contributor

@Setsul Setsul commented Oct 18, 2024

Properly uses average BV across all Meks instead of random ones.
Corrected ally ratio for House command, best guess magic number for Liaison for now.

This should fix the displayed contract difficulty changing semi-randomly when going back and forth between contracts in the contract market, and generally improve the estimate.
This does not yet estimate the difficulty for Liaison command as accurately as it could, but it's better than what we had before and can be improved later.
@IllianiCBT requested mention

Properly uses average BV across all Meks instead of random ones.
Corrected ally ratio for House command, best guess magic number for
Liaison for now.
@codecov-commenter
Copy link

codecov-commenter commented Oct 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 10.43%. Comparing base (0b4d2c4) to head (68bcaaa).
Report is 5 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##             master    #5064   +/-   ##
=========================================
  Coverage     10.42%   10.43%           
- Complexity     6033     6036    +3     
=========================================
  Files           953      953           
  Lines        134106   134121   +15     
  Branches      19434    19437    +3     
=========================================
+ Hits          13986    13990    +4     
- Misses       118772   118781    +9     
- Partials       1348     1350    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

rollingCount += weight;
}

return totalBattleValue / rollingCount;
if (campaign.getCampaignOptions().isUseGenericBattleValue()) {
return ((double) totalBattleValue) / totalGBV;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you be able to explain why we're dividing BV2 by GBV here? I'm not suggesting it's wrong to do so, but I'm trying to get a sense of what returns we're expecting, so I can factor it into my future work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The basic assumption is that difficulty depends on the ratio of player (+allies) BV2 to enemy BV2.
Since FG3 matches GBV it matters less what BV2 the average Mek got, but rather how many points of BV2 it gets per point of GBV.

It's less extreme for the enemies and allies that should be using fairly balanced RATs, but a player achieving an average of ~2500 BV2 per unit entirely with Medium or lighter Clan Meks will face a much weaker OpFor than one achieving the same BV2 average with IS Assault Meks, because the latter gives the OpFor a much larger GBV budget to use.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I can see the logic! :)

To confirm: when we communicate challenge to the player: if I’m displaying half a ‘skull’ per 20% variance between player forces and enemy that will still work with this approach? Or will I need to rethink?

As an illustration, we’re going to be shifting to display skulls as a way of illustrating difficulty. 2.5 skulls would be roughly balanced forces. 2 skulls would have the player force roughly exceed the enemy by about 20%, while 3 skulls would have the enemy power approximately 20% more powerful than the player. And so on, with each half-skull equating to roughly 20% variance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally yes.
For forces with similar weight distribution and therefore similar GBV, the output of the method shouldn't change other than what the bug fix did.
But I have not run the numbers, so I can't say for sure.

I think I understand what you're doing.
0 skulls = 0% of player BV2 (actually up to 10%)
2.5 skulls = 100% (+-10%)
5 skulls = 200%
That seems like a usable range.
Though with the combination of higher tech and higher skill levels, it's entirely possible for an OpFor to go far beyond 200%. I don't think the difference between 300% and 400% would matter, the player should lose either way, but you could use the reciprocal for the upper half of the scale so it covers all possible BV ratios.
As in 3 skulls mean the player's BV2 is 20% lower than the enemy's and so on, with 4.5 skulls meaning around 500% enemy BV (the player having 80% less) and 5 skulls being the same edge case as 0 skulls, one side having 10 or more times the average BV of the other.

That's a design choice though, more granularity in the range that should actually matter vs being able to differentiate between two extremely bad ideas.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, thank you

// TODO estimate the LIAISON ratio by going through each combat lance and
// getting the actual average (G)BV for an allied heavy/assault mek.
double allyRatio = switch (getCommandRights()) {
case INDEPENDENT -> 0; // no allies
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I can see your code I'm getting a much better idea of what you're intending and I think the use of magic numbers here is perfectly reasonable. While I imagine we probably could derive a 'correct' ratio with a bunch of math, that really doesn't seem worth the effort.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I put that in the same category as including salvage or taking the average across all unit types instead of just meks.
Could we? Yes.
Would it be more accurate? Yes.
Would it actually change the difficulty that is displayed? Probably not.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% agree. When you were discussing it on discord I completely misunderstood and thought you were saying that we should use magic numbers instead of determining player power

Copy link
Collaborator

@IllianiCBT IllianiCBT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@IllianiCBT IllianiCBT merged commit 75f7904 into MegaMek:master Oct 19, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants