Reveal the map on the wall demo map (so that it isn't entirely nor partially invisible independent of the selected gamemode and ownership).
Reviewed By: sanderd17
"XXXXXX" : "Optionally define other things here, like we would for a scenario"
The hint states that one can add properties, but not which ones and therefore might be confused with map-specific properties.
The proposal to use the property doesn't work, because the user can (and is supposed to be able to) control the gamesetup settings on random maps. If the the map revelation option is disabled, it will start invisible.
That's the one
They could be ;-)
Yes, having that pointless property is just that. I was mostly trying to be funny.
So making that 140 (and introducing that fancy thing to random maps) shouldn't be that bad.
Yes, players selecting stupid things will result in stupid things happening. But this is a demo map, so having a sane default should be enough.
I just object to not going with the easy solution and instead adding another file (but I do object that one Units Demo change that destroyed the nice single file property of that map (and that one can have such custom code in there if one wants to)).
Agree that avoiding the file would be ideal. We also considered changing the owner of the walls to 1, but then it won't work if the assigned player happens to be > 1 (and since it's a random map we can't force the playercount).
When setting the JSON flag, it will indeed set it as default.
Then we would have to deal with the structures decaying, which just delays the issue.
The map should be of type endless. Is that bug that we don't check whether the victory condition holds on game start? (If yes, we might want to do that only after the first turn (else we could run into issues with skirmish replacements).)
That should be something that the gamesetup rewrite fixes. Also we should really nuke (or fix) that option.
Should we really show demo maps in that case? Yes, that would make that "all" part a blatant lie, but those are just useful for testing (or when someone makes a new map in atlas and forgets to tick (or untick) a checkbox).
I do not consider the RevealMap setting even similar to that one. But a sane gamesetup should be able to handle both nicely.
(Singular is not really appropriate in that context. I won't add more complexity to D322, there is still a rewrite needed to fix the infamous config option (we could only save the chosen settings and derive g_GameAttributes and not save the latter to a file nor broadcasting it via network).
This workaround will work around the bug in this case, but next time but we will end up in the same situation next time we have a similar issue with a non-demo map.
Doesn't matter if it's population capacity, map revelation or any other gamesetting. The design goal has been and still is that the user can chose any setting on random maps and change the map without getting his configuration changed after changing the map.
I'm not sure if we should care about revealed non-demo maps. And if we consider the user changing things and keeping that to be important then we should also regard the user doing stupid things and getting such results to be a consequence of that.
Then we need to remember if some setting was changed explicitly.
The user expects settings to remain the same when selecting a different random map. This is not related to whether or not the user has set a setting explicitlyo r whether it was the default and the user intended to keep it that.
Don't understand this comment
The code is working perfectly fine and meets all criteria. Don't see the point of raising a concern. If there is a patch that changes settings behind the users back, that would be a good reason to raise a concern.
I'd expect settings I set to remain that way, and pick whatever the map has for the rest. Or should we load some trigger scripts on other random maps just because one of the previously selected ones did? (Not talking about victory conditions here.)
Maybe I just fail to see the point why we need to add a new file when a simple setting could do the same.
Maybe the best evidence that random maps are intended to adapt to the user settings while atlas maps can't is the feature to launch a game with a random map.
The gamesetup controller can select the "Random" map and change settings freely, then the game selects a random map and that map is supposed to adapt to the given settings.
Overwriting the user choice can work for one or two settings, but the intended direction is the opposite.
Consider a random map enforcing the map size like FeXoR proposed in #1834, or a random map enforcing the victory condition.
Imagine the user can select the "Random" random map and selects regicide, 1v1 on a non-revealed large map, he might start up with a wonder victory game, revealed map on a tiny 6 player map.
So the "Random" item would lie, be ineffective and/or have to be removed.
can't answer since scenrio's and skirmish maps are played that less often than random maps...
y, as changing the map, is changing the map, not changing a ton of different random settings implied with that.
What reason are you referring to? I think the main reason is the possibility of the fact that "every" combination of setting is allowed and that every time you play the same map, it still is different (I never got sick of playing ambush XD)
#chatspam so chat won't be read, imo just don't change settings
I will remove this concern because it is not specific to this patch.
This does by no means mean I disagree with @leper 's point but rather that this about a design decision: Who should have priority for settings: Player or map (and should there be exceptions) ... and I don't see this being resolved here ;)