Skeetendo

I'm really sorry to bump this thread but after trying to manage by myself I haven't solved a problem.. I don't understand fully what you say in this part:

Quote:

1) When you say "warp-to points" do you mean the place where you are warped exiting from a door?
2) Is map width meant to be calculated in blocks (2x2 tiles) or in tiles (example: pallet town's width is 0x0A in blocks, but 0x14 in tiles)?
3)What do you mean with "X movement"?
4)Looking in the hex, the event displacement bytes look switched, or am i looking the wrong address? Here they are (starting offset 0x182f1):

Hiro's house...........1B C7 05 05
Rival's house..........1F C7 05 0D
Lab......................4F C7 0B 0C

first two bytes are event displacement formula, while the two following are Y and X position, isn't it?
I have troubles when exiting from two houses, while the other house's warp works fine..

I try to explain what is wrong (I use the lab in Pallet town as example)
[map width = 0x0A;
rows above lab door = 0x0B;
X movement = 0]

The formula is
Quote:

.
So i do:
Quote:

instead of "4F C7" that I think is bigendian for C74F. I really don't understand what's wrong..

I don't think so. what's the sense of a pointer, since the task of "event displacement" is to define how tiles and events are displaced when you re-enter the map from a warp (a door) and not from a border.

Quote:

Do I look such a noob? I clearly know what a pointer is and how it works, thanks for concern...

[...going to light a candle to invoke IIMarkus...]

EDIT: sorry, I become ill-mannered sometimes..

Let’s look at an existing map, Erika’s gym. Header is at 488FE. Bytes 6–7 point to 489A6. Going there, we find a lot of pointers:
48A11
48A81
etc etc. Eleven pointers total. (The list isn’t terminated, so your event count had better match up. 0220 is where other data starts.)

So what’s at 48A11? Well, text. But it starts with 08, which signals the text engine to start an ASM routine:

ld a,[$D77C]
bit 1,a
jr z,.ErikaBattle@
bit 0,a
jr nz,.ErikaLater@
call z,$4963
call $30B6
jr .end@
.ErikaLater@
ld hl,ErikaLaterText
call PrintText
jr .end@
.ErikaBattle@
ld hl,ErikaIntroText
call PrintText
ld hl,$D72D
set 6,[hl]
set 7,[hl]
ld hl,ErikaDefeatText
ld de,ErikaDefeatText;

call $3354
ld a,[$FF8C]
ld [$CF13],a ;
call PrepareTrainer
call $32D7
ld a,4 ; Monsters will use Mega Drain
ld [$D05C],a
ld a,3
ld [$D5FF],a
ld [$DA39],a
.end@ jp $24D7

Those labels in the code point to more text, by the way. It’s obvious by following the pointers that this block of code is Erika’s script, and (among other things) prints text and starts a battle with a trainer named Erika who uses Mega Drain. Suffice it to say that the rest of the Object Script Pointers determine the behavior of the rest of the trainers in the gym, and they always point to text data (which may of course call an ASM subroutine, as all of these do).

Note that this is not as simple as “one person, one pointer”: the last three pointers in ObjectScriptPointers are for the Rainbow Badge text, the “got Mega Drain” text, and the “bag is full, no Mega Drain” text. There’s more to it but it’s 11PM and I have work tomorrow… you can figure it out on your own. (But feel free to ask if anything is still unclear.)

I think you have that reversed… here 4FC7 is little‐endian for C74F, I believe. I think it points to the map data in WRAM0 (C000–CFFF).

I was trying to figure out the lab's script, and in the same time I gave a look to the object data in the mapheader.
I've seen that rival'object is defined as a trainer instead of a normal people as I expected (normale people is defined with 6 bytes, while trainer has 2 more bytes that define respectively "trainer type" and "pokemon set").
So I tried to change his "trainer type" (&hE1=rival1) to another one (i put &hCA=bugcatcher, just to say one), and i found out that supposedly nothing really changed.
Eventually I found out where the information of the battle_enemy is stored (it's hardcoded in a subroutine of the "Lab's script"), I edited it and this time it actually worked.

So I was wondering: what actually does that "trainer type" byte do?
Anyone knows something about that?

In fact that's what i was trying to understand: why wasting 2 bytes with useless datas? (also considering that the whole rom is so chaotic because of the programmers' will of reducing space used!!).
Anyway you reassured me saying so. I think I'm going to not giving too much importance to those two bytes..

The garbage might be because you need to edit the connection data on route 5 as well to connect to Cinnabar

Well what part of it is confusing you? Perhaps one of us could better explain it

#2-3: [Pointer to "Connection Strip"s Upperleft Block (Connected Map)]

Quote:

Open RedMap. go to connected map.
If it is located:
East of current map: move the mouse on the block located on the first row (top-to-bottom), first column(left-to-right);
West of current map: move the mouse on the block located on the first row (top-to-bottom), third column(right-to-left);
South of current map: move the mouse on the block located on the third row (top-to-bottom), first column(left-to-right);
North of current map: move the mouse on the block located on the third row (bottom-to-top), first column(left-to-right);

Then take note of the offset (bottom left of RedMap's window), transform it in a pointer (little-endian) and there it is.

#4-5: [Pointer to "Connection Strip"s Upperleft Block (Current Map)]

Quote:

I can't explain better than it is already.

"Y_Movement_of_"Connection Strip" indicates how many blocks the connected map is shifted vertically("0"=connected map aligned to current map; 1=one block shifted to south; ff=one block shifted to north, and so on..)
"X_Movement_of_"Connection Strip" indicates how many blocks the connected map is shifted horizontally("0"=connected map aligned to current map; 1=one block shifted to right; ff=one block shifted to left, and so on..)

#6: ["Bigness"]

Quote:

That's it

#10-11: [Window]

Quote:

IDEM

P.S.:
@IIMarckus or Mateo:
Please edit the first post (typo): Connection Byte -> 01 isn't North, it's East

You probably made some calculation error
I use an example to let you understand best.

For example we want to connect a map north of our current map; size of connected map is: 9 height, 10 (=0a in hex) width.
North formula is:
c6e9 + 09*(0a+06) = c6e9+90 = c779

So the value you have to write is c779 (big endian) --->79c7 (little endian).

EDIT: This stuff i wrote is wrong, don't look at it..

That just messed it up even more.

Cinnibar Header + North Connection Data (I had it in the correct order):

00 09 0A 69 40 81 4A 19 4A 09 10 68 46 EB C6 0A 0A 23 00 F9 C8

Route 5 Header Data:

00 12 0A D2 45 B5 56 B2 56 0C