Difference between revisions of "Entity Handle Misinterpretation"
(Created page with "{{P2 Title|Entity Handle Misinterpretation}} ==Overview== '''Entity Handle Misinterpretation''' (EHM for short) is an oversight in game's code that can rarely cause an entity...") |
m (→Technical Explanation: Typo fix) |
||
| Line 7: | Line 7: | ||
The game stores entities in '''slots'''. Each slot has a '''serial number''' in a range between 0 and 0x7FFF (32767 in decimal) assigned when you launch the game - these values are random, but they're always the same between different game launches. That serial number is used to create '''entity handles''', which is how the game internally stores references to entities. When an entity is removed from the world, the value of its slot is increased by one (and looped over to 0 if it goes outside of its range), so that the game can know if it's trying to reference an entity that no longer exists. | The game stores entities in '''slots'''. Each slot has a '''serial number''' in a range between 0 and 0x7FFF (32767 in decimal) assigned when you launch the game - these values are random, but they're always the same between different game launches. That serial number is used to create '''entity handles''', which is how the game internally stores references to entities. When an entity is removed from the world, the value of its slot is increased by one (and looped over to 0 if it goes outside of its range), so that the game can know if it's trying to reference an entity that no longer exists. | ||
| − | Because of the mistake in the code, the collision trace algorithm incorrectly interprets certain entity handles. What ends up happening is the entity handle is treated as a static prop if its serial number is equal to '''0x4000''' (16384 in decimal). If that happens, and the slot number of that entity is less than the number of static objects in the map, it leads to the entity being treated as non- | + | Because of the mistake in the code, the collision trace algorithm incorrectly interprets certain entity handles. What ends up happening is the entity handle is treated as a static prop if its serial number is equal to '''0x4000''' (16384 in decimal). If that happens, and the slot number of that entity is less than the number of static objects in the map, it leads to the entity being treated as non-s0lid for player movement and portal shots. |
In order for a slot's serial number to reach 0x4000, the entity occupying the slot has to be removed the amount of times the difference of the original slot's serial number to 0x4000 is equal to (that involves looping over if initial slot's serial number is above 0x4000). This can be achieved in several ways: | In order for a slot's serial number to reach 0x4000, the entity occupying the slot has to be removed the amount of times the difference of the original slot's serial number to 0x4000 is equal to (that involves looping over if initial slot's serial number is above 0x4000). This can be achieved in several ways: | ||
Revision as of 02:55, 20 July 2022
Contents
Overview
Entity Handle Misinterpretation (EHM for short) is an oversight in game's code that can rarely cause an entity to become non-tangible for players and collision traces, allowing you to walk or shoot through it.
Technical Explanation
The game stores entities in slots. Each slot has a serial number in a range between 0 and 0x7FFF (32767 in decimal) assigned when you launch the game - these values are random, but they're always the same between different game launches. That serial number is used to create entity handles, which is how the game internally stores references to entities. When an entity is removed from the world, the value of its slot is increased by one (and looped over to 0 if it goes outside of its range), so that the game can know if it's trying to reference an entity that no longer exists.
Because of the mistake in the code, the collision trace algorithm incorrectly interprets certain entity handles. What ends up happening is the entity handle is treated as a static prop if its serial number is equal to 0x4000 (16384 in decimal). If that happens, and the slot number of that entity is less than the number of static objects in the map, it leads to the entity being treated as non-s0lid for player movement and portal shots.
In order for a slot's serial number to reach 0x4000, the entity occupying the slot has to be removed the amount of times the difference of the original slot's serial number to 0x4000 is equal to (that involves looping over if initial slot's serial number is above 0x4000). This can be achieved in several ways:
- Reload the level/save. In this case, all entities will be removed and added again, occasionally even twice.
- Use entities that spawn/destroy objects (for instance, cube spawners or tractor beams being enabled and disabled).
Appearance In The Game
An example of EHM happening to Burger40 in Wakeup during his fullgame run.
Entities created when loading a map or a specific save will always occupy the same slot, although the arrangement may differ between loading a map and loading a save in that map (and may also differ between different saves).
There are several known EHM instances that runners claim to encounter. Here are some of them:
- Aperture door in Wakeup (occupying slot 38, with initial serial number 16284, 100 away from 0x4000)
- PotatOS grate floor (occupying slot 301, with initial serial number 14400, 1984 away from 0x4000)
- Bridge Gels grate floor (occupying slot 74, with initial serial number 15557, 827 away from 0x4000)
Usage in fullgame Least Portals
Since this glitch allows you to literally walk or shoot through solid entities, this is a huge tech for Least Portals challenge. It is theorized that, using specific PeTI-created levels, we can manipulate specific slots to cause certain objects to become intangible. This would allow us to complete many maps in less portals than normally, lowering the total count drastically.