ID:2061480
 
BYOND Version:510.1327
Operating System:Linux
Web Browser:Chrome 49.0.2623.87
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Server starts to overload after animate is used.
Numbered Steps to Reproduce Problem:
Get ss13 server.
Get 30+ players online.
Use animate on some object with 15-20 overlays on it and 5-10 atoms inside of it.
Code Snippet (if applicable) to Reproduce Problem:
dropped_object.pixel_x = rand(-400, 400)
dropped_object.pixel_z = 1000
animate(dropped_object, pixel_z = 0, pixel_x = 0 , time = 15)


Expected Results:
Animation without significant server load.
Actual Results:
Server CPU usage raises from 70-80 to 140 from single animate.
Does the problem occur:
Every time? Or how often?
Every time when online is 20-30+. No issues with local server with single player on it.
In other games?
Didn't checked.
In other user accounts?
Yes.
On other computers?
Yes.

When does the problem NOT occur?
Occurs everytime.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Did not checked.
Workarounds:
Don't use animate for objects with multiple atoms or overlays on it.
This needs to be retested in a server running the latest version, 510.1334, because the way this kind of thing is handled has changed dramatically. Actually I'm not even sure why you'd see this on a 510.1327 server, because that doesn't use map chunking.

Regardless, if this bug can't be confirmed in a 510.1334 server then it's an old one that's been fixed already.
Thank you for response! After we have 510.1334 live on server i retest it and give you additional feedback.
we actually saw this on /tg/ for another feature on 1323, it seems to relate exclusively around animating pixel_x/y more than the tile size. We had to scrap the feature.

I didn't make a bug report because at the time, 1328 had came out and also because the coder who made it isn't known for the most optimized code.

I'll see if i can't do another test run on the live server to see if it happens in 1334
1327 would have used the pre-chunk system, so the act of animating a large pixel offset may have caused the visible turf bounds for all players to go berserk, expanding (albeit not by a ton) and refreshing their turf maps.
That basically was my conclusion, it would make world.cpu jump ALOT but nothing stood out in profile, and it scaled with player count.

I figured something was happening where too many players were getting more turf updates then they needed because of it
With map chunks I think what you're likely to see is that the obj may show up in their updates if the animation is in range of them, but that should have a very minor impact on the server.