 |
In the test map, the location_separator is spawned first, and correctly marks the portal as "BLOCKING", which means it's the boundary of a location. The func_portal is then spawned, and it marks the portal as "NON-BLOCKING", undoing the "BLOCKING" that had been set earlier. This erases the boundary condition. Fix forthcoming. |
|
|
When a func_portal is spawned after an info_locationseparator, and they’re both on the same portal, the func_portal undoes the location boundary marker on the portal. The ‘state’ on a portal is set up as a collection of bits that indicate whether the portal blocks the view, sound, etc. However, the routines that manipulate these bits don’t do so at the bit level, using bitwise operators. They simply write a complete ‘state’ to the portal, with no consideration for the bits they’re not interested in. Luckily, the boundary bit is used at the start of the mission to establish the extent of locations, and after that’s done, it doesn’t matter if an opening door clears the portal state, wiping out the boundary bit. Func_portals, however, can wipe out the boundary bit at spawn time, destroying the location zones. The solution is to have everyone who plays with these bits use bitwise operators, but for now, I’m restricting the solution to only having the func_portal do so. Changing all programs to use bitwise operations would require extensive testing, and since the boundary bit isn’t used after mission start, we’re probably not improving anything. Rev. 5751: Misc.cpp |
- Anonymous
