Comment 14 for bug 1226558

The thing about area 0 seems to be we don't seem to actually explicitly
create it! Also the code to move rooms to an area does not seem to
update the old area to take the room FROM it - we get away with this at
mostly at the moment because I guess the typical usage is to create a
room and then put it into the desired area and relatively rarely does
rooms get moved to a new area.

I'd suggest ensuring that an area 0 is created with new maps, and that
during map auditing of existing ones, we add area 0 and all rooms with
area = 0 to that area, also I'd be minded to check that each room only
appears in the "rooms" of one area. If we increment the map version at
this point the user will only be hit by these extra checks once per map
file.

In general adding a room should auto-magically place it in area 0. Also
TArea.cpp need a removeRoom method which will be used both on room
deletion and movement to a different area. Of course calls that add or
delete rooms from an area should also cause an update to the min/maxs
and the ebenes (levels?) for that area - which I am not sure is
happening universally at the present.

Right, I'm going to brew a fresh cup of coffee and take a look at trying
to coding this unless someone else has a solution already worked out...

On 27/09/13 16:50, Chris wrote:
> So I think the best solution is to nix the use of area 0, have -1 be a
> void area, and enumeration begin at 1. This doesn't appear to break any
> scripts, as using area 0 actually causes scripts to break. If perusing
> the code supports this, I'll put in this fix.
>