Region

by Forum_account
Lets you specify regions of the map that trigger Entered and Exited events. [More]
To download this library for your Linux/Mac installation, enter this on your command line:

DreamDownload byond://Forum_account.Region##version=9

Emulator users, in the BYOND pager go to File | Open Location and enter this URL:

byond://Forum_account.Region##version=9

1658 downloads
Version 9
Date added: Apr 17 2011
Last updated: Mar 7 2012
11 fans
Areas can be used to create large parts of the map (spanning multiple turfs) that respond to Entered and Exited events. For example, you can place a certain type of area over a whole room and use the Entered event to make something happen when you step into the room.

The problem is, what happens if you have a room inside of that room that you need to define a similar Entered event for? Each turf can only be inside of one area, so if you use areas you'll exit the outer room when you enter the inner one. Sometimes this is ok, sometimes it's not.

This library solves the problem by creating an object type called /region. You can create sub-types of /region (ex: /region/my_region) and place them on the map. The object has Entered and Exited events that are called when a mob enters the region, but since they aren't areas a turf can be inside any number of regions.

Version 9 (posted 03-07-2012)
* Added roof-demo which shows how to hide regions of the map until the player enters the region.

Version 8 (posted 03-03-2012)
* Added #define FA_REGION to the .dme file. This can be used outside of this project to detect when the Region library has been included.
* Added the get() and get_list() procs for region objects. The global region.get and region.get_list procs simply call these procs for each region the source turf is in.
* Added the add, remove, added, and removed procs for the /region object. Each proc takes a turf as an argument. The add/remove procs add or remove a turf from the region. The added/removed procs are called when a turf is added or removed from a region.
* Added wire-demo which shows how to create a graphical effect associated with a region. It uses a region to manage which turfs have wires placed on them. It also uses the get_list() proc to find all doors that are connected to a button.
* Moved some code from region.dm into the new movement.dm.

Version 7 (posted 02-29-2012)
* Added the global variable called region which is an object containing the get() and get_list() procs. These procs split the turfs within a region into disjoint sets and search the source atom's set for instances of a specified object type. For example, you can place region objects on the map connecting a switch object to a door object. Then, at runtime, you can call region.get(switch, /obj/door) to get a reference to the door.
* Added button-demo which is an example of what I just described. It uses the region.get() proc to associate buttons with doors.
* Added partition.dm which contains the new features.
* Added _readme.dm which contains a description of the library and a version history.

Version 6
* Added support for the region's Entered() and Exited() procs when using pixel movement.

Version 5
* Added support for Enter() and Exit() procs on the region. You can now restrict movement by overriding these procs. When you try to Enter a region, the region's Enter proc will be called. If it returns false the move isn't allowed. The same is done with the Exit proc when leaving a region.
* The library used to use both turf/Entered and mob/Move to detect the Entered and Exited events for regions. The library now only uses mob/Move. This is beneficial because previously, you could break the library by overriding turf/Entered but not call ..().

Version 4
* To save memory, the turf's regions var is no longer initialized to be a list. If the turf is in any regions it will be set to a list, otherwise it'll be null.

Version 3
* Fixed a mistake - the region's Entered/Exited procs were being passed the turf, not the mob.

Version 2
* The /region object now has a list of turfs that it contains.
* Cleaned up the code a little and added some more comments to it.

Version 1
* Initial post, the library defines the /region

Comments

FIREking: (Jan 5 2012, 10:22 pm)
I couldn't get the map editor to let me select region1 for drawing. I used enabled all nodes and selected it from the tree, but no instance would show up in the object box on the map editor. I was able to right click an already drawn region atom on the map and select make this active object, and then draw with that.

Weird map editor bug?
Forum_account: (Oct 14 2011, 3:52 am)
D4RK3 54B3R wrote:
Rendering weather effects can be pretty challenging to do without area objects.
There's the obvious loop through every tile and set an overlay, but I imagine that'd be atrociously slow in most realistic applications.
[EDIT]: Yep, looping through everything and placing objects is atrociously slow.

Yeah, that's the only way you could do it with regions. Even if I didn't delete the region objects to keep just a single instance and left them on the map, you'd have to loop over all of them to set each of their icons individually.

The alternative is to use a dynamic lighting system that doesn't use areas =)
D4RK3 54B3R: (Oct 13 2011, 4:12 pm)
I have an environment lib that let users set up their own ambient sounds and simulated, to some extent, climates with user defined weather states and effects.

Unfortunately, that library relied on references to /area objects. I was hoping to use that library along with my lighting system, but my lighting system uses /area objects for the sake of multiplayer performance. (It worked well before I switched my lighting system from /image to /area)

My lighting system clones areas like no other and pretty much renders references to area objects worthless.
It at least preserves the area's attributes while cloning.

I used to use my own equivalent of your Region library as an alternative to area objects, but your implementation is cleaner and more convenient for the developer, so I switched over.

Rendering weather effects can be pretty challenging to do without area objects.
There's the obvious loop through every tile and set an overlay, but I imagine that'd be atrociously slow in most realistic applications.
[EDIT]: Yep, looping through everything and placing objects is atrociously slow.
Forum_account: (Oct 13 2011, 9:21 am)
D4RK3 54B3R wrote:
If you apply an icon to a region object, does it behave the same way an area does?

As in, the region object's icon will display on every tile the region contains.

No, only a single instance of the region object remains after the world has started up (and I'm pretty sure the one instance that's kept is moved off the map). The only reason they're atoms is so you can paint a region on the map in the map editor.

I've thought about how I'd make them have an appearance, but I never figured out a good way to make it work. They're intended to be static so that might make it easier.

Did you have a usage in mind that'd require them having a graphical representation?
D4RK3 54B3R: (Oct 13 2011, 9:07 am)
If you apply an icon to a region object, does it behave the same way an area does?

As in, the region object's icon will display on every tile the region contains.