fun bits

a.k.a. OpenWIG bugs worth mentioning, and their respective cartridges

Srnčí důl:
the official Players call "OnSet*" before performing the setting. I.e., when you set task.Complete = true, then the player first calls OnSetComplete and only after that actually sets the variable.
The OnSetComplete event in Srnčí důl (Roedeer deep), for some wicked reason, checks for this behavior: if task.Complete == false then (do stuff) So if at the moment of calling OnSetComplete, it's already Complete, there be failurez.

Blair Witch:
so I took the latest and greatest version and headed out, to try and play this cartridge, which is probably best one in CZ, and also the most complex one. So it was kind of baptism of fire for OpenWIG. Plus, this time, i was a member of a group equipped with Colorados, so i could check the behavior against the "right" one.
Found two bugs. In one, i could see all my virtual companions long after we left them behind in a dead zone. The other, at first i didn't think that it's a bug. I just completed a simple task ... then all the coloradists spent half hour trying to complete the very same task and failing spectacularly.
Both bugs were rather easy to find and remove.
First one: when a zone deactivates, it stops evaluating position events. That means that if you deactivate a zone in which you stand, as far as OpenWIG is concerned, you'll stand there till the end of days. Because it will never again check if you are inside or not. It just remembers the last state.
Fixed by forcefully removing a player from a deactivated zone.
Second: in the mentioned task, you have to carry an object outside of an invisible zone that envelopes the visible zone in which you start.
The respective event asks if invisibleZone:Contains(Player). Welll..... Yes, if the zones overlap, the player can be in more than one zone at once. That works fine. But when doing that, I apparently overlooked something: it doesn't go the other way around. Player is in multiple zones, but only one zone Contains() the player. So when i was in the inner visible zone, the event never found out that i was also in the invisible zone, and let me throw the task object away without hassle.
Fix was fairly trivial, i just needed to override zone's Contains method... ah, why would i write all this, you can figure it out.

...and for a time, it was good...

Petřínská Wherigovka:
This cartridge also has that habit of deactivating zones that you stand in. But it turns out that when fixing the problem from Blair Witch, i overlooked something again.
There are two internal states for a zone: contain says whether you are present in (close to, distant from) the zone, and ncontain aka "next contain" says whether you are going to be present in the zone in the next five seconds, unless something happens. So most of the time it's the same as contain.
When "forcefully removing" the player, i reset the value of contain, but not ncontain. In the next timestep, zone realized that the player is going to be inside it real soon, and invoked the OnEnter event.
Which had a rather lengthy dialog. Which ended in a question. Which, if answered correctly, would deactivate the zone. Which would lead to another OnEnter... you see where this is heading.
Also i found out that even when the zone is inactive, quite a lot is going on in it.
So i put a stop to it, and that's the end of this nasty little bug.

...or is it?