Anything in bold is something I want more opinions about.
Quote:
Originally Posted by jackie_w
As an occasional patch contributor I'll be happy to test your new system if I can do the testing on Windows. Is this possible at the moment?
|
Yes, but you will need to compare the output manually (the checksums).
Quote:
Originally Posted by jackie_w
Also a comment about Offset/Find/Replace…
I like the new option which places each of these on its own line rather than combining into a single line. It should be less confusing for new users who want to tweak the defaults. For me the single line of the current system is what makes it more awkward to ensure that the before/after strings are the same length.
|
Yes. That is part of the flexibility of the new system. A patch can go in one line, multiple lines, or even a combination. It supports any feature YAML (the markup language) supports.
Quote:
Originally Posted by jackie_w
I'm looking forward to being able to patch nickel zlib css in a more user-friendly way. I'm hoping it will make it possible for users to fine-tune them.
|
Yes. I'm still working out how to extract the strings efficiently, but I'm making progress so far. If @GeoffR has any tips, they would be useful.
I am also looking for ideas on how everyone wants this feature to look (simple find/replace, find by CSS ID, etc).
Quote:
Originally Posted by oren64
@geek1011 it works ok, what the difference between the old and new file.
|
My version has more built-in checks and will end up having it's own format and become a complete patching system. The drop-in binary was only for testing and migration. Also, I'll be writing a converter to convert from the old format to the new one.
How many people want this? I could also just add compatibility with the old format, but parsing it is error-prone due to its ambiguity.
Quote:
Originally Posted by jackie_w
I should have been more specific in my question. I saw a couple of linux files (testalllibnickel.sh and testallnickel.sh) which I thought (perhaps wrongly) were needed to check old-result vs. new-result.
|
You were right (partially). Those scripts just automate checking the differences between the old and the new patcher.
Quote:
Originally Posted by dmapr
Code:
- FindBaseAddress: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n"
- ReplaceString: {Offset: 0x0, Find: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n", Replace: "ReadingFooter {min-height:15px;max-height:15px;}\n"}
One thing that stands out in some of these examples is repeating the search string in the FindBaseAddress and ReplaceString instructions. Is it possible to write the above as
Code:
- FindBaseAddress: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n"
- ReplaceString: {Offset: 0x0, Replace: "ReadingFooter {min-height:15px;max-height:15px;}\n"}
omitting the Find parameter and the default being the value passed to the FindBaseAddress? |
That seems like a good idea. I could implement that as a FindReplaceString instruction which would combine the two.
What do you think of that?