You are not logged in.
Pages: 1
Good evening everyone, posting here today to ask/learn how to edit these files.
First off, I have the "pokered" files pulled from github and Notepad++ updated to open the ".ASM" files.
Second, I am referring to the "scripts" folder with the "oakslab.asm"file and in the "text" folder found with the "oaks_lab.asm"file.
Thirdly, if needed, I can edit this post to paste the "code" here.
Okay, so I am interested in learning how the structure of these files work...and by doing so, learn how to edit the game's dialog.
I am unsure what "text, line, cont, para" mean...along with "call, xor, jp, dw"
If anyone is able to help me get started, do message me or reply below.
Also, are there any updated forks of pokered that have fixed some of the bugs from the vanilla game ?
Offline
Good evening everyone, posting here today to ask/learn how to edit these files.
First off, I have the "pokered" files pulled from github and Notepad++ updated to open the ".ASM" files.
Second, I am referring to the "scripts" folder with the "oakslab.asm"file and in the "text" folder found with the "oaks_lab.asm"file.
Thirdly, if needed, I can edit this post to paste the "code" here.
Okay, so I am interested in learning how the structure of these files work...and by doing so, learn how to edit the game's dialog.
I am unsure what "text, line, cont, para" mean...along with "call, xor, jp, dw"
If anyone is able to help me get started, do message me or reply below.
Also, are there any updated forks of pokered that have fixed some of the bugs from the vanilla game ?
"text, line, cont, para" I think have to do with how the text moves in the game, how it starts a new paragraph or keeps on with the same sentence.
"call" calls for a function, but I'm still getting around to learning how that works. Same with jp (it jumps to another part in the program).
"xor" is a logical function. It compares two registers bit by bit, if they match, the result for that bit is 0 (reset), if they're different, the result for that bit is 1 (set).
As for "dw", I'm not really sure.
Offline
You actually described the "cp" functionality instead of "xor" there. You should really look up tutorials on learning gameboy z80 assembly, since without that, you won't be able to really understand the code at all. here is a document that describes the instructions in more detail. However, I think there are a few differences in syntax in some places between the way this document presents them and the way the RGBDS compiler expects them to be written.
also, "dw" is not really a cpu instruction. "dw" means you're placing a word, "db" means you're placing a byte. Often times, you'll see "dw LabelNameHere" used, which means it places the address of routine whose name you wrote there (so you don't have to worry about calculating pointers). Similarly, you'll often see things like "db BULBASAUR" so that you don't have to remember what Bulbasaur's internal ID number is. Expanding on this, pokered includes some macros with similar names derived from those. "dbw" for example is one that lets you put a byte followed by a word on the same line, to make things more clear. "dba" is used as a short-hand for putting a "3 byte pointer" or "far pointer" to something. Think of is as "declare bank, address". So "dba Mon001_EvosMoves" would put the bank that label is in, followed by the address where it is stored.
I am not very active on this forum. I only pop in from time to time.
Offline
You actually described the "cp" functionality instead of "xor" there. You should really look up tutorials on learning gameboy z80 assembly, since without that, you won't be able to really understand the code at all. here is a document that describes the instructions in more detail. However, I think there are a few differences in syntax in some places between the way this document presents them and the way the RGBDS compiler expects them to be written.
also, "dw" is not really a cpu instruction. "dw" means you're placing a word, "db" means you're placing a byte. Often times, you'll see "dw LabelNameHere" used, which means it places the address of routine whose name you wrote there (so you don't have to worry about calculating pointers). Similarly, you'll often see things like "db BULBASAUR" so that you don't have to remember what Bulbasaur's internal ID number is. Expanding on this, pokered includes some macros with similar names derived from those. "dbw" for example is one that lets you put a byte followed by a word on the same line, to make things more clear. "dba" is used as a short-hand for putting a "3 byte pointer" or "far pointer" to something. Think of is as "declare bank, address". So "dba Mon001_EvosMoves" would put the bank that label is in, followed by the address where it is stored.
I probably made a booboo trying to throw the example from the beginning, lol. I forgot to talk about logical functions first, and it would have been less confusing. The ASM tutorial will do a far greater job than I can, though. I've taken notes from here and it helped me understand the code better. However, there are some things I can't quite put my finger on (example it uses the call function to a function that apparently has nothing, and I can't seem to work that out).
Offline
Thanks for the replies !
Here is an example from text\maps\oaks_lab.asm
_OaksLabText_1d340:: ; 9526b (25:526b)
text "PROF.OAK is the"
line "authority on"
cont "#MON!"
para "Many #MON"
line "trainers hold him"
cont "in high regard!"
done
So from my understanding :
"text" starts the dialog
"line" writes the dialog on a new line (like hitting return in MS Word)
"cont" seems to do the same as line ?
"para" does not seems to break the dialog, but just starts a new sentence.
"done" ends the dialog
Do correct me if I am wrong or rather elaborate on these terms.
Now, I tried to search for where this lines up in scripts\oakslab.asm
OaksLabText9: ; 1d336 (7:5336)
db $08 ; asm
ld hl, OaksLabText_1d340
call PrintText
jp TextScriptEnd
OaksLabText_1d340: ; 1d340 (7:5340)
TX_FAR _OaksLabText_1d340
db "@"
This is where I get a bit lost...can you explain what each line is doing ?
* thanks in advance *
Offline
Thanks for the replies !
Here is an example from text\maps\oaks_lab.asm
_OaksLabText_1d340:: ; 9526b (25:526b) text "PROF.OAK is the" line "authority on" cont "#MON!" para "Many #MON" line "trainers hold him" cont "in high regard!" done
So from my understanding :
"text" starts the dialog
"line" writes the dialog on a new line (like hitting return in MS Word)
"cont" seems to do the same as line ?
"para" does not seems to break the dialog, but just starts a new sentence.
"done" ends the dialogDo correct me if I am wrong or rather elaborate on these terms.
Now, I tried to search for where this lines up in scripts\oakslab.asm
OaksLabText9: ; 1d336 (7:5336) db $08 ; asm ld hl, OaksLabText_1d340 call PrintText jp TextScriptEnd OaksLabText_1d340: ; 1d340 (7:5340) TX_FAR _OaksLabText_1d340 db "@"
This is where I get a bit lost...can you explain what each line is doing ?
* thanks in advance *
As for the last part, I'm having the same confusion but with another script (I made the Rival choose the starter weak to yours but although his team evolves accordingly and he goes to pick the supposed Pokéball, he always picks the one he picked in the original games).
As for "cont", I think it has to do with having the text continue, instead of starting a new paragraph. In the game, the first line would go away to make room for the new one.
Offline
text = starts the text
line = new line, right after "text" or "para"
cont = pushes the old text up a line, to show a new one
para = starts a new paragraph
The line that looks like:
db $08 ; asm
is technically outdated. I know why you have it, though. I told you to grab the "compatible" branch of Red++ instead of Master, and that branch is missing a lot of vanilla pokered updates that Master has (but that branch also is still supported by GlitchMap and doesn't have halfway-finished updates and such). Anyways, modern pokered replaced that with
TX_ASM
to make it more obvious its an in-text code that means what follows is an ASM routine instead of normal text.
As for *why* it uses the ASM routine just to print some other text without doing anything useful, not sure. But that's all it's doing.
ld hl, OaksLabText_1d340
just loads the hl register with the address for that text
call PrintText
calls the routine PrintText, which prints out a textbox with whatever text hl is pointing to
jp TextScriptEnd
jumps to the common routine for finishing up after a text script such as this one. Then, of course, OaksLabText_1d340 does nothing except
TX_FAR _OaksLabText_1d340
db "@"
TX_FAR just means it is calling text from another bank. 90% of the text in the game is grouped together into a few banks of its own instead of being in with the scripts that reference it, so you see TX_FAR a lot. The db "@" just marks the end of the text.
-----
To answer the question about where Gary walks to, I'd have to look into that a bit more to see what all you've already done. Oak's Lab has a lot of connected scripts for the different parts, so I can see why it's a mess for you to figure out. But without knowing exactly what you've done it's hard to say what went wrong. If you project is on github that would make it a lot easier to get help from me or others, since we can see exactly what you did, and therefore tell you what you did wrong and how to fix it.
Last edited by Luna (2017-07-17 02:39:07)
I am not very active on this forum. I only pop in from time to time.
Offline
To answer the question about where Gary walks to, I'd have to look into that a bit more to see what all you've already done. Oak's Lab has a lot of connected scripts for the different parts, so I can see why it's a mess for you to figure out. But without knowing exactly what you've done it's hard to say what went wrong. If you project is on github that would make it a lot easier to get help from me or others, since we can see exactly what you did, and therefore tell you what you did wrong and how to fix it.
I appreciate your help! I'm new to this, and I don't have it on github at the moment. Didn't want to put it up there (and never bothered to set it up) until I made a bigger breakthrough, but I ended up putting my project on hold because I got stuck with stuff. I hear it's useful though, so chances are I'll upload it there in the near future.
Anyway, here's the part of the code regarding the script. It's from scripts/oakslab.asm
OaksLabScript8:
ld a, [wPlayerStarter]
cp STARTER1
jr z, .Squirtle
cp STARTER2
jr z, .Bulbasaur
jr .Charmander
.Charmander
ld de, .MiddleBallMovement1
ld a, [wYCoord]
cp $4 ; is the player standing below the table?
jr z, .asm_1ccf3
ld de, .MiddleBallMovement2
jr .asm_1ccf3
.MiddleBallMovement1
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_UP
db $FF
.MiddleBallMovement2
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db $FF
.Squirtle
ld de, .RightBallMovement1
ld a, [wYCoord]
cp $4 ; is the player standing below the table?
jr z, .asm_1ccf3
ld de, .RightBallMovement2
jr .asm_1ccf3
.RightBallMovement1
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_UP
db $FF
.RightBallMovement2
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db NPC_MOVEMENT_RIGHT
db $FF
.Bulbasaur
ld de, .LeftBallMovement1
ld a, [wXCoord]
cp $9 ; is the player standing to the right of the table?
jr nz, .asm_1ccf3
push hl
ld a, $1
ld [H_SPRITEINDEX], a
ld a, $4
ld [H_SPRITEDATAOFFSET], a
call GetPointerWithinSpriteStateData1
push hl
ld [hl], $4c
inc hl
inc hl
ld [hl], $0
pop hl
inc h
ld [hl], $8
inc hl
ld [hl], $9
ld de, .LeftBallMovement2 ; the rival is not currently onscreen, so account for that
pop hl
jr .asm_1ccf3
.LeftBallMovement1
db NPC_MOVEMENT_DOWN
db NPC_MOVEMENT_RIGHT ; not yet terminated!
.LeftBallMovement2
db NPC_MOVEMENT_RIGHT
db $FF
.asm_1ccf3
ld a, $1
ld [H_SPRITEINDEX], a
call MoveSprite
ld a, $9
ld [wOaksLabCurScript], a
ret
OaksLabScript9:
ld a, [wd730]
bit 0, a
ret nz
ld a, $fc
ld [wJoyIgnore], a
ld a, $1
ld [H_SPRITEINDEX], a
ld a, SPRITE_FACING_UP
ld [hSpriteFacingDirection], a
call SetSpriteFacingDirectionAndDelay
ld a, $d
ld [hSpriteIndexOrTextID], a
call DisplayTextID
ld a, [wRivalStarterBallSpriteIndex]
cp $2
jr nz, .asm_1cd28
ld a, HS_STARTER_BALL_2
jr .asm_1cd32
.asm_1cd28
cp $3
jr nz, .asm_1cd30
ld a, HS_STARTER_BALL_3
jr .asm_1cd32
.asm_1cd30
ld a, HS_STARTER_BALL_1
.asm_1cd32
ld [wMissableObjectIndex], a
predef HideObject
call Delay3
ld a, [wRivalStarterTemp]
ld [wRivalStarter], a
ld [wcf91], a
ld [wd11e], a
call GetMonName
ld a, $1
ld [H_SPRITEINDEX], a
ld a, SPRITE_FACING_UP
ld [hSpriteFacingDirection], a
call SetSpriteFacingDirectionAndDelay
ld a, $e
ld [hSpriteIndexOrTextID], a
call DisplayTextID
SetEvent EVENT_GOT_STARTER
xor a
ld [wJoyIgnore], a
ld a, $a
ld [wOaksLabCurScript], a
ret
What I recall having changed from the original is switching around the Starters and the HS_STARTER_BALL parts. But, for example, when I pick Bulbasaur, Gary walks up to the Pokéball containing Squirtle, but takes the one containing Charmander. And, in battle, I already edited his team so that he chose Squirtle. I think it has to do with that wRivalStarterTemp part, but I can't seem to make heads or tails out of that.
Offline
"xor" is a logical function. It compares two registers bit by bit, if they match, the result for that bit is 0 (reset), if they're different, the result for that bit is 1 (set).
You actually described the "cp" functionality instead of "xor" there.
No, he did in fact describe an xor operation.
Offline
Ah whoops, I misread. I read it as him saying it compares the two registers, then returns the z flag as set or reset depending on whether the registers matched completely. Which would be cp but without mention of the carry flag. Sorry for giving misinformation due to not reading carefully.
I am not very active on this forum. I only pop in from time to time.
Offline
Thanks friends, after a little problem solving on my end, I now have the "Cygwin64 Terminal" up and running now.
* just had to upgrade from 32 to 64 bit *
Followed the "INSTALL.md" instructions and got "rgbds" setup correctly.
The cloning process went great and even the "make" command worked fine.
Now that I have the files, I am going to start looking into editing the starting dialog.
Offline
@Break - Another thing to keep in mind, since I know you're using Red++ as a base: there are a few instances where you may have two very similarly named files by accident, where one is used and the other is not. Such as read_trainer.asm (what I called it) and read_trainer_party.asm (what vanilla pokered called it) where one is a leftover vanilla version and the other is the actually used version. Just an artifact of the recent merges that will be cleaned up later. In those cases it should be obvious which one is the "real" one though just by glancing through them. In those examples, you can tell at a glance that there are comments referring to things that definitely weren't in vanilla Gen 1 in my copy. There shouldn't be too many places where that comes up, but just something to let you know about.
Last edited by Luna (2017-07-18 07:42:06)
I am not very active on this forum. I only pop in from time to time.
Offline
@Mateo
Ah, that is a helpful note !
I tested out the "make" red file up to the rival battle.
Red++ has a lot going on ^_^"
After editing most of the pallet town dialog, I would like to look into the splash screens and title screen programs.
Hmm, but for now I will read through the oaks lab code and see if I can make changes.
Offline
Pages: 1