Update 2024-02-29-creating-the-perfect-modding-language.md

_posts/2024-02-29-creating-the-perfect-modding-language.md

@@ -166,9 +166,9 @@ There is a big difference between the options of giving every entity a map, and
 - With a map, entity A can put something in the map of entity B, even when entity B doesn't ever look at that thing.
 - With messages, entity B can choose to ignore a message.
 
-The map approach can be more suitable when there is a `blade` entity that needs to apply a lasting "poison" effect on a `human` entity, assuming the poison effect is something the mod came up with. If a human doesn't want to be poisoned, it could put `unpoisonable` in its own map, which the `blade` could check for. If the message approach were to instead be taken, then every human would need to be modified, to handle a potential `poisoned` message.
+The map approach can be more suitable when there is a `blade` entity that needs to apply a lasting "poison" effect on a `human` entity, assuming the poison effect is something the mod came up with. If a `human` doesn't want to be poisoned, it could put `unpoisonable` in its own map, which the `blade` could check for. If the message approach were to instead be taken, then every `human` would need to be modified, to handle a potential `poisoned` message.
 
-The message approach on the other hand is stateless, in the sense that it just processes/ignores a message and moves on, which can be nice. If the game developer allows mods to allocate their own data structures, then the message approach might make the most sense.
+The message approach on the other hand is stateless, in the sense that it just processes/ignores a message and moves on, which can be nice. If the game developer allows mods to allocate their own data structures, then the message approach might make the most sense. A `blade` could for example just maintain a dynamic array of `human` IDs that it has poisoned, though it would mean that other `blade` entities can't tell whether the `human` has been poisoned by someone else.
 
 ## Documentation, security, and type checking in one