encukou/test-1 — Issue #7: Add location encounter data
Author: encukou
Created: 2011-11-03 18:33:59+00:00
State: open
Labels: assigned-to Eevee, feature, urgent

**Reported by [Eevee](http://bugs.veekun.com/users/1) on 2009/04/24 22:07:24 +0000 · Migrated from [Redmine issue 6](http://bugs.veekun.com/issues/6)**

---

I’m still mucking about with the details, but so far the schema looks something like this.

A **location** is a place in the game world that has a name. Route 212, Pastoria City, Lake Verity, and so forth are all locations. These are stored in the `locations` table, and have a generation id so as to distinguish between RBY’s Route 1 and GSC’s Route 1.
An **area** is a chunk of a location, distinguished by having a different set of Pokémon encounters. Some Routes are L-shaped and consist of one area for each branch. Most dungeons have a different area per floor. The lakes and a couple other places have one area before a condition but switch to being another area afterwards. Pretty much everything else consists of only one area. These are stored in `location_areas`.

An **encounter type** is a way of encountering a wild Pokémon: walking around, surfing, or fishing. These are stored in `encounter_types`.
An **encounter slot** is one space in the list of Pokémon that can appear somewhere using a given encounter type. It has an associated rarity. For example, when surfing, there are five slots: 60%, 30%, 5%, 4%, 1%. These are stored in `encounter_type_slots` and belong to a single encounter type.
An **encounter condition** is some state the *world* can be in that affects what Pokémon appear. This includes swarms, time of day, whether the PokéRadar is being used, and the dual slot feature in D/P. These appear in the form “during a swarm”, “in the morning”, etc.

There are two possible ways to join slots to conditions.

1. Put conditions in `encounter_type_conditions`. Join them to slots via `encounter_type_slot_conditions`. This would connect each slot (and thus rarity) with the types of conditions that can affect it, and requires that the “name” of the group of conditions is in the slot table. This is what I have now, but it kinda sucks.

1. Put conditions in `encounter_conditions`. Group them ~~- e.g. “dual slot”~~- in `encounter_condition_groups`. Give each slot a nullable `encounter_condition_group_id`. This is far more logical, and I think I’m going to switch to doing this.

Make sure this is documented, either way. It’s bloody convoluted.

Redmine metadata:
Updated on: 2009/08/12 20:07:38 +0000
Start date: 2009/04/24
Done ratio: 100%
Relations:
blocks #7

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2009/05/01 20:39:47 +0000**

Added in 27d9bff9. I did indeed go with the latter option, and it seems to be working out sanely.

Done: 0% ⇨ 100%

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2009/05/01 20:42:08 +0000**

Status: OPEN ⇨ FIXED
Assignee ⇨ Eevee

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2009/05/17 02:28:35 +0000**

I believe the data consolidation and documentation just about wrap this up!

I am retarded and put the wrong issue number in a bunch of commits, so they were:

1f1496e7 - Improved some location and area names.
f97e3dc5 - Consolidated Solaceon Ruins and Old Chateau areas.
cff12e98 - Documented crazy encounter schema.

---

**Comment by [Eevee](http://bugs.veekun.com/users/1) from 2009/08/12 20:07:37 +0000**

: fixed
Difficulty: Normal