Currently, zscript can reference sectors in a level through it's level.sectors array. the problem is, if a wad has given two sectors the same index, there is no way to tell them apart. two sectors from opposite sides of the map can be regarded as the same sector and this can mess with code that needs to analyse their geometry.
it would be great if these islands could be listed as subsectors within the sector, or even separated in zscript.
The ability to differentiate sectors with the same id
Moderator: GZDoom Developers
Re: The ability to differentiate sectors with the same id
It'll be interesting to see how this one pans out because I'm not sure what you are asking about is accurate. (I assume that you are also Captaindando on GitHub as there is a very similar suggestion there).
The reason I said I'm not sure about the accuracy of what you are asking about is because you refer to "two sectors that have been given the same index". The thing is, by my understanding at least, that once they have been "given the same index" they are no longer two sectors; they are the same sector. There are not two separate sets of data for the two areas. There is one sector definition and it is referenced by all the lines facing the various bits of it. So, there is only one sector, not two (or more) when a sector is split like this. If there was data for a second sector, it should have been cleaned out at node-build time.
I once (a very long time ago) saw a sector being described as "infinitely wide." (Or, more realistically, as wide as the limits of the map size.) Once you create one, it is effectively everywhere at editing time (and the size of the blockmap when the map is completed and being played). We just use lines to chop it up into accessible playable areas and contain it. That's why when you noclip around a map, you can find yourself going up and down in height in the void as the game decides which sector you are currently in.
Of course, with modern map editors, the process of creating a sector is invisible. We just draw lines and once the shape is closed "voila" we also have a sector. That wasn’t the case with the oldest editors where the various elements had to be created separately. You can also come across some old maps where the node builder used perhaps wasn't as good at cleaning things up and sectors that are not referenced by any lines may exist. They can't really be seen or visited in the usual way, but they exist in the map data. Some source ports might give you a message at the console such as "Sector X has no lines." So, while it might be convenient to think about a sector being defined by its lines, that isn't necessarily the case. A sector has floor height, ceiling height and brightness (plus associated properties) but where the sector visibly extends to as far as gameplay is concerned is bound by lines that have sidedefs that border and reference the sector - and they can be anywhere on the entire area of the map because the sector effectively extends that far.
However, I am by no means an expert on this and I suspect there are some inaccuracies in what I just said. So if someone with better knowledge wants to chip in, that would be most welcome.
Speaking of old maps, one reason why you come across so many split sectors is an effort to reduce disk space. Many sectors are split these days for special effects purposes or because of the mapper's preference, but sometimes it was done to save disk space at a time when that was still at a premium. There were some command line tools that could analyse a map in a WAD, find all the identical sectors and merge them into one, changing sidedef references as it went, and some map editors had a similar function built in. (A similar thing could be done to merge identical sidedefs too.) Doing this reduced the size of the WAD file on disk because it contained fewer sector definitions. Of course, it could also come with down sides: if one part of the split sector moved (door, platform, whatever) they all did. Most tools would therefore try to avoid splitting sectors referenced by door lines or with sector tags. Also, sound propagation across the map could be messed up because if you make a sound in a sector, and it has a section on the other side of the map, the enemies there will wake up and start hunting the player. If you are working with maps that were "compressed" in this way, you may find many, many split sectors.
It sounds like you are mostly interested in looking at existing maps, rather than editing, but I have a script for UDB (kindly provided by Boris) that searches the map that you are editing and lists any merged sectors. It's quite simple. I don't know if it will help or not, but here it is:
The reason I said I'm not sure about the accuracy of what you are asking about is because you refer to "two sectors that have been given the same index". The thing is, by my understanding at least, that once they have been "given the same index" they are no longer two sectors; they are the same sector. There are not two separate sets of data for the two areas. There is one sector definition and it is referenced by all the lines facing the various bits of it. So, there is only one sector, not two (or more) when a sector is split like this. If there was data for a second sector, it should have been cleaned out at node-build time.
I once (a very long time ago) saw a sector being described as "infinitely wide." (Or, more realistically, as wide as the limits of the map size.) Once you create one, it is effectively everywhere at editing time (and the size of the blockmap when the map is completed and being played). We just use lines to chop it up into accessible playable areas and contain it. That's why when you noclip around a map, you can find yourself going up and down in height in the void as the game decides which sector you are currently in.
Of course, with modern map editors, the process of creating a sector is invisible. We just draw lines and once the shape is closed "voila" we also have a sector. That wasn’t the case with the oldest editors where the various elements had to be created separately. You can also come across some old maps where the node builder used perhaps wasn't as good at cleaning things up and sectors that are not referenced by any lines may exist. They can't really be seen or visited in the usual way, but they exist in the map data. Some source ports might give you a message at the console such as "Sector X has no lines." So, while it might be convenient to think about a sector being defined by its lines, that isn't necessarily the case. A sector has floor height, ceiling height and brightness (plus associated properties) but where the sector visibly extends to as far as gameplay is concerned is bound by lines that have sidedefs that border and reference the sector - and they can be anywhere on the entire area of the map because the sector effectively extends that far.
However, I am by no means an expert on this and I suspect there are some inaccuracies in what I just said. So if someone with better knowledge wants to chip in, that would be most welcome.
Speaking of old maps, one reason why you come across so many split sectors is an effort to reduce disk space. Many sectors are split these days for special effects purposes or because of the mapper's preference, but sometimes it was done to save disk space at a time when that was still at a premium. There were some command line tools that could analyse a map in a WAD, find all the identical sectors and merge them into one, changing sidedef references as it went, and some map editors had a similar function built in. (A similar thing could be done to merge identical sidedefs too.) Doing this reduced the size of the WAD file on disk because it contained fewer sector definitions. Of course, it could also come with down sides: if one part of the split sector moved (door, platform, whatever) they all did. Most tools would therefore try to avoid splitting sectors referenced by door lines or with sector tags. Also, sound propagation across the map could be messed up because if you make a sound in a sector, and it has a section on the other side of the map, the enemies there will wake up and start hunting the player. If you are working with maps that were "compressed" in this way, you may find many, many split sectors.
It sounds like you are mostly interested in looking at existing maps, rather than editing, but I have a script for UDB (kindly provided by Boris) that searches the map that you are editing and lists any merged sectors. It's quite simple. I don't know if it will help or not, but here it is:
Spoiler:FWiW, Doom already has the concept of subsectors (shortened to SSECTORS in the map data), but it's different to what you were asking about: https://doomwiki.org/wiki/Subsector
Re: The ability to differentiate sectors with the same id
If subsectors could be triangulated, it might work, though I think it will affect performance for everyone