lang: Don't create global config in loadLanguage
#1178
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #1177.
Don't attempt to save and load the global config in
loadLanguage
unless it exists.Prevents
loadLanguage
, which is called very early, from creating the global config beforesetSteamPaths
has a chance to define some paths that are needed to create the global config.Most notably, this fixes Luxtorpeda and Roberta variables from being incorrect when created too early by
loadLanguage
, as this function creates the global config beforesetSteamPaths
has a chance to defineSTEAMCOMPATOOLS
which is needed in order to build a valid path forLUXTORPEDACMD
andROBERTACMD
. SteamTinkerLaunch tries to auto-detect Luxtorpeda installations and this has not worked for probably the last 2 years or so, sinceloadLanguage
created the global config too soon. However, Luxtorpeda could always be and still can be manually selected by the user, so the only breakage was for the auto-detection.This may possibly fix other similar cases as well, where Steam paths are needed in the global config but it is created before paths exist.
This fix will not retroactively apply to global configs, as we don't know whether the variables are incorrectly generated by us or the user. Bad global configs will need re-generated.
This PR needs some testing to ensure the
-f "$STLDEFGLOBALCFG"
check is safe. I think it is, but this will need a bit of further testing.