mapified a lot of vehicle stuff

[PatrikLundell]

Summary

None

Purpose of change

Make the code reference the same map in different parts of the call chain by passing it along rather than calling get_map() all over the place. This time more vehicle stuff.

Describe the solution

Essentially look for get_map() calls and replace those with usage of new map parameters passed from the operation callers.
I ran into issues with const maps vs non const ones resulting in more map parameters being const, as well as some map * parameters being converted to const map& in order to be able to compile the code.
No functional changes to existing code (possibly excluding map offset explosions), as the call chains start with the reality bubble map, which is what get_map() returns.

Describe alternatives you've considered

Go all in on changing map * parameters to const map &, as feeding const map & parameters to operations using non const profiles doesn't work (for good reason).

Testing

Load save, walk up ramp, jump into car, examine car (as some changes were made to code involved in this), drive through hay bales, run over zombie corpse with inventory, run over turkey, smash into stationary vehicle.

The last step gave odd results, as the first hit generally didn't result in either damages to the vehicles or the PC, while repeated ramming did.
I retried this about 3 more times with the same result.
After that, I committed the changes and switched to master, recompiled, and reran the same test with the same unusual result, which indicates the cause is within master rather than this PR.
It can be noted that the tests ran on the previous PR in this series (which is incorporated into master) did not have this behavior. I also have no idea how the changes would be able to result in no damage at some times but not others.

Additional context

[moxian]

No functional changes to existing code (possibly excluding map offset explosions), as the call chains start with the reality bubble map, which is what get_map() returns.

Can you point to an example code that operates on some map other than reality bubble?
Essentially, trying to understand what would be passed in that map argument if not the result of get_map()

[PatrikLundell]

Sure,

A part of the explosion handling code operates on a full size map only partially overlapping the reality bubble one in order to generate craters crossing the edge of the reality bubble (so craters aren't cut off when the explosion happens on the edge).

There's also work on the same code being triggered a bit outside of the reality bubble through a grenade launcher.

In addition to this, there's also the various mapgen applications operating on tinymaps and smallmaps. On a map shift newly generated terrain is partially outside the reality bubble (only half or a quarter of it is inside on a map shift, as whole OMTs are generated, not the single or double submaps that are covered by the sliding reality bubble map). There are also remote mapgen operation (such as base camp tree felling somewhere remote, which loads a remote map, manipulates it, and then places it back into the map buffer), However, those usages SHOULD be handled by careful crafting of the limited selection of call chains invoked by that usage: the mapgen operations do pass the map used with them. As long as mapgen users stick to the "safe" subset, everything works correctly (and the operations available to JSON mapgen is tightly constrained by the JSON syntax support).

[moxian]

Can you give me a couple of code pointers please (function name or file+line)? I'm just trying to figure out how exactly they are accessing those non-reality-bubble map objects.

[PatrikLundell]

In the explosion case the map is generated by explosion.cpp operation process_explosions() when the explosion doesn't fully cover the explosion radius.

In the mapgen case it's hidden somewhere in there (I always have trouble following these call chains). There's a class called mapgendata that contains the parameters, including the map (tinymap, smallmap, or fakemap) used. Thus, the maps should be created close to where mapgendata objects are created (and MSVC isn't helpful when trying to find such places, at it will list all places a class is used, rather than only the places where the selected object creator method is used).

In the standard case the map originator is the caller of map::generate(), where a smallmap is generated and passed in. It then ends up being placed in the mapgendata class above.

As indicated, there's also maps generated for faction camp upgrades, both player ones and others. The former are triggered by the bulletin board (the code is either in faction_camp.cpp or basecamp.cpp), or through dialog with the faction (e.g. Tacoma farm upgrades). I'm not sure where that code resides, but it is follows the same principle as PC basecamps,, i.e. a small/tinymap is loaded, a JSON manipulation is applied, and you're done (as the submaps are saved during the process).