Changeset View
Standalone View
binaries/data/mods/public/gui/common/gamedescription.js
| Show First 20 Lines • Show All 210 Lines • ▼ Show 20 Lines | |||||
| /** | /** | ||||
| * Sets an additional map label, map preview image and describes the chosen gamesettings more closely. | * Sets an additional map label, map preview image and describes the chosen gamesettings more closely. | ||||
| * | * | ||||
| * Requires g_GameAttributes and g_VictoryConditions. | * Requires g_GameAttributes and g_VictoryConditions. | ||||
| */ | */ | ||||
| function getGameDescription(extended = false) | function getGameDescription(extended = false) | ||||
| { | { | ||||
| let titles = []; | let titles = []; | ||||
| if (!g_GameAttributes.settings.VictoryConditions.length) | |||||
elexis: From an UI point of view, we should prioritize Conquest above the other VCs. We could add a… | |||||
| { | |||||
| let victoryCondition = g_VictoryConditions.find(data => data.Name == "endless"); | |||||
| if (victoryCondition) | |||||
Done Inline ActionsThe idea behind the label value split was that people only have to read the orange labels if they want to know the settings quickly, so "Endless game" would be more precise (otherwise it could be an endless tomato or endless fish match too). The description should explain the consequences of that setting rather than the causes of that setting, i.e. something like elexis: The idea behind the label value split was that people only have to read the orange labels if… | |||||
| titles.push({ | |||||
| "label": victoryCondition.Title, | |||||
| "value": victoryCondition.Description | |||||
| }); | |||||
| } | |||||
| let victoryIdx = g_VictoryConditions.Name.indexOf(g_GameAttributes.settings.GameType || g_VictoryConditions.Default); | for (let vc of clone(g_GameAttributes.settings.VictoryConditions).sort((a, b) => a > b ? 1 : a < b ? -1 : 0)) | ||||
| if (victoryIdx != -1) | { | ||||
| let victoryCondition = g_VictoryConditions.find(data => data.Name == "endless"); | |||||
| if (victoryCondition) | |||||
| { | { | ||||
| let title = g_VictoryConditions.Title[victoryIdx]; | let title = victoryCondition.Title; | ||||
| if (g_VictoryConditions.Name[victoryIdx] == "wonder") | if (vc == "wonder") | ||||
| title = sprintf( | title = sprintf( | ||||
| translatePluralWithContext( | translatePluralWithContext( | ||||
| "victory condition", | "victory condition", | ||||
| "Wonder (%(min)s minute)", | "Wonder (%(min)s minute)", | ||||
| "Wonder (%(min)s minutes)", | "Wonder (%(min)s minutes)", | ||||
| g_GameAttributes.settings.WonderDuration | g_GameAttributes.settings.WonderDuration | ||||
| ), | ), | ||||
| { "min": g_GameAttributes.settings.WonderDuration } | { "min": g_GameAttributes.settings.WonderDuration } | ||||
| ); | ); | ||||
| let isCaptureTheRelic = g_VictoryConditions.Name[victoryIdx] == "capture_the_relic"; | let isCaptureTheRelic = vc == "capture_the_relic"; | ||||
| if (isCaptureTheRelic) | if (isCaptureTheRelic) | ||||
| title = sprintf( | title = sprintf( | ||||
| translatePluralWithContext( | translatePluralWithContext( | ||||
| "victory condition", | "victory condition", | ||||
| "Capture the Relic (%(min)s minute)", | "Capture the Relic (%(min)s minute)", | ||||
| "Capture the Relic (%(min)s minutes)", | "Capture the Relic (%(min)s minutes)", | ||||
| g_GameAttributes.settings.RelicDuration | g_GameAttributes.settings.RelicDuration | ||||
| ), | ), | ||||
| { "min": g_GameAttributes.settings.RelicDuration } | { "min": g_GameAttributes.settings.RelicDuration } | ||||
| ); | ); | ||||
Not Done Inline ActionsI always wanted that "endless" hardcoding to disappear, I had hoped it would be possible in this diff, but indeed we need strings. Perhaps we could hide it by making that some kind of hidden victory condition, but probably not since it would mean that this vc could be deleted and then hell breaks loose. But it might be good to centralize the hardcoding in the code rather than having one hardcoding in each processing of vcs, if that's possible. elexis: I always wanted that "endless" hardcoding to disappear, I had hoped it would be possible in… | |||||
Not Done Inline ActionsJust leave the strings remain at settings.js and import them here? elexis: Just leave the strings remain at `settings.js` and import them here? | |||||
Not Done Inline Actionsthe problem here is that g_VictoryConditions shouldn't contain "endless" as we loop over that in gamesetup. So we could store it in settings, but then we need to have a getter for it specifically, thus creating more hardcodation, so I don't really see the benefit of doing so. bb: the problem here is that `g_VictoryConditions` shouldn't contain "endless" as we loop over that… | |||||
Not Done Inline ActionsWe should eventually group this descriptive text with the other gamesetting manifest currently in gamesetup.js (obviously should be moved to common/gamesetup/ or something like htat). Also check the ticket on the milestone for my proposal to display all gamesettings in the gamesetup for clients, so that clients don't have to open and switch the tabs. (Will take a closer look very soon.) elexis: We should eventually group this descriptive text with the other gamesetting manifest currently… | |||||
Not Done Inline Actionsstrings are used in the objectives window too, so that need to be considered bb: strings are used in the objectives window too, so that need to be considered | |||||
| titles.push({ | titles.push({ | ||||
Not Done Inline ActionsThat's alphabetic sort according to internal identifier / filename? Needed to group Conquest Units / Structures? elexis: That's alphabetic sort according to internal identifier / filename? Needed to group Conquest… | |||||
Not Done Inline Actionsn, just to have a order, i.e I didn't want it to depend on insertion order, but some fixed order bb: n, just to have `a` order, i.e I didn't want it to depend on insertion order, but some fixed… | |||||
| "label": title, | "label": title, | ||||
| "value": g_VictoryConditions.Description[victoryIdx] | "value": victoryCondition.Description | ||||
Done Inline Actionscontinue elexis: continue | |||||
| }); | }); | ||||
Not Done Inline ActionsThe timeout labels above come first because they combine the VC label and the timeout label in one. Therefore either the label should be hidden for these cases or the labels should be decoupled and appear after the VC label. elexis: The timeout labels above come first because they combine the VC label and the timeout label in… | |||||
Not Done Inline Actionsbut the labels are hidden right? We set a default value for title in L230 and overwrite it in those cases... bb: but the labels are hidden right? We set a default value for `title` in L230 and overwrite it in… | |||||
| if (isCaptureTheRelic) | if (isCaptureTheRelic) | ||||
| titles.push({ | titles.push({ | ||||
| "label": translate("Relic Count"), | "label": translate("Relic Count"), | ||||
| "value": g_GameAttributes.settings.RelicCount | "value": g_GameAttributes.settings.RelicCount | ||||
Not Done Inline Actions(Was there a particular reason to kill the comma? Maybe it was introduced because there was a reason?) elexis: (Was there a particular reason to kill the comma? Maybe it was introduced because there was a… | |||||
Not Done Inline Actions(If my memory doesn't fail you yelled about it on irc someday) bb: (If my memory doesn't fail you yelled about it on irc someday) | |||||
Not Done Inline ActionsIndeed I'm a comma-after-and-avoider, which is why I wonder why there is one. Someone else must have had some kind of opinion. This comma comes from D104 (I would have guessed transifex). elexis: Indeed I'm a comma-after-and-avoider, which is why I wonder why there is one. Someone else must… | |||||
| }); | }); | ||||
| if (g_VictoryConditions.Name[victoryIdx] == "regicide") | if (vc == "regicide") | ||||
| if (g_GameAttributes.settings.RegicideGarrison) | if (g_GameAttributes.settings.RegicideGarrison) | ||||
| titles.push({ | titles.push({ | ||||
| "label": translate("Hero Garrison"), | "label": translate("Hero Garrison"), | ||||
| "value": translate("Heroes can be garrisoned.") | "value": translate("Heroes can be garrisoned.") | ||||
| }); | }); | ||||
| else | else | ||||
| titles.push({ | titles.push({ | ||||
| "label": translate("Exposed Heroes"), | "label": translate("Exposed Heroes"), | ||||
| "value": translate("Heroes cannot be garrisoned, and they are vulnerable to raids.") | "value": translate("Heroes cannot be garrisoned, and they are vulnerable to raids.") | ||||
| }); | }); | ||||
| } | } | ||||
| } | |||||
| if (g_GameAttributes.settings.RatingEnabled && | if (g_GameAttributes.settings.RatingEnabled && | ||||
| g_GameAttributes.settings.PlayerData.length == 2) | g_GameAttributes.settings.PlayerData.length == 2) | ||||
| titles.push({ | titles.push({ | ||||
| "label": translate("Rated game"), | "label": translate("Rated game"), | ||||
| "value": translate("When the winner of this match is determined, the lobby score will be adapted.") | "value": translate("When the winner of this match is determined, the lobby score will be adapted.") | ||||
| }); | }); | ||||
| ▲ Show 20 Lines • Show All 169 Lines • Show Last 20 Lines | |||||
From an UI point of view, we should prioritize Conquest above the other VCs. We could add a GUI_order number in the JSON file. The VCs that aren't a Conquest one can keep the same value, in which case alphabetic Title order can be used. fpre had a similar sorting order committed to lobby.js to prioritize buddies and then sort by state secondly. number.toFixed(3) + string or something.
Can be done as a follow-up.