Rename map:: get_global->get_abs, bub_from_abs->get_bub, omt_from_abs->get_omt

[PatrikLundell]

Summary

None

Purpose of change

Fix #79118, i.e. rename operations.
This is really the first PR in a series, but there's no need to keep the suggestion open.

Describe the solution

Use the "rename" VS functionality to refactor the names of:

• map::getglobal ->map::get_abs
• map::bub_from_abs -> map::get_bub (two instances)
• map::omt_from_abs -> map::get_omt

Note that this shouldn't result in any functional changes.

Describe alternatives you've considered

Testing

Load save, walk up ramp, jump into car, drive through hay bales, run over zombie corpse with inventory, run over turkey, smash into stationary vehicle. Nothing odd seen.

Additional context

As indicated, this is intended as the first in a string or PRs. The others will deal with variously named position getting operations.

This PR has a high risk of causing merge conflicts given that it affects a lot of spread out places, and thus shouldn't be merged as part of a batch. That's also the reason follow up PRs won't be produced until the previous one has been merged, as resolving merge conflicts between them seems like unnecessary work.

[github-actions]

Auto-requesting reviews from non-collaborators: @andrei8l

[Procyonae]

I'd prefer if omt_from_abs and getglobal( const tripoint_omt_ms &p ) were removed altogether bc they're misleading, not preserving where the coordinate was pointing to at all unless I'm misunderstanding.
I also feel like bub_from_abs is a conveniently intuitive name and keeping it and doing getglobal -> abs_from_bub would be better but I don't have that strong an opinion on it.

[PatrikLundell]

omt_from_abs and getglobal(omt) (the names changed in this PR) are direct analogs to their corresponding operations on bub positions. The difference is that they're working on tinymaps whose native coordinate system is the omt one, but they transform a local position to an absolute one and vice versa. Internally omt/bub are both the local coordinates of the position relative to the top left of their map object, with the only difference being where that position is located, and thus what range the positions can take and still lie within the map (C++ doesn't have the capability to define sub range types, so that can't be enforced without a lot of hoops, so there's no inherent range restriction: the ob/ib stuff is an attempt to sort of emulate this). That's why the implementation of the omt versions can just cast to bub coordinates. Thus, the point of having two types for the local coordinates is to remind users which coordinate ranges they're operating in.

The reason I went for get_abs/get_bub over abs_from_bub/bub_from_abs is my perception that C(++) people are adverse to long names (probably harking back to the single finger typing of old). I'm personally happy with either, as long as we're consistent. I guess we need to have some kind of a vote.
I propose:

• laughing face for get_bub/get_abs/get_omt; and
• frowning face for bub_from_abs/abs_from_bub/omt_from_abs/abs_from_omt
• Thumps up: Holding a vote is a good idea
• Thumbs down: Holding a vote is a stupid idea
• The rest: It's fun to be a non conformist and spread confusion and obstructing things.

[Procyonae]

Why does them being tinymap make the bub_ms directly treated as a omt_ms without projection make sense?

        tripoint_omt_ms omt_from_abs( const tripoint_abs_ms &p ) const {
            return rebase_omt( map::bub_from_abs( p ) );
        };

tripoint_omt_ms rebase_omt( tripoint_bub_ms p )
{
    return tripoint_omt_ms( p.raw() );
}

[PatrikLundell]

The "anchor point" of a map is the top left corner of the map, and that's what stored in abs_ms in the map object. The absolute position of a local position is the top left corner position (i.e. abs_ms) plus the relative position of the point within the map (using bub or omt coordinates as applicable), and it doesn't matter what we call our coordinate system when performing this operation.

A crucial thing about the map class hierarchy construction is that the map class has no inherent concept of its size: all that is defined on its definition (the available constructor calls the protected one, which sets up the dimensions, while the dependent classes have access to the protected operation, and thus are able to set up their dimensions differently), but the dimensions are part of the object. This means that a tinymap (and smallmap) IS a map, just defined with different dimensions. This is also why we can cast a tinymap/smallmap and things continue to work correctly (it's done in a few places where it's essentially needed unless you want to go through gymnastics with selection of function pointers in a rather messy way).

All of this means that bub and omt coordinates are identical when referring to the same map object, but they tell the user what kind of ranges to use. It would have been possible to only use bub coordinates throughout and leave it to the user to keep track of which kind of map they're operating on. Personally I think defining separate types was a good idea (it was done before my time, so I have had nothing to do with that), but I guess people with more of a C mentality might find it annoying.

If this doesn't make sense, I can try a new approach given a few hints of where the problems lie (It's always tricky to judge whether explanations make sense when you're not sure if your starting point makes sense to the receiver).

I assume it feels like a bub coordinate should push the corner away from a local location and an omt one should pull it closer, but that's not how it works. Instead, the corner location is fixed and the difference is how the coordinates are used, but these usages are all within the same context.

Edit:
Direct answer to the question:
The position is relative to the top left corner of the same map, and the map's absolute top left corner position remains unchanged as the map doesn't change size in the process.

[GuardianDll]

i didn't read the pr very closely, but doesn't old name bub_from_abs imply conversion? as a layman programmer, i would find a set of functions of type x_to_y or x_from_y much easier to ghasp than get_bub

[PatrikLundell]

To me both imply conversion, with the from version being explicit (and thus very clear) and the other implicit in that you feed in data in one coordinate system and receive a result in another.
I assume this means you would vote for the second option...

[GuardianDll]

I'm all for any sort of standartization, i think people get used to any naming scheme as long as it would be consistent; i do not have strong opinion for specific name