Jump to content

Things about Doom you just found out


Sigvatr

Recommended Posts

Gez said:

It's a weird and inconsistent behavior (only projectiles from arachnotron, mancubus, and revenant have this property, not those from imp, baron/knight, cacodemon, cyberdemon, and player weapons) caused by id Software forgetting to update code. It's hard to argue that it should be there; I could see it supported in a "Doom (Strict)" compat setting but not in a general way.

Yeah, so typical of you and your ZDoom crew. Maybe I want to make a cool Doom level where arachnotrons and mancubi "sound the alarm" and activate lifts with more monster ambushes. Yet you say it shouldn't be done and aim to threaten vanilla maps with obscurity. You can bet that I'm gonna add ZDoom-only stuff that breaks ZDoom, if you keep with that.

Share this post


Link to post

Yeah, how very dare those Heretic (pun intended) (G)ZDoomers deviate from The One, True, Code of DooM!?

Share this post


Link to post
printz said:

stuff

If you do, you're being a pretty major dick to your players, forcing them to learn some really obscure and outright nonsensical quirk of the engine or else leaving them utterly baffled when a trap triggers at absolute random, sometimes never, from their perspective at least.

I mean, there's some merit if you want to make something made only to be played by someone who knows every exploit in the engine ( like the Item Abuse hacks for Super Mario World ) but by that point you've already thrown away ZDoom compatibility anyway, due to the physics being rewritten likely making a majority of the puzzles stupidly cheesable or completely broken anyway.

Share this post


Link to post
Arctangent said:

If you do, you're being a pretty major dick to your players, forcing them to learn some really obscure and outright nonsensical quirk of the engine or else leaving them utterly baffled when a trap triggers at absolute random, sometimes never, from their perspective at least.

I mean, there's some merit if you want to make something made only to be played by someone who knows every exploit in the engine ( like the Item Abuse hacks for Super Mario World ) but by that point you've already thrown away ZDoom compatibility anyway, due to the physics being rewritten likely making a majority of the puzzles stupidly cheesable or completely broken anyway.

You're assuming the WRONG thing. I'm not aiming to require players to "let arachnotrons start fire in some inaccessible area just to reveal a temporary lift to a one-chance secret". I was specifically talking about ambushes and traps being triggered by letting arachnotrons fire. Such lifts would be activateable by other means too, such as any actor passing by. Due to the setup, a player is first gonna assume the trap always springs, until he/she notices a pattern. I'm not trying to make her/him learn obscure tricks. It's much easier to trigger the trap than not. Just give the player a bonus if they manage to kill the arachnotron without getting near it and without letting it fire a plasma...

EDIT: If I look angry, it's because the only thing that would motivate me to make vanilla Doom levels is if I push it to the limits in every direction, and that includes all stable hacks in the book. I don't want to work on something ordinary, but I also don't want a gimmick experiment map either. If important ports refuse to support such tricks, I'm feeling forced to put huge disclaimers that "it doesn't work", rather than nerfing the tricks and turning my map into something standard and artificially limited. If I want conventional maps, I map for Eternity or what have you.

Share this post


Link to post
Arctangent said:

I mean, there's some merit if you want to make something made only to be played by someone who knows every exploit in the engine ( like the Item Abuse hacks for Super Mario World )

For a while I have wanted to make a WAD based around exactly this.

Share this post


Link to post
Arctangent said:

If you do, you're being a pretty major dick to your players, forcing them to learn some really obscure and outright nonsensical quirk of the engine or else leaving them utterly baffled when a trap triggers at absolute random, sometimes never, from their perspective at least.


Actually, I always fantasized about making a "Jinx" kind of map, where even completely unrelated and random player actions (e.g. walking on the "wrong" side of a hallway, choosing the "wrong" door, out of two or three possible choices, or even allowing a monster to shoot in a particular direction), cause different traps to activate later on, items to be provided or denied, monsters to be released etc. and the map to feel completely different to each player, without any reasonable explanation ;-)

printz said:

[b]I don't want to work on something ordinary, but I also don't want a gimmick experiment map either.


Please combine arachnotron-fired linedefs with that weird shootable/sliding romero-head thing demo ;-)

Share this post


Link to post
esselfortium said:

Is it possible to create that behavior in ZDoom as-is using DECORATE?

You should be able to by applying +ACTIVATEMCROSS on the projectile, so this doesn't seem like a huge problem

Share this post


Link to post
printz said:

Yeah, so typical of you and your ZDoom crew. Maybe I want to make a cool Doom level where arachnotrons and mancubi "sound the alarm" and activate lifts with more monster ambushes. Yet you say it shouldn't be done and aim to threaten vanilla maps with obscurity. You can bet that I'm gonna add ZDoom-only stuff that breaks ZDoom, if you keep with that.

And what if I want to make a level where imps and barons sound the alarm? Huh? What about it? Stop oppressing me, you vanilla freaks!


No but seriously how can you get angry about this? Seriously? "Threaten vanilla maps with obscurity" no but WTF are you smoking? Here we are, in 2017, over 23 years after Doom's release, and we're in a thread about "things you just found out" and one person has just found out you could make, I quote, an "obtuse puzzle" with this quirky behavior. And apparently saying that in ZDoom this would be restricted to a specific compatibility profile is something that would make everyone forget about every vanilla map ever released to this day? Woohoo, what an awesome power!

Kind of a weird power, though, because it not being supported at all right now, instead of supported in a compatibility option as I suggested, hasn't made vanilla maps obscure yet. So apparently the magical obscurity spell in ZDoom only works if you add support for vanilla hacks? Wizardry is really strange.

printz said:

EDIT: If I look angry, it's because the only thing that would motivate me to make vanilla Doom levels is if I push it to the limits in every direction, and that includes all stable hacks in the book. I don't want to work on something ordinary, but I also don't want a gimmick experiment map either. If important ports refuse to support such tricks, I'm feeling forced to put huge disclaimers that "it doesn't work", rather than nerfing the tricks and turning my map into something standard and artificially limited. If I want conventional maps, I map for Eternity or what have you.

Sorry but by its very definition, using this effect would be a weird gimmick experiment.

In fact your whole project of using "every stable hack" is pretty much the definition of a gimmick. You're not worried about making a map that looks good or plays well; you're worried about ticking down a bunch of checkboxes for "using feature X", "using feature Y" and so on. If you go down that way you won't end up with a playable map, you'll end up with a demo map, not much different than BOOMEDIT or MBFEDIT. If you're worried about using features for the sake of using features, you will not design something fun to play, I can guarantee you that.

Same as someone making a ZDoom map and insisting on ticking down the feature list of having at least one 3D floor, one slope, one custom monster, one particle fountain, one mirror... That's really not how you should approach mapping. You should instead use features that are available if and when they are useful.



Finally need I point out that some of the effects that can be achieved by arachplasma, fatso fireballs and revenant rockets are W1 lines? And that as a result they can end up accidentally screwing up the player by preventing the player from finishing the map?

Share this post


Link to post

That's a pretty cool effect that I'd love to use some day.

It reminds me of some stuff that SoM was doing in Doom Legacy at one time. I can't remember if it ever got finished or morphed into something else. I think it was some kind of scripting thing. Anyway, one of the things you could achieve with it was allowing projectiles to teleport. I had a lot of fun with that. I have a GIF somewhere of a BFG ball bouncing back and forth between two opposing teleport lines. I can't remember if I had given it gravity or not, but the ball is moving vertically too, it looks like a game of pong.

I also started constructing "force field" style arrangements by having arachnotrons fire at a teleport line and then routing their projectiles into a field/net arrangement. It looked awesome but was noisy as hell since the arach shot is loud anyway and this was pre-boom in legacy so the teleporters were all non-silent too.

I imagine this stuff is probably trivial in modern EE or Zdoom but I never took it any further at the time and I'd love to try that stuff again.

(IF I ever find the stuff on my old backups I'll try to fill in some blanks as to SoM's experiments on the doomwiki)

Share this post


Link to post

Good stuff, Gez. This discussion looks so funny.

Gez said:

Finally need I point out that some of the effects that can be achieved by arachplasma, fatso fireballs and revenant rockets are W1 lines? And that as a result they can end up accidentally screwing up the player by preventing the player from finishing the map?

Well, W1 doors should generally be avoided. I'll probably address this as a bug report when I get to it (when I have some WIP going on), months, years or decades later.

Share this post


Link to post
Arctangent said:

If you do, you're being a pretty major dick to your players, forcing them to learn some really obscure and outright nonsensical quirk of the engine or else leaving them utterly baffled when a trap triggers at absolute random, sometimes never, from their perspective at least.

I mean, there's some merit if you want to make something made only to be played by someone who knows every exploit in the engine ( like the Item Abuse hacks for Super Mario World ) but by that point you've already thrown away ZDoom compatibility anyway, due to the physics being rewritten likely making a majority of the puzzles stupidly cheesable or completely broken anyway.

As is typical, you've got the innocent and guilty parties reversed. Who changed the behavior is the party responsible for inconsistency - duh.

See, the expert mappers tweak their levels to precise details. And, no, they don't have to know every minute detail of the engine - that's what play testing is for. It's only the silly, amateur children mappers that don't notice subtle changes in the game play of their maps.

There's nothing wrong with "fixing" the Doom2 missiles, if your engine only applies that fix to non-vanilla, port-specific maps. Unfortunately, even in 2017, there is no reliable way to mark a map as port-specific. But there are port-specific lumps. So, that leaves a reasonable option:
Make MAPINFO flags for this, and any other deviation from vanilla the port offers. That keeps vanilla happy, and provides a specific way to manage random changes to core gameplay.

Doom II missiles trigger certain lines, period. If not, the port is broken (without their being a specific, per-map way to turn port-specific "fixes" on. This is the only way to ensure that the map plays as the author intended.

Share this post


Link to post
Arctangent said:

If you do, you're being a pretty major dick to your players, forcing them to learn some really obscure and outright nonsensical quirk of the engine or else leaving them utterly baffled when a trap triggers at absolute random, sometimes never, from their perspective at least.


Quoting for being the only thing in this part of the discussion that makes sense.
Some things are really better left untouched because there's just no way for a non-expert to know these things.

But instead we again get into a pointless discussion about the glorification of vanilla bugs and how to abuse them to do 'cool' stuff.

But the mere fact that nobody ever reported this as a problem in ZDoom for all the maybe 15 years the current behavior is in place should tell the entire story (which is, people do not tend to make stupid maps like that.)

@kb1: I see no point catering to shitty bug exploits. If I can discourage their use by not supporting them I see that as a plus for everybody involved by forcing modders to map responsibly. For the average player these things are not cool, they are merely annoying.

Share this post


Link to post
Graf Zahl said:

@kb1: I see no point catering to shitty bug exploits. If I can discourage their use by not supporting them I see that as a plus for everybody involved by forcing modders to map responsibly. For the average player these things are not cool, they are merely annoying.


This is just the wrong approach to take, but to each their own. It is a banner of shameful defensiveness you choose to carry around, much like the word "demo"-anything, because you choose to take such a hard stance on so minor a concept, rather than accommodating what little you can without borking your port and still retaining the usefulness of Doom's original design.

Graf Zahl said:

(which is, people do not tend to make stupid maps like that.)


Oh don't worry, I got this covered; coming soon...

Share this post


Link to post
Maes said:

Actually, I always fantasized about making a "Jinx" kind of map, where even completely unrelated and random player actions (e.g. walking on the "wrong" side of a hallway, choosing the "wrong" door, out of two or three possible choices, or even allowing a monster to shoot in a particular direction), cause different traps to activate later on, items to be provided or denied, monsters to be released etc. and the map to feel completely different to each player, without any reasonable explanation ;-)

This would be very cool, with one caveat: As long as the "proper" way to play is somehow "discover-able", this would be awesome. Like if every proper place had something different about it, like a certain colored pixel in the textures/flats, or something like that. But, if there was no way to ever know, short of reverse-engineering the map, it would be cool for you, but no one else :)

Share this post


Link to post
Graf Zahl said:

But instead we again get into a pointless discussion about the glorification of vanilla bugs and how to abuse them to do 'cool' stuff.

But the mere fact that nobody ever reported this as a problem in ZDoom for all the maybe 15 years the current behavior is in place should tell the entire story (which is, people do not tend to make stupid maps like that.)

@kb1: I see no point catering to shitty bug exploits. If I can discourage their use by not supporting them I see that as a plus for everybody involved by forcing modders to map responsibly. For the average player these things are not cool, they are merely annoying.

You always miss this point. It has nothing to do with deliberately using a "shitty bug", or glorification, etc. Mappers tweak their maps in a loop: mod, play test, mod, play test, etc. The general theory is that they do this until they like how the maps feels to play, regardless of their knowledge of engine quirks.

When a port changes the way the engine renders the map, the map no longer plays as intended.

Imagine if your compiler was secretly updated to say, return different results from multiplication. Maybe they fixed a small bug. On the surface, this seems like a good thing. But, what if it changed the math in a way that broke something in your engine. But only some compilers fixed the bug, and others did not. You would be upset - you'd have to add hacks to your source to handle both cases, or you'd try to convince the compiler developers to stop making subtle changes recklessly.

That is what is being described here. And, I'm sure you realize all of that. So, I have to ask, why can't you see the conflict you are causing with this approach?

I provided a quite reasonable way to handle this issue, but you glossed over it.

You claim to be encouraging mappers to avoid the use of "shitty bugs" (as if you have that right), but really what you're doing is causing mapper's hard work to be in vain.

You are causing your whole user base to not get the experience the map authors intended, and the sad thing is: they're blindly following you like little puppy dogs, encouraging you to do so. If they only realized...


In one sentence you charge map authors with "catering to quirks", yet also claim that you're encouraging mappers to not use

Share this post


Link to post

kb1, the fact that projectiles from Doom 1 don't do this means that it was a slip on id's part and the way it was originally intended was for projectiles to not trigger it, meaning that mappers that use it are going against id's intended design are they not?

Share this post


Link to post
kb1 said:

You are causing your whole user base to not get the experience the map authors intended

Makes me wonder how you must feel about "death of the author" and artistic interpretation and all that.

Share this post


Link to post

"See it's really important that if the player doesn't race to the W1 teleporter before the mancubus shoots, then they get stuck, unable to move to the next section of the map."

"Also it's essential to my Intended Map Experience™ that if the player opens this door, the game crashes. Don't you dare fix bugs and remove limits you heathens!"

Share this post


Link to post
Arctangent said:

Makes me wonder how you must feel about "death of the author" and artistic interpretation and all that.



No point to discuss such matters with people like kb1. They think in absolute terms of 'vanilla is always right' and then enter endless diatribes to justify it.

About the issue at hand: ZDoom takes the stance of consistency here - a missile is a missile is a missile. End of story. By default, missiles can only activate projectile triggers, and unless explicitly enabled they cannot be teleported, that cue was taken from Raven's games but made a universal trait.

BTW, we are talking about something that was changed a bit more than 18 years ago, so it's not some change ZDoom gratuitously made in recent times.

Strange that the people come out of their holes now. Where were they when these changes were made???

Maes said:

Four words: The Sky May Be /winsthread


Yes, something along that lines is the potential use case here.
I generally tend to rate vanilla quirks on how many maps need a compatibility setting for it in ZDoom. Contrary to common belief it's only a relatively small number of maps that need one and there's not a single one out there that requiores some stray projectile to teleport or trigger a door.

Share this post


Link to post
Graf Zahl said:

I generally tend to rate vanilla quirks on how many maps need a compatibility setting for it in ZDoom. Contrary to common belief it's only a relatively small number of maps that need one and there's not a single one out there that requiores some stray projectile to teleport or trigger a door.


I wonder if some -otherwise unremarkable- map from the early days of Doom made use of such a trick without the author giving even as much as a hint (or it happened unintentionally), nobody could make sense of it, and just called it "1994 garbage".

Share this post


Link to post

Doubtful. Back then people were a lot less informed, it may be that some map inadvertently could enter a situation where such a trigger was possible but in order to require a compatibility setting it is a requirement that it was deliberately exploited. And if such a map existed back then I think we'd know about it by now.

Don't forget that only teleporters, the retriggerable door open and lower lift functions are subject to the quirk. Ignoring one-time teleportes (which would break the teleporter if such a projectile entered it, which is a genuine and valid concern), the worst that could happen is that some passage gets prematurely opened, releasing or alerting some monsters before they are supposed to.

Share this post


Link to post

Hmm...this could be exploited in a map where you have to "protect" a target from being hit by monster attacks, even by taking damage yourself if need be, as long as this was clearly indicated (e.g. if a "portal" is struck by monsters, not only does it becomes inoperable, but some walls rising/dropping indicate that it's now "broken". Of course, this shouldn't leave the map unwinnable (IMO, that's the biggest flaw a Doom map can have, no matter how/why it is achieved).

Share this post


Link to post
Maes said:

Four words: The Sky May Be /winsthread

That was what I was alluding to with the second line. It has a door with a "do not open" texture and changed the crash message to "told ya so" or something to that effect. Therefore, playing it in a limit-removing port breaks the experience intended by the author and that means that every limit-removing port should be expunged from the Earth as the vile blasphemy they are.

Graf Zahl said:

Don't forget that only teleporters, the retriggerable door open and lower lift functions are subject to the quirk.

No, it's the unretriggerable door open that's subject to the quirk.

  • 4: W1 Door
  • 10: W1 Lift Also Monsters
  • 39: W1 Teleport
  • 88: WR Lift Also Monsters
  • 97: WR Teleport
  • 125: W1 Teleport Monsters Only
  • 126: WR Teleport Monsters Only
So it can break four of the eight effects, and that includes a door, a lift, and a teleport that the player may require to move forward.

The bug is also present in Heretic where it affects the door and the teleports. (The lift and monster teleport linetypes aren't present in Heretic.)

Share this post


Link to post

As esselfortium asked, can this behaviour be emulated by modifying DECORATE? I suppose doing this is better than trying to block ZDoom from running the map.

Share this post


Link to post
printz said:

As esselfortium asked, can this behaviour be emulated by modifying DECORATE? I suppose doing this is better than trying to block ZDoom from running the map.


i would think so

Share this post


Link to post
printz said:

As esselfortium asked, can this behaviour be emulated by modifying DECORATE? I suppose doing this is better than trying to block ZDoom from running the map.


If you give the projectile the +ACTIVATEMCROSS flag and clear -NOTELEPORT it should be able to activate monster lines, provided that it won't get excluded by some other check I don't know of.

Gez said:

  • 4: W1 Door
  • 10: W1 Lift Also Monsters
  • 39: W1 Teleport
  • 88: WR Lift Also Monsters
  • 97: WR Teleport
  • 125: W1 Teleport Monsters Only
  • 126: WR Teleport Monsters Only
So it can break four of the eight effects, and that includes a door, a lift, and a teleport that the player may require to move forward.


Even worse. And even more reason not to have the behavior on by default. The chance of this breaking a map is magnitudes higher than some odd map out there being broken by not having it.


Gez said:

The bug is also present in Heretic where it affects the door and the teleports. (The lift and monster teleport linetypes aren't present in Heretic.)


Only the door. AFAIK all projectiles in Heretic have MF2_NOTELEPORT set which excludes those lines.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...