So if I assigned offsets using 0x900000 as the dynamic, it will only apply to the expanded 16 mb?

Cool. I want to play it :D

"Someone bumped your Pokemon Dark Future thread.
Why did you stop? Not a lot of interest, I saw, but maybe you could've promoted it more..."

Actually, I never stopped
I just didn't bump it myself which I've done several times already (planned on doing so before releasing the next beta).

Someone bumped your Pokemon Dark Future thread.
Why did you stop? Not a lot of interest, I saw, but maybe you could've promoted it more...

Anyway, I'd love to help make a Gold hack with you, if you would be interested. GBC hacks are cool.

I know all about how bits, bytes, flag true/falses and RAM work :P

So I was right, in a way: Using a flag in unspecified space could cause corruption, but using a flag in pre-allotted space is fine since the game is programmed around that space already, I figured this.

Using that logic, though, shouldn't one be able to set any flag as long as they then delete the old, non-edited data later? It would make sense, I think.

"Flags" are actually bits. A byte consists of 8 bits, each of them can either have value 0 or 1. In case all eight bits are set, the byte is FF in hexadecimal (11111111 in binary).

Well, you know what RAM is don't you?
The game transfers data from ROM to RAM memory to store temporary data.
Some of RAM will stay unchanged when the game is running (e.g. flag bit data) while other part of it will change time after another (e.g. the place where the game stores which enemy you're battling against, your pokemon used and its moves...).

Anyway, let's say that flag bits from 1000 to 1007 affect a byte in ram memory at offset $D000 and flag bits from 1008 to 100F ram memory at offset $D001 (because 8 bits form one byte). In this case, we know that for example flag bit 2000 affects byte at $D000 + 0x1000 / 8 = $D200 in ram where for example the names of your pokemon in party are stored. So basically, it's only safe to use the flag bits used in the original game to make sure you won't affect other ram data with the flag bits you're using.

Then again, if you for example know that there is unused ram in DA00 to DB00, you can use flag bits that affect that part of ram region.

Oh wow that explanation for connections is a lot like mine, except better. That's cool to know I was close though.

Thanks I'll look at that.

Also, I saw YOUR conversation with Spiky-Eared Pikachu, and while I know unused flags can be unstable, why is that exactly? Would it be because they could overwrite other parts of the ROM, or is it more like common programming where the flags won't work without defining them first? I'm curious. (I used "unstable" flags in my first FR hack and nothing went wrong, now I realize it was risky >_>)

This should help you figuring out how map connections work properly:
http://datacrystal.romhacking.net/wi...Red/Blue:Notes

Anyway, I haven't "mastered" them either but eventually, happen to get them working.

Link to RBY Map Headers? Is that a thread, you mean?

And also looking back that info I gave seems REALLY spotty. One day, I might get the urge again to find out more, but it's tough without any tuts, and horizontal connections are a nightmare. Dx

Edit: I saw your video here with a rightward connection, do you have any set way? (Other than not changing the map size ) I've gotten OMDL to load correctly, but upon stepping onto the map, the CMPDL is wrong and, although the movement permissions match the graphics, no more graphics are loaded after stepping on the map, and I cannot go further.