So I changed a weapon.

Weapon Scripts



Wondering where the weapon scripts are stored? Time to put the mystery to rest at long last!

There's no such thing.

After some poking around in a code dump and picking apart a structure that seemed like sprite data, I found a routine which handles the firing of a weapon and manages the projectiles. Turns out weapons are handled programatically in the code. There's absolutely no way to edit a "script" short of assembly hacking. Sorry everyone - even knowing where weapons are handled in the code would amount to nothing unless you can write machine code...

The above screenshot is a hacked fireball which bounces against walls and rises upwards slowly, hugging ceillings (instead of bouncing on them like it does with walls.) After a while it puffs out of existence. Little proof of concept - it can be done, but the behavior of this weapon is 100% coded in machine language.

All hope is not yet lost. I believe there's a way to "easily" edit the animation sequences. An interesting large chunk of MOV instructions into a big block of reserved memory seems like a series of bounding boxes that could be used to describe which frames make up the animation. If this is the case, however, short of changing the code there's no easy way to change the space reserved for animation sequences.

I'll post updates if I find anything that anyone with a hex editor can make use of.

 

Wondering where the weapon scripts are stored? Time to put the mystery to rest at long last!

There's no such thing.

After some poking around in a code dump and picking apart a structure that seemed like sprite data, I found a routine which handles the firing of a weapon and manages the projectiles. Turns out weapons are handled programatically in the code. There's absolutely no way to edit a "script" short of assembly hacking. Sorry everyone - even knowing where weapons are handled in the code would amount to nothing unless you can write machine code...

The above screenshot is a hacked fireball which bounces against walls and rises upwards slowly, hugging ceillings (instead of bouncing on them like it does with walls.) After a while it puffs out of existence. Little proof of concept - it can be done, but the behavior of this weapon is 100% coded in machine language.

All hope is not yet lost. I believe there's a way to "easily" edit the animation sequences. An interesting large chunk of MOV instructions into a big block of reserved memory seems like a series of bounding boxes that could be used to describe which frames make up the animation. If this is the case, however, short of changing the code there's no easy way to change the space reserved for animation sequences.

I'll post updates if I find anything that anyone with a hex editor can make use of.

Well, damages has to be stored in there somewhere, and anyone with a hex editor ought to be able to change the values on damage

 

Looks and sounds interesting...can't wait to see it in action.

 

The damage should be in there somewhere, but I still haven't found it. It's probably just a matter of a few hours though, at most.

One thing that could happen is that the damage is calculated via a formula (for instance, damage(n+1) = damage(n) + (n-1) (where n-1 is always greater than 0): 1=1, 2=2, 3=4.) Each weapon has its own bit of code, and I've seen similare things, so I wouldn't rule that out.

I know where the exp is loaded, and that's not a calculated value, so chances are some other function pushes a damage value onto the stack based on the weapon ID, plain and simple.

I can confirm with a near-100% degree of certitude that the value isn't stored directly in the executable as data, but rather pushed onto the stack as needed somewhere. Sprite IDs and such are stored that way, and the game doesn't read from itself save for a few graphic-related situations.

 

I know where the exp is loaded, and that's not a calculated value

Does this mean you know how to change how much exp it takes to level up? I always thought that if you make the exp needed from lvl 3 bubbler to max bubbler big enough, it would be a better weapon then P-star. You could also increase the exp needed from lvl 1-2 nemisis, to make it even better.

If you know how to make something like that work it would be a great addition to your assembly hacks thread.

 

Wouldn't that just make the game easier? You could just give yourself weapon 0x2C in that case and not worry about anything else.

I don't think I explained myself properly. What I mean by knowing where it's loaded is, I know where in memory the data gets loaded, not where it gets loaded from. However knowing that is just a few steps away at that point.

 

I for one would like to make the bubbler more robust, and stay at level 3 longer, because in my own mod there is a point where it could be your primary weapon. So it is has a valid use beyond "making the game easier".

 

Just as one could increase EXP to make the weapon stay stronger longer (and harder to upgrade in the first place), you could decrease the EXP required to have the opposite effect. Of course, can bias the EXP needed for each level if you wanted to emphasize a quick/slow upgrade process, or a quick/slow deterioration process. Certainly a 10/30/60 EXP system (easy to upgrade and keep strong) would give very different results from a 60/30/0 system (slow to upgrade, yet hard to keep strong).

If you can change the weapon damage as well (stronger, weaker, or mixed : regarding the "mixed" point, Fireball usually does 6/6/6 damage, but Polar Star does 1/2/4, and you could change those to 4/6/8 and 3/3/3 and substantially affect how they are treated. These examples may not be particularly interesting, but you may find one or more weapons worth tweaking in this way, more or less), you can do a pretty solid job of adjusting the heirarchy of weapons (through damage) and some of their other nature (EXP needed, as explained earlier). So, maybe you prefer to make a weapon other than the Spur the ultimate gun.

Ideally you would like to have a nice mix of behavior, and Cave Story already does that in one regard, but there may be multiple different setups that would appeal to different modders. One may prefer to generally increase damage, another may seek to decrease it, and yet another may have a more sophisticated set of changes in mind.

 

Don't forget the number of shots. This has a very important impact on a weapon (and is also stored in the code; the gun has a fixed number (2 shots) for every level, and the fireball makes a case for each of its levels, for instance.)

The weapon I've added is of limited use because it archs upwards. After a bit of playing with it, I've grown very fond of it (moves fast and can be used to make trick shots) but its rate of fire was too low compared to the gun, which fires faster despite having less shots.

After upping it to 3/4/5, the Ion Device is now a weapon of death and destruction when used properly. You can fill the screen with glowing bouncing plasma without having to stop to reload. This is balanced out by its slightly slow movement and awkward angle, though.

The game seems to have a limit of 0x60 sprites onscreen at once (that's the size reserved to the sprite structure.) This means short of having 80+ bullets onscreen at once, you can make a weapon fire a crazy amount of shots. Imagine a fireball-like weapon that does 1 damage but can be fired indefinately - you could fill a map with them and switch to another weapon, creating a death-trap for any enemy wandering the map.

 

Now that I'm home, I figured I'd post the starting offset of the weapon functions. You're the hacker - you do the disassembly and altering.

0x00004160, 0x000043f0, 0x000047b0
0x00004b30, 0x00005120, 0x000055a0
0x00005d80, 0x00005f30, 0x00006190
0x000064d0, 0x000068b0, 0x000075e0
0x000078a0, 0x00006bb0, 0x00006e60
0x00007110, 0x00007910, 0x00008080
0x00008230, 0x00008710, 0x00008ae0
0x00008230, 0x00008f40, 0x00008f90

The calls to these functions are made in 0x00008FC0. It shouldn't take much effort to reverse engineer that function and figure out which call maps to which weapon (protip: branching doesn't occure on the weapon TYPE but rather on the weapon ID; which means that the gun Lv 1 isn't going to have the same value as the gun Lv 2.) Just trace your way over to the proper function and give it a look.

You're the hacker, it's your hack - go out there and write up some insane weapon code. Nothing else jumps to the weapons' code so you can go wild and replace the code 100%. Enjoy!

 

u checked out adress 0x000C745 ??
Well, maybe to change something with TSC or npc's?

 

How does it have anything to do with NPCs...? Just wondering - a disassembly hack reveals this is smack dab in the middle of an instruction, which seems more like a randomly picked address than an actual traced location. A few values get imul'ed together, addresses which don't quite seem to have much to do with NPCs at all. So I'm kinda curious how you got there, here...

For the record...

0000c741 - a1 ec d4 49 00 - mov eax,[0049d4ec]
0000c746 - 0f af 05 14 f9 48 00 - imul eax,[0048f914]
0000c74d - a3 ec d4 49 00 - mov [0049d4ec],eax
0000c752 - 8b 0d f0 d4 49 00 - mov ecx,[0049d4f0]
0000c758 - 0f af 0d 14 f9 48 00 - imul ecx,[0048f914]
0000c75f - 89 0d f0 d4 49 00 - mov [0049d4f0],ecx

Then it's a few PUSHes and a CALL to a function.

If anything, an interesting function can be found at 0x0006FAAA, which is where (I beleive) NPCs (events on a map, to be precise) get initialized. Seems like a good place to get started...

 

Well i just noticed that near the offsets of the Weapons the C745 is used often!!!
And when i edit C746 the game crashes (only on some maps, i think labyrinth maps)
Well so i think there is maybe a important use of it and that would maybe be a command who is used in labyrinth or a npc who is used in labyrinth!

 

Well i just noticed that near the offsets of the Weapons the C745 is used often!!!
And when i edit C746 the game crashes (only on some maps, i think labyrinth maps)
Well so i think there is maybe a important use of it and that would maybe be a command who is used in labyrinth or a npc who is used in labyrinth!

What you're dealing with is code, not data. The stuff you're encountering are commands. They're bound to be reused often because many MOV commands exist in the weapon code.

If you want to find pointers, look for addresses within the program space, not in the file itself. :eek: