Scratch on an Eight Ball

All right, this thread is sort of spawned by laziness (I apparently can't get myself to comb through the game's scripts and figure this out myself), but I figured I'd ask anyway...

My mod is essentially being made using sort of a "from scratch" method (i.e. deleting all the maps and making completely new ones), seeing that it's not even remotely based on the Cave Story world. However, due to this, I'm not 100% sure what kind of "safety boundaries" I'm pushing. For one, I'm just using flags in numerical order, starting at 100. CS tends to skip quite a few *and* sorts them in map order.

So basically, I'm curious as to what "limitations" I have to keep in mind if I go about my mod in this manner. Firstly, are some effects and events "hard-coded" to certain flags (Mimiga mask, for example), and if so which ones? I wouldn't want to use flag x to control a locked door and later find out it switches my spritesets every time I try and open it.

Yeah, I'm picking up the art of modding pretty fast, really, but the complexity of it all leaves a few questions to be asked. I'll come back later when I can think of more to say.

 

I believe the npc flags, event flags (FL+/FL-), and the equip flags (EQ+/EQ-, mimiga mask) are separate from eachother. So you can use FL+0064 without the risk of looking like a mimiga.

Runelancer found that setting event flags (I think, can't remember) above 8000 causes other stuff to happen than the setting of the flag.
Also, some event flags are used in the "head" section under "script" in Sue's Workshop, so they shouldn't be used elsewhere to avoid messing things up (like unsetting flag 0431, causing you to restart the game instead of loading if you die).

I don't know if there are any event flags (below 8000) that work as anything more than condition switches for script events. Haven't seen any.

Edit: Your avatar is from xombie or whatsitscalled, correct?

 

Xaser? Don't I know you?

 

@Orfvar: Thanks for the clarity. Somehow I failed to realize that EQ+/EQ- were indeed seperate. I *did* happen to run across Runelancer's thread describing the effects you've mentioned, but they look a bit tough to utilize effectively. Seems I've got a lot to learn, hehe.

Oh, and yep, my avy's Zoe from Xombie all right. You really know your stuff.

@Deathsong: Great Scott, where'd you come from? Hehe, yep, that'd be the same me from ZDoom, still just as crazy-like. Nice to see a familiar face thingy.

Having said that, there's a user named Lamneth both here and on the ZD forums... I wonder, could they be the same, too? "Hooray coincidental?"

 

Runelancer found that setting event flags (I think, can't remember) above 8000 causes other stuff to happen than the setting of the flag.

In making the savegame editor, I found that there are exactly 8000 flags (1000 bytes) stored in profile.dat, no more. There should also be room for 30 items and no more than 5 weapons at a time. (Which is why you have to trade for some.) Plenty of space for your mod.

 

Hehe, good news then. I seriously doubt anyone's crazy enough to use all 8000... at least I hope not.

Thanks for the help there. I was thrown off a bit by the fact that the flags in-game tend to "skip" around a whole lot. Good thing it's not required, hehe.

I'll come back to this thread if I have any more questions or something like that. Nothing comes to mind now, though... go figure.

 

Hi there, remember me?

Someone drew my attention to this thread, asking me via email about flags about 8000. This stuff is from really way back, but I think I remember most of it.

These flags are not stored - the game reserves space for 8000 flags. However, beyond these flags is other stuff used for different things. Basically if you were to chop up memory into segments of 1000 bytes, it would look like this.

|0|1|2|3|4|5|6|7|8|9|

Slots 0-7 (ie, 0000-7999) contain the flags. However, beyond that, there are two other slots used to store other info. If you tell the game to write there, interesting things can happen. It could be your character's health, your position on the map, whatever. I really don't remember, but I think there were various effects like shaking the screen and managing the water level.

This information is not saved. The game is told to grab slots 0-7 and dump them to a file. However DURING gameplay you can still alter the later slots and do trippy things.

I seem to remember posting a few choice offsets I stumbled on in another thread. If anyone wants further information, give it a look if you can find it. The forum's search function should be handy.

Ciao!

 

Hehe, wow! Nice to see you around again, even though I'm relatively new and we've never talked a day in our lifetimes!

I do have a few notes saved from some of your older posts (<3 forum searches), and there's some pretty neat stuff to be done.

Well... *maybe* see you around, anyway?


*EDIT* - While I'm thinking about it, I'll go ahead and ask about another thing I'm having some trouble working... One of RuneLancer's posts (from the same thread I linked earlier, I just realized o_O) describes a method to change the little "Studio Pixel presents" text upon startup. No, I'm not gonna attempt to jack all the credits or anything silly like that, but I figured I should give it a spin anyway.

The only problem is, I (naturally) can't figure out how the devil to do it! I'm assembly-illiterate (sadly), and after many attempted searches, I can't seem to find the offending string in the hex data. Yes, I saw the notes about how the string's hex data was 1 less than what is displayed, but even after transposing all the little numbers, I still couldn't find the matching string. Ugh. >_<

Now if I'm correct, the following hex string maps out to " Studio Pixel presents":
20 53 74 75 64 69 6F 20 50 69 78 65 6C 20 70 72 65 73 65 6E 74 73

And due to reasons described in the thread, the hex data should actually wind up looking like this:
1F 52 73 74 63 68 6E 1F 4F 68 77 64 6B 1F 6F 71 64 72 64 6D 73 72

Neither of the two can be found using xvi32's search feature. How nice. I just *know* I've missed something obvious and/or stupid, but since I don't know the offset where the string starts, this is the closest I've been able to come on my own. Have any of you guys done this for yourselves and can point me in the right direction? I can't help but feel like the village idiot sometimes.

 

I may not have explained myself clearly in that thread; my appologies. The data is MOVed into memory directly; the data isn't simply sitting "there" in the exe.

The MOV instruction in assembly is used to move data around between RAM and registers. Registers being basically temporary storage locations the processor works with; it's like some kind of mini-RAM hooked up directly to the processor. All operations on data has to be made through a register, so the MOV instruction can be used to read something from RAM, do stuff to it, then write it back in there. Also, it can be used to directly write to RAM if you give it a numeric value (which is the case here.)

In this case, what you'll see is a series of C6 45 ?? ?? one after the other (C6 being the MOV instruction and 45 the addressing mode; don't worry about this stuff too much.) The first ?? will start at E0 and move up by 1 each letter (this is just telling the game which address the number gets written to.) The second ?? is what you're after: it's the ASCII value of the letter - 1.

I had to dig through a few CDs but I think I tracked down a copy of my notes. Or part of them at least. The block looks like this...

C6 45 E0 xx
C6 45 E1 xx
C6 45 E2 xx
C6 45 E3 xx
...

Happy hacking. (Btw, there are two spaces at the start, not one.)

 

Hi Rune, remember me? :x
Well, so you're back?

 

Holy jumpin' jack jesus, Rune?

Wow it's been awhile since you've posted here hahah, how's it been?

(ps I don't care if I'm off topic.)

 

Ah, much better. Runelancer, you're a lifesaver! It works like a charm, now. And somehow that actually made sense to me, which is surprising considering how horrible I am with coding in general. Well, at least I know enough about assembly that if anyone mentions "MOV" or something similar, the discussion's usually over my head (barring that paragraph of yours... memory management makes sense).

The makeshift "string" starts at address $000140FE, in case anyone else somehow needed to know. Very interesting, I say...

 

@Gardebiter:
Hey there! I'm not back (I really don't have time to work on CS anymore - too busy with a very big FFV ROM hack and Endless Saga) but I got an email from someone asking about this thing. I've got the thread on notify so I've been checking back every once in a while to put this question to rest.

@Chaddy-meister:
Oi man!

@Xaser:
Most, if not all, of assembly involves managing memory one way or another. For instance, having something jump is just a matter of manipulating their X/Y position and velocity using simple operations (add this, subtract that, grab this value, do this and that with it, write it back to RAM...) It's all very simple, so long as you can cope with having to puzzle out unknown memory offsets (trial and error works best when all else fails.)

If it's any help, "MOV" is a lot like an equal sign. For instance...

MOV eax,0x10

This is exactly the same as saying...

eax = 0x10

(Where eax is the name of one of those fancy-shmancy register thingabobs.)

If you can dump the game's code (there are plenty of disassemblers out there - I recommand anything that's under a meg or two; you're after the code, not some purdy bloated interface. ) and figure out a few offsets in RAM (like health, current weapon, ammo, so forth) it's not too hard to just look for some MOV instructions and change the numbers to get new effects. Give it a try sometime.

'Course it becomes a lot easier once you understand what everything does, but you have to start somewhere. Knowing assembly is just a big series of instructions telling the processor how to shuffly data around is enough to get anyone started, so long as you're up for some experimenting a little bit of research.

Happy hacking, Xaser!

 

Well the thing I ever wanted to know is: If you actually have got any offsets in ram or you know where data in rom is stored (like you know that the adress is for health or something) how do you actually figure out the rom adress? O_o

 

You'll need a disassembler for this one, as doing this by hand is impossible without an extremely high amount of familiarity with assembly (well, mainly, being able to convert hex to assembly in your head. Takes a lot of memorizing. )

Let's suppose you know offset 0049E6D0, which is for your max health. You found this out through, say, some program to trace the contents of a process's memory or some cheating device. Now you want to know what you can do with it. The first thing you'll do is create a blank text file and name it "Notes.txt" somewhere in your rom hacking folder or wherever you keep this info. You'll write the offset down, give it a name (MaxHealth), and a quick explanation ("This value keeps track of the player's max health.")

Now grab ahold of your assembly dump. Using your favorite text editor (TextPad? ) replace all occurences of "0049E6D0" with "MaxHealth." Save. You're going to build yourself a simplified version of the code, because digging through it with all those offsets is just not possible. Now you can run around in the code and see what every reference to "MaxHealth" does.

If you're a crafty little hacker, you'll find a place where MaxHealth is set to 3. It should be the first reference, starting from the start of the assembly dump. If you're even craftier, it won't take you more than a few minutes to realize this is where startup information for a new game is handled. And if you really have it in you to be an assembly hacker, you'll be unexplainably drawn to it and won't resist the urge to mess around with that chunk of code to see what you can do with it.

You can also find offsets by finding them with a hex editor in the exe, locating them in the assembly dump (always add 0x00400000 to the ROM offset when looking for it in the code,) and figuring out how the game loads it. For instance if there's a fictional structure with enemy data in the ROM laid out as so...

Byte 1: ID
Byte 2: Health
Byte 3: Damage

...and you notice the game loads all three bytes in RAM at 0x0004GH18, 9, A; you've found yourself 3 offsets. Take notes, name them, replace. Takes some familiarity with assembly though, as you have to figure out what the game is doing.

 

Hi RuneLancer, nice to see you around.

I actually posted a disassembly here a few days ago, it's linked in my introduction thread, on the second page, I think.

I'm working towards a better understanding of how the game works to facilitate making the kind of changes I want for my hack / mod. Since this includes weapons changes, I might end up making a tool for them, because everyone wants to change the weapons. But since I just started from scratch the other day and my assembly knowledge is so horribly rusty, it will take me quite some time.

Just a shot in the dark, but if RuneLancer wants to share any notes with me, I won't stand in the way. =P

Aside from that, relearning assembly a bit every day

 

My opinion that a hack should be the sum of an individual person's knowledge, experience, and talent still stands.

However, I've never been opposed to giving the occasional push in the right direction so long as the final result is your work, and not mine. So if you have questions, just ask ahead. It may be easier via email as I don't check the boards anymore (other than this thread; I get an email everytime someone posts here so it's kind of hard to ignore ) but who knows, maybe nostalgia will catch up with me after I'm done with a project or two. Either way, I remain available for questions if you need any help.

It's really good to hear that people are taking more of an interest in assembly - it's nothing too complicated, but it takes a lot of research and trial and error to puzzle your way through a dump. Even with all the work I did on CS, I don't have a complete, clean dump (though I have most of the more important game-related things worked out - there's no reason to pick away at code randomly until you need/want to do something.) It's easy to get into this stuff, but good luck nevertheless.

I had an editor for CS in the works, and I think the code (or what there is so far) is still laying around in my programming folder. The biggest snag you'll run into is the fact that all entities (weapons, enemies, items...) are operated through assembly, and not just a few parameters. But there are a couple of editable parameters you can mess with, and writing an editor for those isn't any hard.

Best of luck!

Edit: Talk about hijacking a thread huh? ^^; Sorry about that.

 

Thanks Rune
So this means the ram knows where to store in rom? (Adress)
And you can actually see it in the disassembler?

Anyway I've learned basic assembler and I learned lots of 65x02 Assembler (In my opinion the easiest) but actually, is DOS and Windows Assembler the same? (Besides of the 32 bit registers...)

 

The RAM stores nothing in the ROM. It's called "Read Only Memory" for a reason after all.

RAM is like a big sheet of paper the game can take notes on, make calculations, and keep track of stuff with. The ROM contains all of the actual information needed to make things happen, like some kind of video game strategy guide. If you've played pen and paper tabletop RPGs (dungeons and dragons, or whatever) you're likely to have notes for the quest you're running and character sheets. The notes are your ROM, and the character sheets (and the stuff currently happening) are the RAM.

By disassembling the game, you're basically sneaking a peek at your game notes. You can figure out what goes where in RAM. However, you can't view RAM with a disassembler because that's a completely different thing. Using the above tabletop RPG anology again, it's like reading the GM's quest notes. You know, for instance, there's a hoard of giant spiders in room #3, but you won't know how the fight'll turn out until you actually play it.

As for assembly, it's based on the processor. Instructions are implemented by the processor, not the OS. However, the OS plays a very important part in how things work. You can, for instance, call "interrupts" in DOS. These are low-level routines that do stuff like read from the mouse or the keyboard. However these things don't exist in Windows. Instead you'd call routines existing elsewhere in memory that have been loaded by Windows from a few DLLs.

You WILL understand DOS assembly if you understand Windows assembly and vice-versa. However, you won't be able to code the same way in either of them.

Btw, nice choice of chipsets. The 6502 is great stuff, and prepares you for the jump to the 65816, the SNES instruction set. Excellent knowledge to have if you plan on doing some SNES ROM hacking. The differences between 6502 and 80x86 (PC) assembly are very big however, but knowing one REALLY makes it easier to get into the other.

(Wtf is up with the board auto-logging me out mid-post? :x)

 

The RAM stores nothing in the ROM. It's called "Read Only Memory" for a reason after all.

Sorry I was in hurry, I meant:
So this means the rom knows where to store in ram? (Adress)

lol exchange it

Ram is the computers temp memory as far as I know.

And well Im not planing on hacking Im planing on developing games for old consoles ;D <3 old skool!