Slimefun4
Slimefun4 copied to clipboard
Cumulative Armor-Scheduling changes (Rainbow Armor + Radiation update)
This is a cumulative pull requests consisting of:
- [x] #3059
- [x] #3131
Your Pull Request was automatically labelled as: "🎈 Feature" Thank you for contributing to this project! ❤️
After the new radiation system was added, armor-update-interval
(which is in seconds) causes delayed application of the hazmat suit, which would result in you getting up to 10 seconds without it applying.
Should this delay be reduced, and if done how?
We have four options:
- Not do it at all
- Do it, and ask users to change it down to one/two
- Do it, and convert
armor-update-interval
to ticks which would give a 0.5s update interval, along withradiation-update-interval
also being converted to ticks and being set to 20. - Do a config update converting 10 to 1, somehow.
After the new radiation system was added,
armor-update-interval
(which is in seconds) causes delayed application of the hazmat suit, which would result in you getting up to 10 seconds without it applying. Should this delay be reduced, and if done how? We have four options:
- Not do it at all
- Do it, and ask users to change it down to one/two
- Do it, and convert
armor-update-interval
to ticks which would give a 0.5s update interval, along withradiation-update-interval
also being converted to ticks and being set to 20.- Do a config update converting 10 to 1, somehow.
I am not quite sure I understand what you mean
I am not quite sure I understand what you mean
Essentially after the update this was how radiation applied (1 line = 1 second):
radiation !
radiation !
radiation !
radiation !
radiation !
radiation !
radiation !
radiation !
radiation !
radiation armortask
...
and, if you wear a hazmat suit, it won't take effect until the next armortask
I see, perhaps the "armor update" should be moved to the super class then, we could implement a "minimum delay" to reduce redundant runs then. In other words, every one of the "armor" tasks triggers an update to the cached armor but updates will be skipped if the last update has been less than x ticks ago.
I see, perhaps the "armor update" should be moved to the super class then, we could implement a "minimum delay" to reduce redundant runs then. In other words, every one of the "armor" tasks triggers an update to the cached armor but updates will be skipped if the last update has been less than x ticks ago.
Looks good to me. I'll PR in my other changes.
Formatting will need to be checked, see #3293 I messed up a couple things, will see if I can fix them but just in case I am putting a comment in
Handled in #3892