Smallmap scope for parameters

[Procyonae]

Is your feature request related to a problem? Please describe.

I want to make the underwater OMTs at the edge of lakes/ocean a gradual descent rather than just cubes but doing so with either C++ or JSON is currently very awkward. Ravines could also use choosing a more random edge that's mostly fixed all the way down.

Lining up road to sewer manholes with JSON without using a overmap special that I want to avoid is also awkward rn due to the sewers under the manhole not being a fixed orientation (rn they use the nonsense teleport stuff that exists primarily for old labs)

Solution you would like.

Both of these could be solved by adding a new parameter scope for the new smallmap Patrick introduced, a vertical stack of tinymaps.

This would allow OMTs placed outside of specials and even unrelated maps in the case of roads and sewers to use parameters for nest alignment.

Describe alternatives you have considered.

I'll attempt to do this myself at some point by cargo culting #50681 but if anyone who actually understands the code well wanted to add this sooner I'd be thankful

Additional context

No response

[PatrikLundell]

I think you should start with just using smallmap, as the complication of dealing with some, but not all Z levels probably isn't worth it (and if there is a need for limited levels for performance reasons, I'd rather introduce a new type of map with a limited range of Z levels when the need becomes apparent. Porting whatever has been done with smallmap for those cases to this new map version should be straightforward.).

Note that smallmap isn't a stack of tinymaps, but a full column of all Z levels in a 2 * 2 submap grid, just like map covers all Z levels over an 11 * 11 submap area. This means smallmap can be used in the same manner as map (but with the same coordinate origin and range as tinymap, and thus, from that perspective, as a tinymap), with access to all Z levels as needed.
It can also be noted that if there is a need for some map operations which are currently not made available through smallmap it's typically easy to export them (if they make use of Z levels, just make them unavailable in tinymap and forward them to smallmap). What's currently made available in tinymap and smallmap is what's currently used, not what might make sense to make available for use.

Note that if you're cargo culting the lot, it would probably be easier to copy however existing code juggles tinymaps, but going forward I think using smallmap is the better choice.

If you need to align what's on different Z levels with each other I assume it has to be done either the same way mapgen currently does it for when it's actually done, or by code that looks for where the stairs are on the source level and then generates stairs (and the rest) based on that.
I would guess you can simplify the former by ensuring the controlling surface level maps only use a small number of different locations (which, in some cases, probably can be rotated) so you only need a limited number of lower level variants.

If I understand it correctly, things like rivers and shores (and ravines, which aren't present in vanilla) are generated by code to provide variation. Generation of lower levels would need to depend on how the level above them was generated to determine their layout, with the same kind of logic (possibly with different parameters, so e.g. the steepness can decline as you go down) applied for each deeper level. If the surface is generated by JSON, I think it would be a horrendous nightmare to encode the variations in the lower levels in JSON, with nightmarish conditions (assuming it's even possible).
Code can easily read what was placed in the layer on the Z level above and generate a level based on that (I'm not saying the code to determine what to place where is trivial, but the input information is available, as opposed to the results a sequence of RNG rolls you can't get hold of).

[Procyonae]

I think you should start with just using smallmap, as the complication of dealing with some, but not all Z levels probably isn't worth it (and if there is a need for limited levels for performance reasons, I'd rather introduce a new type of map with a limited range of Z levels when the need becomes apparent. Porting whatever has been done with smallmap for those cases to this new map version should be straightforward.).

Where did I say I wanted to use anything other than smallmap?

Note that smallmap isn't a stack of tinymaps, but a full column of all Z levels in a 2 * 2 submap grid, just like map covers all Z levels over an 11 * 11 submap area. This means smallmap can be used in the same manner as map (but with the same coordinate origin and range as tinymap, and thus, from that perspective, as a tinymap), with access to all Z levels as needed.

I'm not going to pretend I understand the difference you're trying to highlight here, are you just saying it's all the submaps that would be in a vertical column of tinymaps but not the actual tiny maps themselves?

Note that if you're cargo culting the lot, it would probably be easier to copy however existing code juggles tinymaps, but going forward I think using smallmap is the better choice.

Again I don't understand where I'm suggesting I don't want this based on smallmap? It's literally in the title

If you need to align what's on different Z levels with each other I assume it has to be done either the same way mapgen currently does it for when it's actually done, or by code that looks for where the stairs are on the source level and then generates stairs (and the rest) based on that.

I don't think any of the sub level stuff should matter here as parameters aren't defined/used until they enter reality bubble

I would guess you can simplify the former by ensuring the controlling surface level maps only use a small number of different locations (which, in some cases, probably can be rotated) so you only need a limited number of lower level variants.

Eh?

If I understand it correctly, things like rivers and shores (and ravines, which aren't present in vanilla) are generated by code to provide variation.

River shores barely have variation atm but yes all are currently hardcoded, I'm unhardcoding rivers atm (to potentially be backported to 0.H) and plan to unhardcode the others when I get round to it.

Generation of lower levels would need to depend on how the level above them was generated to determine their layout

Ye you'd have like a nested_mapgen_id parameter for the surface where like wibblywobblysurfaceA which would use wibblywobblyz-1A etc going down with minor randomised placement within each, tailored to suit the layer above.

If the surface is generated by JSON, I think it would be a horrendous nightmare to encode the variations in the lower levels in JSON, with nightmarish conditions (assuming it's even possible).

I really don't think it's that bad at all, all the logic would be housed in the below surface omt (probably a new one seperate from the all water one to make it possible to distinguish for stuff spawning on the bottom) and then all the groups of nests categorised by variant and then z-level. This is already possible if I hacked lakes into placing vertical columns as specials I just don't want to do that bc ew.

Code can easily read what was placed in the layer on the Z level above and generate a level based on that (I'm not saying the code to determine what to place where is trivial, but the input information is available, as opposed to the results a sequence of RNG rolls you can't get hold of).

I actually tried this previously and didn't get anywhere, I appreciate it's possible but I'd rather use an unhardcoded solution anyways

[PatrikLundell]

I'm not going to pretend I understand the difference you're trying to highlight here, are you just saying it's all the submaps that would be in a vertical column of tinymaps but not the actual tiny maps themselves?

A map is an 11 * 11 submap area with all Z levels, a smallmap a 2 * 2 submap area of all Z levels, and a tinymap a 2 * 2 submap area of a single submap. All are variants of the map. Thus, a smallmap contains all the data that a stack of tinymaps covering the same overmap tile but at different Z levels cover. Note, however, that a tinymap isn't a fundamental structure. The base unit is a submap. You can do most of the things you can do on a smallmap with a stack of tinymaps. The things you can't do are the ones where the code silently does nothing when trying to access other Z levels if the map doesn't support Z levels (which the single level tinymap obviously can't do).

I don't think any of the sub level stuff should matter here as parameters aren't defined/used until they enter reality bubble
I thought everything was realized when touched by the reality bubble. Only the overmap type gets defined prior to that, so I thought both the surface and the other levels got created at the same time.

Eh?
Basically: Make sure the surface maps you depend on has the connection in as few different places as possible and make the lower level connecting maps be one of a limited number of types. Typically the stair location cannot be set freely, but has to align with everything else, such as the tunnels they are in.

River shores barely have variation atm but yes all are currently hardcoded, I'm unhardcoding rivers atm (to potentially be backported to 0.H) and plan to unhardcode the others when I get round to it.
That's probably fine for the surface level, but I can't see it working for lower levels (Code working on what's defined above doesn't have to care how the level above was generated).

Ye you'd have like a nested_mapgen_id parameter for the surface where like wibblywobblysurfaceA which would use wibblywobblyz-1A etc going down with minor randomised placement within each, tailored to suit the layer above.
The problem is that each level gets increasingly more complicated to define as you have to take into consideration what might have been generated on the level above in an increasing number of steps.
However, if you're convinced you can pull it off and it works, I've been proven wrong (and I'm fine with that. I just find it very scary).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.