Open zbee opened 2 months ago
I created a pre-release version with additional logging to help identify the cause of your issue. Please install the pre-release version debug-v0.2.0.1 and provide the additional log messages.
Depending on which line is causing your issue it might be necessary to share a screenshot of either:
I'm specifically talking about the shortcuts Google Play Games (Beta) creates at:
%AppData%\Microsoft\Windows\Start Menu\Programs\Google Play Games
Textual content is only required from the beginning of the file until the name of the game after the googleplaygames://launch/
URI. This part should not include any personal details like Windows user name or similar.
In my case all shortcuts contain the following at the beginning:
L<control or Unicode characters>googleplaygames://launch/?id=<game ID>&lid=<some number>&pid=<some additional number><optionally additional control or Unicode characters>„<game name>“, <localized application name without (Beta)><other data not required to identify the issue>
The regular expression used to extract the game start URL creates an array with 5 parts:
googleplaygames://launch/?id=
<game ID>
&lid=<some number>&pid=<some additional number>
The only issue in regards to shortcut content I personally encountered was caused by Google Play Games (Beta) temporarily deleting all shortcuts for an unknown reason. Fixing this required to restart the application once.
I removed 1 google play game from my library and ran the import again with 0.2.0.1.
I then realized from starting your next steps that I had a shortcut in there to test, simply a url shortcut to googleplaygames://launch/?id=<game id>
, I removed that and ran the import again - however it still failed.
My shortcuts are ... interesting. When I open their properties I cannot copy anything like normal shortcuts, and when I open them in fleet or sublime it's just hex, not textual content like if I make a custom shortcut or open any desktop shortcut, et cetera. I am under Windows 11, if you reckon that would be the difference.
Here are my 'protected' shortcuts: shortcuts.zip (this is the entirety of the contents of the folder as ran for the 'cleaner' logs above)
Just as a note, they were in the same 'protected' state when I first imported the games before 0.2.0, and they did import successfully (though with no launch, and the name was just the game id).
I tried reinstalling a game, and it produced the same type of shortcut.
Apologies for not being able to be of more assistance in regards to these shortcuts.
It's okay. Providing said shortcut archive is enough to fix it. I cannot comment on fleet or sublime. Notepad++ at least displays the shortcut data in a way that matters in regards to the used regular expressions.
(As a side note Google developers seemingly created .url
shortcuts using .lnk
type. They are definitely not regular .lnk
shortcuts. It's something that resulted in having to write multiple workarounds to get the important data for game launch and time tracking instead of using the right commands to get everything at once.)
I guess a short term fix would be to add a setting where users have to provide two values, the complete description in the first one and only the game name in the second one. These values would then be used to change how the regular expression for game name parsing works.
A fix not depending on user input will likely require to test different language / locale settings to incorporate some internal list how game names are created.
I'm using Windows 11 myself but the description field is not using the same structure. I tried different games especially in regards to special characters like trademark symbol or similar. But I did not expect that different device settings will affect the description field besides the localized application name.
As an example the shortcut content of Eversoul
with de-DE
device settings:
googleplaygames://launch/?id=com.kakaogames.eversoul&lid=1&pid=1
<optional special or Unicode characters>
„Eversoul“, Google Play Spiele
and en-US
device settings (at least I assume you might be using en-US):
googleplaygames://launch/?id=com.kakaogames.eversoul&lid=1&pid=1
<optional special or Unicode characters>
Eversoul - Google Play Games
The issue here is that there's a different separator between game name and application name. Plus the first character not belonging to the game name is missing in your case which would also result in a failure in regards to time tracking.
The reason to even parse any of these values is that I'm not sure if lid
and pid
will always be 1
or not.
(Technically even googleplaygames://launch/?id=<game ID>
, meaning googleplaygames://launch/?id=com.kakaogames.eversoul
would work to launch the game. But I don't want to cause additional unexpected bugs as a result of bad assumptions.)
I might add time tracking that doesn't depend on retrieving the real game name
but this would also result in import of games reverting back to using game ID
for the name field of imported games. I personally disliked this behavior.
I am glad that was enough to examine the shortcuts. I am using en-US, yeah.
I can certainly see the problems with handling the textual content here ... I suppose another approach could be a setting for the addon where the user chooses a language code, and then based on that choice there is a different regex that would be applied to the shortcut content.
I prefer game name
over the game ID
as well, certainly agree with you there.
It's most likely possible to query said user chosen language/locale settings dynamically but it would still require to create an internal list of possible description field variations before adding this. I have no clue how many different variations exist. Considering Google Play Games (Beta) is available in over 100 countries I have my doubts it would be reasonable to test all of them.
I'll rather reuse the description part of your shared image. Create one for my own settings and add them as part of an exemplary guide on the settings page itself.
I plan to add the following:
As an intermediary step I released v0.2.1 that restores the old behavior and uses game ID as fallback for game name if shortcut data parsing is defective.
I finished creating the settings page including all input fields and examples.
Missing steps for a proper fix are using these values to dynamically create the regular expression for game name parsing and verifying the input. I'm not sure if I should additionally check if a shortcut corresponding to the set values exists. I guess a checkbox to enable a strict verification might make sense.
As an additional intermediary step I will release a fallback for time tracking if game name parsing fails. At least right now game start URL parsing is completely independent of device settings meaning a fallback for this part is not necessary.
Second intermediary step allowing game launch as long as game start URL parsing works is now released with v0.2.2.
In other words everything except game name parsing which requires the dynamic regular expression is now done.
The intermediary release v0.2.3 changes game name retrieval to use shortcut names without extension as fallback instead of the previously used game IDs. This allows to return readable names even without using advanced settings.
I still plan to add advanced settings to improve game name retrieval but these settings will be optional.
With 0.2.0 I now get this error when I removed one game and attempted to import it again: