-
-
Notifications
You must be signed in to change notification settings - Fork 507
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
Oxygen and Carbon Dioxide Rebalance #5693
base: master
Are you sure you want to change the base?
Conversation
@@ -32,6 +33,8 @@ private void ApplyVolcanism() | |||
{ | |||
foreach (var patchKeyValue in targetWorld.Map.Patches) | |||
{ | |||
GD.Print(patchKeyValue.Value + " volcanism"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like leftover debugging code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I knew I forgot something!
I want to make a future PR doing the diffusion better, but right now I think this is good enough for surface patches. Would appreciate lots of testing, since that gets very time-intensive. |
@@ -27,14 +26,12 @@ public void OnTimePassed(double elapsed, double totalTimePassed) | |||
HandlePatchCompoundDiffusion(); | |||
} | |||
|
|||
private static (float Ambient, float Density) CalculateWantedMoveAmounts(Patch sourcePatch, Patch adjacent, | |||
private static (float Ambient, float Density) CalculateWantedMoveAmounts(Patch adjacent, | |||
KeyValuePair<Compound, BiomeCompoundProperties> compound) | |||
{ | |||
// Apply patch distance to diminish how much to move (to make ocean bottoms receive less surface | |||
// resources like oxygen) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this comment now incorrect?
// TODO: improve the formula here as sqrt isn't the best | ||
float moveModifier = Constants.COMPOUND_DIFFUSE_BASE_MOVE_AMOUNT / | ||
MathF.Sqrt(Constants.COMPOUND_DIFFUSE_BASE_DISTANCE + Math.Abs(sourcePatch.Depth[0] - adjacent.Depth[0])); | ||
float moveModifier = Constants.COMPOUND_DIFFUSE_BASE_MOVE_AMOUNT; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just using a flat modifier here makes it so that there's nothing preventing oxygen from going to the deepest ocean very fast now, which is one of the major reasons I added the distance modifier. Maybe instead we could rewrite the code to only use the distance modifier if the distance is like at least 500?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number of patches between the epipelagic and sea floor already do that pretty well, but based on my quick research even that isn't accurate. As Buckly mentioned in the last Thrivestream, oxygen is actually pretty well spread in the modern oceans: https://en.wikipedia.org/wiki/Oxygen_minimum_zone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on what I'm seeing, Oxygen in the bathypelagic or abyssopelagic should be around a third of the surface, while in this current code it's more like a tenth at best
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I have to accept that as much as I think that will lead to players submitting bug reports I have to then read (as I'm almost the only one dealing with bug reports)... Though the comment that was left above is then obviously incorrect as it no longer related to the changed code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on what I'm seeing, Oxygen in the bathypelagic or abyssopelagic should be around a third of the surface, while in this current code it's more like a tenth at best
That's probably a fair compromise to try to aim for that with the algorithm. I'm not good at coming up with math functions that do what I want so I had to settle on the square root usage here and call it good enough.
{ | ||
if (co2Out == 0) | ||
{ | ||
// in the rare event we aren't making either compound, do nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But now consuming the compounds also doesn't do anything? I think this is a wrong conclusion to make in the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct. If microbes had only bio processes that destroyed O2 or CO2 without producing anything in return, this code doesn't account for that. Right now the PhotosynthesisProductionEffect class is dependent on the special case of conservation of mass (and that CO2 and O2 are only being converted into each other)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code shouldn't depend on that then as someone will make a mod eventually that breaks the laws of physics and will get confused why it doesn't do things correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, I've modified the code to handle matter sinks, and while a matter generator will result in absurd numbers, I've protected against divide-by-zero exceptions.
|
||
if (co2Balance != 0) | ||
changesToApply[Compound.Carbondioxide] = co2Balance; | ||
changesToApply[Compound.Oxygen] = (oxygenTarget - existingOxygen.Ambient) / 2.0f; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more efficient to multiply by 0.5f than to do a float division.
} | ||
else | ||
{ | ||
oxygenTarget = oxygenOut / (oxygenIn + co2In) * total; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment here explaining the logic? I don't really understand this kind of scaling because ApplyLongTermCompoundChanges already does a relative applying of gases. So higher oxygen output reduces the effect of the co2 adding and vice versa. So to me it looks like this is now doing the same effect twice, which doesn't logically make a ton of sense as ApplyLongTermCompoundChanges needs to be given the absolute change wanted and then it automatically makes gases related to each other and caps it to a 100%.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair. Rather than explain here, I will add the comment and see if the explanation makes sense to you.
Brief Description of What This PR Does
Balances O2 and CO2 more tightly in the special case of that (mostly) closed loop between them. Also simplifies the diffusion simulation to let those compounds spread a little more, and modifies the auto-evo to make photosynthesisers more common to allow for more oxygen in the first place.
Related Issues
Progress Checklist
Note: before starting this checklist the PR should be marked as non-draft.
break existing features:
https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
(this is important as to not waste the time of Thrive team
members reviewing this PR)
styleguide.
Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.