For a health meter, you'd pretty much only be accessing the vars responsible for the meter's values, and a couple of appearance vars. Thus the lookup of those var definitions in the type tree is trivial, because that would tend to happen almost never. The list of changed vars for that object would be the real issue, and that would be just as small regardless of whether it was a turf or an obj.

And of course it can't be an atom directly, because atom is an abstract type. Atoms are always either areas, turfs, objs, or mobs, never anything separate. Defining something with parent_type=/atom will produce undefined behavior, and is therefore a horrible idea. parent_type=/atom/movable is also undefined, although it seems to shake out as making the item an obj for internal bookkeeping purposes.

Movables do have a bigger struct than the one used for handling interesting turf info, so there is that, but it's a very minor memory concern--and they're fairly easy to access directly, which isn't as true of turfs because they use tricks to cut down memory. Areas have direct access and a smaller struct than movables, but areas don't make sense as screen objects either.

MrStonedOne wrote:

parent_type=/atom/movable is also undefined.

This is actually used quite a bit on ss13.

Yeah, I wouldn't do that. The behavior is undefined and it's basically just asking for trouble. Relying on undefined behavior is a great way to run afoul of breaking changes that aren't actually breaking changes.

Rushnut wrote:

? I've been using /atom and /atom/movable for all sorts for years and never had an issue.

Eventually you may. They're abstract types. Defining a var or proc under it is one thing (and quite normal), but they're not meant to be used as a parent_type directly. I know from seeing it in action that parent_type=/atom/movable will make something an obj, although I believe it's not an /obj. That's a pretty weird situation and it'd be naive not to expect problems--present or future--from it. But parent_type=atom is weirder, because there's no such thing as an atom that isn't a turf, area, obj, or mob internally.

I really don't understand why screen_loc is under /atom/movable.

It's because objs and mobs are the most "fluid" atom types; they're designed to be put in any container, and don't need a physical location. Turfs are either on the map or they don't exist, period. Areas could technically be considered similar to movables in not needing a physical location, but that would be a super weird choice--hence they were never brought in on it; ultimately an area is really only meaningful as either a collection of turfs or an abstract location in a MUD.

Limiting screen objects to movables also simplifies a number of things internally. Although it might have been pretty well doable to allow turfs and areas to be HUD objects as well, it would have meant more code to do so, and probably most of it would never have been used. Plus, in the past when we used to interlayer regular icons and HUD icons, turfs and areas as screen objects would have appeared beneath movables unless their layer was changed, and that'd be straight-up weird.