tilesets: add support for looks_like field

[mlangsdorf]

This adds support for a looks_like field in most things that have tileset images.
If the tileset loader fails to load a tile for a terrain, furniture, monster, vehicle part, or item, it will check to
see if the object has a looks_like field. If it does, it will attempt to load that tile. If that fails, it will check
if the looks_like object has a field, repeating the process up to 10 times.

the looks_like defaults to the value of copy-from if the object has a copy-from field, or it can be set
explicitly.

Fixes #19932

[mlangsdorf]

Mike the Mechanic, in a game without looks_like support.

Mike the Mechanic, in the same savefile with looks_like support.

I'll need to add a separate PR to add some looks_like fields, but hopefully this PR will make it easier for
people to add new content and keep their tileset games looking pretty.

[mlangsdorf]

Will add doc/ changes tomorrow. Sorry I forgot.

[lispcoc]

It Seems good, but overlay_XXXX tilles is not taken into account. Support them is hard to implement?

[mlangsdorf]

As far as I can tell, overlay tiles are handled in draw_entity_with_overlays(), which pulls the overlay string ids from pl.get_overlay_ids() and then looks for overlay_(fe)male_$OVERLAY or overlay_$OVERLAY via find_tile_type(). If one of those two matches, draw_from_string_id() is called, but it will necessarily return a tile because draw_from_string_id doesn't get called unless there's a tile to return.

overlays aren't terrain, furniture, monsters, vehicleparts, or items. They don't have an json object associated with them that can have a looks_like value. I don't think looks_like overlays would necessarily even be a good idea.

But maybe I'm wrong. I think I can code up a find_mutation_looks_like and find_effects_looks_like fairly straightforwardly, and the existing find_item_looks_like could be altered to take an optional prefix string and perform the search with the prefix string. The biggest problem is the number of the potential searches: overlay_male_ultimate_winter_survivor_coat might have to search for overlay_ultimate_winter_survivor_coat, overlay_male_winter_survivor_coat, overlay_winter_survivor_coat, overlay_male_duster_survivor, overlay_duster_survivor, overlay_male_duster_leather, overlay_duster_leather, overlay_male_duster, overlay_duster, overlay_male_trenchcoat, overlay_trenchcoat, overlay_male_coat_winter, and overlay_coat_winter to satisfy the looks_like series of
ultimate_winter_survivor_coat: winter_survivor_coat,
winter_survivor_coat: duster_survivor,
duster_survivor: duster_leather,
duster_leather: duster,
duster: trenchcoat,
trenchcoat: coat_winter

though I guess that's only 6 loops through and 24 searches (because you have to search for seasonal variations each time), not too bad. I suspect the find() operator is O(1), so doing it 40 times (in the absolute worst case scenario) per tile shouldn't be too bad, and I don't expect most tiles to need the full 10 iterations to either find a matching tile or run out of looks_like.

Might take me a couple of days. Thinking about it, I'd rather open a second PR for overlays after this gets merged, because I'd like this to get extensive reality testing before expanding it, if that's okay by you.

[SomeDeadGuy]

Addition:
How about this - give looks_like to randomly generated artifacts! So now artifacts can look like something, what they actually are!

[mlangsdorf]

Artifact tagging added to the todo list but not for this PR.

[mlangsdorf]

minimal documentation added.

Off to go revise JSON_INFO.

[Night-Pryanik]

After this PR is merged, you can also update info on json API changes in #19376.

[codemime]

Immutable strings should be passed by constant references: const std::string& id.

[codemime]

You could've stored already visited items using a set or something, thus preventing infinite loops. The counter based approach raises questions like "why 10"? Checking for inconsistencies beforehand would be even better.

[codemime]

find_tile_with_season() is invoked twice per draw_from_id_string(). The first invocation is here.

[mlangsdorf]

I think the issue you're pointing out is addressed in #24778

[codemime]

I meant something else:

    const tile_type *tt = find_tile_with_season( id );	// <- 1st find_tile_with_season(id).
    
    if( !tt ) {
	...
        if( category == C_FURNITURE ) {
            tt = find_furniture_looks_like( id, effective_id );	// <- 2nd find_tile_with_season(id) with the same id inside the function

Map lookup times are noticeable in tiles, so this may slightly impact the overall performance.

[codemime]

These functions look very alike. They introduce unnecessary duplication which can be avoided with something like:

const tile_type *cata_tiles::find_tile_looks_like( const std::string& id, TILE_CATEGORY category )
{
    switch( category )
    {
	...
	
	case C_FURNITURE: {
	    const furn_str_id fid( id );
	    return fid ? fid->looks_like : nullptr;	
	}
	
	...	
    }
    
    return nullptr;
}

[mlangsdorf]

Yeah, I realized that after I submitted it. Refactoring it is on the todo list.

[codemime]

The very idea of using copy_from for obtaining missing tiles looks sound. I think it's great, actually.
However, I'd avoid introducing the explicit looks_like filed for two reasons:

1. It's kinda way too tile related and makes no sense in the absence of tiles. Tiles are supposed to be on top of items, not vice versa.
2. Most of the time it simply restates copy_from.

[mlangsdorf]

Completely disagree on the second point. Most of the time it doesn't restate copy-from at all. None of the hd vehicle door/hatches/trunk doorss are copy-froms of the non-hd versions.
People aren't introducing new terrain or furniture via copy-from, for better or worse. But they can say an autodoc couch looks like a sofa, and fills a gap until the tilesets are updated.

As far as the first point, I don't see any other place to put this information than in the item JSON. Any other location is going to be inherently fragile.

[codemime]

People aren't introducing new terrain or furniture via copy-from, for better or worse.

Good point. This looks like an issue to me. You've outlined it and offered a workaround which would work for tiles, but only if people are willing to use it.

I don't see any other place to put this information than in the item JSON

JSON is perfectly fine for the purpose. I just meant that if you store the ancestor's id somewhere (the item copy-from references), it would suffice.

[ZhilkinSerg]

Using ofcopy-from would make sense if all items utilized this field.

[codemime]

Using ofcopy-from would make sense if all items utilized this field.

This PR relies solely on copy-from (doesn't introduce any new looks_likes). Still, it's said that it resolves the corresponding issue.

[mlangsdorf]

See #24768

[lispcoc]

I think id is not updated to seasonal_id. May this cause break seasonal tile? #24819