Missing Encounters and Location_Areas in Gen 6: Friend Safari in XY and Mirage Spots in ORAS.

Both of these locations contain a ton of Pokemon. And while they're modeled in locations.csv they're not in location_areas.csv, location_area_encounter_rates.csv, encounter_slots.csv, or anything else related to encounters.

Mirage spots are fairly straight forward, add them to location areas and add their encounters to the relevant csvs.

Friend Safari needs a bit more thought. The way it works is each type for a Pokemon (like poison, fire, etc) can have a "safari" and you get 1 safari per person on your 3ds friend list. And their friend code gives a specific type of safari.

After that in the safari the zone is populated by 3 pokemon of that type.

I would suggest we make a location-area for each of the types based on the 680,6,friend-safari. So it would be appended as friend-safari-fire, for example.

In location_areas it would look like:

1204,680,0,fire.

Encounter method is just walking.

I'd be willing to model these myself of course, but it's a bit of a backlog for me now. Once the current location PRs are done for Hordes and Events, I'll be doing one for Colo and XD locations first.

I'm interested in taking a look at this, if that's okay with you.

I was hoping you would, given your work on horde encounters! It'll take me a while to go thru CXD location areas, I plan on doing all locations for orre in 1 PR.

Do you plan on doing one or both of these things? Either is totally fine with me btw.

I can take a look at both Mirage Spots and Friend Safari.

@ItsMeJoji

Sounds good to me @ItsMeJoji !

Try to keep the first PR small so to be able to review it easily. Thanks for the cooperation!

@Naramsim

@Naramsim I'll be creating a PR for each Mirage location, as to not to bombard with a single huge PR.

Wanted to get some insight on how we should handle the Friend Safari encounters.

The issue I'm seeing is that each Safari will have 3 encounters slots, each at 33.3% Encounter Rate, but each of the 3 slots can be 1 of 4 Pokemon.

So for example, the normal-type-safari will have slot-1 at 33.3 encounter rate, but that spot can have either teddiursa, aipom, dunsparce, or lillipup.

Have y'all had this sort of issue in the past that we can take inspiration from?

https://bulbapedia.bulbagarden.net/wiki/Friend_Safari

I'm thinking a solid approach to this would take some notes from the sos-encounter encounter method. We could create an encounter method (e.g. friend-safari) and then just list all Pokemon that can be in slot 1 in slot 1. This would mean that if you count up all the chances it would be over 100%, but that's just because this new encounter method needs to be handled differently from a normal encounter (like the sos-encounter).

We could have encounter conditions attached to them to mark them as mutually exclusive? Something like slot 1 - group A, where group A contains teddi/aipom/dun/lili.

If I recall correctly each slot has a random pool of Pokemon to pull from, so I would think it may get confusing to have to look for Pokemon in slot 1 group A but slot 2 group C and so on.

Edit: https://www.serebii.net/xy/friendsafari.shtml

I'm thinking a solid approach to this would take some notes from the sos-encounter encounter method. We could create an encounter method (e.g. friend-safari) and then just list all Pokemon that can be in slot 1 in slot 1. This would mean that if you count up all the chances it would be over 100%, but that's just because this new encounter method needs to be handled differently from a normal encounter (like the sos-encounter).

Maybe we can have friend-safari-slot-1, friend-safari-slot-2, friend-safari-slot-3 as encounter methods to designate them to a exclusive group.

For example:

location_area
1321,680,0,normal-type-safari


location_area_prose
1321,9,Normal-type Safari

encounter_method
54,friend-safari-slot-1,54
55,friend-safari-slot-2,55
56,friend-safari-slot-3,56

encounter_slots
1391,15,54,1,33
1392,15,55,2,33
1393,15,56,3,33

encounters
71344,23,1321,1391,216,30,30
71345,23,1321,1391,190,30,30
71346,23,1321,1391,206,30,30
71347,23,1321,1391,506,30,30
71348,23,1321,1392,294,30,30
71349,23,1321,1392,352,30,30
71350,23,1321,1392,531,30,30
71351,23,1321,1392,572,30,30
71352,23,1321,1393,113,30,30
71353,23,1321,1393,132,30,30
71354,23,1321,1393,133,30,30
71355,23,1321,1393,235,30,30
71356,24,1321,1391,216,30,30
71357,24,1321,1391,190,30,30
71358,24,1321,1391,206,30,30
71359,24,1321,1391,506,30,30
71360,24,1321,1392,294,30,30
71361,24,1321,1392,352,30,30
71362,24,1321,1392,531,30,30
71363,24,1321,1392,572,30,30
71364,24,1321,1393,113,30,30
71365,24,1321,1393,132,30,30
71366,24,1321,1393,133,30,30
71367,24,1321,1393,235,30,30

As a side note, why are we using the integer value as the encounter rate for SOS-called Pokemon? Take Ultra Moon Route 1 Pichu for example. It can call Pichu, Pikachu and Happiny at the highest call rate of 15 (on the 0 - 15 scale) Serebii breaks it down to an actual percentage (https://www.serebii.net/pokearth/alola/route1.shtml), but not sure how they came to these percentages, and Bulbapedia doesn't show them (https://bulbapedia.bulbagarden.net/wiki/Alola_Route_1#Route_1_proper_4).

So if I understand properly, this would mean adding teddiursa, aipom, dunsparce, and lillipup all to friend-safari-slot-1, each in an encounter slot with a 25% chance? I feel like that would move away from what the chance is supposed to represent, which is the chance it appears, not the chance that it will be in the spawn pool to begin with.

@notblisy

So if I understand properly, this would mean adding teddiursa, aipom, dunsparce, and lillipup all to friend-safari-slot-1, each in an encounter slot with a 25% chance?

The 25% is just the chance of it being assigned the Friend Safari Slot when a Friend Safari is generated for a 3DS friend. That Pokemon will then be set at 33.3% Encounter Rate when entering the Friend Safari.

I think I see why @notblisy suggest adding encounter_condition to these. Each slot group Pokemon is set randomly at 25% chance when registering friends.

Something like this:

Yeah the reason I think conditions work well is because it allows all 4 pokemon to maintain encounter slot 1 while being noted as mutually exclusive from eachother.

You know that you can only have one per group. So in the prose for conditions we would have a new condition called “group” or “friend safari group”

And then you’d make four conditions. For each group.

So it’d be “friend safari group a”.

The prose would say something like:

All Pokémon in a friend safari group have a 25% chance to take up the encounter slot.

Yeah the reason I think conditions work well is because it allows all 4 pokemon to maintain encounter slot 1 while being noted as mutually exclusive from eachother.

You know that you can only have one per group. So in the prose for conditions we would have a new condition called “group” or “friend safari group”

And then you’d make four conditions. For each group.

So it’d be “friend safari group a”.

The prose would say something like:

All Pokémon in a friend safari group have a 25% chance to take up the encounter slot.

Something to the effect of:

encounter_conditions
17,friend-safari-slot-1
18,friend-safari-slot-2
19,friend-safari-slot-3

encounter_conditions_prose
17,9,Friend Safari Slot 1 assignment at a 25% chance
18,9,Friend Safari Slot 2 assignment at a 25% chance
19,9,Friend Safari Slot 3 assignment at a 25% chance

encounter_condition_value
169,17,friend-safari-slot-1,1
170,18,friend-safari-slot-2,1
171,19,friend-safari-slot-3,1


encounter_condition_values_prose
169,9,Randomly assigned to Friend Safari Slot 1 at a 25% chance
170,9,Randomly assigned to Friend Safari Slot 2 at a 25% chance
171,9,Randomly assigned to Friend Safari Slot 3 at a 25% chance

encounter_condition_value_map
71344,169
71345,169
71346,169
71347,169
71348,170
71349,170
71350,170
71351,170
71352,171
71353,171
71354,171
71355,171
71356,169
71357,169
71358,169
71359,169
71360,170
71361,170
71362,170
71363,170
71364,171
71365,171
71366,171
71367,171

I've never added encounter conditions to the API, so forgive me if I connected anything incorrectly in my example.

I think the only thing you have wrong is encounter conditions would only need one thing.

It'd be:
encounter_conditions.csv:
friend-safari

encounter_condition_values.csv:

friend-safari-slot-1,1
friend-safari-slot-2,1
friend-safari-slot-3,1

The way conditions work is you can append basically anything after them. The text there is only descriptive and doesn't link to anything other than the encounter in encounter.csv. Otherwise you have it.

My recent gamecorner PR should be a good reference: #1467

I think this approach should work well

I think we can consider this issue closed now with all of the Mirage Spots and Friend Safari encounters in the API.

Navigation Menu

Repository navigation

Missing Encounters and Location_Areas in Gen 6: Friend Safari in XY and Mirage Spots in ORAS. #1420

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Missing Encounters and Location_Areas in Gen 6: Friend Safari in XY and Mirage Spots in ORAS. #1420

Description

Activity

ItsMeJoji commented on Feb 23, 2026

notblisy commented on Feb 23, 2026

ItsMeJoji commented on Feb 23, 2026

notblisy commented on Feb 24, 2026

Naramsim commented on Feb 24, 2026

ItsMeJoji commented on Mar 4, 2026

ItsMeJoji commented on Apr 9, 2026

jemarq04 commented on Apr 9, 2026

notblisy commented on Apr 9, 2026

jemarq04 commented on Apr 9, 2026

ItsMeJoji commented on Apr 9, 2026

jemarq04 commented on Apr 9, 2026

ItsMeJoji commented on Apr 9, 2026

ItsMeJoji commented on Apr 9, 2026

notblisy commented on Apr 9, 2026

ItsMeJoji commented on Apr 9, 2026

notblisy commented on Apr 9, 2026

jemarq04 commented on Apr 9, 2026

ItsMeJoji commented on Apr 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions