Compare commits

...

20 Commits

Author SHA1 Message Date
NewSoupVi
b350521893 Update docs/apworld_dev_faq.md
Co-authored-by: qwint <qwint.42@gmail.com>
2024-09-05 22:21:51 +02:00
NewSoupVi
a2ba2f3dbf Update docs/apworld_dev_faq.md
Co-authored-by: qwint <qwint.42@gmail.com>
2024-09-05 21:30:30 +02:00
NewSoupVi
ce8d254912 Update apworld_dev_faq.md 2024-09-05 21:23:33 +02:00
NewSoupVi
153f454fb8 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-09-05 21:22:36 +02:00
NewSoupVi
df1f3dc730 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-09-05 21:21:24 +02:00
NewSoupVi
8cefe85630 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-09-05 21:20:51 +02:00
NewSoupVi
a1779c1924 Update apworld_dev_faq.md 2024-09-05 21:20:35 +02:00
NewSoupVi
663b5a28a5 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-09-05 21:20:10 +02:00
NewSoupVi
cf3d4ff837 Update apworld_dev_faq.md 2024-09-05 19:04:07 +02:00
NewSoupVi
1d8d04ea03 Update docs/apworld_dev_faq.md
Co-authored-by: qwint <qwint.42@gmail.com>
2024-09-05 18:56:33 +02:00
NewSoupVi
49394bebda Update docs/apworld_dev_faq.md
Co-authored-by: qwint <qwint.42@gmail.com>
2024-09-05 18:55:58 +02:00
NewSoupVi
9ec1f8de6e Update docs/apworld_dev_faq.md
Co-authored-by: Scipio Wright <scipiowright@gmail.com>
2024-08-13 18:19:21 +02:00
NewSoupVi
e74e472e3f Update docs/apworld_dev_faq.md
Co-authored-by: Scipio Wright <scipiowright@gmail.com>
2024-08-13 18:18:55 +02:00
NewSoupVi
850033b311 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-07-31 22:34:10 +02:00
NewSoupVi
3a70bf9f4f Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-07-31 22:33:57 +02:00
NewSoupVi
205fa71cc7 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-07-31 22:33:50 +02:00
NewSoupVi
8420c72ec4 Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-07-31 22:33:44 +02:00
NewSoupVi
f9b07a5b9a Update docs/apworld_dev_faq.md
Co-authored-by: Exempt-Medic <60412657+Exempt-Medic@users.noreply.github.com>
2024-07-31 22:33:36 +02:00
NewSoupVi
295e719ef3 Actually copy in the text 2024-07-31 19:34:37 +02:00
NewSoupVi
db5be6a411 Docs: Dev FAQ - About indirect conditions
I wrote up a big effortpost about indirect conditions for nex on the [DS3 3.0 PR](https://github.com/ArchipelagoMW/Archipelago/pull/3128#discussion_r1693843193).

The version I'm [PRing to the world API document](https://github.com/ArchipelagoMW/Archipelago/pull/3552) is very brief and unnuanced, because I'd rather people use too many indirect conditions than too few.
But that might leave some devs wanting to know more.

I think that comment on nex's DS3 PR is probably the best detailed explanation for indirect conditions that exists currently.

So I think it's good if it exists somewhere. And the FAQ doc seems like the best place right now, because I don't want to write an entirely new doc at the moment.
2024-07-27 08:18:00 +02:00

View File

@@ -43,3 +43,26 @@ A faster alternative to the `for` loop would be to use a [list comprehension](ht
```py
item_pool += [self.create_filler() for _ in range(total_locations - len(item_pool))]
```
---
### I learned about indirect conditions in the world API document, but I want to know more. What are they and why are they necessary?
The world API document mentions indirect conditions and **when** you should use them, but not *how* they work and *why* they are necessary. This is because the explanation is quite complicated.
Region sweep (the algorithm that determines which regions are reachable) is a Breadth-First Search of the region graph from the origin region, checking entrances one by one and adding newly reached nodes (regions) and their entrances to the queue until there is nothing more to check.
For performance reasons, AP only checks every entrance once. However, if an entrance's access condition depends on regions, then it is possible for this to happen:
1. An entrance that depends on a region is checked and determined to be nontraversable because the region hasn't been reached yet during the graph search.
2. After that, the region is reached by the graph search.
The entrance *would* now be determined to be traversable if it were rechecked, but it is not.
To account for this case, AP would have to recheck all entrances every time a new region is reached until no new regions are reached.
However, there is a way to **manually** define that a *specific* entrance needs to be rechecked during region sweep if a *specific* region is reached during it. This is what an indirect condition is.
This keeps almost all of the performance upsides. Even a game making heavy use of indirect conditions (See: The Witness) is still significantly faster than if it just blanket "rechecked all entrances until nothing new is found".
The reason entrance access rules using `location.can_reach` and `entrance.can_reach` are also affected is simple: They call `region.can_reach` on their respective parent/source region.
We recognize it can feel like a trap since it will not alert you when you are missing an indirect condition, and that some games have very complex access rules.
As of [PR #3682 (Core: Region handling customization)](https://github.com/ArchipelagoMW/Archipelago/pull/3682) being merged, it is also possible for a world to opt out of indirect conditions entirely, although it does come at a flat performance cost.
It should only be used by games that *really* need it. For most games, it should be reasonable to know all entrance &rarr; region dependencies, and in this case, indirect conditions are still preferred because they are faster.