EZPATCH [Assembling Initial Database]

Tools, assembly, and file formats.
Post Reply
User avatar
Fleexy
Site Admin
Posts: 490
Joined: Fri Dec 12, 2008 1:33 am
Location: Bloogton Tower

EZPATCH [Assembling Initial Database]

Post by Fleexy »

I've solved that annoying problem with the array overwriting. Now, I just need help creating the PDB files, and this amazing application will be ready for use by new modders/patchers! You can download the Consumer Preview here. The original (first-edit) text follows.
This program is now in the coding stage. The original text follows.


So, I've been thinking of starting work on a new patch helping utility (like The Neural Stunner or Patchotron). One thing I've noticed about these (at least TNS) is that they support a very limited number of patches (no offense, they are extremely useful for common patches). With these new include-BIN patches (like the V2), a utility like this that supports them would be great. Another reason is that the Patch Index goes by first letter. Some people might think of the first letter differently. It took me a while to find that [M]oving Platforms is actually under [P]latforms. (Which redirects me to something in Sprite Patches. Which is rather difficult to navigate.) And there are also patches that never get into the Index (like changing "Oops." in Keen 2).

~~~

Getting to the point: I am thinking of making a utility that contains files for ALL patches ever made. It would be in two parts: an engine and a patch database.

The engine is the main program that lets you search patches (by tag, episode, ktl*). It lets the user select a patch, then (if applicable) set parameters. It then inserts the patch into the patch list. This list != CKPatch compatible (so far). It lets the user remove patches and change parameters (something TNS and company cannot do). Then, when the user is satisfied, it compiles the list into a CKPatch-compatible file (and generates the batch file as well). It could also save into a special format to go back and edit the patch list later (maybe EZP extension?).

The patch database would store the Patch Index (ie. all known patches) in a special format that contains the patch, the parameters, the patch description, the parameter descriptions, valid parameter entries, what other patches it is not compatible with, necessary binaries, and patch tags (for searching). The engine would load this file. I would supplement this file every month to include new patches. I would probably need the help of one of the Patch Index managers to notify me about new patches.

~~~

So, for me to start this (large and time-consuming) project, I would need to be sure of the following things:
- that people will actually use it
- that I actually have the coding skill to do it
- that a Patch Index manager will regularly alert me to new patches for the supplement

~~~

What do you think of this idea? Would you use it? Would you help with it (I can write the engine, but the patch database would be a real pain to make in a compatible format). Is my plan for including new patches (keep a database separate from the engine and only update the database unless a patch is strange and needs extremely specific configuration) OK? Thanks for reading!

-Fleexy

~~~

*Greek version of etc
Last edited by Fleexy on Sat Mar 17, 2012 5:03 pm, edited 2 times in total.
User avatar
Tulip
Posts: 394
Joined: Mon Jun 16, 2008 2:40 pm
Location: Heidelberg, Germany
Contact:

Post by Tulip »

Since it sounds like you'd need Mink to actually code it, I'd like to see this worked into TNS, because I love that program layout.
And concerning the patch index, I'm not entirely sure, but I think it's not maintained anymore, Llass is working to get all the patches up onto KeenWiki
Mink
Posts: 192
Joined: Sat Nov 03, 2007 4:08 pm
Location: Providence, RI, US

Post by Mink »

I'm seeing a few problems with your proposed idea:
A) How many people are going to use this? It's just as easy to use the old patch index and maybe even easier to use the new one integrated into the Keenwiki. The important thing is that the more complex lemm-patches find their way to the wiki (and your proposed program), too, since iirk they're not in the old index.
B) You'll need to continually update the database file unless you want this going the way of the Patchotron/TNS dinosaurs; you have to ask yourself if you'll be willing to convert the patches from the index to whatever format you've got cooked up, a process I'm having trouble characterizing as anything other than more trouble than it's worth.
C) I'm pretty sure Tulip's right about Lla exclusively updating the Keenwiki index. Assuming this is the case, you have merely to check the recent changes page on the wiki for when/which new patches are uploaded -- you won't need Lla to inform you when new stuff goes up.

That said, I've had no intention whatsoever of revamping and/or adding to TNS, which was released like a couple months before lemm brought patching out of the dark ages, because A) I'm pretty sure no one, not even myself, even used or cared about it anymore and B) because it is a colossal pain to add anything to it. You're probably better off coding your own front-end, but if you want, I can dig up TNS's shoddy, mangled VB.NET code and send it your way if you think you might like to cannibalize or expand it.
User avatar
Fleexy
Site Admin
Posts: 490
Joined: Fri Dec 12, 2008 1:33 am
Location: Bloogton Tower

Post by Fleexy »

Thanks for your observations!

~~~

A) Well, I actually find it seriously difficult to use the Patch Index. One, it's not being updated. Two, it cannot contain complex patches like lemm's. I have devised a (IMHO) good way to do this. Three, the Sprite Patches folder is very difficult to navigate. I, for one, don't follow the trail of reasoning that puts jump heights in (without external notation) to "Speeds". Then again, that might be just me.

B) The conversion to KeenWiki will greatly help with this. I think the hardest part will be getting the current amount of patches in. Once I have all these in, I can just check the KeenWiki or the Patches forum to learn about patches. Updates will be monthly.

C) Excellent.

~~~

It could help people who don't understand hex. I think new modders would really like to use it. And even if not, I would certainly. I might even show it to people at my school and get them interested in modding.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

The Keenwiki hasn't got even a quarter of The Patch Index patches in it sad to say. Redirects help, or using the search feature. (Look for Platforms, take a peek at their pages.)
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Hi Fleexy,


A GUI patching tool sounds like a good idea, but I think what you have proposed doesn't really provide anything that isn't already available. The Keen Wiki is quite easy to use (just copy/paste), it is maintainable by a community, and the search function makes it easy enough to find things quickly. Complicated patches can be added to the Wiki. In short, I don't think it is compiling a patch file that is difficult, but compiling the patches properly that takes skill, and moreover, time.

In my experience, many patches are easy to apply. The most complicated and desirable patches, however, are those that alter sprite behaviours, and these are generally the patches that take the most time to create. It's also rather difficult to learn how to manipulate actions in Keen Galaxy to achieve the desired sprite behaviour. I think you should make modifying sprite behaviours (in particularl, for Galaxy and Dreams) the focus of this tool, at least to start off. In other words, the tool is not just a searchable database of patches; rather, it helps the user create new sprite behaviours in a user friendly manner as opposed to compiling a gigantic text file by copy/pasting.


You might want to start off by making an action browser. It could contain a menu with all the actions in the episode. When the user clicks on an action, all the details for that action would appear in a separate field. The offsets of the functions are converted into names, the left and right chunks are converted into pictures, perhaps an animation loop previewer, and all the other fields are given headings. The user can then edit these by a visual interface (e.g., you make it simple to swap out one behaviour function for another).

If you finish that, you could extend this tool to modify the sprite behaviours themselves. Your patch database could contain all the patches that apply to one particular sprite behaviour, such as the bounder bouncing function, for example, which has bounder jump height/distance, how often the bounder jumps to the left, what sound the bounder makes when it jumps, what action the bounder switches to when it decides to go left, &c.

I could help you by itemizing all the actions and all of the sprite behaviours (many of them are already listed in the patch index).
User avatar
Fleexy
Site Admin
Posts: 490
Joined: Fri Dec 12, 2008 1:33 am
Location: Bloogton Tower

Post by Fleexy »

I have completed coding the EZPATCH engine (graphical interface), and it supports many of the above features, minus the animation preview and pictures. Here is an incomplete list of what it can do:
  • Easily searchable database
  • Each patch has "parameters" that have "types" to avoid confusion:
    • Number: integer value, max/min limits set by patch
    • String: string value, has buttons for CR/LF, max length set by patch
    • Choice: dropdown choice, value selected out of a list of choices (like the sprite behaviors or the sounds)
    • Boolean: checkbox to include or not include an optional patch part (like "Keen3-style doors" in the background patch)
  • Formats and writes the patch for the user (so he/she doesn't need to find/insert the item bytes or be good with hex)
  • Shows patches that are incompatible with the current patch and patches that it requires
I only have about 30 patches in the searchable index now. It isn't really designed for making sprite patches, but I have put in all the butlerbot stuff and it CAN be tortured into making (actually pretty good) sprite adjustments easy for the user.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Any links?
User avatar
Fleexy
Site Admin
Posts: 490
Joined: Fri Dec 12, 2008 1:33 am
Location: Bloogton Tower

Post by Fleexy »

Here is the alpha engine (no patches, but if someone had a valid patch database it would work):

Download EZPATCH Engine v0

There is only one problem: every patch randomly gets set to the previous one in the database. I am working on the problem. After this, the engine will be complete. Unless, of course, I modify the string editor, which is messy to say the least.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Looks pretty neat so far.


A couple things I would request:

A function to check if patches overlap each other, that prints out which bytes overlap (is this included in the incompatbility checker?)

A method of incorporating existing patch files that I write by myself (and, checking if my own patches overlap with anything in the database).

Is there some way we can create databases? Do you have a valid patch database?
User avatar
Fleexy
Site Admin
Posts: 490
Joined: Fri Dec 12, 2008 1:33 am
Location: Bloogton Tower

Post by Fleexy »

I am working on a database, but it only has about 60 Keen 1 patches in it and that's all. I do have the file format specification ready if you'd like.

Those ideas sound pretty hard. The first one could probably be done by me writing in (by hand) which bytes overlap, but reading in an already-made patchfile would be basically impossible (or result in billions of uneditable "Custom Patch" entries :/
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Also, what is the format of the patch database files?
Post Reply