You are not logged in.
I need to learn how to make it so regular trainers have a different party based on how many badges the player has. I found this thread here: https://hax.iimarckus.org/topic/7137/ . However it seems to be based on an older version of pokecrystal than the one I am working with. I've tried to adapt it to a more current version but I'm not getting how to make it work, I don't really know much about how the language works to figure it out. I found some very helpful tutorials on the github page for pokecrystal, but the tutorial I need hasn't been finished yet, unfortunately.
There are probably lots of various ways to tackle this problem, but one that comes directly into my mind would be to first look up the routine that loads the trainer data for a trainer based on its "Trainer Group" and "Trainer No." value for that trainer group. You could call your own subroutine there that possibly increments the "Trainer No." value based on the amount of badges the player has.
You could make use of this kind of solution by for example having three different variations of generic trainers in the game. This could be done by reserving trainer numbers 01, 02, and 03 for different pokemon data for the first trainer of a certain trainer group, 04, 05, and 06 for the second, 07, 08, and 09 for the third, and so on. You could even implement variation between trainer groups/classes by for example having a table which tells, how many different pokemon data combinations trainers of each group have, and then have your own routine determine, how to possibly increase the "Trainer No." value based on this table, and the amount of badges the player has.
If you're however okay just by for example modifying the levels of the pokemon the trainer has, you could modify the trainer's pokemon data after it has been loaded into ram, but before the battle starts. I'm not sure how "doable" this latter option would be because I remember there being some issues when I had been trying to manually modify trainer data of trainers in ram after a battle has started. It has been ages since I tried though.
Last edited by Miksy91 (2018-09-25 21:21:14)
I should note I followed this tutorial: https://github.com/pret/pokecrystal/wik … -nicknames
I found where I can increment the trainer ID by one, and have successfully done so. So I should just be able to increment it by the number of badges. The difficulty I'm having now is doing so only when the trainer in question is the specific trainer type that is variable. I'm basically trying to say "If trainer type is "variable, then (increment trainer ID). I just don't know how that's done. Everything I am trying just seems not to work.
So I do this
ld a, [wOtherTrainerID]
which successfully increments the trainer ID by one. Elsewhere in the script I see this:
ld a, [wOtherTrainerType]
bit TRAINERTYPE_ITEM_F, a
jr z, .no_item
which appears to be the way its doing an if statement, but my ignorance of assembly is keeping me from doing it myself with any success.
I have gotten closer to solving this. For whatever reason if I check the trainer's class instead of their type it works perfectly, but if I want it based on the trainer's type it doesn't work. But at least I know that I'm checking a variable correctly.
You should have a byte table defined by trainer classes' ids / byte codes for which you want to increment the trainer number. In the following example, you would have $FF as the terminator byte of the table.
You can have the following routine for checking, whether the trainer class encountered is listed in a FF-terminated table.
ld a, [TrainerClassEncountered] ld b, a ld hl, TableAddress jr .loop .loop ----- ldi a, [hl] cp a, $FF jr z .notFound cp a,b jr nz, .loop ret .notFound xor a,a ret
After this routine, the z flag is set if you should increment the trainer number by badge count or whichever way you like based on the badge count. You could for example build for own subroutine for incrementing by 1 if you have less than 3 badges, by two if you have less than 6, and by 3 otherwise.
Also notice that this routine resets the values of a, b, and hl. If the original values of b, or hl are important after this routine is executed, you should push, and pop bc and hl inside this routine, or just before it is called. Register pair af you cannot pop in the end because that would also reset the value of z flag to what it used to be. Register f is after all used for storing the values of c (carry) and z (zero) flags.
This kind of a routine most likely exists in rom bank 0 already, so you could look for the existing implementation and use it directly.
Last edited by Miksy91 (2018-09-29 09:45:40)