Hi,
I'm trying to make a portable version of this game and it uses a HKCU registry key.
So i set it up with [RegistryKeys] and it works fine, the .reg gets saved and its fine.
However, the second time the app is run, the settings (which are stored in said registry key), are all messed up.
I investigated the issue and found that the PAL Launcher saves the .reg wrong.
Below are the registry key i got with regedit, by running the game without PAL and the file the Launcher saved. Note the difference
Regedit Export :
[HKEY_CURRENT_USER\SOFTWARE\Failbetter Games\Sunless Sea] "UnitySelectMonitor_h17969598"=dword:00000000 "Screenmanager Resolution Width_h182942802"=dword:00000500 "Screenmanager Resolution Height_h2627697771"=dword:00000300 "Screenmanager Is Fullscreen mode_h3981298716"=dword:00000000 "unity.player_sessionid_h1351336811"=hex:36,37,30,33,33,38,37,37,32,31,35,32,\ 31,39,30,33,35,31,37,00 "unity.player_session_elapsed_time_h192694777"=hex:34,39,35,37,31,00 "unity.player_session_background_time_h123860221"=hex:31,35,30,34,32,31,33,31,\ 32,33,38,31,31,00 "MusicVolume_h3041295148"=hex(4):00,00,00,40,33,33,e3,3f "SFXVolume_h2009793184"=hex(4):00,00,00,a0,99,99,e9,3f "BlurEnabled_h1049161833"=dword:00000001 "FontSize_h80309299"=hex(4):00,00,00,00,00,00,2a,40 "UIScale_h186351137"=hex(4):00,00,00,00,00,00,f0,3f
PAL Launcher saved .reg file:
[HKEY_CURRENT_USER\SOFTWARE\Failbetter Games\Sunless Sea] "UnitySelectMonitor_h17969598"=dword:00000000 "Screenmanager Resolution Width_h182942802"=dword:00000500 "Screenmanager Resolution Height_h2627697771"=dword:00000300 "Screenmanager Is Fullscreen mode_h3981298716"=dword:00000000 "unity.player_sessionid_h1351336811"=hex:37,39,39,36,37,37,34,39,31,32,30,37,\ 34,38,35,38,36,30,31,00 "unity.player_session_elapsed_time_h192694777"=hex:31,37,36,31,35,00 "MusicVolume_h3041295148"=dword:40000000 "SFXVolume_h2009793184"=dword:a0000000 "BlurEnabled_h1049161833"=dword:00000001 "FontSize_h80309299"=dword:00000000 "UIScale_h186351137"=dword:00000000 "unity.player_session_background_time_h123860221"=hex:31,35,30,34,32,31,33,32,\ 31,35,39,33,38,00
Can this be solved with custom code? Or is there an easy workaround
Thank you
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
All that's happening when saving the file, is the launcher is using NSIS's Registry plugin, which exports and imports the registry key. It's a standard import/export, we're not doing anything else with it.
The problem is that those values are incorrectly set to the dword type, when they should be the qword type (hex(b):). Because they are the wrong type, the NSIS Registry plugin only sees up to the first 32-bits, whereas qwords are 64-bits in size. The workaround would be to have either custom code that swaps the type to either qword or binary before the export and swap the type back to the incorrect dword type after the import, or use the appropriate .ini settings for PAL in a way that accomplishes the same thing. Though I'm not sure how to do that myself and it would be better if either the game or unity itself used the correct type in the first place.
Note: I'm pretty sure that in this case, 32-bit and 64-bit has nothing to do with cpu architecture. Someone more knowledgeable in this subject may freely correct me where and if I am wrong.
This is something that would need to be handled in custom code.
With the game running, can you confirm what type the registry is seeing those values as?
I don't have the game myself, so can't confirm it (not spending AUS$24.09 just to confirm something)
What I can see though is that the Windows Registry Editor shows the values in question as "Invalid DWORD (32-bit) value" when hex(4): is used. With hex(b): it shows as a valid QWORD (64-bit) value should. However, having said that, it does look like the byte-order might be reversed (though at least one of them goes above 32-bits even with the standard byte-order).
Here's an imgur imageset of screenies:
https://imgur.com/a/F5sEp
Note: Done on Windows 7 (64-Bit)
This is with the game running.
http://imgur.com/a/WY7C2
I have no idea what is happening.
Is that during the first run with PAL where it all seems to be working correctly, the second run with PAL where it messes up, or during normal running of the local version?
~3D1T0R
Normal run, without PAL.
With PAL, the first run works properly, as the keys are written, but the second gets bugged.
I did actually understand that bit from your first post. What I was asking was whether the images in the post were taken during a normal, fully functional (non-portable) run of the game, or from the first or second run of a PAL wrapped run of the game.
What would actually probably be most informative is if you were to run the standard local version of the game twice (to verify that it isn't screwing up), then take screenshots of the registry like you did before, and upload those.
~3D1T0R
As far as QWord and the registry are concerned, when trying to write a qword string to the registry the data needs to be exactly 16 hex characters long, no 0x prefix. The data is interpreted as bytes and not as a 64-bit number and that is a bit inconvenient so you need to reverse the strings you're trying to work with in the custom.nsh file.
daemon.devin
The problem is that Unity (the game engine used for the game being made portable) doesn't set the correct type, which causes the NSIS Registry plugin to not see half of the data as the value type is set wrongly.
It would be better (at least for now, and for other games made with Unity) if there was a setting for the NSIS Registry plugin to export values that are invalid as hex(#): where # is whatever hex value corresponds with the set registry type (and to ignore type related errors).
Although this should actually be default behaviour anyway, even the Windows Registry Editor exports as expected (values with invalid data for the set type get exported as hex(#):)