From 4b6ad121920b25a88b47ae59751004d926c99f46 Mon Sep 17 00:00:00 2001
From: NewSoupVi <57900059+NewSoupVi@users.noreply.github.com>
Date: Sat, 21 Sep 2024 18:51:30 +0200
Subject: [PATCH] Update world api.md

---
 docs/world api.md | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/docs/world api.md b/docs/world api.md
index 59dfdaef33..37e47ca7a9 100644
--- a/docs/world api.md	
+++ b/docs/world api.md	
@@ -745,9 +745,12 @@ and check whether they were **unlocked**.
 `get_newly_locked_enemies` should only consider enemies that are *already in the set*
 and check whether they **became locked**.
 
-There are a multitude of other ways you can optimise LogicMixin. Some games choose to have a `mygame_state_is_stale`
-variable that they simply set to True in collect/remove, and then only call the recalculating functions
-from any relevant access rules by checking `state.mygame_state_is_stale[player]` and setting it back to `False`.
+There are a multitude of other ways you can optimise LogicMixin. Some games use a `mygame_state_is_stale`
+variable that they simply set to True in collect/remove, and then call the recalculating functions
+from the actual relevant access rules only when state.mygame_state_is_stale[player] is True,
+after which they set it back to False.
+This can help quite significantly because it is possible for 0 local access rules to be called between two calls to
+`collect`, so recalculating on every `collect` is very slow.
 
 Only use LogicMixin if necessary. There are often other ways to achieve what it does, like making clever use of
 `state.prog_items`, or using event items, pseudo-regions etc.