Closed Litro closed 3 years ago
L1nkZ
commented
3 years ago Hi,
Yes this could be a feature. This would require a Rust -> JS binding that sends the plist's content as well as the current client patch index, and adding a start_index argument to the JS -> Rust binding that starts the patching process.
I don't think it's a common use case though, is it?
Litro
commented
3 years ago usually there is case where player didn't has or yet with latest patch, well it was web / site patch or connection fault. with current thor patcher player can't see if he is on the last patch or not. if thor patcher didn't or can't receive any new patch (but let's say there is new patch). if the patch is crucial enough, and player didn't got the patch and got crashed upon the game it become question why? and what happen... I seldomly got this issue but yeah there is.
imo this is good feature to have, to sync client in patch just to know if the player has the latest patch.
L1nkZ
commented
3 years ago Oh okay, I see. You mean, being able to modify the cached patch index yourself (as a player) in case you applied an offline update manually?
Yes I agree that this would be useful to have. I made the patcher cache file (rpatchur.dat) a binary file because I thought nobody would have to manually edit it.
Making that file a text file (JSON or whatever) would solve this problem.
let's say if in plist.txt the latest is 2021 and the client last patch is 2020 it will show 2020/2021 and add config where user can set the last patch in client so can select to re-patch from specific number like jikari patcher didn't need to re-download entire plist.txt