Differential D11 Diff 7277 binaries/data/mods/public/gui/campaign/campaign.js

Changeset View

Standalone View

binaries/data/mods/public/gui/campaign/campaign.js

This file was added.

				/**
				* ID of the current campaign. This is the name of the json file (not the "human readable" name)
				elexisUnsubmitted Not Done Inline Actions JSdoc comments allow to describe individual arguments, return arguments and the like using `@param`, `@return` etc.. (Better make them all consistent earlier than later before other contributors will add `//` comments to functions too with non-machine readable formats). elexis: JSdoc comments allow to describe individual arguments, return arguments and the like using…
				elexisUnsubmitted Not Done Inline Actions JSdoc comments for consistnecy, / elexis: JSdoc comments for consistnecy, /
				*/
				elexisUnsubmitted Not Done Inline Actions `g_CampaignName`? (since the JSON property is Name too) elexis: `g_CampaignName`? (since the JSON property is Name too)
				wraitiiAuthorUnsubmitted Not Done Inline Actions Volontarily no, as "campaign name" would be the human readable name imo wraitii: Volontarily no, as "campaign name" would be the human readable name imo
				elexisUnsubmitted Not Done Inline Actions Just `var g_Foo;` unless we need to distinguish between null and undefined. elexis: Just `var g_Foo;` unless we need to distinguish between null and undefined.
				var g_CampaignID;

				/**
				* Campaign template data from the JSON file.
				*/
				var g_CampaignTemplate;
				elexisUnsubmitted Not Done Inline Actions `g_CampaignSaveFilename`? elexis: `g_CampaignSaveFilename`?

				/**
				* name of the file we're saving campaign data in
				elexisUnsubmitted Not Done Inline Actions `g_CampaignSaveData` or `g_CampaignSaveState` ? elexis: `g_CampaignSaveData` or `g_CampaignSaveState` ?
				*/
				var g_CampaignSaveFilename;

				/**
				* Current campaign state, to be saved in/loaded from the above file
				*/
				elexisUnsubmitted Not Done Inline Actions Just why? I don't see any reads to this property. elexis: Just why? I don't see any reads to this property.
				var g_CampaignState;

				/**
				* This function is called by session.js at the end of a game. It should save the campaign save state immediately.
				*/
				elexisUnsubmitted Done Inline Actions Sentences start with a capital letter. elexis: Sentences start with a capital letter.
				function onCampaignGameEnded(data)
				{
				g_CampaignID = data.ID;
				g_CampaignTemplate = data.template;
				g_CampaignSaveFilename = data.save;
				g_CampaignState = data.data;

				if (data.endGameData.status === "won")
				elexisUnsubmitted Not Done Inline Actions How is that TODO helping anyone? elexis: How is that TODO helping anyone?
				{
				if (!g_CampaignState.completed)
				g_CampaignState.completed = [];
				if (g_CampaignState.completed.indexOf(data.level) == -1)
				g_CampaignState.completed.push(data.level);
				}

				saveCurrentCampaign();
				}

				/**
				* @param level the ID of the level.
				* @returns true if the level is available.
				*/
				function meetsRequirements(level)
				{
				return !level.Requires && g_CampaignState.completed && MatchesClassList(g_CampaignState.completed, level.Requires);
				}

				elexisUnsubmitted Done Inline Actions IMO better off in https://en.wikipedia.org/wiki/Conjunctive_normal_form or https://en.wikipedia.org/wiki/Disjunctive_normal_form i.e return !requires \|\| completed && matches;, possibly with newlines indicating logical grouping elexis: IMO better off in https://en.wikipedia.org/wiki/Conjunctive_normal_form or https://en.wikipedia.
				wraitiiAuthorUnsubmitted Done Inline Actions TBH I find the imperative way easier to read, but it's probably through habit. wraitii: TBH I find the imperative way easier to read, but it's probably through habit.
				/**
				* @param level the ID of the level.
				* @returns true if the player has completed the level
				*/
				function hasCompleted(level)
				{
				return g_CampaignState.completed && g_CampaignState.completed.indexOf(level.ID) != -1;
				}
				elexisUnsubmitted Not Done Inline Actions `return !level.Requires \|\| g_CampaignState.completed && MatchesClassList(g_CampaignState.completed, level.Requires)` ? elexis: `return !level.Requires \|\| g_CampaignState.completed && MatchesClassList(g_CampaignState.
				wraitiiAuthorUnsubmitted Not Done Inline Actions Not nearly as readable imo, but up to you. wraitii: Not nearly as readable imo, but up to you.
				elexisUnsubmitted Not Done Inline Actions Would have never guessed that it reuses the class matching system from the code elexis: Would have never guessed that it reuses the class matching system from the code
				elexisUnsubmitted Not Done Inline Actions j s d o c elexis: j s d o c
				elexisUnsubmitted Done Inline Actions Explicit checks `===` and `!==` are incredibly important to distinguish falsy values, most often `0` from `undefined`. The reader should always be informed if such a check is crucial or not. If we use explicit checks everywhere, then the reader isn't informed if that explicit check is crucial here or not. So all irrelevant explicit checks had been removed in `gui/`. I have also tried a forum thread about making such things a coding convention entry, but the only feedback was Josh giving a like. xd elexis: Explicit checks `===` and `!==` are incredibly important to distinguish [[https://developer.
				wraitiiAuthorUnsubmitted Done Inline Actions I wasn't sure what our convention on that was, actually. Seems sensible enough to me. wraitii: I wasn't sure what our convention on that was, actually. Seems sensible enough to me.