Bizarre teleport trap problem

Regardless of what the problem is, that teleport setup is a bad idea. If a monster fails to warp, because it's blocked by a live monster, it'll wander in that space, perhaps indefinitely. 'The player will probably kill those monsters' is not a good justification; that logic should be expunged from your thinking otherwise you're 100% going to have buggy teleporters in your maps somewhere. I'd suggest shrinking that bottom 'free space' so that monsters can't actually move into and around in it. 

I agree with NIH. This sort of error often stems from a trivial oversight. What's worth noting is that you need four tags, not just four sectors. If you have two destinations with the same tag, one will be ignored entirely.  

edit: also, W1 Teleports in closets? Unless you're wiring up some obscure setup, stacking W1 teleports, where a monster sometimes goes to one spot and sometimes to another, avoid entirely.

I'll pitch in here, though there's plenty enough answers here to get you going.

Here's a setup I concocted that would work better for you.

The thing is that here, all the teleport linedefs refer to the same tag, meaning these four buggers push out of the same teleporter. Why did I do this if that's not what you're doing? To show how you can make sure the monsters come out even though the destination might be blocked.

The important things here are:

- You use WR teleport actions (there's no reason why they should be W1 if we're intending for them to come out eventually).

- You have the teleport line to both directions. If the monsters fail one pass, they start moving in the other direction. This way they can trigger it going both ways.

- Keeping the space small for individual monsters is key, because they won't walk too far back from the player. This way they'll keep crossing the linedefs until they teleport.

- The rooms are exactly as tall as the monsters (and the linedefs between them are monster blocking). The blocking walls are 1 unit off the floor (or ceiling), so that it's just enough to block them. This, combined with the placement of the teleport linedefs, creates a somewhat^{(citation needed)} instantenous teleport, more so than in your original setup.

There are too many things that could be wrong here, and sometimes it's something pretty darn "stupid", too. mind posting the map?

A couple of things that might help root out the problem:

• Does the caco teleport only break in Crispy? If it's a source-port-specific bug diagnosing the issue might get a bit tricky (although Crispy should theoretically reproduce vanilla behavior), but if it breaks in PrB+, GZ, etc. it should be relatively straightforward.
• Does the caco teleport fail even without the pinkies? This will probably give a big hint as to whether it's an issue with the Caco closet (or, more likely, destination) construction or whether there's still some monster blocking in the destination area.

Posting the wad will probably be the easiest way to get to the bottom of it. From the editor shot my suspicion is that monster blocking could still be an issue. Pinkies move quite a bit faster than cacos, so it's not inconceivable that they could hit the teleport first and move just enough to slightly block the caco. Strictly speaking, you can't do truly "instant" teleporting in limit-removing format, though there are some setups that can be functionally instant and simultaneous for multiple monsters. I'm not enough of an engine expert to know for sure whether your setup will actually work that way in this case, particularly just from a visual.

4 hours ago, Marn said:

- All monsters teleport in instantaneously, so there shouldn't be any issues with the caco's teleport destination being blocked by a pinky 

This assertion appears to be incorrect according to what I'm seeing in the screenshots. Monsters teleport when their middle crosses the teleport line, and since the monsters need to walk about half their lengths before teleporting, and since pinkies are faster than cacos, the pinkies will teleport faster. And then, if a pinky blocks the caco, the caco will be stuck in the space below the teleport lines (as rdwpa pointed out).