ID:2839072
 
BYOND Version:515.1596
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 107.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary: When the world is set for LEGACY_MOVEMENT_MODE and a /movable has density and bound_width or bound_height set for a value larger than world.icon_size, calling Enter() on the turf where the oversized /movable is present results in an incorrect return value.

Numbered Steps to Reproduce Problem:
1) Download the following test project: http://files.byondhome.com/Higoten/Tests/ Large%20Bounds%20Enter%20Test.zip
2) Compile and run the project.
3) Click the test() verb.
4) Observe that the attempt to move is expected to fail, however Enter() reports that it will succeed, with the actual attempt to Move() failing due to the dense blockage.

Expected Results: For Enter() to return a value indicating that the turf will or will not block the movement.

Actual Results: When using Enter() on a turf containing a dense /movable with bounds greater than world.icon_size, Enter() returns an incorrect value.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Untested.
In other user accounts? Untested.
On other computers? Untested.

When does the problem NOT occur? The problem does not occur if the bounds variables are set to world.icon_size.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Yes, the issue does not occur in BYOND 512.1435
I'm not quite sure how to handle this. The problem is, the behavior that exists presently might be relied on for some older games, but it's not 100% consistent with the way the reference describes it.

The reference states this:

What actually happens in turf.Enter() is more detailed: Cross() is called for the turf, and if it succeeds (movement is permitted), then Cross() is called for any atoms in turf.contents that cover the entire tile. If any Cross() call fails, Enter() fails too and will return 0.

In this case the obj technically does cover the entire tile, but it covers more than the tile, and because of that it's considered a pixel mover by the legacy code, and does not therefore count inside of Enter().

TBH the behavior as-is is not good. I'm just concerned about how this could impact older games.
I was curious if the age of this bug would be a problem. Just as a spitball idea, perhaps one solution is to change the reference to clearly reflect the current behavior for oversized bounds given the current code treats them as a pixel mover (with density not being taken into account in Enter()). A potential change could involve expressly giving an /movable with oversized bounds the TILE_MOVER appearance flag, with Enter() then being treated as expected in the report above.