Helion - C# (0.9.2.6 1/1/23 - Goodbye BSP tree rendering)

11 minutes ago, Gregor said:

i changed the directory on the command line to helion's dir. but it now it complains that can't load the iwad even though it is right there in its root directory. 

I just tested with doom2.wad and another wad file both in Helion's directory. All I did for the command was 'Helion.exe -file somefile.wad' and it worked. I'm guessing you don't use a launcher like Doom Launcher or ZDL.

Wait. I have to put BOTH the iwad and pwad in the root directory??

Where's the fun in that?

EDIT: Seriously though, that worked. I only load wads through batch files and command prompt. Never saw the benefit of a launcher.

On 11/24/2022 at 8:29 AM, RastaManGames said:

This is small test that I've made on the wave of hype about that big & dense "CrazyMaze.WAD".
In "GZDoom" 4.9.0 I had only ~5 FPS and not sure how many I had on "Helion C# 0.9.1.0" ('cause just writing vid_fps 1 does nothing here & am not sure if I can attach "ReShade" to it at all), but entire feeling of framerate was very smooth & comfortable!

Only sad thing that entire auto-map is revealed at the start, but it can be fixed soon!

 

oh my god. The map hasn't even been out for half a month and it's already being use to torture test Doom source ports, Damn.

I know I said I'd come back a few days later, and I know I'm a bit late, but... depending on how technical you'd want to get with vanilla compatibilty, might I suggest aiming to implement mikoportals? One of the best recent examples I have used is esselfortium's Knee Deep in Knee Deep in ZDoom. I'd imagine if it could support this, it could support pretty much anything.

Something a little less extensive (and admittedly a bit self advertising) is my own wad, Emblem. It's a WAD for Ultimate Doom, and it does feature some new enemies. Although the new enemies DO seem to work, there are some weird oddities. For starters, the undead scientists don't seem to play their noises at all when they should. I've tested this extensively in other ports and it works as intended except for this one. I'd imagine it'd have to do with the differences between executables and how you're internally applying the dehacked patch. Another thing I noticed in both my own wad AND the original is that Pinkies don't seem to play their noises on time. Usually, on the first frame of the demon's attack, it'll play the demon biting sound, but here it seems to only play a few seconds after the LAST frame.

I'd also like to point out that, back to my own WAD, the afrits do NOT actually have their hitboxes matching up to where they actually are. It seems as though, although they can fly, it doesnt seem like the autoaim is picking up on that, which looks pretty odd. I can get a screen capture of this, not sure how fixable it would be.

On 11/25/2022 at 11:48 AM, hobomaster22 said:

I really hate how windows handles this. With how common laptops with two GPUs are now one would think they would handle it better. I have not found a good way to force it. For me the only way Windows will ever fully use my RTX 3070 is if I'm plugged into my external gaming monitor. If not it always puts it on my integrated Radeon GPU...

You can try this but I have never had any luck with it (I think it requires a restart to take effect... if it feels like it)

Thanks for this. This is exactly what I did as per my previous post, and as outlined there, the FPS only increased a little with using the dedicated GPU.

What's really odd is that my 1060 reached only a maximum of 7% utilized while I was in-game (if Task Manager is accurate), along with about 30% for the CPU. Something is bottlenecking the port, but I have no idea what.

2 hours ago, Bauul said:

 

Thanks for this. This is exactly what I did as per my previous post, and as outlined there, the FPS only increased a little with using the dedicated GPU.

 

What's really odd is that my 1060 reached only a maximum of 7% utilized while I was in-game (if Task Manager is accurate), along with about 30% for the CPU. Something is bottlenecking the port, but I have no idea what.

 

You may have missed my previous post on this but if you are using The Given then it's going to be slow on 0.9.1. I'm actually glad you found this because it exposed an inefficiency with how scrolling lines were handled. I have a fix for this in the next version but I was able to go from about 150FPS to 1,900FPS rendering The Given now that scrolling is handled properly. If you run something like Sunder MAP10 or 15, Frozen Time, Planisphere 2, Sunlust MAP28 these should be extremely fast on your 1060 with 0.9.1.

5 hours ago, Athel said:

I know I said I'd come back a few days later, and I know I'm a bit late, but... depending on how technical you'd want to get with vanilla compatibilty, might I suggest aiming to implement mikoportals? One of the best recent examples I have used is esselfortium's Knee Deep in Knee Deep in ZDoom. I'd imagine if it could support this, it could support pretty much anything.

Something a little less extensive (and admittedly a bit self advertising) is my own wad, Emblem. It's a WAD for Ultimate Doom, and it does feature some new enemies. Although the new enemies DO seem to work, there are some weird oddities. For starters, the undead scientists don't seem to play their noises at all when they should. I've tested this extensively in other ports and it works as intended except for this one. I'd imagine it'd have to do with the differences between executables and how you're internally applying the dehacked patch. Another thing I noticed in both my own wad AND the original is that Pinkies don't seem to play their noises on time. Usually, on the first frame of the demon's attack, it'll play the demon biting sound, but here it seems to only play a few seconds after the LAST frame.

 

I'd also like to point out that, back to my own WAD, the afrits do NOT actually have their hitboxes matching up to where they actually are. It seems as though, although they can fly, it doesnt seem like the autoaim is picking up on that, which looks pretty odd. I can get a screen capture of this, not sure how fixable it would be. 

Thanks for coming back with this. Mikoportals aren't that hard in themselves. It's on the list but there is something else with KDIZD dealing with physics that wouldn't allow it to work properly. I was able to get some of the mikoportal examples people have posted to work, but KDIZD is exposing some strange vanilla quirk with how it allows the voodoo dolls to move down the sector.

I actually played the first 3 maps of Emblem with Helion a while back, looks like in June. Pretty cool maps. I see what you mean with the afrit. I didn't notice these issues when I previously played it but I will take a look :)

7 hours ago, HalfLife9000 said:

oh my god. The map hasn't even been out for half a month and it's already being use to torture test Doom source ports, Damn.

This map is actually showing how much the BSP tree traversal and adding segs to a view clipper really hurts Doom ports. The worst of it is that you only end up viewing just a few walls and flats. The traversal is wasting too much CPU. With my Ryzen 5900HS and Mobile RTX 3070 I am only able to squeeze out 80 FPS using GZDoom. With Helion I am able to get just over 1,000FPS.

Ill post my findings with a in-dev build (unreleased) later using my garbage.

It does have the devs stumped though, aint that right @hobomaster22? :P 

Even still, i am amazed to see this gigantic worlds come to live without my small 1 litre PC go to Phobos's itself.

33 minutes ago, Redneckerz said:

Ill post my findings with a in-dev build (unreleased) later using my garbage.

It does have the devs stumped though, aint that right @hobomaster22? :P 

 

Even still, i am amazed to see this gigantic worlds come to live without my small 1 litre PC go to Phobos's itself.

Ha! Your Intel GPU from 2013 is slow in some very strange ways. It is quite the miracle that we got some of the largest maps rendering in the 30 FPS range :)

11 hours ago, hobomaster22 said:

This map is actually showing how much the BSP tree traversal and adding segs to a view clipper really hurts Doom ports. The worst of it is that you only end up viewing just a few walls and flats. The traversal is wasting too much CPU. With my Ryzen 5900HS and Mobile RTX 3070 I am only able to squeeze out 80 FPS using GZDoom. With Helion I am able to get just over 1,000FPS.

try this. Evan's Torture Test (Build 11-27-22)

11 hours ago, hobomaster22 said:

Thanks for coming back with this. Mikoportals aren't that hard in themselves. It's on the list but there is something else with KDIZD dealing with physics that wouldn't allow it to work properly. I was able to get some of the mikoportal examples people have posted to work, but KDIZD is exposing some strange vanilla quirk with how it allows the voodoo dolls to move down the sector.

I actually played the first 3 maps of Emblem with Helion a while back, looks like in June. Pretty cool maps. I see what you mean with the afrit. I didn't notice these issues when I previously played it but I will take a look :)

Cheers! I'll try to see if I can do a full playthrough of the WAD through Helion. I skipped to E1M9 since that was the most advanced (for me, anyways) and I noticed something going on with the second act of the level not letting me through but that could just be something I'd need to put in the bugfix version of my wad. I'll also hit it with a couple more wads I think would stretch vanilla to its limits. Im curious to see how it would handle TCs...

20 hours ago, hobomaster22 said:

Ha! Your Intel GPU from 2013 is slow in some very strange ways. It is quite the miracle that we got some of the largest maps rendering in the 30 FPS range :)

And on that note, some numbers: All set with Render.maxdistance to 0 and uncapped vsync at 1080p.

My specs:

• Core I5-4590T
• Intel HD 4600
• 16 GB DDR3

Tested WADS:

• Saturnine Chapel plays around 25-35 fps, with 21 fps as lowest. What is curious though is that when standing in midair, i get spikes to 80-90 fps for a split second. I am not making any movement. 
• The Given is around 30-40 fps, so a bit better than Saturnine Chapel. Except for one = I went to the ceiling and found a teleporter. The first sec after teleporting was brutal, and i hit 8 (!) fps as a result. Probably the dynamic shift caused it to plummet. Either way, it is fascinating seeing this run on this kind of hardware
• Dance on the Water's map01 is around 30-40 fps. When monsters awake i get a brief 12fps spike. It can hit 60, but it stays around 30-35 FPS. map04 (The Focus) is where my PC dies. From a distance (Aka: When i start) it is 30 fps. But as soon as i close into the structure, i get to 12-15 fps. This is just too dense in geometry. According to @hobomaster22 this is highly unusual and exceptionally low. You mentioned testing this yourself, right?
   

2 hours ago, Redneckerz said:

And on that note, some numbers: All set with Render.maxdistance to 0 and uncapped vsync at 1080p.

My specs:

• Core I5-4590T
• Intel HD 4600
• 16 GB DDR3

Tested WADS:

• Saturnine Chapel plays around 25-35 fps, with 21 fps as lowest. What is curious though is that when standing in midair, i get spikes to 80-90 fps for a split second. I am not making any movement.  
• The Given is around 30-40 fps, so a bit better than Saturnine Chapel. Except for one = I went to the ceiling and found a teleporter. The first sec after teleporting was brutal, and i hit 8 (!) fps as a result. Probably the dynamic shift caused it to plummet. Either way, it is fascinating seeing this run on this kind of hardware 
• Dance on the Water's map01 is around 30-40 fps. When monsters awake i get a brief 12fps spike. It can hit 60, but it stays around 30-35 FPS. map04 (The Focus) is where my PC dies. From a distance (Aka: When i start) it is 30 fps. But as soon as i close into the structure, i get to 12-15 fps. This is just too dense in geometry. According to @hobomaster22 this is highly unusual and exceptionally low. You mentioned testing this yourself, right?
   

Also note, Red is using an unreleased development build that addresses performance issues found in Saturnine Chapel and The Given.

I did some testing with my Intel HD 500. I am still in disbelief that we are testing on such low end GPUs and getting anywhere near playable FPS ranges on some of the toughest maps known to Doom...

• Windows 10
• Intel Celeron J3455
• Intel HD 500
• 4GB RAM

Saturnine Chapel also gets around 25-30 fps
The Given: 50-60 fps
Dance on the Water MAP01: 25 fps
Dance on the Water MAP04: 50-60fps

On paper your Intel HD 4600 should be better, but I suspect the reverse is actually true. The results for Saturnine Chapel and Dance on the Water MAP01 are bottle necked by this Celeron CPU dealing with changes that need to uploaded to the GPU, where your i5 handles it more efficiently. This would explain why you do better on DOTW MAP01 that is loaded with dynamic light changes, but then it reverses on MAP04 because all the map geometry is static.

27 minutes ago, hobomaster22 said:

Also note, Red is using an unreleased development build that addresses performance issues found in Saturnine Chapel and The Given.

I did some testing with my Intel HD 500. I am still in disbelief that we are testing on such low end GPUs and getting anywhere near playable FPS ranges on some of the toughest maps known to Doom...

• Windows 10
• Intel Celeron J3455
• Intel HD 500
• 4GB RAM

Saturnine Chapel also gets around 25-30 fps
The Given: 50-60 fps
Dance on the Water MAP01: 25 fps
Dance on the Water MAP04: 50-60fps

On paper your Intel HD 4600 should be better, but I suspect the reverse is actually true. The results for Saturnine Chapel and Dance on the Water MAP01 are bottle necked by this Celeron CPU dealing with changes that need to uploaded to the GPU, where your i5 handles it more efficiently. This would explain why you do better on DOTW MAP01 that is loaded with dynamic light changes, but then it reverses on MAP04 because all the map geometry is static.

I may have found a reason why our performance metrics are so different. Yes my CPU trounces your Celeron, and my GPU is better too, but your rig only has 4 GB of ram and mines has 16 GB. Intel IGP's dynamically adjust system ram based on the amount of RAM you have - I believe a HD 4600 can addres up to 4 GB. Considering you are at 4 GB total RAM, it may well be that your system gives you only 512 MB's to work with. Bandwidth might also be a variable considering we are sending stuff to the GPU. My 16 GB DDR3 is in dual-channel configuration - The best allowed.

It might be tht UMA memory plays a part in performance, because dualchannel-quadchannel memory configs definitely do. IGP's love this stuff.

Furthermore, an HD500 believe it or not actually has more modern OpenGL support. So it may either be driver degression, of maybe even a CPU-related bug that stalls on this kind of large static maps. I wish i could do more to verify this, but you may need a similar Haswell system for that. It isn't terrible though: As soon as you hit the ground in The Focus it gets back to framerates that are good enough, so its just the approach that tanks it. Still, 15 FPS on something like that, still impresses.

On 11/28/2022 at 4:04 AM, Bauul said:

 

Thanks for this. This is exactly what I did as per my previous post, and as outlined there, the FPS only increased a little with using the dedicated GPU.

 

What's really odd is that my 1060 reached only a maximum of 7% utilized while I was in-game (if Task Manager is accurate), along with about 30% for the CPU. Something is bottlenecking the port, but I have no idea what.

 

I'm having the same issue. I'm testing with an rtx 3060 and a ryzen 7 2700 and it's using 12% cpu and 30% gpu tops with vsync disabled on sunder map15, and it isn't playing very smoothly which is rather odd, and getting a min fps of around 35-40.

I'll also use this opportunity to recommend PUSS X: Summer of Slaughter (SOS_Boom.wad) map32 as a good benchmark for this port. This map in particular plays much better on this port than on dsda-doom and woof, all around being more stable in regards to performance.

7 minutes ago, Blip said:

I'm having the same issue. I'm testing with an rtx 3060 and a ryzen 7 2700 and it's using 12% cpu and 30% gpu tops with vsync disabled on sunder map15, and it isn't playing very smoothly which is rather odd, and getting a min fps of around 35-40. 

 

I'll also use this opportunity to recommend PUSS X: Summer of Slaughter (SOS_Boom.wad) map32 as a good benchmark for this port. This map in particular plays much better on this port than on dsda-doom and woof, all around being more stable in regards to performance.

Sunder MAP15 is very stressful in two ways. One is the map geometry. We handle that very easily and RTX cards can render that in the 1,000+ FPS range. The issue is the nearly 6,000 monster count and Sunder is not efficient with this. When you fire, it wakes up all the monsters and they start moving using a ton of CPU. The world simulation runs 35 times a second in Doom. All the monsters run their movement, line of sight checking, collision, etc which delays sending to the GPU. After the world simulation frames are able to be blasted out very fast because it's just level geometry until the next game tick. So the average is very high, but the low will be dragged down by the world simulation. All source ports have this problem, and we do not hide it in our FPS counter by just showing the average :)

Running the ports that support it with -nomonsters would show how much we have removed the rendering bottleneck for most maps. Dealing with optimizations for world simulation is on the list, but one of our goals is being able to free mappers from worrying about map geometry dragging down performance.

Thanks for posting SOS_Boom.wad, haven't seen this one yet.

multi threaded monster logic, maybe? 

3 minutes ago, Turin Turambar said:

multi threaded monster logic, maybe? 

It's certainly a possibility, but honestly that would be an absolute last resort. I have thought about this a bit but there are a lot of objects that states can potentially modify that need to be locked that it may not even be worth it. Plus it would make the code significantly more complicated and harder to maintain. And I'm not even thinking about doing it in a way that is deterministic, which would be another complication.

There is a lot of work we can do optimize the monster routines before we consider this route, we have just done most of the obvious ones so far :)

Plus, rendering sprites in general is more expensive than it needs to be. We have some ideas for this. Because things can change textures at anytime and their coordinates are changed based on the viewers play angle makes it significantly more difficult to handle compared to map geometry.

One idea I had to help mitigate the monster issue for future maps is adding a line special to allow spawning in monsters/things similar to ACS Thing_Spawn. This would give mappers a lot more control over monster spawns with voodoo conveyors. This way they wouldn't need to exist in boxes way off the map just waiting for their time to spawn eating up precious CPU time.

On 11/21/2022 at 4:57 PM, hobomaster22 said:

Thanks for taking the time to respond. That is cool that you got it working on Linux. One problem was using System.Drawing for image processing and Visual Studio didn't warn us that it's Windows only like it does now. I wanted to remove this dependency but the third party .NET core image processing libraries aren't as nice to use. But it will happen eventually. I can add the field of view option quite easily for the next release. I was honestly unaware that ports even let you change this, so I learned something new.

Thanks, most ports support fov changing but cause 90 is good enough for most, not many know/do it.

And visual studio not warning you sounds like the program working as intended lol.

Hello again, I am currently testing my update to my wad, and I've noticed something that I'm not sure has been mentioned before but... the movement in this port feels... off. It doesn't really feel as responsive as vanilla/dsda-doom's movement? I feel like it takes an extra bit of a second to actually move. I'm not sure if that's something port specific or if that's something that is known? I'd be down to doing more testing in the matter, but has this been noticed by others?

41 minutes ago, Athel said:

Hello again, I am currently testing my update to my wad, and I've noticed something that I'm not sure has been mentioned before but... the movement in this port feels... off. It doesn't really feel as responsive as vanilla/dsda-doom's movement? I feel like it takes an extra bit of a second to actually move. I'm not sure if that's something port specific or if that's something that is known? I'd be down to doing more testing in the matter, but has this been noticed by others?

Some GPUs have issues and delay rendering. You can try setting render.forcepipelineflush to 1. Let me know if that fixes it and what your GPU is. So far I’ve only seen this happen with Intel cards. 

Hmm, that seems to have helped a bit, but something still feels a bit off in the movement... I'm using an Intel Core i5, Nvidia Geforce RTX laptop. I'm not sure if it's the display that's messing with me or if it's just me nitpicking on a small detail or if it's movement code.

Also, another thing I'd like to report as I have just found this--it seems that the codepointer A_KeenDie does not work as intended. In vanilla, it would check to see if all enemies with the codepointer were dead before opening doors tagged 666, but in Helion, it seems as though it always triggers if only one is dead. I'll test how it works in Doom 2 in a bit, as well as checking other maps which use specific code pointers to see if it applies to them as well.

I have noticed classic Doom sprite clipping issues with floors.

I think that can be solved by rendering planes without updating z-buffer. Of course you need something to block other sectors from bleeding trough. This should be possible by extending walls to "infinity". Kinda like this test i did a while ago:

Of course you don't need to actually render those hidden walls textured or even use RGB channels, you only have to update z-buffer.

Oh, and two-sided walls should probably be extended to.

This is just an idea, hope you find it interesting ...

2 hours ago, kgsws said:

I have noticed classic Doom sprite clipping issues with floors.

 

I think that can be solved by rendering planes without updating z-buffer. Of course you need something to block other sectors from bleeding trough. This should be possible by extending walls to "infinity". Kinda like this test i did a while ago:

Of course you don't need to actually render those hidden walls textured or even use RGB channels, you only have to update z-buffer.

Oh, and two-sided walls should probably be extended to.

 

This is just an idea, hope you find it interesting ...

It's definitely an interesting idea. I'm not aware of any hardware rendering port that renders sprites to exactly (or very closely) match Vanilla. Helion is using an algorithm to tweak the sprite clipping allowed so it's (probably) not too crazy. It can be disabled entirely by setting render.spriteclip to 0 if you like. There is a slew of render.spriteclip* variables that one can play with to change how the algorithm works too. Looking at the image you posted the default value for render.spriteclipfactormax might be too high.

3 hours ago, Athel said:

Hmm, that seems to have helped a bit, but something still feels a bit off in the movement... I'm using an Intel Core i5, Nvidia Geforce RTX laptop. I'm not sure if it's the display that's messing with me or if it's just me nitpicking on a small detail or if it's movement code.

Also, another thing I'd like to report as I have just found this--it seems that the codepointer A_KeenDie does not work as intended. In vanilla, it would check to see if all enemies with the codepointer were dead before opening doors tagged 666, but in Helion, it seems as though it always triggers if only one is dead. I'll test how it works in Doom 2 in a bit, as well as checking other maps which use specific code pointers to see if it applies to them as well.

The RTX definitely shouldn't have an issue.

There could be an issue if what you are testing against is using dehacked depending on the modifications. I does seem to be functioning against Doom 2. Let me know what wad and map is incorrect and I can take a look.

The issues you mentioned before are fixed for the next version as well. The sound issue with the demon bite, and the issue with the afrit is fixed which was related to the sprite clipping kgsws posted. For some reason it's image has a bunch of completely blank pixel rows at the bottom. This causes the clip detection algorithm to push the sprite way up. Had to update our sprite loading to throw those pixels in the trash.

That's great to hear!

I was testing Emblem against Helion. KeenDie is used three times throughout the WAD, on E1M2, E1M8, and E1M9. In vanilla/chocolate, this behaves exactly as it should. Doing similar tests under dsda, zdaemon, zandronum, etc. all yield the same results. I'll keep doing some tests on my end and get back to you with some detailed and properly formatted reports.

On 11/30/2022 at 4:29 AM, hobomaster22 said:

One idea I had to help mitigate the monster issue for future maps is adding a line special to allow spawning in monsters/things similar to ACS Thing_Spawn. This would give mappers a lot more control over monster spawns with voodoo conveyors. This way they wouldn't need to exist in boxes way off the map just waiting for their time to spawn eating up precious CPU time.

Just FYI there are GZDoom mappers, even with access to Thing_Spawn (or the other ACS equivalents), that prefer to use classic monster closets for a couple of reasons:

1) The monster count number is accurate upon loading the level (with summoning monsters it increases over time)

2) The flow of teleporting monsters into a level is more organic rather than all spawning it at once, as the natural movement AI introduces some variation

Thinking out loud here, what might be more useful is a "Monster Closet" sector flag, that simplifies the monster AI when a monster is inside it.  You could do a something like have the flag trigger a simplified version of A_Chase that skips the melee check and the missile check (because monsters will necessarily do neither in a monster closet), the active sound function, even the LOS check.  All a monster needs to do is wake up and the raw basics of moving around.  Then when they teleport in, the flag is no longer present so the monster reverts to the full-fat AI.

1 hour ago, Bauul said:

 

Just FYI there are GZDoom mappers, even with access to Thing_Spawn (or the other ACS equivalents), that prefer to use classic monster closets for a couple of reasons:

 

1) The monster count number is accurate upon loading the level (with summoning monsters it increases over time)

2) The flow of teleporting monsters into a level is more organic rather than all spawning it at once, as the natural movement AI introduces some variation

 

Thinking out loud here, what might be more useful is a "Monster Closet" sector flag, that simplifies the monster AI when a monster is inside it.  You could do a something like have the flag trigger a simplified version of A_Chase that skips the melee check and the missile check (because monsters will necessarily do neither in a monster closet), the active sound function, even the LOS check.  All a monster needs to do is wake up and the raw basics of moving around.  Then when they teleport in, the flag is no longer present so the monster reverts to the full-fat AI. 

This is an interesting idea, there could definitely be ways to help that I will have to think about. The unfortunately thing is that the biggest time suck for A_Chase is purely the monster movement. I ran a few of the large monster count maps including Sunder MAP15 against the Visual Studio profiler and it all comes down to monster movement. It wastes the most time checking blocks against other things/lines. It compounds from here because they are boxed in so the first direction might fail, and then the next... etc. Then when it determines a successful move the next biggest time suck is actually linking it to the sectors in the blockmap (which is a line blockmap traversal) and then BSP subsector link. I believe LOS checks only accounted for 2% or less of the total CPU time, while blocking and linking was about 15% total. You can also take this with a grain of salt because this is Helion, these numbers could be very different for other ports.

I think Bauul brings some valid points as to why classic monster closets still beat Thing_Spawn.

Though if monster closets were to be improved in the engine in a way that requires mappers to do something, why not go a bit further, and make it even more convenient for both the mappers and the engine. For example here's a rough idea:

- The monster closets could just be simple tagged sectors where the mapper dumps a bunch of monsters, without all the work involving teleport lines, monster movement and sound propagation, etc...
- Have for example 3 line specials (for doom/boom format):

• Create Monster Closet (tag) : On map load marks the sector to which the line belongs to as a monster closet, making all monsters dormant inside it. Linedef length could for example determine the frequency at which the monsters attempt to teleport out or something like that. Tag is the tag of the sector(s) to which the monsters will teleport to.
• Activate Monster Closet (tag) : Tag of the monster closet to activate.
• Deactivate Monster Closet (tag) : Tag of the monster closet to deactivate.

- For a hexen format/udmf special you could probably get away with less line specials, and more options to customize too.

Edit: I suppose for doom/boom format you would need a bunch of variants of the activate/deactive specials to account for different line activation methods...