Things about Doom you just found out

[drygnfyre]

13 hours ago, Angry Saint said:

TIL At one point in development, the Spider Mastermind was going to have a magic attack that likely would've held the player in place, leaving them vulnerable to the demon's normal chaingun attack. This is a frame for it. Sorry if someone already posted.

 

 

but actually a spiderdemon magic attack similar to the archvile one would be interesting...

I read this was canned because the developers couldn't decide on exactly what the attack would do. I feel like if nothing else, just have it launch fireballs or something. It could have been implemented that way.

 

Given these frames exist, would it be possible to recreate this magic attack?

[kb1]

On 4/24/2017 at 0:13 AM, axdoomer said:

Today I have found out that a hitscan error occurs on E3M6. When you shoot through the air, bullets can get blocked. See this video. It previously saw it occurred on Doom 2 map12, but the cause seemed more obvious because it occurred along the four long walls which make the square box of the map. 

 

 

Seems like it's caused by the linedef #0 which is duplicated to another location on the map. I have drawn a green line where I know it occurs. Seems like Doom as some trouble checking hitscan collisions against long linedefs and it moves the linedef somewhere else. It may be an overflow. It happens more frequently when linedef #0 is too long because the engine always check for collisions against this linedef due to a bug. 

 

 

I've updated the DoomWiki article, but it may not be displayed yet because it needs to be approved by an admin first. (I forgot to login, so the changes were made as an anonymous user) 

This is that node builder bug that, since forever, incorrectly adds linedef #0 into all the nodes. This is further complicated by the fact that, fixing the modebuilders and trying to play a map built with fixed nodebuilders craps out Boom/MBF ports because Lee added code that tosses out the first line of every node without checking! (Can anyone find the link to that new nodebuilder - I cannot remember the name of it. Thanks).

[Quasar]

12 minutes ago, kb1 said:

This is that node builder bug that, since forever, incorrectly adds linedef #0 into all the nodes.

Blockmap blocks, not nodes.

[Arctangent]

2 hours ago, drygnfyre said:

I read this was canned because the developers couldn't decide on exactly what the attack would do. I feel like if nothing else, just have it launch fireballs or something. It could have been implemented that way.

I dunno why so many people feel compelled to implement everything at all cost, even if there's barely anything to them. There's usually reasons why stuff is canned, and even if those reasons are "lack of disc space" or "time constraints," you usually cut low-priority or underdeveloped features when you're crammed for space or time.

 

Exactly what would a secondary fireball attack even do for the mastermind, aside from making her an even more underwhelming fight due to you not even having to worry about her hitscans half the time? Y'know, the reason why she's a threat at all?

[printz]

Heh. That post also quotes the spiderdemon potentially having a stun attack. You can already do it in Doom 1 Dehacked by using the archvile fire attack and modifying the flash to be solid. The player will be held in place by the solid thing, until running backwards fast enough to escape.

[Arctangent]

I wouldn't be surprised if the "held in place" idea was dropped because they couldn't figure out a way that didn't feel unfun or unfitting for what they were going for. Especially if they also couldn't figure out a good way to communicate that you're being held in place, instead of, say, your keyboard suddenly failing.

 

Also might've had something to do with the lack of multiple attacks in general. Doom 1 enemies only really had one attack, unless I'm forgetting something - the melee attacks aren't actually distinguishable in the slightest from the missile attacks, as they're actually the exact same and the actual "attack" code pointer deals with deciding whether to launch a projectile or deal instant damage. It's hard to say that this is due to limitations, considering Doom 2's revenant shows that the melee and missile attacks being distinct isn't too difficult and most Raven monsters with multiple missile attacks don't exactly do anything more exotic than a code pointer that jumps to randomly decided state out of a set. Between that and the overall simplicity and same-yness of the Doom 1 bestiary, I don't think it's a stretch to say that that simplicity was the goal.

 

I mean, dealing with height already made the game far more complex than a lot of games their audience would've had experience with. Making what the monsters attack with predictable and easily learnable is a courtesy that doesn't seem out of place in the slightest.

Edited April 29, 2017 by Arctangent

[jerk-o]

On 4/28/2017 at 6:23 PM, kb1 said:

This is that node builder bug that, since forever, incorrectly adds linedef #0 into all the nodes. This is further complicated by the fact that, fixing the modebuilders and trying to play a map built with fixed nodebuilders craps out Boom/MBF ports because Lee added code that tosses out the first line of every node without checking! (Can anyone find the link to that new nodebuilder - I cannot remember the name of it. Thanks).

Zokumbsp

[riderr3]

Boom 2.01 have bug (or feature) when player can pull switches from other side if the sector between exists.

Found this when I changing my maps format to Boom. Because I'm set complevel 8 instead of proper 9.

Edited May 5, 2017 by riderr3

[zokum]

The nodebuilder you are talking about is indeed ZokumBSP. It's fully ZenNode compatible, but provides smaller sized blockmaps in just about every case. There's loads of blockmap theory, case studies and other information on the project web page, http://doom2.net/zokum/zokumbsp/

You can use this tool to do some special effects I don't think any other tools can let you do. As always, send me a msg on irc if you got any questions.

[kb1]

On 4/28/2017 at 9:36 PM, Quasar said:

Blockmap blocks, not nodes.

 

On 5/1/2017 at 1:54 PM, jerk-o said:

Zokumbsp

 

3 hours ago, zokum said:

The nodebuilder you are talking about is indeed ZokumBSP. It's fully ZenNode compatible, but provides smaller sized blockmaps in just about every case. There's loads of blockmap theory, case studies and other information on the project web page, http://doom2.net/zokum/zokumbsp/

You can use this tool to do some special effects I don't think any other tools can let you do. As always, send me a msg on irc if you got any questions.

Right - Blockmap, of course. I'm adding the suggestion to fix this into the Boom+ standard, which, if we're lucky, will clean up this issue most everywhere.

[Albertoni]

7 hours ago, zokum said:

You can use this tool to do some special effects I don't think any other tools can let you do. As always, send me a msg on irc if you got any questions.

- Linedefs with tag 998 will not be added to BSP tree, ie not rendered.

 

The potential uses of this heavily intrigue me, but shouldn't that be a command line option? I can see this breaking a few maps.

[kb1]

24 minutes ago, Albertoni said:

- Linedefs with tag 998 will not be added to BSP tree, ie not rendered.

 

The potential uses of this heavily intrigue me, but shouldn't that be a command line option? I can see this breaking a few maps.

Well, it would only break maps that have used ZokumBSP with the option to remove the #0 lines, which would not play in said ports correctly anyway, right? If it gets fixed quickly, problem solved, cause maps without the 0 lines won't play properly anyway. It may be a good case for a complevel, simply to support the playing of a demo of a broken game, but that sucks :)

[zokum]

The use of tag 998 will only matter if you rebuild the map with ZokumBSP. It has nothing to do with the linedef #0 switch in the blockmap builder part. These are two distinct matters.

 

I chose tags 998 and 999 since I figured it would be an easy way to add support for this in most editors out there without interfering with existing maps. If a map is already using these tags and you want to rebuild it, simply 'retag' those tags. For those of you wanting to build big maps that are vanilla compatible, tag 999 can make your life a LOT easier. The numbers are inspired by id's tag 666 and 667. :)

 

I really hope most ports will fix the faulty skip-first-linedef optimization, I know Eternity has a fix for the problem. Chocolate and vanilla Doom doesn't have any problems of course.

[RjY]

@zokum BSP (the original, by Colin Reed, Killough, et al, and now maintained by cph) uses tags >= 900, and 999 in particular, for its own purposes (see "special effects" in the second link). It is perhaps unlikely to matter in practical terms, as I don't know if BSP is still used much, but just in case you weren't aware.

[zokum]

13 hours ago, RjY said:

@zokum BSP (the original, by Colin Reed, Killough, et al, and now maintained by cph) uses tags >= 900, and 999 in particular, for its own purposes (see "special effects" in the second link). It is perhaps unlikely to matter in practical terms, as I don't know if BSP is still used much, but just in case you weren't aware.

I think BSP is still pretty widely used. I am aware of the 900+ tag meaning special lines. I don't think it should be a problem. I might see if I can't add a similar option of try-not-to-split lines tagged with a certain tag, but I am unsure how often this was used.

[esselfortium]

14 minutes ago, zokum said:

I think BSP is still pretty widely used. I am aware of the 900+ tag meaning special lines. I don't think it should be a problem. I might see if I can't add a similar option of try-not-to-split lines tagged with a certain tag, but I am unsure how often this was used.

Most sourceports don't support it, and I've never seen it used in an actual map. I wouldn't worry about it too much. 

 

Edit: Lol I'm an idiot and didn't read. I was thinking of another BSP tagging hack that rotated segs for weird hall of mirrors effects.

[RjY]

13 hours ago, zokum said:

I might see if I can't add a similar option of try-not-to-split lines tagged with a certain tag, but I am unsure how often this was used.

FWIW I used it once, in a map for which I was already using bsp for the hom-free transparent door effect. Tag 900+ seemed to eliminate some slime trails on some overly fiddly overlapping floor/ceiling detail (circular ceiling light over a curve on the floor didn't mix well). But this was years ago and I'd likely do things differently now (in particular I'd avoid that kind of tiny linedef detailing, it's just not worth the bother)

 

[galileo31dos01]

This is a bug related to 3D bridges, I assume others already know this but it's the first time I've seen it:

 

 

As seen in the video, passing through that invisible wall made it disappear, and rockets were not blocked anymore. 

Just sharing...

[Empyre]

I know that map. There is an invisible sector that raises up so you can walk on the bridge, and it lowers down so you can walk under it. When you approached it to walk under it, the floor lowered so you could walk under it. If you approach it from the other way to walk over the bridge, it will raise up so you can cross the bridge. When it is up, it will block the rockets. It is not a bug, but a unavoidable side effect of a clever map design.

[galileo31dos01]

2 hours ago, Empyre said:

I know that map. There is an invisible sector that raises up so you can walk on the bridge, and it lowers down so you can walk under it. When you approached it to walk under it, the floor lowered so you could walk under it. If you approach it from the other way to walk over the bridge, it will raise up so you can cross the bridge. When it is up, it will block the rockets. It is not a bug, but a unavoidable side effect of a clever map design.

Oh ok, that also explains other similar situations with 3D bridges and invisible walls in other wads that I've seen. Not the "side effect" but the usage of those things. 

[Alfonzo]

The size of the blood splat sprites is determined by the damage you inflict on the monster/player.

[damerell]

21 minutes ago, Alfonzo said:

The size of the blood splat sprites is determined by the damage you inflict on the monster/player.

I didn't know that either! The aim of providing feedback on damage caused (as the Wiki has it) seems to have fallen flat, though, since 99% of the splats you see will be produced by your own pistol, chaingun, or shotgun projectiles, all of which of course do the same range of damage.

[scifista42]

^ Same range of damage, yes, but each particular hit deals either 5 damage (producing a little blood splat), 10 damage (producing a medium sized blood splat), or 15 damage (producing a big blood splat). So, the blood size isn't indicative of what weapon you use, but of how much damage a particular shot deals, which is the right spirit.

[roadworx]

4 hours ago, Alfonzo said:

The size of the blood splat sprites is determined by the damage you inflict on the monster/player.

huh. i never knew or noticed that.

[Cruduxy Pegg]

It is easier to notice with lower fps as well.

[damerell]

9 hours ago, scifista42 said:

^ Same range of damage, yes, but each particular hit deals either 5 damage (producing a little blood splat), 10 damage (producing a medium sized blood splat), or 15 damage (producing a big blood splat). So, the blood size isn't indicative of what weapon you use, but of how much damage a particular shot deals, which is the right spirit.

I know. All I'm saying is that since every splat is from the same damage range, the player doesn't really get any information about relative weapon effectiveness.

[Rathori]

I just found out that hitscanners' shots are automatically aimed up or down if there are other enemies between them and whatever they're shooting at (unlike projectile-based enemies, who can shoot wherever the hell they like, it seems), which is very useful for infighting and general danger assessment.

Edited May 16, 2017 by Rathori

[42PercentHealth]

Some recent use of the terms "SR40" and "SR50" sent me to doomwiki.org to see what they meant. I had no idea that there were two straferunning speeds! I also had no idea that lateral movement was slower than forward/backward movement, so I learned that the SR40 speed (which is the only one I've ever used) is not a 41% increase, but only a 28% increase.

 

Might have to re-map some keys, and play with SR50 for a bit... :-P

[Nine Inch Heels]

10 minutes ago, 42PercentHealth said:

Some recent use of the terms "SR40" and "SR50" sent me to doomwiki.org to see what they meant. I had no idea that there were two straferunning speeds! I also had no idea that lateral movement was slower than forward/backward movement, so I learned that the SR40 speed (which is the only one I've ever used) is not a 41% increase, but only a 28% increase.

 

Might have to re-map some keys, and play with SR50 for a bit... :-P

 

[42PercentHealth]

@Nine Inch Heels Yup, that's the "recent use" of those terms I was talking about. :-)

 

FTR, I don't intend to use any cheats -- just want to see if I can make any use of a faster straferun.