0 Members and 3 Guests are viewing this topic.
Quote from: Streetwalker on January 23, 2013, 01:32:55 pmBasically, he wants you to check if an enemy pokemon's level is enough for it to have evolved and if so, make it the evolved form. Actually, I think he is suggesting the opposite. For example: Dragonite evolves from Dragonair at level 55. As such, you shouldn't normally encounter any Dragonite used by trainers or in the wild that are under level 55. However, I believe there have been some exceptions in pokemon games, but usually that isn't the case.
Basically, he wants you to check if an enemy pokemon's level is enough for it to have evolved and if so, make it the evolved form.
delete your save filehit continue
Who's Lola ?
For now, every trainer has a tile number, let's say from 1 to 50 for example (in fact, I think it starts at 171 or some other ugly number ). So when you walk on a number between 1 and 50, if the number saved in {TrainerNumber} (smart name isn't it ?) is lower than the tile number you walked in, well battle, and when you beat the trainer, {TrainerNumber} increases. And if {TrainerNumber} is greater than the tile, then you already beat the trainer and there is no more battle
The game has no protection against continuing a game without having started one, which makes for an interesting way of exploring the RAM contents of the calculator
The game, after maxing out any stats past 255, will set them down very low.So, if I have a Pidgeot at level, say, 75, it's health will be so high, it will be (something like, this is just a random guess) 287 and thus it rolls over to a number like 287 - 255 = 32. I don't like going into battles against level 50 pokemon and losing my best one in the first hit.
To continue this discussion :Quote from: Hayleia on March 15, 2013, 02:41:58 pmFor now, every trainer has a tile number, let's say from 1 to 50 for example (in fact, I think it starts at 171 or some other ugly number ). So when you walk on a number between 1 and 50, if the number saved in {TrainerNumber} (smart name isn't it ?) is lower than the tile number you walked in, well battle, and when you beat the trainer, {TrainerNumber} increases. And if {TrainerNumber} is greater than the tile, then you already beat the trainer and there is no more battle How many tiles you really have ? Cause if it's under 77 (which is pretty much sure), then you can stick with your system and use rle compression.Elsewhere, you have to beat all the trainers in a certain order, right ? I don't remember if the progress through maps was kind of linear, but if so, then it's not a problem.I've compressed your map using horizontal RLE+7th bit for "lonely" tiles and (if I'm correct)... it compressed up to 85% (from 10948 bytes to 1723) Spoiler For compressed map: <snipped >But keep in mind that the speed to read it on the fly will really depend on the tiles you're trying to reach... That's why dividing it into smaller parts would help.
I'm not quite sure how your trainer system works. It sounds like you have to walk on top of a trainer to battle them? What is TrainerNumber? You use one variable for every single trainer? One way you could do it would be to use a single tile for every trainer, say tile 85. Then you could have a table listing the coordinates of each trainer and possibly a pointer to the trainer's sprite. Actually, you really don't even need a special tile, especially if you divided your maps into smaller pieces. With each map segment you would pass a pointer to a table that contains the coordinates of the trainers. When the trainer is on screen, just subtract the trainer coordinates from the map coordinates and draw them. You could use the same table for NPCs, and since in each little map section (each town/route) there won't be that many trainers/NPCs, you could load the table into RAM and change the coordinates as you please without worrying about modifying the data in your program. That way you could have NPCs that walk around, trainers looking in different directions, etc.