Jump to content





Photo

PatchIt! Dev-log #5

Posted by le717 , 06 March 2013 · 153 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.

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 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.)



Photo
JimbobJeffers
Mar 06 2013 09:58 PM

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.

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.

 

I... did not catch that. I wrote this down on paper first, and typed it up yesterday. I took no thought to what name I put there.

 

Now that you mention that, yes, it could be possible. A quick research lead me to these:

 

http://stackoverflow.com/a/4866330

 

http://stackoverflow.com/a/4796812

 

And of course, there is always the tutorial I followed to learn Python:

 

http://swaroopch.com...n-input_output/

 

I might end up merging the code from the second Stack Overflow and Byte of Python.

 

I really did not think about that. Thanks! This is way I wanted to start a Dev-log. Someone else may have and idea or solution I did not think of.

 

Also, I've already made a Draft 2 of this, so it will not mention this "keep reading file" idea. ;)

July 2014

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728 29 3031  

Recent Entries

Recent Comments