Transfering the Patch Index

[levellass]

To the Keen wiki!

Since there has been little more than talk on this, I've decided to ask for permission to just do the job myself. I figure if I do a few pages every day I can get the lot transcribed in a month or two.

I'm thinking pages by topic, with titles like Patches: Rayguns (So there will be no confusion with non-patch pages.) Each page will be divided by episode (If applicable) and each patch will have its own section with explanatory text and the patch itself. (So a look at the top of the page will list all the patches available.) I'll probably keep required files (As for some of Lemm's patches) with the old Index or converted to hex.

I am curious on a few points however:

* How do I color wiki text? This would be useful for highlighting variables in bigger patches. Also, it makes things look more colorful
* What should I do for categories? I want this to be search-friendly and I'm not sure how wikkis work with these things.


I'd also appreciate people's comments and suggestions on this plan.

[Draik]

Well as far as I recall Malv had some sort of syntax highlighting thingy set up, but I forget how exactly you enabled it. It was in one of the other topics about moving the patch index.

[Tulip]

Well when it comes to categories, the wiki is very versatile, and you can add all the categories you want, but I can see the basic infrastructure for adding the patches has been set up already: http://www.shikadi.net/keenwiki/Category:Patches

Also if you want to see how the colouring and formatting of the text works in wiki, just open up one of those patch pages that exist already, go to edit and copy it.

[levellass]

That wasn't quite the colorscheme I had in mind, but it will be useful. The categories look interesting and it will be a learning experience I am sure.

Just want to make sure everyone is ok with this.

[Mink]

Heh, everyone has been okay with this for quite a while now. And wow, I was figuring it would take more work than that to add in the coloring.

[levellass]

The coloring there is nice, but it's not quite in my interest. For one it doesn't let me highlight variables of interest, it's more like a programming language color. Is there any way I can color individual 'words'? This would be very useful for a lot of patches, so readers could get some idea of how the patch is structured. All I'm asking for is three basic colors, say RGB to highlight things that may be of interest to patchers.

[Tulip]

This should do it.

Code: Select all

<font color="red"> </font>

[Fleexy]

This should do it.

Code: Select all

<font color="red"> </font>

Isn't that HTML?

[Draik]

Doesn't HTML work in MediaWiki????

[levellass]

It works. The only question is what colors to use. (White-yellow-green is evidently right out.)

I'm going to try and get the hang of this before doing anything big.

[levellass]

New question for everyone; the transfer is going well, we now have 34 patch pages up, mostly for Keen 1-3. I'm planning on starting to transfer the Keen 1-3 sprite patches (Speed, animations, etc) to the wiki, but I have a problem. Or rather, a question for all of you.

How should it be done?

The old Index has separate sections for animation, sprite properties and such; so if modding a Yorp you would look up the Yorp in each of the sections you wanted to patch it. However the Keen wiki allows us to link to all sorts of other pages and information, so I'm giving serious thought to a new layout. (especially since everyone can edit things and it would be gauche of me to keep an old and possibly disliked system just because it's how I originally set stuff up.) There are three basic options:

1.) Old system. Separate pages for each sprite property (Animations, what happens when shot, speeds, etc) which explains how the patches work and lists all of the sprites' values in-game. The disadvantage is, you need to go to separate sections to get all the patches you need for a given sprite. The advantage is that by having all the game's values in one place it is easy to see how other sprites use their default values and work.

2.) Separate pages for each sprite listing all of that sprite's patches. This would have everything you need to patch one sprite in one place. It would list the Yorp's speed, animations and death all in sections on that page. This will be quick for seeing what you can patch with a sprite, but may be confusing if a modder doesn't know quite how the patches work.

3.) Separate pages, but with links to explanation pages for various things. This would be like option 2, but there would also be links to pages detailing how patches work; the speeds patches would have a link for example to a page on patching speeds that noted how negative values work, a rough guide to how fast speed x would be and so on. I'm in favor of this option myself, since I think it would allow newer patchers to see how a patch works, without getting in the way of those who already know.

I would appreciate your thoughts on this, as well as any other suggestions you may have for other options.

[CommanderSpleen]

I think you could combine these options somewhat. Each sprite could have its own page, but patches that can apply to many different sprites could be given separate pages and linked from the sprite-specific pages--though the latter could also contain some prefabricated examples for the sprite in question.

This is mostly for the sake of maintenance. It would possibly be easier in terms of reference to have specific patches for every sprite on each page.

[lemm]

How should it be done?

Option 3 sounds good, arranging the patches by concept is a good idea. I think for a more advanced modder, it would also be helpful to have the patches arranged by location in the exe.

What I want to see is a patch index that helps the modder create enemies with new behaviours by chaining together existing behaviours that have their variables altered. It's the functions that are the building block of a sprite's character. ABSOLUTELY NO ASSEMBLY CODING KNOWLEDGE at all is required. The only "technical" details the modder needs to know is how the memory is laid out, what a sprite looks like, and the high level structure of the game loop. There is a tutorial section and an appendix section. The tutorial section describes all of the syntax one finds in the appendix. For example, the tutorial section could describe the comparison of 32-bit integers, and how to mod the two numbers being compared. Another example would be how to patch in 2 , 4, 8, or 2^n frame animations.

To sum up, if patches are grouped by sprite or by concept, then you are taking the approach of "patching the yorp," "patching the garg," etc. This is perfectly fine and you can get some cool sprites this way. On the other hand, if patches are grouped by the function that they modify, then you are taking the more general approach of "sprite A does this when it contacts keen, but does this when contacts Sprite B or Sprite F." It's slightly more technical, but its a different way to look at things. (As an exception to all of this, I would make a separate section for keen.)

Appendix Section Example: Yorp searching think

There is really only one rule when patching. Any like can be exchanged with another like. A 16-byte word can be exchanged with any other. In the example below, sprite.velX(2) can be exchanged with the memory location of keen's velX. sprite.posX(0) can be exchanged with the X-scrolling coordinate of the level. Sprite.velX(1) could be exchanged with sprite.think, and VELX1 would contain the offset of the corresponding think.

As a slightly more complicated patch, you could change jump instructions. For example, the > symbol in sprite.time(0) > TIME0 could be changed to an == symbol, sprite.time(0) could be changed to keen.think, and TIME0 could be changed to the offset of the keen jumping-start function, so that when keen starts a jump, the former yorp does something.

Now you can see how knowing NEXT TO NOTHING about assembly can result in a HUGE variety of novel sprite behaviours. In addition, if you are just replacing like with like, you cannot crash the game due to patch incompatability, (unless of course you do something deliberate like divide by zero or give the sprite.think field a bad offset which would call gibberish code, but that can be warned against in the tutorial).

To accompany all of this, we make a huge list of all the byte, word, and dword memory locations in the keen exe. All of this is already known, it would just be a matter of doing it.

You can also see how such a system would be good for an automated patch program...

Code: Select all

Type of function: think
Location: $19D3 to $1A2B
Original purpose: yorp searching

Default Code:

sprite.velX(0) = VELX0
Increment Sprite Time
Do FRAMELIMIT0 - 1 length animation at SPEED0 starting at FRAME0.  
If sprite.time(0) > TIME0 Then
  If sprite.posX(0) > keen.posX(0) Then
    sprite.velX(1) = VELX1
  Else
    sprite.velX(2) = VELX2
  End If
  sprite.think(0) = THINK1
End If

*******
CONSTANTs:

byte:
%patch $19F0 $05 #SPEED0

word:
%patch $19E7 $0030W #FRAME0
%patch $19E4 $0003W #FRAMELIMIT0

# etc etc for the rest of all values...
THINK1
TIME0

VELX0
VELX1
VELX2

Memory Locations:
word:
sprite.velX(0)
sprite.velX(1)
sprite.velX(2)
sprite.time(0)
sprite.think(0)

dword:
keen.posX(0.hi) 
keen.posX(0.lo) 
sprite.posX(0.hi)
sprite.posX(0.lo)  

**********

OTHER PATCHES:
#This is where you would put patches that are not strictly modifying values or memory locations.  An example is the $90 $90 $90 type of patch.

%patch $1A24 $90 $90 $90 #Sprite does not fall