Custom comp tick #780
Custom comp tick #780
Conversation
… separate PMComp list that mirrors regular comps
…nstructor, and add error checking if the specified type is not valid
There was a problem hiding this comment.
Looks fine to me.
As mentioned multiple times in comments, there are probably quite a number of things that can be optimized further, and maybe some namings that can be improved.
However without any actual implementations, it's hard to tell properly, and I think it's worth trying out if nothing else.
I agree that we should probably look over the entire hediff tree and clean it up. I moved over most of the main systems to the "new" hediff inheritance tree, but some things remain on the old one and that old one was never removed.
Implementing this will require going over everything else anyway.
|
|
||
| if (_hasComps && comps != null) | ||
| { | ||
| int compCount = comps.Count; // Not caching this genuinely has a noticeable performance impact for hediffs that |
There was a problem hiding this comment.
I am amazed that this would have a noticeable effect considering .Count is
// Read-only property describing how many elements are in the List. public int Count { get { Contract.Ensures(Contract.Result<int>() >= 0); return _size; } }
There was a problem hiding this comment.
The main reason for that is that it's being called several hundred thousand times a second (because it gets called every iteration of the loop, which means once per comp + 1, per hediff, 60 times a second...). I assume that most of the time spent calling it is actually just all the dynamic dispatching overhead rather than the implementation itself.
| for (var index = 0; index < compCount; ++index) | ||
| _pmComps[index]?.TickHour(ref severityAdjustment); | ||
|
|
||
| if (hashOffsetTick % 60000 == 0) // Once an in-game day |
There was a problem hiding this comment.
This could technically be gated behind % 60 checks to only have 2 modulus checks per tick.
There was a problem hiding this comment.
It could, yeah. I figured it was more readable this way, and I haven't tested it to see if the performance matters enough yet.
| // Note that PMComps.CompPostTick() is never called. This is because that method exists only for legacy support. | ||
| // That method cannot be overridden and only does exactly what we're doing here (but slightly less efficiently) | ||
|
|
||
| if (hashOffsetTick % 60 == 0) // Every real-life second |
There was a problem hiding this comment.
The interesting part here to consider is that this is only a real-life second at 1x speed with no lag.
But we could potentially increase delay on higher gameplay speeds and do more interpolation to compensate if we wanted to.
If we go by "Run once every RL tick regardless of game speed and provide a count of how many ticks has past since last call."
There was a problem hiding this comment.
Honestly, I prefer that it be synced to game speed instead of real-life speed. Otherwise we get the possibility of non-deterministic behavior that depends on how fast the game is runs on your machine, which is just a headache.
I can change the comment to clarify that that's only at 1x speed without lag, though.
The initial draft for HediffComps that tick less often than every tick. In order to avoid iterating over the PMComps every tick anyway, I had to split them out into a separate PMComp field in the def.
This draft doesn't include updating any actual comps or hediffs to use the new base classes yet, only base classes themselves.