New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slightly optimize shroom spreading code #53652
Conversation
if(spreadsIntoAdjacent || !locate(/obj/structure/glowshroom) in view(1,earth)) | ||
possibleLocs += earth | ||
CHECK_TICK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will note I have removed this.
If this causes server lag I will delete glowshrooms
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
based
faabdc0
to
78e309a
Compare
We did a number of things here, first we collect the potential turfs for the view call in a single pass, not once per yield run. Second we dont' run a second view(1) on every single potential turf, instead we try to randomly pick a turf 3 times during yield phase and check the view then. If we fail to find a potential location then we bail out of that yield phase. This is a tradeoff between processing time spent finding locations and the chance that the glowshroom fails to spread Finally, we have maximum limit on how many times a glowshroom fails to spread, if it fails to spread at least 5 times over any iteration, it stops processing completely. As a bonus, the timers have been made unique, so we don't accidentally generate multiple timers for a single shroom, other than the two it already needs. This code would benefit from being a seperate subsystem and grouping, generations of the plants together as a single ticking entity and just spreading from selected edge plants. However I don't particularly feel like plumbing that together, so this will suit for now.
78e309a
to
a261434
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks fine, improvements are reasonable, worked in testing
There were some recent lag events on the servers caused by the timer subsystem jamming
up with glowshroom timers. I whined about this but nobody did anything so
There are a few changes here, first we collect the potential turfs for
the view call in a single pass, not once per yield run.
Second we dont' run a second view(1) on every single potential turf,
instead we try to randomly pick a turf 3 times during yield phase and
check the view then.
If we fail to find a potential location then we bail out of that yield
phase. This is a tradeoff between processing time spent finding
locations and the chance that the glowshroom fails to spread
Finally, we have maximum limit on how many times a glowshroom fails to
spread, if it fails to spread at least 5 times over any iteration, it
stops processing for spread completely.
As a bonus, the timers have been made unique, so we don't accidentally
generate multiple timers for a single shroom, other than the two it
already needs.
This code would benefit from being a seperate subsystem and grouping,
generations of the plants together as a single ticking entity and just
spreading from selected edge plants. However I don't particularly feel
like plumbing that together, so this will suit for now.