Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • 0
Marn

Bizarre teleport trap problem

Question

I'm testing a map in Crispy Doom and I have a typical teleport trap set up like so:


Screenshot_1.png.d24edb7ab20adc099cdf73abdf627ce3.png

 

Each demon is behind a 1-unit thick door that opens when triggered, allowing monsters to teleport into the room via a W1 monster only teleport.

 

Each line corresponds to its own sector:

 

Screenshot_2.png.6c4a5784a795b3d26946dae546d7e32b.png

 

All of the monsters teleport into the room successfully except for the cacodemon, which wanders across the teleport line without triggering it and proceeds to wander around in the setup area.

 

- All teleport linedefs are facing in the right direction

- The setup is exactly the same for each monster

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

- There's enough room on each side of the teleport linedef 

 

I should also add that originally each monster teleported into the same sector, but this broke in Crispy which resulted in the current multi-sector setup, which resulted in the caco not teleporting as it should.

Share this post


Link to post

5 answers to this question

Recommended Posts

  • 0

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.

Edited by rdwpa

Share this post


Link to post
  • 1

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.

 

setup.JPG.1c61a5fb7c3c336cae147dc945c5cea0.JPG

 

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.

Share this post


Link to post
  • 0

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.

Share this post


Link to post
  • 0
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).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×