PatchIt! Dev-log #5

This is this first entry in the PatchIt! Dev-log, in which I digitize my writings, notes, ideas, and future of PatchIt! for everyone to read, comment on, give feedback, and get an idea of where I am going in the development.

No, that is not a typo. This is Dev-log #5. While this is the first online entry, I have written others before this one, but I am not wanting to release those due to many errors in the logic and ideas.

March 4, 2013
#5 PiP File Format Revision for Version 1.1 Stable Draft 1

I did not realize this when it was first drafted, but the PiP file format has some inherit flaws. Before I explain these flaws, I will give the current layout of the PiP file layout, in the form of a example file. I have added line numbers for clarity, they are not really written in the file.

(1) // PatchIt! Patch format, created by le717 and rioforce.
(2) [General]
(3) This is my mod
(4) Version: 1.0
(5) Author: Jimmy
(6) [Description]
(7) This is a description for my mod. Cool, huh?
(8) [ZIP]
(9) This is my

The inherit flaws are the length of a line and file layout. If the description (line 7) is longer that 161 characters (the calculated length), it will be either be written one two lines or be written on one but break the line numbering that PatchIt! relies on for getting the information. Both of these scenarios have the same effect: the name of the zip archive (line 9) will no longer be in the correct place, and a File Not Found error will be raised. It’s not just the description:  if any user-defined field is longer than 161 characters, then the entire file will be broken, with even more severity the closer to the top of the file. I’ve already added a length check into PatchIt! for the description, but a new format needs to be created to completely fix these errors. I will be adding a proper GUI into V1.1, so I will hold off on this backward-incompatible change until then. However, I need to go ahead and draft the new format, so I can be working on it. The following is Draft 1 of the new format. Again, line numbers are added for clarity. Lines 10 and 11 will not be indented, it is just that way thanks to the line numbers.

(1) // PatchIt! PiP file format V1.1, created by le717 and rioforce.
(2) [ZIP]
(3) This is my ?(. )?
(5) Jimmy
(6) 2.0
(7) This is my mod
(9) This is the first line of my description
(10) This is the second line of my description
(11) This is the third line of my description

In this first draft, I’ve essentially reversed the file layout. By placing the zip archive first, it will not be lost if any of the lines below it are longer. I would assume the shortest lines would the the version (line 6), author (line 5), and name (line 7), since I do not think there would be many mods whose name was more than 161 characters, and if there were, it would have an abbreviation or acronym, and unless scores of people work on a mod, the author field will not be filled up too much either. I could move the version above the author, but the layout makes more sense this way. By placing the description last, the mod creator has more space to describe their mod. If the new lines (10 and 11) are left empty, I can easily discard them and not display the blank space. I’ve left an empty pair of parentheses on line 3 in case I want to change the extension of the zip archive to something else to match the PiP file.

I would retain backward compatibility to install mods using thee current (legacy) format, only if someone wanted to use an older version of a mod or if a certain mod was never updated. However, all new patches would be written in and use the new format. (Backward compatibility for mod installation will be saved for another Dev-log, and will be explained here.)


6 thoughts on “PatchIt! Dev-log #5

    1. As I already told you, PatchIt is the first major program I have ever written. When I started, I had not idea an XML parsing module existed in Python, and using one would have (at that time) been very complex, because I would have to do a lot of line split and membership testing and some stuff I’m still figuring out. That’s why I did not even think about or consider an XML for the PiP file.

      1. “Line split”, “membership testing”… Ok, it is probably harder to use than I thought, as I don’t know what are these. Furthermore, a program is always in evolution, so starting with a custom file format was a good idea and you may whenever improve it or completely change technology. I have one important warning: always use/create open file format.

      2. I meant that using an XML would have been hard at the beginning. I still have not tried out that XML module, so I do not know how it works. But I’m sure it does not need all those things I said.

        Of course a program is always in progression! Go read the PatchIt change log starting at Beta 1. I’ve made so many changes to it, even after the 1.0 release, that I understand that something is always improving!

        And that’s why I started this dev-log: To tell my future plans and give the users a chance to chime in, say what they think, and have a bit of fair warning that things will change. 🙂

        By “open”, do you mean on that other programs can/do use, or open documentation/format? If the former, that was my plan from the beginning. If the latter, it’s hard to do that when your source code is open-source. 😛

      3. Fine if a link to an other blog?

        Version 1 Stinks but Release it anyway

        Similar to the way Linus made Linux grow and be what it is today. As soon as someone proposed a patch, it was verify and he was adding it to the Linux kernel. User feedback and co-developers were highly important in Linux development.
        Like that, so for example files like PNG, XML, HTML, etc. I also suggest that setting files are actual text file and not binaries. (Something like this is not possible for most video/audio open format.)

        In conclusion, the way you are developing PatchIt is already mostly what I have said. Which is good, IMO. 😛

        Edit by le717: Put blog link in an <a> tag. I don’t mind links, but that site… I may remove it later. 😉

      4. No, I don’t mind links; I’m just kinda wary of them sometimes. I’ve seen that blog before, and it has some content that I enjoy and dis-lilke. I may remove the link later. 😉

        Makes since. And I actually could use a binary format for the PiP or settings file.

        with open('settings', 'wb') as settings:
        # Write content here. And 'wb' stands for 'W'rite 'Binary', while text is 'wt'.

Comments are closed.