EOC OMT search functions look for matching type

[RenechCDDA]

Summary

None

Purpose of change

Ran into a small error with how EOCs search for OMTs, found out it had been worked around in other places...

Cataclysm-DDA/data/mods/Magiclysm/items/enchanted_boots.json

Lines 279 to 289 in 4314562

	{ "not": { "u_near_om_location": "road_curved", "range": 1 } },
	{ "not": { "u_near_om_location": "road_four_way", "range": 1 } },
	{ "not": { "u_near_om_location": "road_tee", "range": 1 } },
	{ "not": { "u_near_om_location": "road_straight", "range": 1 } },
	{ "not": { "u_near_om_location": "road_end", "range": 1 } },
	{ "not": { "u_near_om_location": "road_sw", "range": 1 } },
	{ "not": { "u_near_om_location": "road_ne", "range": 1 } },
	{ "not": { "u_near_om_location": "road_ew", "range": 1 } },
	{ "not": { "u_near_om_location": "road_ns", "range": 1 } },
	{ "not": { "u_near_om_location": "road_nesw", "range": 1 } },
	{ "not": { "u_near_om_location": "road", "range": 1 } }

Describe the solution

Properly remove all mapgen-related suffixes when using the EOC functions near_om_location and at_om_location, not just the cardinal direction ones. This includes directional line connections as well as mutables.

Clean up all the duplicated json lines previously used to work around this issue.

Describe alternatives you've considered

This bug may be present in other calls to oter_no_dir but this is just trying to fix what I know is wrong, rather than an endless fishing expedition

Testing

Additional context

In draft until I push another commit for the json changes Remaining in draft for more testing

There were some existing checks for river_c_not_sw(etc) which I did not touch. These appear to be hardcoded definitions, not actual rotations. Weird stuff!

[RenechCDDA]

@Maleclypse I'm vaguely concerned about how it will interact with this:

{ "u_at_om_location": "arvore_genius_loci_NW" },

arvore_genius_loci_NW is a manually defined ID, not a rotation or connection? I would ask if you can check EOCs checking for this location still function as expected. It should only be trimming _nw and not the capitalized version, but if it has unexpected changes I may need to consider a different approach.

[Maleclypse]

@Maleclypse I'm vaguely concerned about how it will interact with this:

{ "u_at_om_location": "arvore_genius_loci_NW" },

arvore_genius_loci_NW is a manually defined ID, not a rotation or connection? I would ask if you can check EOCs checking for this location still function as expected. It should only be trimming _nw and not the capitalized version, but if it has unexpected changes I may need to consider a different approach.

I missed this in my GitHub feed so I’ll test this asap

[Maleclypse]

@Maleclypse I'm vaguely concerned about how it will interact with this:

{ "u_at_om_location": "arvore_genius_loci_NW" },

arvore_genius_loci_NW is a manually defined ID, not a rotation or connection? I would ask if you can check EOCs checking for this location still function as expected. It should only be trimming _nw and not the capitalized version, but if it has unexpected changes I may need to consider a different approach.

So yes, it's a 4 square terrain where I named each square after it's relation to the center. The EOC works as expected in a current game. I'll compile your PR and test it as well.

[Maleclypse]

Pulled your PR, compiled and set a message , { "u_message": "This EOC works still, tell Renech" } on the offending Arvore EOC. Tested it at Great Tree and at Arvore Genius loci. Received messaged at both locations. Looks like this works like a charm.