Implement curved roads as nested json pieces. [WIP]

[sparr]

Summary

Features "Curved roads. Roads as nested json pieces."

Purpose of change

Road shapes are hard to edit with the current C++ code that uses arithmetic and logic to draw them. Moving a significant part of the road mapgen to JSON will help alleviate this problem and allow a wider range of contributors to edit the shapes of roads in the future, as well as allow them to be customized in mods.
Six years ago I thought 90 degree angles were ugly so I rewrote the road mapgen to do 45 degree angles. I recently started playing again and I think 45 degree angles are still ugly so I rewrote it again to do curves.

Describe the solution

The layout of terrain and furniture (lights) for roads have been moved out to mapgen json files, with related changes to palettes and parameters.
The C++ logic that previously drew them has been replaced with logic that assembles the new json mapgen pieces, most of which represent 1/8 to 1/2 of a map, and most of which have parameterized optional elements like sidewalks and street lights.

Describe alternatives you've considered

I started to implement the curves in the existing C++ mapgen_road function, compositing lines and rectangles and circles. This made the code even less readable than it was before.

Testing

I have only spot checked the results. This is a WIP PR and needs significant testing and further tweaking before it is ready to merge. In addition to testing all the possible interactions of roads with the world, this PR also touches the s_gas (gas station) mapgen json as well as the mirror functions used for various other parts of the codebase. I'll be attempting to make a thorough test of every impacted element, but would also appreciate spot checking and feedback from anyone who tests this and sees problems.

Additional context

Curves with sidewalks have gaps in them, just like diagonal roads with sidewalks did with the 45 degree angle implementation. I'm not sure how folks will react to roads turning so close to buildings in cities. The gentle 90 degree curves in cities could be replaced by the tighter ones used in u-turns to alleviate these concerns. This would also reduce the number of places where buildings with their own sidewalks or driveways expect to connect to a road sidewalk but fail to do so alongside a curve.

There's a lot of duplicate/redundant code here. I wanted to get this working and demo-able so I can get feedback on it before I spend too much time on optimizing and abstracting and organizing and commenting parts that might not make the cut.

I did not intentionally change the locations of street lights, but I also haven't gone through to confirm they are in the correct place. Nailing that down to match the old mapgen would come in a final pass.

I did intentionally...

• change crosswalks from 1-on-1-off to 1-on-2-off to make them symmetric.
• change the road stripes from 3-on-1-off to 2-on-4-off for aesthetic reasons, especially in curves.
• move traffic lights from corners back to alongside the stop line, because I think they are more realistic there and that is where a stop sign would go if we make some signed intersections later and it makes driving in cities a little easier.

PS: This PR also eliminates the "plaza" concept from the road mapgen, which AFAIK has been a dead code path for almost six years. See #61334

[NetSysFire]

Amazing! This looks like a big step towards being able to define arbitrary connections via JSON.

[PatrikLundell]

The images look good, and it seems they're not applied to cities (where they generally shouldn't be applied, as most roads ought to be according to the grid format). However, I'm worried these roads would make driving a lot harder, given that vehicle swivel around the center rather than turn after the front wheels and morph in ways that's easy to mis-predict when at a 45 degree angle, resulting in a lot of collisions and/or slow downs to crawl, with abandoned vehicles blocking off even more of the available passages past them.

[DPavonis]

Found a location where the road probably should have connected, but didn't. Seems to be related to .../data/json/mapgen/robofachq_static.json

[DPavonis]

Trailer park spawns disconnected from the roads, ...\data\json\mapgen\trailer_park.json

[sparr]

I am facing a significant implementation question. Is it preferable to have fewer unique json puzzle pieces with more complex logic to put them together, or more redundant jsons with simpler logic to put them together? The old code is nothing but logic, and it got too complex, so I'd like to avoid going too far down that route. However, the other end of the spectrum involves a lot of redundant content that needs to be updated when something changes.

e.g. each of the exits from a 3 or 4-way intersection could go straight (if pointing at a straight road or a tight corner) or curve left or curve right (if pointing at a wide corner or a 45 degree turn onto a diagonal road). Right now I assemble all of those intersections from 3-4 unique pieces and various amounts of rotation and mirroring. The code would be much simpler if, instead, there were just 21 separate jsons each representing an entire intersection with one permutation of exits.

[I-am-Erk]

That is a hard question. It might be better to see if there are simpler ways to express the logic.

[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.

[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.