mp_create_game: Show preview if map_file is set

[jostephd]

Fixes the second bullet of #4397 (comment).

Could someone double check the change to the generator_assigned condition? Is it about the case that a scenario file defines both map_file and a map generator? I would have expected that to be an error, actually.

[gfgtdf]

Could someone double check the change to the generator_assigned condition?

Is it about the case that a scenario file defines both map_file and a map generator?

yes.

The result of the map generator is stored in the map_data attribute , so that code checks whether the map was already generated and does so if it didnt happen yet.

[gfgtdf]

from looking at the code im suprised this works, since all codes you are changing are inside type == ng::level::TYPE::RANDOM_MAP blocks, and i'd expect that the normal mp maps are not 'random maps'. In fact random maps are the only type of maps where map_file does not make sense.

[jostephd]

@gfgtdf That branch of the switch statement handles all of the following:

		case ng::level::TYPE::SCENARIO:
		case ng::level::TYPE::USER_MAP:
		case ng::level::TYPE::USER_SCENARIO:
		case ng::level::TYPE::RANDOM_MAP: {

[gfgtdf]

@gfgtdf That branch of the switch statement handles all of the following:

right, forogt how C++ switch works for a second.

but don't we use FALLTHROUGH for intentional fallthough switches and don't he compiler give a wanring for missing FALLTHROUGH?

[jostephd]

but don't we use FALLTHROUGH for intentional fallthough switches and don't he compiler give a wanring for missing FALLTHROUGH?

Compilers probably suppress that warning when a label is followed by another label with no statements in between. Anyway, falling through happens whenever there's no break; statement; comments don't affect control flow.

[jostephd]

By the way, I wanted to put somewhere an accessor function, foo::map_data() that just gets the map_data from either the map_data attribute or the map_file attribute, whichever exists, and use that accessor function in all three places that currently access "map_file"...but I couldn't figure out where to put the new function. The three places that handle map_file don't seem to even have a common #include.

[soliton-]

Factoring the code out to a common function sounds good. Not sure where to put it either though.

[jostephd]

I could just create a non-member function somewhere and have the three places use it. Even if that's not the best possible place to declare the function in, we can move it to a more suitable home when we come up with one.

CC @Vultraz

[gfgtdf]

well at least one of three function that use map_file don't 'access' it they, read map_file and store it into map_data. So not sure how muhc there is in common actually.

[jostephd]

well at least one of three function that use map_file don't 'access' it they, read map_file and store it into map_data. So not sure how muhc there is in common actually.

I thought of a function that takes a config object and returns a string. That string will be c.has_attribute("map_file") ? filesystem::read_map(c["map_file"]) : c["map_data"]. All three locations can use that, I think.

[gfgtdf]

hmm no the saved_game code does more like if c.has_attribute("map_file") then c["map_data"] = read_map(c["map_file"]) end return c["map_data"]; and in fact i think that'd also make more sense for the mp_create code so that the map_file is not read twice.

[jostephd]

and in fact i think that'd also make more sense for the mp_create code so that the map_file is not read twice.

Done

[sevu]

Tested and works

[jostephd]

error validation: Invalid key 'map_file=' in tag [multiplayer]

[jostephd]

The rebase should fix this.