Decomp & Disassembly Tutorials
Pokeemerald Following Pokémon Page 3
Started by WiserVisor October 14th, 2021 10:35 PM- 16040 views
- 61 replies
What would I need to change to make your followers the last mon in the party instead of the first?
To do this, you would need to go to src/field_specials.cand edit the function
GetLeadMonNotFaintedIndexto look like this:
u8 GetLeadMonNotFaintedIndex(void)
{
s8 i;
for(i = CalculatePlayerPartyCount() - 1; i > -1; i--)
{
if (GetMonData(&gPlayerParty[i], MON_DATA_SPECIES2, NULL) != SPECIES_EGG && GetMonData(&gPlayerParty[i], MON_DATA_SPECIES2, NULL) != 0
&& GetMonData(&gPlayerParty[i], MON_DATA_HP, NULL) != 0)
{
return i;
}
}
return 0;
}This will walk through the back of your party first, looking for the last non-fainted mon.
Also, two followers if possible XD
You'll have to ask ghoulslash about that one, since I did not create the Follow Me code myself.
I found a pretty weird bug. When you jump over a ledge and land in tall grass, you will get an encounter 100% of the time as soon as you take a step. I tested it on the unmodified FollowerGen1-3 branch.
I'm also curious if there's any way to implement this in firered it would be cool to have charmander follow you around on the map if anyone does figure it out pls tell me, also wouldn't it be possible to make this a patch for those who just want to play the game as is with the follower pokemon or am i missing something like does it have to be activated in some way first or is it just too different from base emerald to use as a patch?
I'm also curious if there's any way to implement this in firered
There is. It's all code, so anyone that can at least read and understand the code written in Pret's projects and Wiser's branch could just port the code over to Pokefirered.
also wouldn't it be possible to make this a patch for those who just want to play the game as is with the follower pokemon or am i missing something
That's technically and easily possible, yes. Whether anyone's willing to do that would be a separate matter.
does it have to be activated in some way first
It doesn't. As explained in the first post, there's a couple of overworld scripting commands used to spawn a following Pokémon, but just like Wiser edited Prof. Birch's script for it, anyone could edit Oak's in a hypothetical Pokefirered port.
or is it just too different from base emerald to use as a patch?
I mean, if you mean what I think you mean, then yeah, it is.You can't create a patch with the feature as it's coded right now, only compatible with and built on the codebase of Pokémon Emerald, apply that patch into a FireRed ROM and expect things to work.
That's just a recipe for disaster as you inevitably break the patched ROM due to the many differences in the code of the 2 games.
Hey, I just tried pulling this into my branch that cloned off pret in Novemeber 2022 and got lots of conflicts that 1.5hrs of merging couldn't get all of the bugs out of. This commit seems to have many outdated references (such as gWeatherPtr->altGammaSpritePalIndex). For any newbies trying this commit: If you aren't too far into your romhacking, I'd recommend just cloning this repo and using that as a base.
hello, would you happen to know why i get palette errors on the newer overworld sprites? (im using emerald dx source for my project)
i followed everything 1:1 alongside the chimecho data so happiny would appear afterwards in all possible applicable places.
im using the following from your repository:
const u32 gObjectEventPic_Happiny[] = INCBIN_U32("graphics/object_events/pics/pokemon/happiny.4bpp");
const u16 gObjectEventPal_Happiny[] = INCBIN_U16("graphics/object_events/palettes/followers/happiny.gbapal");
in: object_event_graphics.h
along with
$(OBJEVENTGFXDIR)/pokemon/happiny.4bpp: %.4bpp: %.png
$(GFX) $< [email protected] -mwidth 4 -mheight 4
in: spritesheet_rules.mk
but the happiny shows up with messed up colors
torchic working properly:
mons past chimecho aka happiny:
sorry for the large images
i followed everything 1:1 alongside the chimecho data so happiny would appear afterwards in all possible applicable places.
im using the following from your repository:
const u32 gObjectEventPic_Happiny[] = INCBIN_U32("graphics/object_events/pics/pokemon/happiny.4bpp");
const u16 gObjectEventPal_Happiny[] = INCBIN_U16("graphics/object_events/palettes/followers/happiny.gbapal");
in: object_event_graphics.h
along with
$(OBJEVENTGFXDIR)/pokemon/happiny.4bpp: %.4bpp: %.png
$(GFX) $< [email protected] -mwidth 4 -mheight 4
in: spritesheet_rules.mk
but the happiny shows up with messed up colors
torchic working properly:
mons past chimecho aka happiny:
sorry for the large images
hello, would you happen to know why i get palette errors on the newer overworld sprites? ..........
Initially, it would seem like the Happiny sprite is not indexed properly, since all the right colors seem to be there, just in all the wrong places. Is that sprite indexed? If it is, I would have to do a bit more digging to tease out the real issue.
Hey, I just tried pulling this into my branch that cloned off pret in Novemeber 2022 and got lots of conflicts that 1.5hrs of merging couldn't get all of the bugs out of. This commit seems to have many outdated references (such as gWeatherPtr->altGammaSpritePalIndex). For any newbies trying this commit: If you aren't too far into your romhacking, I'd recommend just cloning this repo and using that as a base.
Yeah.....yeah. I've been meaning to sync these repos up with pret's, but I just haven't made the time. It takes a hot minute, like you said.
hey, that was the issue, the sprites were not indexed, all is working now as it should be :) thank you!
Just did a large merge with pret's repo, so merging this project into your own (assuming your project is built on pret's) should be substantially simpler now, and removed the Gen 4 Pokémon sprites that snuck into the Gen1-3 branch. Also added a few macros and bug fixes relating to the follower_face commands, which can be used in scripts. Credit goes to Karl for those two.
I found a pretty weird bug. When you jump over a ledge and land in tall grass, you will get an encounter 100% of the time as soon as you take a step. I tested it on the unmodified FollowerGen1-3 branch.
You are right, that bug is definitely there. I've tried looking into the code relating to the odds of a wild encounter, as well as code relating to jumping off of ledges, but I didn't see something that would be causing this issue. Very strange. If anyone has any ideas for fixing that bug, I'd be happy to hear it.
Just did another smaller pret sync, as well as added a few bug fixes and a new option to speed up followers exiting doors and jumping down ledges. I've written how to use it in the "Recommended Use" section on the main post, but I'll write it here too: To make the followers move faster in these scenarios, go to
include/constants/global.hand scroll down to the bottom of the file, where you'll see
FAST_FOLLOWERS. If you set that define to TRUE, the player will be able to walk immediately after exiting doors and jumping ledges, and the follower will not get out of sync. Thanks to Karl for asking for and helping bug test this addition.
Just added a new macro called
setfollowerwarpposto be used when doing a scripted warp. I detailed the use of it on the main post under "Recommended Use". Karl's going crazy with the bug finds, so thanks to him again for leading me to make this fix.
I found a pretty weird bug. When you jump over a ledge and land in tall grass, you will get an encounter 100% of the time as soon as you take a step. I tested it on the unmodified FollowerGen1-3 branch.
You are right, that bug is definitely there. I've tried looking into the code relating to the odds of a wild encounter, as well as code relating to jumping off of ledges, but I didn't see something that would be causing this issue. Very strange. If anyone has any ideas for fixing that bug, I'd be happy to hear it.
I experienced this bug too and decided to have a look...It seems the game checks for random encounters on the first frame a player is standing still after having moved or turned. When the player takes a step after having jumped a ledge, the time it takes for the player to walk to the next tile and stop is shorter than the time it takes for the follower Pokémon to land after jumping the ledge. Looking at the code, it seems the player's
tileTransitionStatebecomes
T_TILE_CENTERonce they finish walking to the next tile, but it stays as
T_TILE_CENTERuntil the follower Pokémon has finished jumping the ledge (where normally it would stay as
T_TILE_CENTERfor only one frame). This causes the game to check for an encounter every frame until the follower has landed from the jump.
encounter.gif
This can be fixed by adding an additional check on line 121 in
src/field_control_avatar.cto see if the player is allowed to move (which as far as I can tell doesn't break anything else...).
if (forcedMove == FALSE)
{
if (tileTransitionState == T_TILE_CENTER && runningState == MOVING)
input->tookStep = TRUE;
if (forcedMove == FALSE && tileTransitionState == T_TILE_CENTER && gPlayerAvatar.preventStep == FALSE)
input->checkStandardWildEncounter = TRUE;
}encounter2.gifI hope this helps. :)