Jump to content

Ultimate Doom "In Name Only" - On IDgames


Recommended Posts

I've just about finished with all the automap edits for the whole megawad, which has taken a surprisingly long time but will hopefully be worth it.

 

For those that don't know what that means: I aim to make the automaps as clean and readable, so the player spends as little time as possible being lost. That means removing unnecessary ceiling markings, outdoor scenery, and rendering any place unreachable to the player as invisible. Here's some examples of my edits, with the original on the left and my refinement on the right:

 

E3M7

UDINOautomap1.jpg

 

E1M2

UDINOautomap2.jpg

 

E2M8

UDINOautomap3.jpg


You can see how basically any corridor-centric map stays mostly the same while outdoor zones have considerably less detail cluttering the screen. I find the simplicity pleasing, and it's definitely something I'm going to be doing for all my maps from here on out.

Share this post


Link to post
  • 3 weeks later...

Congrats team! I'll play and savour it again once I've finished my own project for a change.

Share this post


Link to post

Let me just say: 

Spoiler

E1M7 turned my world upside-down. Masterpiece level work all around, but that one ranks among my top 5 WTF moments in Doom.

Congrats on the final release!

Edited by omnibot
Added spoiler tag

Share this post


Link to post

https://www.mediafire.com/file/0fupzxlmqf7llw8/E1M2acq.zip/file

 

I feel like I need to go to the principal's office.

 

It's hard to believe I could have gone through this map so many times and failed to notice what you see here. If you look at the ceiling, there are 3 rectangles of ceil5_2. There are 3 more on the other side of the nukage drip, all corresponding to the lockers below. They're kinda hard to make out, which is probably why this flaw went undiscovered for so long.

 

p1DpEpv.png

 

I noticed that Dobu put in a couple clues for the Green Armor secret in this room. I kept them in, and also changed the armor to a box of rockets, since the armor was a basically useless secret. At least rockets will help the player in the final battle.

 

I offer this as a judgment call. It may not be worth revising the megawad for this trivial issue that nobody ever noticed, but it's here if you want to. 

Share this post


Link to post
9 hours ago, Steve D said:

I offer this as a judgment call. It may not be worth revising the megawad for this trivial issue that nobody ever noticed, but it's here if you want to. 

 

cannonball will take care of any last minute edits. Luckily it's not on /idgames yet!

Share this post


Link to post

I think there's a problem with @Nine Inch Heels's E3M8.

 

If you do the ridiculous secret jump, you're supposed to trigger a bunch of lines, including one with tag 14/action 22. This triggers unpredictable behaviour in complevel 2 because of a particular vanilla limit on the number of adjacent sectors that action can check against. The end result is that some cyberdemons in a closet are supposed to come and teleport into the masses of imps and barons to infight, but don't always do so. This never happened to me when I played the previous versions (I think it was RC2 that I tried it in?) but I think it's always been a problem, I guess I just never triggered it before.

 

Oddly I count fewer than 20 sectors adjacent to the trigger sector, maybe each linedef adds a check? In any case dsda-doom gives me a bunch of warnings:

P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 1567, heightlist index 22: cannot be emulated - unpredictable behaviour.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 1572, heightlist index 23: cannot be emulated - unpredictable behaviour.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 1573, heightlist index 24: cannot be emulated - unpredictable behaviour.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 1579, heightlist index 25: cannot be emulated - unpredictable behaviour.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 1585, heightlist index 26: cannot be emulated - unpredictable behaviour.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 2347, heightlist index 27: cannot be emulated - crash with high probability.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 2354, heightlist index 28: cannot be emulated - crash with high probability.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 2360, heightlist index 29: cannot be emulated - crash with high probability.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
Sector 173, line 2366, heightlist index 30: cannot be emulated - crash with high probability.


I think this could be fixed by changing the linedef action to something else? Or separating some sectors maybe. I can take a crack at it if you guys want.

Share this post


Link to post

I guess I can take a look later. Typical really as I uploaded this to IDgames last night (I was waiting to see whether it cleared checks before posting a temporary link). I guess I will need to reupload this onceI have sorted this.

Edited by cannonball

Share this post


Link to post
2 hours ago, plums said:

Hah good timing, sorry! I'll let you guys handle the fix.

 

Hmm I am left in a bit of an impasse, I have played through this map again in crispy doom and there was no issues with the map and everything worked fine (second time today where I got 100% kills). Given this port is supposed to emulate vanilla outside of the limits of course I am left questioning whether I am risking the complete breakage of the map mechanics to fix a problem that doesn't appear to exist outside of DSDA doom flagging errors. Add to that the map author whilst people can question the fairness of the map is someone who I would expect to have a good handle on the port mechanics (Including more obscure limits and potential issues that can hinder ports, even ones where the limits are raised to the level where there are essentially no limits.

To fix this I would probably need to use more linedef actions to lower the number of sectors used at once, more linedefs probably means altering the design of the secret area (Potentially leaving just a teleporter on the platform, which takes the player to a space outside of the map where all of the linedef actions can be implemented before returning to the playable area of the map). 

Share this post


Link to post

Crispy also flags it in the terminal, though not in a way that suggests it can't handle it:

Sector with more than 22 adjoining sectors. Vanilla will crash here

However reading on this bug/limit it's fairly clear that this error produces undefined behaviour. And any limit-removing port I've tried doesn't raise the sector reliably. (I seem to be able to get it to raise consistently if I inch slowly over the linedefs one at a time, whereas just running over them all usually doesn't raise the sector properly.)

 

100% kills is still possible if the sector doesn't raise properly, it means the cyberdemons on the demon-face flats will keep teleporting in there, instead of in the middle of everything where they're meant to.

 

I'll see if I can find an easy, non-invasive solution. Unfortunately just splitting the sectors doesn't seem to fix the problem (again it raises properly only if I inch over the linedefs), even though the error no longer gets flagged; maybe there's something else going on but I'm not sure what.

Edited by plums

Share this post


Link to post

If I split each of the cyber cubbies up into their own section, DSDA gives me this error:

T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync
 gametic: 631 sector: 173 complevel: 3
T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync
 gametic: 631 sector: 1170 complevel: 3
T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync
 gametic: 631 sector: 1171 complevel: 3
T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync
 gametic: 631 sector: 1172 complevel: 3
T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync
 gametic: 631 sector: 1173 complevel: 3
T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync
 gametic: 631 sector: 1174 complevel: 3

Each of these sectors are where the cyberdemons are

Edited by dobu gabu maru

Share this post


Link to post

Okay I think I have fixed this; Just E3M8 in this download but if noone finds any more issues then this will replace the current E3M8 saved within the main wad and I will reupload to IDgames

https://www.dropbox.com/scl/fi/5b1yigt5nllrjhyz9sje7/E3M8fix.wad?rlkey=i60fpxpo8nxnysu6z9fka5gda&dl=0

The adjoining sectors error is an easy fix (You don't even need to break apart the monster closet, just simply giving each sector with tag 14 its own sector index number does the trick). The issue with this one is because the sectors are merged, it adds every surrounding sector around every piece of that sector, simply making this change reduces the surrounding sectors from 22 to 3 or 4.

To fix the other issue I have simply changed the floor lowering action from 22 to 119, I have no idea why action 119 works and 22 goes strange because the only difference is that action 22 has the "Changes texture" element. 

I tested this in DSDA and got 100% kills with no error messages in the command prompt.

Edited by cannonball

Share this post


Link to post

@cannonball looks good to me! Good work.

 

Linedef action 22 also clears the target sector's type. (For some reason UDB doesn't indicate this in the action's description.) I feel like that might have something to do with it, but that's just a guess.

Share this post


Link to post

EDIT: This is wrong, see my next post.

 

So here's why action 22 doesn't work and 119 does:

 

Action 22 is technically a "platform" action while 119 is a "floor" action. Even though the effect (other than the texture/type change) is the same, they're handled in different parts of the code.

 

For action 22 (and similar platform actions), id didn't initialize some values properly in the code, leading to some undefined behaviour. (It will probably work consistently in the same port, but it's not really portable.) I don't know if it's "safe" to use in situations where you only have one sector to compare to, or not. (Surely people have used this action type before without problems?)

 

Action 119 and other floor actions have a completely different code path, one that lacks this bug.

 

Seems like Entryway (PrBoom+ dev) and others had a lot of fun dealing with this bug, especially regarding demo compatibility.

https://sourceforge.net/p/prboom-plus/bugs/211/

 

Edited by plums

Share this post


Link to post

Gave this a quick spin and IDCLEV, after being mired in '94 wads for the last few days, seeing stuff like Spawning Vats and Unto the Cruel is an eye opener. Lots of great music in there too.

 

(also that automap post at the top of this page, I greatly appreciate clean automaps, I am on record for annoying people for reporting automap errors a lot back in my testing days)

Share this post


Link to post

OK, so the REAL reason why action 22 (platform) doesn't work and 119 (floor) does:

 

Another key difference between platform and floor actions is that, as long as they're not set to crush, a platform will reverse direction if there's a thing preventing it from raising, whereas a floor will just wait until it can move up to it's target destination.

 

THIS is the problem with those platform actions that have undefined behaviour -- they don't set the original height they should lower back down to if they hit something. That's also what the message "T_PlatRaise: raise-and-change type has reversed direction in compatibility mode - may lead to desync" is about (I was reading it wrong before). So those actions are safe to use as long as there's never going to be a thing blocking them from raising.

 

But wait, what's blocking the raise action in the first place? Well it turns out when the other cyberdemons in adjacent sectors are being crushed, it's enough to interfere with the height checks in vanilla/complevel 2. This is true even if the tag 14 sectors have nothing in them. This is why I was able to get the old version of the map to work properly if I inched across the trigger linedefs - the floor of the tag 14 sectors would finish rising before the crushers started. You could *probably* fix this by adding a buffer sector between the crushers and the rising floor sectors -- just making them wider isn't enough from a quick test -- but using action 119 is good enough.

Share this post


Link to post

Well even in these experienced times you get a scenario where you learn something new. Cheers for the research.

 

Here is a new temporary link to the IDgames submission that I hope will go through safely. I will update the thread again once the IDgames link is available.

 

https://www.dropbox.com/scl/fi/4yepngldwlinytmp4dmov/UDINO.zip?rlkey=uylt7u5foszgmgqxbikzd1une&dl=0

 

Share this post


Link to post
8 hours ago, Lingyan203 said:

My guess is that is this going to be going to the /idgames release?

 

Most likely so, but I would wait and see before downloading the current version in case more things come up.

Share this post


Link to post

E1M2 seems to be a bit broken in the latest version. I tried a couple of source ports: Woof and DSDA both crash on load while Eternity reports that "E1M2 not found or is not a valid map".

 

Edit: IDCLEV'd through the rest of the levels to see if the same thing would happen anywhere else and sure enough, E2M7 doesn't start either. The error message DSDA gives is different, though ("There is no ML_SSECTORS lump" vs. E1M2's "no subsectors in level").

Edited by veevil
Additional information

Share this post


Link to post

I’m going to hazard a guess that this is a node builder issue that for some reason occurred when saving the minor changes to both the maps in question. Why this happened now and not at any other time is a matter for the deity of your choice. Oh well I will resave both maps and see if rebuilding the nodes solves this problem. After that I will probably hold onto the file until the IDgames process reaching the email confirmation and then start again.

Sorry about this…

 

Edit - Yes that was the issue and has now been fixed.

Edited by cannonball

Share this post


Link to post

On E2M3 I was able to get into the SW room (with rocket launcher) from the ledge NE of the start, ran across the nukage tubs by straferunning left across them and then got stuck in that room. Took me several tries to replicate it but it is possible and since the north door isn't open I was unable to get out.

Edited by NuMetalManiak

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...