Conversation
|
Please accept this pull request once it's in a state you're happy with. This change would be huge for most players- lots of us draw the same thing tick after tick, so we're just wasting CPU and network usage on your end when we regenerate the visuals each tick. With this upgrade people will still be able to draw each tick if they want, since any tick that writes visuals will overwrite previous ones, but it will also let people such as myself only redraw every 20 ticks and will save a ton of CPU. |
|
It would be nice if there were an argument or flag to enable this sticky behavior, I currently rely on visuals only lasting a single tick as they usually reflect the things that happened in that tick. Having them persist would be a problem. I don't necessarily write new visuals every tick. Just ignore if i'm misunderstanding what this does. |
|
@bonzaiferroni - if you send new visuals (any at all) during a tick those visuals will clear out any cached ones. The only time this pull request would take effect is if you did not add more visuals on a tick. |
|
like I said, I don't necessarily write new visuals every tick, and a lot of my visuals are giving information that is only valid during that tick. An example would be an overlay of a flee matrix. I suppose it wouldn't be a big deal though to write a single visual on a tick to clear the sticky. On the flip side, in the situations where I do want to maintain a visual it would be nice to not write the extra logic, so I think I'd grow to appreciate that too. |
|
It should be fairly easy to add a function to flag sticky, maybe |
This removes gametime from visuals redis keys and multiplies the timeout for visuals by config.visualCacheTicks (Set to 20).
This allows visuals to be 'sticky' after rendering, reducing CPU usage by not having to render visuals every tick.
Companion PR for backend at screeps/backend-local#7