PatchIt! Dev-log

Sign in to follow this  
  • entries
  • comments
  • views

About this blog

The future, thoughts, and ideas on PatchIt!

Entries in this blog


PatchIt! Dev-log #10

March 11, 2013,

Revised May 29, 2013

#10 Post-creation, in-app editing of PiP file

@JimbobJeffers made this suggestion for PatchIt!: perhaps it would be possible to edit the PiP file after creating it, but from within PatchIt! instead of an external editor. I thought about this idea, and it would be a great addition to PatchIt!, but it would have to come later on in the V1.1.x series. In this Dev-log, I will very roughly explain why this addition will work. (I said very roughly because this Dev-log is very scattered, and may be harder to follow than my other Dev-logs.)


PatchIt! Dev-log #9 has been intentionally skipped. The contents of the Dev-log dealt with the creation of a GUI, and the library that was to be used for such. However, the conclusion it reached is no longer valid, as other ways a GUI could be implemented have come up, and are being researched. Therefore, PatchIt! Dev-log #9 will not be posted.

Since I will already have a full GUI written up and an multi-line editor for Patch Creation (allowing everything to be done in one step), I can reuse that code and auto-populate it with the info from the PiP file. But I’m getting ahead of myself. When PatchIt! is loaded, the user will have the standard options, but there will be a new option: Edit a PatchIt! Patch. When it is clicked, the user will select a PiP file, all the info will be gathered, and the multi-line editor will come up. But first, the validity line is read, ensuring it is a Patch, and a Modern Patch at that (if the Legacy Installation module is still present), and a file check for the Patch archive will be conducted to ensure it exists. Only if everything checks out will the editor come up. It will look like the Patch Creation screen, except the Game field will be grayed out, and cannot be changed. Of course, there will also be the obligatory Save and Cancel buttons. If the user clicks Cancel, all changes are lost, and the PiP is left alone. If they click Save, the changes are saved (duh). Since the inplace setting in the fileinput module is hard to use and doesn’t always work, the changes will be saved in the following manner. When a Patch is selected for editing and everything checks out, a copy will be made with .bak appended to the file extension. When the change are saved, the non .bak file is rewritten with the new info, and the Patch archive is renamed (if needed). If Cancel is clicked, the .bak is deleted, the PatchIt! main menu is loaded, and the Patch is not touched any more.

Clearly, this Dev-log pulls a lot of code from my other Dev-logs and changes, so that is why I said it would have to come later in the V1.1.x series. :)


I originally wrote this Dev-log on March 11, but I revised it in May 29 with updates from issues and changes that surfaced since the initial writing, such as the Game field and Patch archive, as well as improving the actions and fields of the PiP Editor.


PatchIt! Dev-log #8

March 5-6, 2013

#8 PiP File Format Revision for Version 1.1.0 Stable Draft 2

“Oh! I forgot to tell you one last thing!†Just as the Infomaniac forgot, I forgot to write something in Dev-log #5.

I did not do this in V1.0.x, because the command-line style UI does not lend itself well to this kind of thing, but a full GUI does: Mod Type.

In LEGO Rock Raiders modding, there are multiple types of mods: map mod, sound mod, graphics mod, overhaul mod, just to name a few. Racers already has this kind of mod types: PWB layouts, texture (graphics) mod, custom racers… an overhaul mod is actually already started. In LRR modding, you know what kind of mod you are installing. PatchIt? Not so much. For me to do a mod type field at the beginning of PatchIt! would have been hard work. A GUI, however, simplifies this somewhat. When you are creating a Patch, you can select from a drop down menu a list of predefined mod types, and it can be updated when needed. Depending on the type selected, the PiP file has a line saying what kind of mod this is, and is displayed when installing a Patch. The type must be selected; it cannot be left empty (if this is even possible). The new, Draft 2 layout of the PiP File Format is displayed below. It uses the Draft 1 layout, but with the new Mod Type field. Again, line numbers are included for clarity, They are not written in the file.

(1) // PatchIt! PiP file format V1.1, created by le717 and rioforce.

(2) [ZIP]

(3) This is my ?(. )?


(5) Dr. Spock

(6) 2.1

(7) This is my mod

(8) Overhaul mod


(10) This is not really an overhaul mod,

(11) it is really a complete form of the sub-atomic particle "kco-pS"

(12) but since I am on a budget and this crude software does not have the proper term, I choose

As you can see, the new field is on line 8. Again, I’ve left an empty set of parentheses on line 3 if I can find a different extension for the ZIP. I’ve overly written a description, but it is a good example of the new length. Update

Since this Dev-log was written, the PiP format has been updated, improving on the Mod Type field. In the Draft 3 format, Mod Type was renamed to MP (short for Multipurpose), and a new Game field was added. In essence, the change to the PiP File Format was adopted, but was later improved on, making this Dev-log more of a building block than an actual big change.


Requesting Feedback on a GUI


Wow, I'm a curious person lately...

If you are reading this, please leave your feedback. I really need to know what you think.

I have said all along that I want to add a full GUI into PatchIt, and I actually have to learn some GUI code to finish ICU. However, a GUI is complex, and would add a bunch of time and code to make it before a release, not mentioning the new features I have planned.

In addition, there are a few GUI libraries to choose from. Tkinter, which comes bundled with Python, works well (it is what I am using for the dialog boxes), but it is not always the prettiest, and it takes a lot of code to draw something. Qt4, but that is Object-Orientated, and my eyes glazed over on the Python OOP chapters. WxWidgets, but that is a mixed bag completely.

I guess my question for everyone: Do I even need to write a GUI for PatchIt, and if so, which one of these do I use (only if you can answer this). A GUI would be nice, surely it is, but I am not sure if I have the skills needed to write one yet. In a few months? Perhaps. But now? Don't think so. I can go ahead and start making the new changes to PatchIt, and leave a command line-style UI for now (or ever), but I am just stuck as where to go/what to do.


PatchIt! Dev-log #7

March 5, 2013

#7 Backward compatibility for legacy PiP format in Version 1.1 Stable

I, nor anyone else, knows how much PatchIt! will catch on, nor how many mods will be created with/updated for compatibility with PatchIt! (although I hope the answer to both of these questions are “A lot!â€), especially now that version 1.0.2 is out, and most of my focus has shifted toward version 1.1. Whether a lot of mods are packaged for it or not, I need to have some sort of backward compatibility to install legacy patches. What am I thinking? When a patch is selected for installation, the validity line, like usual. But this time, not only is it read to see if it is a valid patch, it also checks if it is a legacy patch or a modern patch. A bit of sudo-code to illustrate:

if validline == 10patch:

print("This is a legacy patch")

# Call legacy patch installation code

elif validline == 11patch:

print("This is a modern patch")

# Call modern patch installation code

else: #elif validline != 10patch or 11 patch:

print("This is not a patch!")

# Go to main menu

This check would be a separate function in the modern patch installation module, and, depending on the outcome, would call the appropriate code.

Therefore, the validity line serves three purposes:

  1. Is it an actual patch?
  2. Is it a modern patch?
  3. Is it a legacy patch?
The legacy installation code is simply the V1.0.x code moved to a different module, and updated to reflect the changes outlined in Dev-log #6. The validity line, however, would be removed in legacy installation code, as it would be pretty hard (but not impossible) to change the patch layout while PatchIt! is switching from the modern code to the legacy code.

Next Dev-log: #8 PiP File Format Revision for Version 1.1 Stable Draft 2


PatchIt! Dev-log #6

March 5, 2013

#6 PatchIt! Settings file revision for Version 1.1 Stable

Just a small note concerning the settings file. Usually when apps use a file for settings and not the registry, there is some line in the file (usually line 1) denoting the program it belongs to. As another one of my oversights when creating PatchIt!, I did not

include such a line in the settings. This was due to the complex setup I was using to read the file to read the first-run indicator and LEGO Racers installation path, and write all the details. However, this situation has changed now that I’ve switched to the linecache module for reading the file and the new Python 3 print() function for writing the file. I am now free to add a new line denoting the program (PatchIt!) it belongs to. It’s another backward incompatible change, so I will again hold off the change until V1.1.

The new file will have three lines instead of two, and the new (first) line will not even be used unless the need arises. The new layout for the settings file is as follows. Line numbers are added for clarity, they are not really written.

(0) // PatchIt! V1.1 series settings

(1) 1

(2) C:/Program Files (x86)/LEGO/Racers 1999

“V1.1 series†because that is when it was first created (then I guess I shouldn’t use “seriesâ€â€¦). As it can be seen, nothing else has been changed. Updating the code to use this new format is a snap (as already explained), so this can be done with no hassle and at the beginning of the V1.1 process.

March 6, 2013 addition

This was brought to my attention this afternoon, and it bears mentioning. Instead of using a plain text file, why not use a XML file? While many programs do indeed use a file for it’s settings, only a few use custom formats. The majority of those programs use an XML file. As it turns out, multiple Python modules to handle XML files exist, and one module in particular,

, would best suit this need. I have not tried the module out yet, but I will do it soon so I can have some more Python experience. An XML document would suit as a

PatchIt! settings file. I could have a tag to denote the current state of the first-run process, for example. The only thing that would prohibit using an XML would being able to get a clean folder path to direct PatchIt! where to install a patch. I find that a lot of Python modules return a list or tuple (the winreg module I’m using for ICU does this). If it returns a list or tuple, I’ll have a lot of cleanup to do to get a valid folder path. If it returns a normal string and just has a n, tor similar (like linecache does for a plain text file, I can quickly get a folder path. Again, I have not even tested this module, so it could work as I need it to. Just something to look into


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

Sign in to follow this