made some map operations consistent

[PatrikLundell]

Summary

None

Purpose of change

Make methods of the map class consistently work on the object map rather than the official reality bubble map.
This is the first PR of a series of unknown length, as there's quite a lot to check and modify.

Describe the solution

Examine methods to see what operations they call, and whether these operations implicitly use the game reality bubble map (i.e. get_map() or g->m) rather than the own map object. Note that this check is transitive.
If an operation implicitly uses the wrong map, pass the map object to a an overloading version of the operation to make it possible to use the correct map, and adjust the overloading operation accordingly. Typically have the original operation call the new one, passing &get_map() as the map parameter.

Introduced Character::pos_bub(map *here) to make it easier to get the bubble coordinates you actually want and replace "here->get_bub(pos_abs())" with the shorter "pos_bub(here)".

Describe alternatives you've considered

Testing

This should not result in any functional changes to the existing functionality. Failing to catch all implicit usages of the official reality bubble map will, unfortunately, not result in visible bugs until the code is used with other maps.

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. The only oddity seen was that the zombie corpse wasn't destroyed this time (but some items were). Backed over it and the corpse was destroyed. This is attributed to normal variability.

Additional context

Why am I doing this?

Madness can't be ruled out, but the longer term objective (not coordinated with senior devs, but not known to be in conflict either) is to allow for usage of other maps during game play without having to go through this upgrade at the same time as trying to produce new functionality. The first usage of additional maps (outside mapgen) was for explosion purposes, and trying to get that to work properly highlighted the underlying issue of the code simply not being consistent when it comes to the usage of map objects.

At some time it would be desirable to be able to keep multiple reality bubbles in play in order to allow activities to proceed normally e.g. in a camp while the PC is away. That's probably a fair way off due to performance issues, but it is still useful trying to make the foundation a bit sounder.

[RenechCDDA]

At some time it would be desirable to be able to keep multiple reality bubbles in play in order to allow activities to proceed normally e.g. in a camp while the PC is away.

I don't believe that is desired, just FYI. See #69634 for a broad overview.

[PatrikLundell]

Hm, it looks like we have a problem, revealed by the tests:
map::add_vehicle (in mapgen.cpp) sets the coordinates of the vehicle to the coordinates of its own map, NOT those of the reality bubble map they're described be relative to by their definition in vehicle.h.
map::add_vehicle_to_map(mapgen.cpp) also assumes the map is the reality bubble map (veh_to_add->bub_part_pos).

There may be more issues hidden here, requiring more work to untangle.

Best to record the revealing test case: C:\Cataclysm-DDA\Cataclysm-test-vcpkg-static-Release-x64.exe --section mapgen_remove_vehicles

[PatrikLundell]

I'm giving up on this approach due to the amount of messes uncovered, and will try to approach it from a different angle.

The main problem I have is that the vehicle handling mostly pretends to operate in reality bubble coordinated, while it actually uses a mixture of reality bubble coordinates and bub coordinates of the map used, e.g. cramming the latter into the bub position of vehicles, and a usage of cached coordinates that are supposed to be reality bubble ones but probably, again, is relative to whatever the map it was created on uses. This probably works currently through a combination of luck and the fact that map gen involving vehicles usually don't act within the reality bubble. It can also be mentioned that these messy "reality bubble" coordinates don't seem to be saved in JSON, reducing the risk of them being applied on the wrong map.
(Vehicle) operations downstream meanwhile assumes reality bubble coordinates are used regardless in most cases (there's an attempt to create a special environment for mapgen, but unless that environment is severely restricted (which it might be), operations downstream are again using bubble coordinates. Also, the logic to determine if it's mapgen is based on the map not being the reality bubble one (thus being applied to any map not being the reality bubble one).

Thus, I'm going to start to try to bring some order to the vehicle data before slowly trying to tackle vehicle operations as such.