space-station-14
space-station-14 copied to clipboard
space-wizards
Refactor hunger and thirst systems
About the PR
The common logic of those systems was moved into new SatiationSystem that serves as the common base for them. Also it introduces an ability to have damage on different satiation (old thirst and hunger) thresholds.
Why / Balance
The old ThirstSystem was almost the same as HungerSystem.
Technical details
The new SatiationSystem operates on new SatiationComponent which was created by merging Thirst and Hunger components together. The data of merged components has been separated by putting it into new data definition Satiation, which is now part of the Satiation component (one Satiation for thirst, and one for hunger)
Thirst and hunger thresholds enum have been merged into new SatiationThreshold, that would be shared between them and future new Thirst/Hunger systems.
Media
- [x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase
Breaking changes
Fields of old Hunger and Thirst components are now accessed through the Thirst and Hunger fields.
Changed the signature of ModifyThirst, now it accepts nullable component as third argument instead of second.
Removed Thirst Hunger specific mentions from field names.
Merged the HungerSystem and ThirstSystem into new SatiationSystem.
Merged the ShowHungerIconsSystem and ShowThirstIconsSystem into ShowSatiationIconsSystem
As side effect of merging HungerComponent and ThirstComponent, new Thirst and Hunger fields in SatiationComponent share default values.
Changelog
:cl:
- tweak: Thirst and hunger systems now share common logic.
Just combine hunger and thirst component as there's a lot of weird code trying to skirt around this.
I think it now looks bit messy, but done.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This looks pretty good, only one problem. I completely rewrote how hunger is handled in newmed... 😅 That being said, It's going to be a bit before newmed is merged so I don't see why this couldn't be used in the meantime since it sounds/looks like a big improvement over the current hunger/thirst system. (I haven't been able to do a code review because github web is fucking completely unusable for reviewing large prs)
Some elements of this could be reused by the newmed hunger/thirst implementation but a lot of this is made redundant by the blood-glucose and fast/slow calorie storage system that newmed uses instead of a more traditional saturation/hunger approach like you went with.
Quick one from me as I don't have time to read the code (sorry): when hacking in the April Fools slugcats I had to bolt on code to the old hunger system to monitor hunger so I could detect when a scug had eaten enough to conclude their prep-for-hibernation target. How event-driven is this system?
Quick one from me as I don't have time to read the code (sorry): when hacking in the April Fools slugcats I had to bolt on code to the old hunger system to monitor hunger so I could detect when a scug had eaten enough to conclude their prep-for-hibernation target. How event-driven is this system?
As all of master code that touched the Hunger/Thirst system just read their value of hunger and thirst respectively, or just checked if it was on specific level I haven't added any events that would notify about changes. But now when you mention that, I see there could be added event for change of the current satiation threshold. If you look for something like this, I will make another PR with it after this one is done.
This looks pretty good, only one problem. I completely rewrote how hunger is handled in newmed... 😅 That being said, It's going to be a bit before newmed is merged so I don't see why this couldn't be used in the meantime since it sounds/looks like a big improvement over the current hunger/thirst system. (I haven't been able to do a code review because github web is fucking completely unusable for reviewing large prs)
Some elements of this could be reused by the newmed hunger/thirst implementation but a lot of this is made redundant by the blood-glucose and fast/slow calorie storage system that newmed uses instead of a more traditional saturation/hunger approach like you went with.
Probably newmed will supersede entirely this satiation system for hunger/thirst, but the system alone should be flexible enough to be able support some other type of constantly decreasing metrics. It would probably require some small changes then - more generic threshold effect handling?
uhh... why does yaml test fails? the UsedSatiation is in UdderComponent
uhh... why does yaml test fails? the
UsedSatiationis inUdderComponent
Datafields are automatically renamed, you need to use usedSatiation in the prototype
This pull request has conflicts, please resolve those before we can evaluate the pull request.
