View Single Post
Old 07-13-2018, 07:00 PM   #120
geek1011
Wizard
geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.geek1011 ought to be getting tired of karma fortunes by now.
 
Posts: 2,808
Karma: 7423683
Join Date: May 2016
Location: Ontario, Canada
Device: Kobo Mini, Aura Edition 2 v1, Clara HD
Quote:
Originally Posted by JSWolf View Post
It would be a useful feature. And isn't the idea with the new patching system to make things easier?
Yep, but both in the code, maintenance, and usage. Currently, kobopatch is only 130% the LOC compared to patch32lsb (including tests, which makes it easier to code), yet it has more features. It already has features to make maintenance easier (FindZlib, FindZlibHash, ReplaceZlib, FindReplaceString, ResetBaseAddress, automated patch testing, etc). It has features to make usage easier (multiple patch files for single binary, add arbitrary files to KoboRoot, compiling and adding translations, store patch enabled state in config file). I'm trying to balance the ease of use with the ease of maintenance and code.

If I can figure out an easy and elegant way to store changes to variables in patches, I'll implement it.
geek1011 is offline   Reply With Quote