ID:2933827
 
Applies to:
Status: Open

Issue hasn't been assigned a status value.
The Problem

It would be very helpful if there was a convenient way to only alter the visual_bounds for an atom. The use case for this would be for any map_format, but it is obviously most useful for SIDE_MAP.

There are certain cases where you may want an atom's bounding box to operate differently for simple travel or movement. For example, if I want the bounding boxes to only be around the character's feet (let us say it is 16 x 16) so that they can feasibly overlap with walls, or other props.

If I then wanted to have collision for combat effect characters as if they were taking up an entire tile, I would need a secondary collider object that I keep on the character at all times.

This is inefficient as it induces unnecessary overhead.

The Solution

New Variables

To resolve the issue, I would ask that you provide the following new variables and functions.


vis_bound_width: This would be how you set the visual width. By default, it should equal bound_width.

vis_bound_height: This would be how you set the visual height. By default, it should equal your bound_height.

collision_flag: This would be a flag under the /atom type that would allow you to determine what set of bounds were used for BYOND's internal collision checks. This defaults to BOUNDARY_COLLISION, which would be for the current bound_height/width collision.

The other option would be VISUAL_COLLISION. This way you could set certain props operate only based on your visuals -- say if you wanted to be able to overlap with walls. Then for projectiles or other obstacles, you could make it operate based on what your physical bounds.

Collision Changes

To ensure that this change works with Move(), there would need to be some modest changes to collision detection.

By default, Move() does what it does already and simply checks for your bound_width/height (offset by bound_x/y ofc) compared to another object's bound_width/height to determine if Cross/Crossed/Bump/Bumped are being called.

With this change, we'd need to add two argument to the Move() protocol: atom_bound, target_bound.

atom_bound - This obviously determines the moving atom's collision options. Always uses the atom's collision_flag as a default. The move would explicitly be changed to a different value if the programmer desired.

target_bound - This determines if the moving atom is checking for visual bounds, or physical bounds. Likewise, it inherently works based on the atom's collision_flag set.


Closing

This request was all over the place. I should clean it up later. Hopefully this is feasible.