Currently bound_x, bound_y, bound_width, bound_height, step_x, step_y, and step_size are all atom/movable member variables.
It would be nice to be able to have full control over the pixel perfect positions and bounding boxes of all atoms, including those that will never move. In order to achieve this, all variables listed above, other than step_size, should be member variables of atom as opposed to atom/movable.
ID:2418479
 Dec 27 2018, 11:09 am
|
|||||||
| |||||||
I actually ran into this issue with how I set up Paradoxus, I worked around it but it would be GREAT if /turf had pixel_x/y and step_x/y for completeness.
| |
They'd just shift the graphic over and leave a black tile behind beneath it. There's not going to be anything underneath it, the underlays would be shifted too.
| |
Kozuma3 wrote:
I actually ran into this issue with how I set up Paradoxus, I worked around it but it would be GREAT if /turf had pixel_x/y and step_x/y for completeness. /turfs do have the pixel_x/y/w/z vars. That's usually how I set up hex grids. As to the OP, I can see a use for the bound vars on turfs. Partially non-dense tiles, forcefields around tiles, etc. It could all be done other ways, but I can see the usage. The step vars would not really make sense, as they help define an atom/movable's position within a turf. | |
You definitely make a good point about step_x and step_y not really having a purpose right now if they were available to turfs and I'll come back to that but I want to talk about bounding boxes first because I fully disagree that bounding boxes would not be useful for turfs and areas.
After doing some forum diving on the subject I found a post that's very relevant to my feature request that you yourself actually participated in a few years back. http://www.byond.com/forum/?post=1999512 My request was made with essentially the same scenario in mind as the OP of that thread presented. Since objs are so expensive due to being movables, it makes little sense to use them for terrain that shows up often but won't ever move. Ter13 provides a nice workaround as a response to the post but it only saves on rendering costs while coming with the cost of losing the ability to use dense areas for anything but that work around. If it wouldn't come at too much of a cost to all turf performance, turfs should have re-sizable bounding boxes. If it would come at an increased cost an alternative I think worth considering is bringing in a new type such as an official implementation of Ter13's static_obj or maybe a subtype of turf. As of 512, Cross/Uncross/Crossed/Uncrossed are now atom procs instead of just movable procs, turf.Enter() first calls turf.Cross(). My request would expand on 512's update. Instead of turf.Enter() immediately calling turf.Cross(), turf.Enter() would only call turf.Cross() if the bounding box of the atom attempting to cross intersects the turf's bounding box. Same idea for areas and the other movement related procs. With this additional bounding box check, the scenario presented by the OP in the post linked would be fully supported. In addition to supporting that idea, Cross() would still be called on tile-based contents which takes care of the specific situation where the entering atom is not intersecting the turf's bounding box but it may be intersecting the bounding box of an atom in the turf's contents. To summarize bounding boxes, what we get in the end of what I've suggested is a decoupling between a turf's (or area's) contents list and movement calculations. A movable can be physically positioned within a turf's tile, and therefore within it's content list, but that movable may still not necessarily be able to move through the turf's bounding box once the bounding box is collided with. This decoupling allows for much more variety when it comes to interaction with turfs and areas. Bounding boxes are definitely the highlight of this feature request, step_x and step_y are less useful but there is some thought behind why I threw them in as well. With regards to turfs specifically, step_x and step_y are not currently useful, but they could be. Stackable turfs that don't just behave as underlays have been discussed in the past. One place these vars would be useful is if combined with that potential feature. For areas, step_x and step_y would be immediately useful just because they would give the ability to make an area's coverage pixel precise instead of stuck to whatever world.icon_size is defined as. To go even further additional area.width and area.height vars could be implemented and all of a sudden areas have limitless coverage flexibility. It's true that creating higher complexity area shapes means higher overhead on area calculations, but finding a good balance between area complexity and cost is something the game programmer can deal with. Areas have a lot of potential utility as an organizational structure in all sorts of gameplay systems. In SS13 they've been used for atmospheric, electrical, and lighting systems to name a few. If it's not a massive rewrite to the engine to implement, step_x and step_y for areas (and preferably width and height vars too) are worth it because they just gives us more control over an already very useful tool. | |
If you need something on a tile to have pixel-precise bounding and whatnot, use an obj.