• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Which Pokémon Masters protagonist do you like most? Let us know by casting a vote in our Masters favorite protagonist poll here!
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

[Pokeemerald] Following Pokémon

Is there a way to control follower placement/spawning during scenes where there is forced movement on a map? I can get hidefollower to work during events or my own scripts, but when the map launches right into a script on warp/load, it seems like 'hidefollower' is triggering before the follower spawns in and won't work. You run into situations where the follower then runs to your player from off screen or really far away, etc.
 
retrogba said:
Is there a way to control follower placement/spawning during scenes where there is forced movement on a map? I can get hidefollower to work during events or my own scripts, but when the map launches right into a script on warp/load, it seems like 'hidefollower' is triggering before the follower spawns in and won't work. You run into situations where the follower then runs to your player from off screen or really far away, etc.
Click to expand...

I think so, yeah. ghoulslash's Follow Me code is currently designed so that the follower doesn't copy the player's movements when those movements are dictated by a script rather than player input. You can change that by going into src/event_object_movement.c, and then go into the function ObjectEventSetHeldMovement. Make this change:
Code: 
Original
...............
    objectEvent->heldMovementFinished = FALSE;
    gSprites[objectEvent->spriteId].sActionFuncId = 0;
    FollowMe(objectEvent, movementActionId, FALSE); ← ← ← ←
    return FALSE;
}

Change
.................
    objectEvent->heldMovementFinished = FALSE;
    gSprites[objectEvent->spriteId].sActionFuncId = 0;
    FollowMe(objectEvent, movementActionId, TRUE); ← ← ← ←
    return FALSE;
}
There may be new problems which I don't know about that will arise by making this change, so do so at your own risk. You could also instead make changes in src/follow_me.c, specifically in the FollowMe function:
Code: 
............
    else if (!gSaveBlock2Ptr->follower.inProgress)
        return;
    else if (ScriptContext2_IsEnabled() && !ignoreScriptActive)
        return; //Don't follow during a script
That second else-if is the single statement that determines whether the follower moves during scripted events. You could add extra conditions if you only want the follower to move in specific scripted events, but not all. I suppose you could also add these conditions in ObjectEventSetHeldMovement, but it's your call.

As far as I know, those would be the most efficient solutions to your problem without getting anymore detail.
 
Thanks for the response.

If it helps for some context: where I first noticed the weird behavior was on the Devon Corp's 3F; when you go there the first time, the NPC waiting for you begins to interact with you as soon as you enter (triggers "On Warp", I believe). The Follower hasn't even spawned yet, but once the script is finished, the follower will begin moving towards the player as they move around the room.

Do you have a recommended way to just flat-out prevent these types of followers from spawning at all in specific spaces? When I was working with Merrp's followers, I made it so followers didn't spawn indoors (instead of just large pokemon not spawning), and also created a toggle option in the menu for whether or not followers were visible in the overworld. Would something like that be workable with the FollowMe code or would it cause issues?
 
retrogba said:
Do you have a recommended way to just flat-out prevent these types of followers from spawning at all in specific spaces?
Click to expand...

One technique you could use would be to add your own exit conditions at the top of FollowMe in the file src/follow_me.c. For example, if you didn't want any followers to appear when the player is indoors, you could change that if-else chain to be this:
Code: 
    if (player != npc) //Only when the player moves
        return;
    else if (!gSaveBlock2Ptr->follower.inProgress)
        return;
    else if (ScriptContext2_IsEnabled() && !ignoreScriptActive)
        return; //Don't follow during a script
    else if (gMapHeader.mapType == MAP_TYPE_INDOORS) ← ← ← ←
        return; //Don't spawn follower indoors
With this added condition, the follower will never move while indoors, which in turn causes the follower to never appear indoors. Changing that statement to be whatever condition you want will allow you to disallow the spawning of a follower in any situation you want, assuming the follower hasn't already spawned at the time of that condition being met.


retrogba said:
.....a toggle option in the menu for whether or not followers were visible in the overworld.
Click to expand...

For this feature, you would need to add multiple checks to see whether or not that option has been turned on or not. This would require you to add a new exit statement to the top of FollowMe and making sure the follower just becomes invisible when UpdateFollowerPokemonGraphic is run, which can be found in src/overworld.c, rather than going throught its normal process. I think that would be all you would need, since I've made a lot of the follower interactions not happen as long as the follower is invisible. Of course, I could be forgetting some specific interaction, but I'll leave you the joy of finding those edge cases!
 
I added this to the main post, but I figured it would be worth mentioning in its own post.

For those of you using Porymap and the Pokémon Expansion, if you use some of the follower graphics as normal event objects, the sprite you see in Porymap will not be the same sprite you see in-game, since Porymap automatically assumes that POKEMON_EXPANSION is not defined when reading your project's repository to get the sprite data. You can fix this by going into include/constants/event_objects.h and deleting everything from
#ifndef POKEMON_EXPANSION to #else, including those two lines, as well as the #endif associated with it.
 
Last edited:
Is there a way to add this to firered? I tried going over every single change and adjusting it to firered, but I can't seem to make it work. It messes up all the object_events. Most of them are completly gone, some are still there but with wrong graphics and no longer interactable. I've been trying for a few days now, but I'm out of ideas what to do now.
 
Triplehelix said:
Is there a way to add this to firered? I tried going over every single change and adjusting it to firered, but I can't seem to make it work. It messes up all the object_events. Most of them are completly gone, some are still there but with wrong graphics and no longer interactable. I've been trying for a few days now, but I'm out of ideas what to do now.
Click to expand...

There may very well be a way of going about adding it to pokefirered, but I am not well-versed in how that decompilation is laid out. Based on the issue you're having, I would assume there's some issue with adding too many object events into the game, but that's just a wild guess. If you wanted to PM me with a link to your repository, I could take a look so as to better understand the situation, but I can't provide more help than that.
 
Huge Update:

1. Gen 4 Pokémon have been added!

2. Updated dynamic palette system in use for both repositories! No more messed up reflection.

3. All caught up with pret in both repositories.

4. Handful of bug fixes relating to followers and reloading saves, getting on a bike immediately after exiting a door, sand tracks/rushing water ripples, and running/biking while the follower is in the middle of shrinking or growing.


I had some real annoying issues merging pret's stuff, so don't be surprised if something has gone awry and I didn't catch it. As usual, feel free to point out bugs that need fixing. It'll be a hot minute till I get the gumption to start working on Gen 5 sprites after this, so hopefully I'll jump on any bugs that are pointed out pretty quickly.
 
AlmightyK said:
What would I need to change to make your followers the last mon in the party instead of the first?
Click to expand...

To do this, you would need to go to src/field_specials.c and edit the function GetLeadMonNotFaintedIndex to look like this:
Code: 
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.

AlmightyK said:
Also, two followers if possible XD
Click to expand...

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?
 
SSQuiLava333 said:
I'm also curious if there's any way to implement this in firered
Click to expand...
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.
SSQuiLava333 said:
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
Click to expand...
That's technically and easily possible, yes. Whether anyone's willing to do that would be a separate matter.
SSQuiLava333 said:
does it have to be activated in some way first
Click to expand...
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.
SSQuiLava333 said:
or is it just too different from base emerald to use as a patch?
Click to expand...
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) $< $@ -mwidth 4 -mheight 4

in: spritesheet_rules.mk

but the happiny shows up with messed up colors

torchic working properly:
[PokeCommunity.com] Following Pokémon


mons past chimecho aka happiny:
[PokeCommunity.com] Following Pokémon


sorry for the large images
 
Last edited:
PerceptioN95 said:
hello, would you happen to know why i get palette errors on the newer overworld sprites? ..........
Click to expand...

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.

vovovov said:
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.
Click to expand...

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.
 
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.

Triplehelix said:
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.
Click to expand...

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.h and 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.
 
You must log in or register to reply here.
Back
Top