Sign In
Create Account
1
PatchIt! Dev-log #5
Posted by
le717
,
06 March 2013
·
97 views
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.
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.
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, author, and name, 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.)
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
(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 mod1.0.zip
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 mod2.0.zip
(4) [GENERAL]
(5) Jimmy
(6) 2.0
(7) This is my mod
(8) [DESCRIPTION]
(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, author, and name, 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.)
Interesting use of the name 'Jimmy' for the author
I've never scripted in Python before, but is it not possible to have the description length 'infinite'? Which you would implement by allowing as many lines as desired, in the same numbered format, and set the program to read until it reaches the end of the file. Or perhaps it keeps looking for a number within brackets until there are no more?
For instance, in Pascal, you can continuously read a text file using the 'while not eof do' function, whereby it will loop through the contained code until the program reaches the end of the file.