ID:2361667
 
Not a bug
BYOND Version:511
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 65.0.3325.181
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary: After doing way too much icon operations (scaling, shifting with wrap), the game will end up crashing. (Dream seeker has stopped working)

Numbered Steps to Reproduce Problem: (from code snippet)
1. Start game
2. Wait a while
3. After a while, Crash (dream seeker has stopped working)


Code Snippet (if applicable) to Reproduce Problem: https://cdn.discordapp.com/attachments/408435510021718016/ 434509201516265492/crashbug.rar

This is the rar file (Open with winrar) with the source you can use and see how it crashes after a few seconds.

Expected Results:
Moving backgrounds.


Actual Results:
Moving backgrounds, but game crashes after 40/60 seconds.


Does the problem occur:
Every time? Or how often? Every time
In other games? I don't think other games handle backgrounds the same way.
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur? When no icon operations are done in excess.

Workarounds:
Not do icon operations in excess?

This was likely fixed in one of the recent 512 updates. A problem was identified with client-side icon operations. Have you tested this on the latest beta (512.1421)?
No, I will test now.
Still crashing.
Okay, good to know. I'll take a look at your test case on Monday and see if anything is amiss.

There may of course simply be a point where doing way, way too many operations is bound to cause an issue. Icon operations should be done judiciously, always, and most things that used to require them now can be handled way more easily with color, transform, and appearance_flags.
Lummox JR resolved issue (Not a bug)
Closing this as a non-bug. You're doing operations at an incredibly fast rate on a very large icon, and that's why the crash is happening.

A single frame in a regular 32x32 icon, not counting incidental structural stuff, takes up 4K. This icon is 256x256, so each frame is 512K or half a megabyte. 60 of these per second means 30M per second not counting overhead. Except you have six of these, so it's 180M per second. You're simply massively overwhelming DS's ability to cope, long before the garbage collector kicks in. Also, changing an icon incrementally instead of working from the original is always a bad idea, so this shift-shift-shift instead of doing one shift at a time is making things worse.

I would suggest tiling these objects onto a plane master, with overlays to make them 2x2, and applying transforms so you can get the best result. In fact using animate() will give you even better results, since you don't have to make changes server-side and send them to the client every tick.
Is there any chance to customize the garbage collector? Are we getting options for it in the future?
Trying to make the garbage collector operate that fast has never worked out well. You're simply overloading the system with way too many icons. Even if the garbage collector operated at peak possible efficiency and was shedding icons as fast as you made them so memory never crossed too far above a certain threshold, you'd still be blowing the limits of the cache.

Basically the effect you're doing should under no circumstances be done with icon math. You should be figuring out a way to animate instead. Which you can do, by tiling the fog objects (you can add overlays to do the tiling) and using animate() judiciously. It's not easy to setup the animations but it is doable with parallel animations.

The animation would work like this:

0) X and Y offsets in the transform have to be done separately, with parallel animations.
1) Choose a starting point (p0) for one of those vars, and a velocity (v).
2) Depending on whether v is positive or not, animate to p1=256 (v is positive) or p1=0 (v is negative) with a time of abs((p1-p0)/v) * world.tick_lag. I chose 256 because that's your icon size. Start the animation with the parallel flag.
3) p2 is either 0 or 256, whichever p1 is not. Animate to p2 with time=0 as a second step.
4) Now animate a third step, from p2 back to p0, with a time of abs((p2-p0)/v) * world.tick_lag.

The value you're animating is not pixel_x/y but the translation component of a transform.
It sounds like he's uncovered a race condition thats being covered up instead of being addressed.

In response to MrStonedOne
No race condition; he's simply blowing through the memory at a prodigious rate. The garbage collector is set to go off every so often and it can do so a little more often as needed, but every attempt to make it directly sensitive to memory issues has basically blown up. There's only so fast the garbage collector can operate before it causes problems.

It's basically impossible for a well-behaved game to crash in the spectacularly quick way his example does, and trying to make the garbage collection handle it would, if it worked, only forestall a bigger problem with the cache later on because dynamic cache files live as long as the server does.

That said, I grant that a graceful disconnect and close rather than a complete crash would be better.