Teleporting into linedefs

[Quasar]

DOOM allows it. Ports still allow it. Is there a technical argument against trying to fix it? I am curious because it seems like a relatively simple problem to address.

[DaniJ]

Are you meaning when a teleport destination causes teleported things to end up some way through a solid linedef and into the void? How do you intend to fix it?

My 'fix' for this would be to P_Damage(mo, 100000). That way, mod authors will soon learn to position them correctly (unless of course they want an instant death trap...) :)

[boris]

DaniJ said:

How do you intend to fix it?

You could move the thing along the direction vector of the linedef.

[DaniJ]

Yes but then you have to contend with whatever else may already be in that direction. You could try your up most, checking vs other things, other linedefs, in other directions, 'fuzzing' the destination coordinates and still not find a good spot within a tolerable time frame.

If you aren't able to find a good spot algorithmically then its probably because there just isn't one. The map hasn't been built correctly. Therefore, my suggestion of insta-fragging the teleportee isn't as bad as it sounds because then the map author is actually likely to notice and then fix the problem (ha!).

[andrewj]

I don't see any real difference between:

(a) player gets stuck, map author has to fix their map
(b) player gets killed, map author has to fix their map

[Enjay]

I do, however, see a difference between:


(a) player gets stuck, map author specifically wanted this
and
(b) player doesn't get stuck, source port broke the map


Now, I don't suppose that there are many reasons to want this behaviour but I can think of a couple of possible scenarios and, who knows, they may already exist.

Another concern is that a "fix" might encourage sloppy mapping. If the player can get stuck in a map, then the WAD author really should be fixing that problem if it is not a desired one. A WAD where the player does get unintentionally stuck clearly hasn't been tested properly and probably isn't that good in the first place, It quite possibly has other problems too. Allowing teleport spots to be placed badly and then having the engine fix it allows careless item placement and may break map compatibility with other ports.

And finally, I'm sure that we are all aware that many of the problems caused for port authors these days are due to sloppy adherence to editing specs by the engine in the past (from Vanilla onwards). The many twists and turns that have to be gone through to preserve the various idiosyncrasies in newer ports have certainly been discussed as problems on various forums that I have seen. It seems counter-productive to introduce another situation where mappers can be careless and get away with it.

[Quasar]

I am actually more concerned about cases that lead to monsters being stuck than the player, since maps which cause the player to get stuck are intrinsically unplayable anyway.

The problem happens on Lost Episode E5M8, where if you have not raised the center pit properly, the Spiderdemon boss teleports into the pit, gets stuck, and then causes the sector to refuse to move no matter what happens afterward.

If the Spiderdemon wasn't allowed to teleport when it would end up stuck inside linedefs, this wouldn't happen.

I can see how checking 2S lines for teleport allowance might be difficult, however, since P_BoxOnLineSide only tells me if the thing is completely on one side of the line or inside it, and not which side its *origin* is on even if it's inside the line, and that's info I'd need to judge which floorheight (frontsector or backsector) I need to worry about.

[printz]

Don't fix it. I don't know what has got into you to think about fixing it. It's consistent behaviour for something stuck not to move. It's mappers' problem that they can't draw the map properly. Against spiderdemons or arachies who are prone to this, use a thing outside the intended monster range to prevent telesticking.

[Quasar]

The fact that the sector won't raise with a stuck Spiderdemon in it isn't surprising and I'm not suggesting trying to "fix" that. What IS surprising is that the Spiderdemon can teleport into areas as small as a 64x64 box simply because DOOM never bothers to look for linedefs that are in the way. It only checks for things (and it does a poor job of that too, as originally, PIT_StompThing only kills live objects and totally ignores inert ones, causing you to get stuck if you, say, teleport into a lamp post).

[Graf Zahl]

Doom's movement code is not fixable. Once you start you'll never stop. Fix one thing and you have to make adjustments somewhere else - which in turn require even more changes. It's a hopeless mess.

[Enjay]

And, if it is teleporting monsters that you are worried about, I can actually imagine more situations where someone might want a monster to teleport and be stuck than I can with players.

If the map is getting broken by a teleporting anything, it's a broken map and the map should be fixed, not the engine IMO.

[Quasar]

Graf Zahl said:

Doom's movement code is not fixable. Once you start you'll never stop. Fix one thing and you have to make adjustments somewhere else - which in turn require even more changes. It's a hopeless mess.

As a generalization that may be true but in fact this IS fixable - it's just a question of IF it should be fixed or not.

A P_BlockLinesIterator call would be all that is needed, using a customized version of PIT_CheckLine that judges whether or not each particular line blocks the teleportation. Very simple, and it will work. The blockmap bugs that plague thing movement only apply to objects moving into other objects, and not objects moving into lines.

[Gez]

The issue is one of compatibility. If a problem arises in most ports but is silently solved in another, and a "multi-compatible" mod is made but tested only on the one of the target ports which is not affected by the bug, then the mod is effectively compatible only with one port.

Case in point, Xaser's Lost Episodes is intended to be used with either ZDoom or Eternity. Here it's not too much of a problem because the bug does not normally happen; but in a hypothetical future mod it might be inevitable.

[Enjay]

Yes, I meant to make that point too. If it gets fixed in Eternity but no other ports, a map tested in Eternity only, but meant to be Boom or Vanilla compatible could be broken in all other ports. People complain about zdoom-only testing often enough already.

[Quasar]

Do keep in mind this is why EE has compatibility variables. However I'm still not sure if this is worth messing with. It IS an error in the map. Either the pit should not have been placed underneath where the Spiderdemon has to teleport, or some mechanism should have been used to make sure the pit was fully raised before it could teleport.

I understand a new release of the mod *may* be in progress that might fix this issue. I still find it very odd that DOOM will let gigantic monsters teleport into tiny spaces, though. It just seems wrong :P

[andrewj]

Quasar said:

I still find it very odd that DOOM will let gigantic monsters teleport into tiny spaces, though.

Yes it is wrong, but it's not the kind of thing that surprises me. Developing a game engine for a commercial product means a deadline and doing just enough to make it work. Readable code that works 100% reliably are luxuries in that context, which is a very different context to ours: hobbiests improving the code with no time constraints (etc).

[gggmork]

This just happened to me in a wad I made. Masterminds teleported to a 64x64ish area that I assumed only the cacos would fit to teleport to (with 'teleport destination' things & sector tags- not line to line).

[printz]

Quasar said:

I still find it very odd that DOOM will let gigantic monsters teleport into tiny spaces, though. It just seems wrong :P

It's not odd at all, and any "fix" on it will be against the vanilla-like physics that the Eternity engine relies on as a hotpoint. Not only that, but it's really a fixable map editing error, against which the code has no business. It's the mobile objects which are the only culprits on telemerging, and they're already addressed. The only other element I could think would be, and need addressing, is the polyobject, but only if the designer wants to. But static things, and linedef ledges, which are always inert, never interfere as much as the actors on the destination. It's a level design error, not unlike placing monsters on walls. I understand that there's the dynamics of lifting sectors at it, but I fail to see a big difference on concept. Same design shit, really.

There are better ways to address it, by having the author correctly place monsters and walkways, rather than forcing it as a cross-port-confusing bug-cover that would produce Eternity's equivalent of ZDoomisms plaguing limit-removing designed maps.

The author above could have just placed Masterminds (or Arachnotrons, Mancubi, everything...) in different box sectors, with different destinations. It's really no difficulty figuring this out.

More specific cases, such as the final spawner, can very likely be controlled via Eternity's more advanced scripting.

[DaniJ]

Perhaps the best 'fix' for this would be to provide a special "map-error-checking mode". When enabled, all teleport destinations are checked at the start of the map to determine whether they have enough open space around them to receive the largest known thing. If not, inform the user that there may be a problem depending on plane heights, thing radi etc. Other than that, do nothing. However I personally think such a thing is more the responsibility of map editors...

[Gez]

DaniJ said:

Perhaps the best 'fix' for this would be to provide a special "map-error-checking mode". When enabled, all teleport destinations are checked at the start of the map to determine whether they have enough open space around them to receive the largest known thing.

Would be annoying to have lost soul teleport destinations flagged because they're too small for a spider mastermind...

Also, it would be very far from being foolproof. Imagine the reverse situation: a map where you're supposed to have a spiderdemon teleporting in, and then after defeating it you may lower a pit in the arena; but it's possible to lower the pit before the spider teleports. At map start, the situation is okay, so the issue wouldn't be detected.

Once you factor in scripting languages such as ACS as well, making this "mapcheck mode" worth using for the modder would require a ton of work on the engine's side... Really not worth the effort IMO. Either it's simple to implement, but useless; or it's actually useful, but a nightmare to code.

[andrewj]

printz said:

Not only that, but it's really a fixable map editing error, against which the code has no business.

The code could check each teleport and produce a warning in the console or log file which conscientious mappers could check.

Furthermore, imagine if the editor could parse the log file for warnings and allow the user to step through each problem to fix them (not just teleport problems, all sorts of things like missing lowers when a lift goes down, etc).

[DaniJ]

Gez said:

Also, it would be very far from being foolproof. Imagine the reverse situation: a map where you're supposed to have a spiderdemon teleporting in, and then after defeating it you may lower a pit in the arena; but it's possible to lower the pit before the spider teleports. At map start, the situation is okay, so the issue wouldn't be detected.

Absolutely. I wasn't suggesting to bother checking sector heights at all for this very reason. As you say though, the usefulness of such a feature is rather limited but I thought I'd present the option anyway.

[myk]

Quasar said:
Do keep in mind this is why EE has compatibility variables. However I'm still not sure if this is worth messing with.

Yeah, I think it'll do more harm than good, as Enjay described. The more individual compatibilities you add, the more esoteric a source port becomes to the user because if I make a map where I use a teleporting zombieman or thing as some sort of "lift-locking device" and someone is playing Eternity with the "teleport_into_linedefs 0" option, they'll likely have no idea that they are playing a broken map or why it is broken. Maybe having the engine scan for the phenomenon and print "thing X will teleport into solid linedef Y, teleport_into_linedefs 0 is recommended unless the instance was intended by the designer," which you often can't know without playing or examining the map in detail unless the designer by chance decided to note that tidbit in the text file or something. A player will likely not want to ruin surprises in Doom Builder or play it and risk having a bad first experience.

I think it is wise to support "engine models" like in PrBoom/+, where a bunch of critical compatibilities are slapped in so certain widely used level formats work. Which isn't incompatible with the individual settings as an alternative (all of which can still be applied to the default model.) This doesn't have to go as far as demo compatibility to be useful, of course, applying especially features that most likely make or break a level, but it offers a way to practically guarantee widely-used formats will work. Then, if you wanted, you could fix this minor issue in "default" or "Eternity" mode, and maps possibly expecting the glitch would not normally be affected. You'd simply recommend that users apply the corresponding "engine model" when applicable.

[Jodwin]

andrewj said:

The code could check each teleport and produce a warning in the console or log file which conscientious mappers could check.

Furthermore, imagine if the editor could parse the log file for warnings and allow the user to step through each problem to fix them (not just teleport problems, all sorts of things like missing lowers when a lift goes down, etc).

Of course, mappers who would bother checking log files and such are usually more cautious or experienced with their mapping to not make such errors in the first place (or even if they made them, you'd think they'd spot it in testing and fix it). The error checking functionality, when it comes to errors like these, is more geared towards inexperienced mappers, but they are very unlikely to be using error checks in the first place.