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


  • Content count

  • Joined

  • Last visited

About wrkq

  • Rank
    Warming Up

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Are you perchance using a stairbuilder somewhere nearby? Or any other "copy sector trait to another sector" action? https://doomwiki.org/wiki/Stairs_create_unknown_sector_types Edit: *FACEPALM* so I can download it and look, right? So your walkover trigger (line#789) affects the outer bookcase (sector#90) with special#37 "floor to lowest adjacent floor, change texture and type". Sounds pretty darn probable that this somehow sets the sector-type to garbage value under some circumstances. I am nowhere near good enough to tell you where this would read bad value from, as the lowest adjacent sector, the floor, seems to be of normal type. Maybe there's some subtle bug somewhere else corrupting memory, or your editor left some garbage in the sector data that SLADE does not pick up, and I ain't fluent at reading the raw hex data. But maybe you could try just to change that special to #38 "floor to lowest without changing"? It doesn't quite sound right for the top-of-bookcase to change texture as it lowers, *and* it already has the same flats as the surrounding floor sector anyway!
  2. wrkq

    The Official 'Trying to Find a Specific WAD' Thread

    Big thanks, @Keyboard_Doomer & @kmxexii :)
  3. wrkq

    The Official 'Trying to Find a Specific WAD' Thread

    Hey folks. So @EANB over in the TADYJF thread has a vague memory of a map that did abuse the MAP30 monster telestomp hack: https://www.doomworld.com/forum/topic/57270-things-about-doom-you-just-found-out/?do=findComment&comment=2014057 A peek at HR's MAP30 says that it wasn't it, but some other WAD. Does it ring a bell for anyone?
  4. wrkq

    Things about Doom you just found out

    @Graf Zahl, you know it better than most that "if there's some way to abuse an engine quirk, some mapper did it"... And @EANB mentioned such map at the top of page. If we'd have a more solid lead as of to what that map was (sure doesn't look to be HR) we could try and find out how royally it breaks without the telestomp hack...
  5. wrkq

    Things about Doom you just found out

    Good point, I apologize. Tbh, it does seem these two made their way to Hell somehow, so that's pretty significant - just still insufficient - level of badassery. Or maybe they're part of one of the secret UAC expeditions before shit hit the fan on the moons of Mars. Especially that would explain the availability of weapon drops in E3...
  6. wrkq

    Things about Doom you just found out

    Yeah, the way to do equivalent of this in vanilla would have to be, like, have a global variable (eg spawnfly_teleport) then have A_SpawnFly() do { spawnfly_teleport = 1; P_TeleportMove(blah); spawnfly_teleport = 0 } and have PIT_StompThing() look for that variable instead of map number. But that's already edits in multiple places (and probably like five or more because you also need to initialize that gvar on game start, map start, load savegame, etc). Alternatively you'd have to change calling convention for multiple common functions to pass a special parameter to allow stomping, or "manually" implement the whole "scan and kill" routine inside A_SpawnFly() or something. The original hack is a one-line change not requiring support from rest of the code, so easy to see why they went for that :)
  7. wrkq

    Things about Doom you just found out

    I mean... if Vavoom rewrote this to have the floating cube check for obstructions in the spawn destination, kill everything in there if needed, then spawn the monster, that's objectively better solution from every PoV except compatibility with someone's mega clever map which would somehow require monsters to telefrag each other for progression. It's just not what was hacked into vanilla as a very narrow scoped solution to very narrow scoped problem in ten minutes in 1994. "Oh shit, guys? I put some debug prints, and the crash with the new boss map happens because when the ground's occupied the cube can't put a monster on the ground, and leaves the mobj structure in invalid coordinates. How can I cancel the spawned monster?" "You can't, we never needed that... you'd need to clean up all the references manually... wait, you said the ground's occupied? Do we have any teleports in that room?" "No, only the one from starting room to boss room." "Fuck it... just add an exception for the map in the teleport stomp check and don't waste more time on it."
  8. wrkq

    Things about Doom you just found out

    Not true. The flying cube-spawner creates a new monster then uses P_TeleportMove to put it in place, so technically it's that monster which steps on top of player (or another monster). https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_enemy.c#L1986 P_TeleportMove checks for mobs in the destination area via P_BlockThingsIterator+PIT_StompThing. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_map.c#L162 PIT_StompThing has a safety check - players can telefrag on any map, monsters can telefrag only on MAP30. https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_map.c#L101 So if you make a vanilla wad with a MAP30 which includes "standard" teleporters the monsters could step on, they will telefrag a player (or another monster) at teleport destination. Thinking about it, if not for this check that makes teleports simply "not work" for occupied destinations anywhere outside of MAP30, the typical sound-triggered monster teleport traps would result in majority of the mobs just telefragging each other leaving the player with few to deal with. So the MAP30 exception was yet another last minute hack(tm) because otherwise they'd have to care to move or otherwise cancel-spawning of a monster from the cube. Vanilla MAP30 has no walkable teleports in the big room so the downside was irrelevant. I've heard that theory before. My guess is that we're neither - after all according to the plot Doomguy was stuck guarding the ship while rest of the marines were being slaughtered by demons, and he moved in only after they were all dead. So that'd be two of the Nameless Wimpy Marines. Explains the green armor (unlike Multiplayerguys.)
  9. 0_0 Well, I'm kinda honoured you liked my random "would be fun" comment this much! I have to say that's some really nice concept work, Mister Rocket, sir... the final logo version with the gold plate in the background almost asks to be put on a ribbon and attached to a uniform now.
  10. ... with crossed shotgun and chainsaw inlaid in gold on it?
  11. wrkq

    Things about Doom you just found out

    Yeah, id was always using sound tunnels and similar stuff. That's because id's DoomEd operated on an intermediate map-definition file (DWD), and official DoomBSP was not just a nodebuilder, but a much more thorough "map compiler". That map format editor didn't even have an explicit "sector" concept - just one and two-sided lines floodfilling their traits into the area between them. A lot of the quirks/bugs/"*cough* implementation details" discovered by the mapping community tinkering with the binary map format in the WADs were literally "unreachable" via the official tools. Doomwiki.org has a couple of notes on that - look up "DWD" and "DoomEd" once it's recovered from the current database failure message. I'd post links if not for that.
  12. Hey guys, I'm no Doom code guru, but looking at The Old Testament original source... ... uh, in retrospect I am full of regret. Near the end of P_SpawnSpecials() there's a section initializing sector special effects, and type 17 calls P_SpawnFireFlicker(): https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_spec.c#L1328 case 17: P_SpawnFireFlicker(sector); break; In the interesting part of P_SpawnFireFlicker we can see: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_lights.c#L80 flick->thinker.function.acp1 = (actionf_p1) T_FireFlicker; flick->sector = sector; flick->maxlight = sector->lightlevel; flick->minlight = P_FindMinSurroundingLight(sector,sector->lightlevel)+16; flick->count = 4; So, we set up the T_FireFlicker() thinker. Max light is always the starting light level of the sector, min light is "whatever P_FindMinSurroundingLight() returns plus 16". The light level search is here, not quite attractive to quote code bits, but if there's no surrounding sector with lower level, it'll return the second parameter - so our flickering sector's starting light level. https://github.com/id-Software/DOOM/blob/77735c3ff0772609e9c8d29e3ce2ab42ff54d20b/linuxdoom-1.10/p_spec.c#L454 So, uhhhh... that means that if all surrounding sectors are brighter or the same then maxlight is flickering sector's starting level, and minlight is flickering sector's starting level + 16. So, maxlight < minlight. We can also get maxlight < minlight if there's no surrounding sector darker by more than 16. And finally we can't get perfect black, minlight is always at least 16. I need aspirin... Now the T_FireFlicker thinker itself is here: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_lights.c#L46 The interesting part goes like this. amount = (P_Random()&3)*16; if (flick->sector->lightlevel - amount < flick->minlight) flick->sector->lightlevel = flick->minlight; else flick->sector->lightlevel = flick->maxlight - amount; ... okay, screw aspirin, that calls for rum. First we roll the dimmness amount. 0/16/32/48 possible. Then check if current light level minus the amount would end up below the minlight level. That can be "always true" for the cases where maxlight < minlight as above. In that case just reset to minlight (possibly our original+16). Otherwise, take the rolled amount and subtract it from maxlight (the original level). I'm absolutely unable to guess whether these checks are a bug-that's-a-feature or deliberately asymmetrical... TL;DR I think this is how it works... 1. If out of the whole list of neighbors and self, nothing is darker by more than 16 Mostly stuck at ((darkest sector found, which may be self)+16) level, which is the brighter state. 1-in-4 chance to switch to (original) level, which is the darker state, but will always switch back to brighter state on next roll. 2. A neighbor darker by exactly 16 exists Permanently stuck at (neighbor+16) level - which happens to also be the same as (original). 3. A neighbor darker by 17-32 exists Roll 1d4, choose from: (original) (neighbor+16) (neighbor+16) (neighbor+16) 4. A neighbor darker by 33-48 exists Roll 1d4, choose from: (original) (original-16) (neighbor+16) (neighbor+16) 5. A neighbor darker by 49-64 exists Roll 1d4, choose from: (original) (original-16) (original-32) (neighbor+16) 6. A neighbor darker by >64 exists Roll 1d4, choose from: (original) (original-16) (original-32) (original-48)
  13. Hm. I wonder, how hard would it be to make it Do The Right Thing, that is install if unambiguous, but ask otherwise. Consider:
  14. thanks too many e's lol