Expanded cell specialization effects

[Accidental-Explorer]

Brief Description of What This PR Does

This PR is intended to expand the cell specialisation bonus to affect more than just process speeds.

Currently affects:

• Positive environmental tolerance effects from organelles.
• Storage capacities from organelles.
• Movement speed from organelles (only flagella right now)
• Turning speed from organelles (only cillia right now)
• Digestion speed and efficiency from organelles.
• Toxin fire rate reduction from organelles.
• Auto-evo bonuses to emulate all of the above.

Tooltip on the specilization bonus in the editor still needs to be updated, which I will do once everything else is approved.

Related Issues

• Subjective: cell specialisation only has a smaller indirect benefit for cells specialising in non-process tasks like movement.
• Subjective: cell specialisation can allow you to reduce ATP production parts, but that currently also drops your oxygen tolerance as a side effect if you're using oxygen metabolism.
• Cell specialisation makes the bioluminescent vacuole worse by increasing its ATP consumption without improving its oxygen tolerance benefit. (At least for auto-evo. There is actually a cap on the consumption of luciferin in-gameplay, so the effect is limited there)

Progress Checklist

Note: before starting this checklist the PR should be marked as non-draft.

• PR author has checked that this PR works as intended and doesn't
  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)
• Initial code review passed (this and further items should not be checked by the PR author)
• Functionality is confirmed working by another person (see above checklist link)
• Final code review is passed and code conforms to the
  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.

[Accidental-Explorer]

For anyone seeing that last commit: I just implemented the calculations in the "lowest levels" possible to see everything that would have to be changed to match. So I am aware that it is 100% not efficient yet. Just want to see if I can get it to work yet.

(Also, on the gameplay side I got stuck on EndosymbiontOrganelleSystem/MicrobeReproductionSystem for now)

[hhyyrylainen]

Theoretically it might be faster to restructure this loop so that we loop the species' cell types and calculate the specialization once for each type and then go through all cells that use that type. This way we can save on recalculations of the base efficiency. Though I'm not sure if this would help in any visible way in terms of performance.

[Accidental-Explorer]

If I've learned anything from this latest episode, I think once multicellular auto-evo starts, this will be run a lot, so even a small improvement in speed would mean a lot.

So I was about to do as you said, but then I realised that for the same reason at that point it will probably be faster to pre-calculate the specilization bonuses for cell types the way we do for MicrobeSpecies now? I am not sure if it's still worth it at that point, since we would only save the time of looking up the bonus from the cell type?

[hhyyrylainen]

Theoretically I foresee someone wanting to make the cell adjacency specialization logic a lot more complex, so I do see saving a part of the calculation as beneficial.

Isn't there already saving of the cell type specialization in the cell type? I guess this code might be setup like this to allow easy use from the editor as that would need to dynamically calculate specialization from the edits facade otherwise. So again using the cached info here is possible but needs reviewing all code calling this and adjusting that code to make sure it has calculated up to date specialization for each cell type.

[Accidental-Explorer]

Theoretically I foresee someone wanting to make the cell adjacency specialization logic a lot more complex, so I do see saving a part of the calculation as beneficial.

True, but I thought the change mentioned in this comment chain was about saving time by not re-calculating the cell specialization bonus (not adjacency)? The adjacency would still have to be calculated while looping over all the cells.

Though on that note, I feel like for multicellular auto-evo we might actually also end up wanting to cache the TotalSpecializationBonus (cell specialization) for each cell in the design (so, cellTemplate?) to avoid re-calculating it a dozen times. (for in-gameplay cells, this effectively already happens via the Spawner system of course)

Isn't there already saving of the cell type specialization in the cell type? I guess this code might be setup like this to allow easy use from the editor as that would need to dynamically calculate specialization from the edits facade otherwise. So again using the cached info here is possible but needs reviewing all code calling this and adjusting that code to make sure it has calculated up to date specialization for each cell type.

Yeah, basically using the cached specializationfactor for multicellular cell types in the tolerances would be doing the same thing as I did for microbes in his commit two days ago as part of the auto-evo optimisation: ab71429
, with a side-helping of making sure the cell type specialization bonus really is properly calculated and cached for them in all cases.

[hhyyrylainen]

True, but I thought the change mentioned in this comment chain was about saving time by not re-calculating the cell specialization bonus

Yes, by looping like this it can save calculations

foreach (var type in speciesCellTypes)
{
     var typeSpecialization = ....;

     foreach (var cell in speciesCells)
     {
           if (cell.Type == type)
           {
                    var total = typeSpecialization * GetAdjacencySpecialization(cell, speciesCells);
                   
                     ... do stuff here...
           }
      }
}

with a side-helping of making sure the cell type specialization bonus really is properly calculated and cached for them in all cases.

Yeah, that is kind of the main concern with any cache: making sure the cache is always up to date when used. And the main difficulty in making the switch in code to using a cache.

[Accidental-Explorer]

Most of the code was already there, so I just switched it to use the cached version. And I changed the Multicellular editor to have the finishing the editing of one cell also call RepositionToOrigin (which already included the specialization calculation call) instead of preventing it.

I did it this way because not repositioning to origin did not make sense to me. (You would want to see that in the multicellular part of the editor right away, right?) But if there's a reason it should indeed not be done, I can split out the call to CalculateSpecialization.

(the remaining need for re-calculating the specialization bonus of a celltype will come once we actually start mutating them)

[hhyyrylainen]

I did it this way because not repositioning to origin did not make sense to me. (You would want to see that in the multicellular part of the editor right away, right?) But if there's a reason it should indeed not be done, I can split out the call to CalculateSpecialization.

I didn't check your code. But no. Actually we have to prevent that. Because repositioning before fully exiting the entire editor, will blow up action history. So if a cell type is repositioned to origin in a situation where the player is still in the editor, that will have broken editor history and will cause an error when undoing and redoing changes.

That is why the reposition to origin is deferred until fully exiting the editor.

[Accidental-Explorer]

In that case I will revert it and instead put it in OnFinishEditing.

But I have to say the fact that we don't run RepositionToOrigin within the editor makes this implementation (considering the comment):

Intuitively look a bit dubious to me?

[hhyyrylainen]

That comment is that the cell type does not get told in any other way that it was modified.

So it could do with a bit more context.

Technically yes we do have the code in all of the editors to apply the current edits, but those don't have a special way to let the cell type know that "hey, you've been edited". So that's what the comment is trying to say. Or were you pointing out something else?

[Accidental-Explorer]

No, I think that makes sense to me now, thanks!

I put the calculation call for the specializationbonus in the else statement for if not positioning to origin so it's not calculated double for no reason. I hope that's alright. (I did not want to remove it from Reposition to Origin since it's relied on to do it in other contexts)

[hhyyrylainen]

With my new overall time export I was able to now get some comparisons of the performance.

Here's the latest master data in run mode (no debugger attached):

And here's the results on this branch:

There's a lot more randomness, but the alive species is roughly the same as before though some simulation passes have way fewer species alive at the end. The biggest problem is that the runtimes get extremely long with even the fastest world being slower than the slowest master branch run.

So it seems like auto-evo doesn't really know what to do when the specialization affects everything.

---

I made these graphs by exporting the new "overall_time.csv" file from the auto-evo exploring tool and then imported into LibreOffice to create these scatter plots.

[Accidental-Explorer]

Here's a comparison of the new results:

Separated:

Master:

PR:

[hhyyrylainen]

That does seem pretty good now, right? And so it looks like that problem is now solved.

[Accidental-Explorer]

That does seem pretty good now, right? And so it looks like that problem is now solved.

Yes. Statistically, with this sample size I would not be able to say there is any difference between the two. But if anything, the PR average is slightly faster right now.

But I need to check that that second change did not break anything, particularly for multicellular.

[Accidental-Explorer]

Looks like there is a problem with auto-evo prediction in the editor now that I have to resolve as well.

[Accidental-Explorer]

I was able to avoid the errors by calculating the specialization bonus for the setup of new auto-evo prediction and suggestion rounds.

But I have to say it feels off. Both of these systems appear to be cloning an original species, and those are supposed to have their specilizationbonus calculated already.

[hhyyrylainen]

They only clone the species to work as a base and then apply all the edits made in the editor on top, so it would be totally wrong to just copy the specialization. Instead it has to be recalculated to match the actual applied organelles and other editing state.

[Accidental-Explorer]

Considering the extensive changes since this was test-approved, I'll request another round of testing if and when the code is approved.