A priest, a rabbi, and a DM developer walk into a bar and... nothing happens because the bar is defined inside of a BYOND game and the developer had no way to define an Entered proc to execute when mobs step into the bar.
If you were expecting a funny punchline you should have known better.
The problem is that the bar is represented by many turfs so defining the Entered proc to detect when a mob enters the bar wouldn't work, it'd catch every step taken while inside the bar. A single area could be used, but in the case of this joke, the developer was already using areas for something else.
This is a problem I've run into. Areas can be extremely useful but two useful features may both rely on the use of areas and are therefore incompatible.
The solution I've come up with is to define a type of object that is a child of /obj, so it can be placed on the map in the map editor and you can have multiple of these objects per turf. In the library I call this object /region. Every turf has a list of regions that it's a part of. The region's constructor adds itself to it's loc's region list. When you enter a turf, the library checks for regions that you're entering and exiting.
Only a single instance of the region object is kept. They're all stored in a global list and their loc is set to null, the way you don't have to worry about the region objects coming up in things like "for(var/obj/o in view())". Also, because only one instance is kept you don't have to worry about having tons of objects stored in memory. In terms of memory this isn't really any different from using areas. The only catch, and I haven't really played around with it, is that each region object has a constructor so if you have tons of region objects, you might notice some delays when your game is loading.
Hub entry: Forum_account.Region