ID:1058934
 
Keywords: border, bounding, box, color
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Right now, we have several procs that involve the size of, and distance between bounding boxes, but what if we want to actually see a bounding box?

We would have to make an overlay object, take the map coordinates of the bounding box, plug those coordinates into some icon transformation proc, like DrawBox() or Scale(), offset the /icon objects by the right number of pixels, and delete or create them on the fly as the mob moves around. You would have to figure out how to code all of that, while hoping that it actually works at any reasonable speed (most likely not).

This is why I want to suggest creating a proc that is specifically designed for coloring bounding boxes.

Here is an outline of exactly what I think this proc should do. I'm not sure about any of the names, but this will give you the idea.

bound_color proc


Format:
bound_color(Ref, fill_rgba, border_rgba, pixels_in, pixels_out, invisibility)


The effects of this proc are purely visual, and it does not change any existing tiles, or create any new objects.

Args:
Ref: A turf, obj, or mob.

fill_rgba: The rgba value to overlay the entire area of the Ref's bounding box.

border_rgba: The rgba value to overlay the perimeter of the Ref's bounding box.

pixels_in: The thickness of the border overlay, in pixels, extending from the very edge of the Ref's bounding box, to the center. The default value is 1, which gives a border that's 1 pixel thick within the box.

pixels_out: This is just like pixels_in, but instead of thickening the border inward, this thickens it outward, beyond the Ref's bounding box. This has a default value of 0, which gives no outside border. There may be issues when using this with strictly tile-based maps.

invisibility: By default, the visibility of the box is tied to the Ref, and inherits all visibility settings from it, but this may be overridden by specifying a level of invisibility from 0 to 101, which works just like the invisibility var. This is useful if you want certain mobs to see only the Ref, but not the box or vice versa.


Basically, I think there should be a specific proc that will allow you to directly apply color to any bounding box. I can think of several other reasons why you might want to do this, but you might be surprised by how I would make use of this. I plan to create a selection box system that will use a resizing bounding box of a zero density object, controlled by mouse, and compare it with the bounding boxes of mobs using a proc such as bounds_dist() or obounds(), to determine which ones to select.

The problem is, the players need to actually see where this bounding box is while they are dragging it around. It would be nice to avoid using icon transformation procs and managing /icon objects, and instead just using something designed specifically for bounding boxes. It will really help for this to work with pixel movement.

Let us know if you would like to make use of a built-in proc like this one, and what you would use it for.

Please don't close this suggestion just because it might not happen any time soon. Keep the idea alive.
Did you read everything? This does not apply to the atoms themselves. This specifically colors the bounding box, regardless of where the object is located relative to its tile. What I want this for is pixel perfect borders, not so much the fill coloring part.
I believe they are working on maptext's background at the moment. You could achieve the same functionality (except for the invisibility part) if they add border options.
That would require scaling the maptext area to the same size and location as the bounding box, which is changing every tick, so that would likely add lots of unnecessary lag. Also, I would need to be able to control the invisibility of the box, so that when one player is selecting units, the others won't actually see it happening. Either it needs an invisibility setting, or something based around the client, that other players won't see.
A maptext is attached to an atom. It will move wherever the atom moves to. As for the bounding box, you're most likely not gonna change that every now and then. Yes, you cannot control invisibility with it like I have said earlier.

Anyways, if you just need it for selecting units, you can use /image objects and attach them on your atoms. I don't see any other use for this so I think laziness exists on your part.
In response to Jemai1
Multiverse7 wrote:
I plan to create a selection box system that will use a resizing bounding box of a zero density object, controlled by mouse, and compare it with the bounding boxes of mobs using a proc such as bounds_dist() or obounds(), to determine which ones to select.

It's definitely an RTS feature that's been asked about before.
Well, if it is like that, the only missing component is a built-in real-time mouse tracking.