GSoC Week 5: Regeneration 100
Completing Regeneration
After the basic scheduler for regeneration was in place, the next hurlde was handling regeneration of entities with regenRate
less than 1. The regeneration rate are stored in floats, while health increments happen in longs. So conversion usually meant chopping to integer values. But lots of entities depend on less than one regeneration, especially blocks. The soil block, which is building block for terasology gameplay, has 0.75 regeneration rate. So, something was to be done to handle this case in regeneration.
After some possibilites discussed, it was concluded that a float remainder
should be present in RegenComponent
which tracks the remainder of the regeneration happening.
The Concurrence Problem
A serious issue popped up on testing the pull request having basic Regen Logic. The game crashed after several seconds of client and server attacking each other, throwing a ConcurrentModificationException
. Although initially percieved as a multiplayer issue, it intruded in single player as well. The issue was present whenever more than one regeneration was happening.
All entities’ references which are being regenerated is stored in a sorted map in RegenAuthoriySystem
. I initially suspected the addition of regeneration logic to be the culprit, modifying the map while it is used in regen. I went on that trail for a day, all in vain.
Turns out, modifying a map while iterating through it is itself considered concurrent modification. Multi-threading is not always the cause of that exception. So i added a quick fix for this issue in Pull #10 itself.
Removing Regen Made Easy
The present implementation makes removing particular type of regeneration very easy. All a system has to send is DeactivateRegenEvent(String id)
which removes regeneration “id”.
So, the Regeneration system is now capable of
- Handling base regeneration of entities
- Adding addition regeneration effects to entities, with time of the effect
- Removing only certain kind of regeneration effect
- Disabling all regeneration of an entity
This covers almost all of the points that came up on the discussion on Ideal regeneration system.
Also, this is time when I got a little sick, thereby draining my two days’ time.
Removing Regen Recklessly?
I encountered one more issue in the present system. The regeneration system removes the RegenComponent
when an entity reached full health. But what if it has an active effect of regeneration? The removal of the component implies that all the past regen info is lost immediately, which is not desired.
I implemented a check in the removal process, checking for the state of the component, and removing it only if it has only base regen.
Purging old stuff
My initial plan for regeneration was to have events like RegenerateEvent
, BeforeRegenEvent
and OnRegenEvent
to mark the regeneration process. But adding a scheduler made these events obsolete. So, I removed them. I also updated the test for regeneration to test the scheduler way of regen.
What Next?
With the regeneration now complete, the next task is to create the Restoration Logic of healing. This should take up the whole week. Let’s see…