PATCHES GALORE: Keen 1 Sprite Properties (don't miss this!)

[Quirky Moron]

Is it possible to destroy the ice blocks when a zap/zot hits it?

[KeenRush]

All this stuff makes me really want to start a new mod.

I'm not sure what I'm going to do, this is so hard to resist not to get hands on this yet.... Rrrhhhh..

I'm pretty impressed about the "other Keen". I wonder why that kind of thing was coded there -- can anyone tell any more about it? Was that function called by any actual enemy or was it just some code that just was there but wasn't used in the final version?
I really wonder what the makers had planned for that. It is so good stuff.. The "other Keen" does a lot what the original Keen, but sometimes its pogoing gets on while the original's stops, and so on. The moving isn't perfect (like xtra said). When you guide it to near a shooting robot, and when it shoots it, it turns into a dead yorp. :)

This day has been really cool (because of this stuff naturally). I'm really eager to see the future modifications. I can't hardly imagine what kind of cool tricks and more imagination-filled Keenish worlds we can see with the help of these patches.

The Vorticons has changed -- but I like the new way! Good job everyone! :)

This will be a good news for the community mod, if we sometime continue it when we have some time.

There seems to be a lot SI-calling in the code, and I'm sure the speeds and plenty of other that kind of stuff can be changed. I haven't tried those yet. Also, seems that there are those SIs a lot that determine the graphics (according to that adurdin's list of some SI values).
There are also some other that aren't on that list, but dunno what they do. This is all too exciting. :D

[KeenRush]

Is it possible to destroy the ice blocks when a zap/zot hits it?

Hehe, here you go:

Code: Select all

# Destroy big ice block by shooting it.
# As a side-effect (but really cool one), cause two ice blocks to destroy each other when they collide!
# If you shoot ice block or two collide, they will spawn the same random zap or zot than normal ammo does if it hits a wall or enemy. :)

%patch $213E $00 $4A

[xtraverse]

I've noticed that [SI] struct is often at [0x8220] and this location plus an offset may be used in certain instructions instead of [SI+0x??].

I now understand the way sprites work quite a bit more. Every sprite's actions (including Keen himself) are various functions located throughout the executable. There is one default function that should be stored in [SI+0x32] upon the sprite's creation. This is the base function that controls a sprite. This function may put a new function in [SI+0x32] (or more likely [0x8252]). The new function could be something like a yorp/garg searching, a robot shooting, or even Keen jumping. The new function before it ends will usually put the original base function back in [0x8252]. This explains why if I put a Vorticon function in a yorp, it will start to appear and act as a Vorticon until I trigger something that will put a Yorp function back in [0x8252] (such as jumping on it, which puts the stunned yorp function in [0x8252]). This also answers KR's question. Since Keen's movement is defined by functions (that are triggered not by specialized patterns or randomness, but by keyboard input), they can be used by enemies as well. With enough fiddling around, I bet I could make a yorp that can pogo.

[xtraverse]

CS Btw, what is [SI], and how does it relate to the patched values? I don't quite follow that bit.

I don't know much about ASM, but I'll try to explain it the best I can. SI is technically named the "source register," which is in the family of registers called "address registers" which I think are the equivalent of pointers in a programming language.

ASM has the following command:

Code: Select all

MOV ax, bx

Think of bx and ax as variables. This code will move the value of bx into ax. However, if you use brackets, it means something completely different.

Code: Select all

MOV [si], bx

This will move the value of bx to the location SI holds. Say SI holds the value 0x8252. This code will move the value bx to the memory location 0x8252.

In Keen: Vorticons, SI seems to hold the location of a struct (a series of values that are located together) that holds information about a sprite.

If you still have questions, ask adurdin :)

[xtraverse]

KeenRush, I figured out why your killer butler bot didn't work, as with your freezing robot. To save resources, Keen: Vorticons destroys certain types of offscreen sprites. These include ice cubes ([SI] = $0F $00) and robot shots ([SI] = $0B $00). Here's a killer butler bot that doesn't get destroyed, as I gave it the Vorticon's killing properties.

Code: Select all

# make touching a butler bot the last thing you ever do
%patch $1782 $04 $00

[xtraverse]

Oh no, I've turned into an uncontrollable Vorticon!

Code: Select all

# instead of controlling Keen through the levels, watch a Vorticon jump through them

%patch $2730 $0E $1C
%patch $3110 $0E $1C
%patch $3D72 $0E $1C
%patch $3E7F $0E $1C
%patch $40A8 $0E $1C
%patch $4B7B $0E $1C
%patch $3121 $0E $1C
%patch $3B21 $0E $1C
%patch $3FB6 $0E $1C
%patch $3913 $0E $1C
%patch $3AE8 $0E $1C
%patch $3109 $0E $1C
%patch $3AA2 $0E $1C
%patch $3C2D $0E $1C
%patch $3FFA $0E $1C
%patch $3119 $0E $1C
%patch $3DB7 $0E $1C
%patch $4079 $0E $1C

If the vorticon jumps on a yorp to stun it, you can see him flash to Keen for half a second. I'll try to track down the code that's causing this. Maybe next I can make a controllable vorticon :P

[XkyRauh]

If, by chance, the Vorticon reaches an exit, will the level be completed? :-)

--Xky

[adurdin]

Oh no, I've turned into an uncontrollable Vorticon!

instead of controlling Keen through the levels, watch a Vorticon jump through them

Pah! This was done years ago: http://andy.durdin.net/keen/military.zip :)

You know, the funny thing is, I knew about most of this stuff ages and ages ago (though I didn't fully track down all the values and details). It just never crossed my mind that it could be useful for modding :-S


I guess that'll teach me, huh?

[KeenRush]

Ah, now I see -- thanks for the butler bot fix and explainin' xtra. :)

I now understand the way sprites work quite a bit more. Every sprite's actions (including Keen himself) are various functions located throughout the executable. There is one default function that should be stored in [SI+0x32] upon the sprite's creation. This is the base function that controls a sprite. This function may put a new function in [SI+0x32] (or more likely [0x8252]). The new function could be something like a yorp/garg searching, a robot shooting, or even Keen jumping. The new function before it ends will usually put the original base function back in [0x8252]. This explains why if I put a Vorticon function in a yorp, it will start to appear and act as a Vorticon until I trigger something that will put a Yorp function back in [0x8252] (such as jumping on it, which puts the stunned yorp function in [0x8252]). This also answers KR's question. Since Keen's movement is defined by functions (that are triggered not by specialized patterns or randomness, but by keyboard input), they can be used by enemies as well. With enough fiddling around, I bet I could make a yorp that can pogo.

Sorry about the very long quote.. Thanks for the info! So, throughout the code there are function calls that determine the behaviour of enemy -- and Keen? And enemies can share these functions? But what about the graphics, does it change always as well?
The pogoing yorp sounds good. :) Would that mean the yorp would use Keen's pogoing behaviour but still keep it own frames? :D

And with the uncontrollable vorticon -- outstanding work!!!
So, is that just changing the Keen functions to call some vorticon ones, and therefore make it 'special' (and screen follow it)? Those all seem to call the same function, it seems still to create a vorticon with normal behaviour -- this is interesting, and seems that the behaviour pattern doesn't start from the beginning always when the function is called (it just keeps going fluently). But still with the same mortal flaws (vortakeen'll die if it touches a garg). ;)

[another edit] Indeed, if changing all those $0E $1C (in that patch above) to $51 $1B you can say hello to Commander Garg.

We have good possibilities now to examine the enemy in it's real environment.

Try the following: don't use that xtra's uncontrollable-vorticon while doing this test. Just patch this:

Code: Select all

%patch $3E7F $51 $1B

That should make Keen act as a garg, after he has shot. Instead of getting to normal standing mode, this changes Keen to garg. It's interesting that now if a yorp or pusher bots touches you, you'll go to that garg running mode. :) (almost like trying to escape)

With this stuff we can change Keen's behaviour -- with some tweaking it may be possible for example to change Keen to a yorp if Keen shoots (or tries to), and then change the yorp back to Keen if it does that jump for example. Or that kind of stuff. This will make plenty of interesting stuff.

[KeenRush]

If, by chance, the Vorticon reaches an exit, will the level be completed? :-)

I just tested and I'm afraid not.. Not even with a garg! :O (or yorp)

It's interesting to see they move around, though. :) Probably we should take some tests which of these animals can go fastest through a maze and make it to some room. :p (naturally the maze should be made the way they don't need to jump up)
I may try this today later. :)

You know, the funny thing is, I knew about most of this stuff ages and ages ago (though I didn't fully track down all the values and details). It just never crossed my mind that it could be useful for modding :-S

LOL! :D Hehe, I already thought there is no way you could have all this time hacking the exe not noticed this stuff. :) I wonder what other secrets you'll have in your Keen sleeve? ;) It's kinda funny how you didn't realize this can be used for modding benefits, since this is probably the best stuff we've ever seen here in the phorumz.

[adurdin]

Hehe, I already thought there is no way you could have all this time hacking the exe not noticed this stuff. :) I wonder what other secrets you'll have in your Keen sleeve? ;) It's kinda funny how you didn't realize this can be used for modding benefits, since this is probably the best stuff we've ever seen here in the phorumz.

The most interesting bit of all of this, and the bit that I hadn't worked out (so props to Xtraverse!) was about changing the first word in the sprite structure, which affects whether the sprite pushes Keen, or kills him, or things like that, without causing it to change into another sprite. That is not only cool, but very handy for modding. It can add new character to the sprites.

In fact, I'm scared now. In the next mod that comes out, I can no longer assume that the sprite which walks slowly doing little hops is harmless -- youch.

[KeenRush]

I see. And now it's better be always careful in a new mod. Not to mention shooting that harmless hopping creature would do anything. ;)

Here's one interesting patch.

Code: Select all

# Change Keen to garg if he dies.
# The garg will live its own life in the game and act perfectly as some other original garg. :) Though, the shots the robot shoots doesn't have any effect on it.

%patch $4275 $51 $1B

This one I found as an accident when searching the patch above. Dunno how it works though. Also, it doesn't work if the patch above is set on.

Code: Select all

# Change camera to follow dead Keen to the top of the level.

%patch $342F $51 $1B

This looks kinda fun in a level that's height is big. :) (and you die at the bottom)

[grafix]

Camera follows Keen? That could have a realm of modding possibilities. (Me thinks: underwater!) Time to create the Patchcyclopedia...

[xtraverse]

That's rather odd. Using another sprite function for the death handler doesn't turn it into that sprite but it makes the camera follow dead keen? Odd.

I've noticed that the sprite structure is often at [0x6EDA] as well as [0x8220]. And there appears to be an important function for the map sprite at [0x8919].