The Last Sanctuary [on /idgames]

Port: MBF-compatible, prboom+/glboom+/zdoom are recommended.
If you're playing under GZDoom, download the latest build from http://devbuilds.drdteam.org/gzdoom!
If you're playing under glboom+, download the latest build!
map01, complevel 11, doom2.wad

A large (63549 linedefs) map for First-Try Demo Contest #16, which was held at 10.31.2015 14:00 UTC. The archive contains demo files for 15 contest participants and table with results, located in "fdc16" subdirectory.

The demo files have been corrected to run properly with this version of wad (skill 2 instead of skill 4)

It is recommended to use "Hey, not too rough" (contest difficulty) or "Hurt me plenty" for first walkthrough. "Ultra-Violence!" for hardcore players only!

Thanks to skepticist and Da Werecat for beta-testing.

Screenshots:

You could download UV-MAX demo from skepticist here.

Download from idgames archive

Post comments, demos, letsplays...

I watched some of the competition demos and already love this map. Congratulations on the release!

from the screenshots looks impressive!

Is there a possibility of you making a fix for zandronum multiplayer? The rendering is broken in there too.
From what I played until the outdoors part, this is mighty impressive and a really good map! Thanks for this :)

Ven
I haven't managed out how to fix this bug in OpenGL mode. It works perfectly in software mode, so switch to it in Zandronum, and you'll be able to continue. Although it's recommended to play in PRBoom+/GLBoom+ for better gameplay experience.

God I love that palette

I've updated link to idgames archive.

I know it's too late, but just for the record, I encountered four problems while playing in Zdoom 2.8pre-1805:

-If you raise stairs in front of door (sector 4778) and then drop into the secret (sector 6488) from above corridor (sector 6367), you will become stuck inside.

-Misaligned textures on some short linedefs around first acid room (sector 6221).

-Zdoom produces some warnings when the map loads:

Unknown middle texture 'CINVMAP' on first side of linedef 32193
Unknown middle texture 'CINVMAP' on first side of linedef 32194
Unknown middle texture 'CINVMAP' on first side of linedef 32195
Unknown middle texture 'CINVMAP' on first side of linedef 32197
Unknown middle texture 'CINVMAP' on first side of linedef 32198
Unknown middle texture 'CINVMAP' on first side of linedef 32199
Unknown middle texture 'CINVMAP' on first side of linedef 32204
Unknown middle texture 'CINVMAP' on first side of linedef 32205
Unknown middle texture 'CINVMAP' on first side of linedef 32206
Unknown middle texture 'CINVMAP' on first side of linedef 32207
Unknown middle texture 'CINVMAP' on first side of linedef 32209
Unknown middle texture 'CINVMAP' on first side of linedef 32210
Unknown middle texture 'CINVMAP' on first side of linedef 32211
Unknown middle texture 'CINVMAP' on first side of linedef 32212
Unknown middle texture 'CINVMAP' on first side of linedef 32214
Unknown middle texture 'CINVMAP' on first side of linedef 32215
Unknown middle texture 'CINVMAP' on first side of linedef 32216
Unknown middle texture 'CINVMAP' on first side of linedef 32217
Unknown middle texture 'CINVMAP' on first side of linedef 32218
Unknown middle texture 'CINVMAP' on first side of linedef 32219
Missing texture 'CINVMAP' is used 2 more times

-However, the biggest drawback of the map were ammo shortages, mainly in the tech part. Then I got unlucky with pain elementals when I got outside - two of them were hurt by some random lost souls and they flew up high into the hills, spewing dozens more lost souls before I managed to kill them. I completely run out of ammo because of that and couldn't kill chaingunners sniping me in the canyons. I got so annoyed by then I simply used IDFA. After that, I blasted through the map without big problems, using only ammo provided. Oh well, another day, another ruined experience.

Wow! Impressive map. Actually I still have to finish it, I'm a bit lost in the marble temple areas :P but I really like it so far.

review is up. this was a pretty cool adventure-style level. the night / day MBF cycle blew my mind the first time I saw it.

kmxexii said:

review is up. this was a pretty cool adventure-style level. the night / day MBF cycle blew my mind the first time I saw it.

Thanks for review. Let me blow your mind once more : the night/day cycle is completely Boom effect :)

cybermind said:

Thanks for review. Let me blow your mind once more : the night/day cycle is completely Boom effect :)

even cooler.

I notice you've put some ACS in it, supposedly some "Compatibility scripts for ZDoom". However, you forgot to mark these scripts as being part of a library. The result is that if anyone loads it along with some ACS stuff (for example, I have Jimmy's Jukebox in my autoload so that I can get more music if I hear D_RUNNIN when loading a map) then the scripts will become completely broken.

Putting #library "ZDCOMPAT" before #include "zcommon.acs" and recompiling is all that is needed to fix this problem.

At the same time, I'm not sure this is even needed. If PrBoom+ doesn't need it, ZDoom shouldn't need it either. If something doesn't work on ZDoom, it's a bug that ought to be reported instead of worked around. Likewise for the xlat, which I find puzzling: the sky transfer is replaced by an autosave, and skies are instead changed by script. ??? Line types 74 and 77, which normally deal with crushers, will instead give (or stop giving) health and armor bonuses if the tag is 160 or 164. ??????

Finally, the warnings about unknown textures: it seems ZDoom is smart enough not to complain about use of a colormap when the texture is used on a Transfer Heights line (no warnings for lines 32191 and 32192, which have type 242) so it wouldn't be a bad idea to fix them. I know they're only on lines that will not be shown in normal gameplay anyway, but getting rid of warnings is always a good thing.

Gez said:

Likewise for the xlat, which I find puzzling: the sky transfer is replaced by an autosave, and skies are instead changed by script.

Because ZDoom handles all rendering routines (including texture animations done by ANIMDEFS and ANIMATED) in separate parallel thread.

ZDoom ANIMDEFS page said:

texture animations are controlled by the renderer timer instead of the play timer, which allows them finer accuracy.

Vanilla MBF and derivatives handle everything in single thread, so sky animation done by ANIMATED and voodoo dolls responsible for ambient light change remain synced. In ZDoom, pausing the game logic thread (pressing ESC in enough) will make sky animation go out of sync. Thus, I've moved out sky animation out of rendering thread by changing it in game thread by ACS. As for autosave - I don't know if xlat is able to nullify action type, so I've chosen the first placeholder action I've found. Autosave replaces 271 action (sky transfer) so ACS sky cycle will replace ANIMATED cycle.
It's obvious that ZDoom won't change it just for this WAD and get a bunch of other WADs broken, so I've made a workaround.

Gez said:

Line types 74 and 77, which normally deal with crushers, will instead give (or stop giving) health and armor bonuses if the tag is 160 or 164.

The same problem as in my MBF Invasion - incomplete MBF support. These tagged crushers are responsible for regeneration cabins. The crushers crush dummy things that spawn health and armor bonuses (Spawn codepointer) and respawn after a while (another Spawn codepointer). This does not work in ZDoom because of unknown reason. So, here goes another ACS workaround.

Hey, I can use such approach to fix GZDoom rendering of outdoor areas (currently GZDoom does not render outdoor areas at all) and move out all voodoo doll logic into ACS scripts (and this will fix broken Eternity Engine rendering too, as it supports ACS)

Well, maybe in future I will re-release this WAD with GZDoom/EE fix and warnings removed.

cybermind said:

As for autosave - I don't know if xlat is able to nullify action type, so I've chosen the first placeholder action I've found.

Yes, it's able.

cybermind said:

These tagged crushers are responsible for regeneration cabins. The crushers crush dummy things that spawn health and armor bonuses (Spawn codepointer) and respawn after a while (another Spawn codepointer).

Thanks for the explanation. I haven't had the time to play through the map "normally" yet (instead of kill monsters + idkfa + rush to outdoor area). I'll try looking into the Spawn failures.

271 = 0, 0 ()

cybermind said:

Hey, I can use such approach to fix GZDoom rendering of outdoor areas (currently GZDoom does not render outdoor areas at all)

Yeah I've tried to see what the problem in GZDoom was, but I just got crashes whenever the level finished loading. So I figure out I'd debug GZDoom myself to find where it crashes, and so I compile it, and upon compiling the current development version I get no crashes and this is how it renders currently:

cybermind said:

Vanilla MBF and derivatives handle everything in single thread, so sky animation done by ANIMATED and voodoo dolls responsible for ambient light change remain synced. In ZDoom, pausing the game logic thread (pressing ESC in enough) will make sky animation go out of sync. Thus, I've moved out sky animation out of rendering thread by changing it in game thread by ACS. As for autosave - I don't know if xlat is able to nullify action type, so I've chosen the first placeholder action I've found. Autosave replaces 271 action (sky transfer) so ACS sky cycle will replace ANIMATED cycle.
It's obvious that ZDoom won't change it just for this WAD and get a bunch of other WADs broken, so I've made a workaround.

Since the animation state is never saved in any port, there is no guarantee this will remain synced in the other ports as well. Just one save/reload action should be enough to break sync.

That's the reason why ZDoom doesn't bother with this.

Gez said:

upon compiling the current development version I get no crashes and this is how it renders currently

Cool, I could confirm it too. I see some skybox-related changes in GZDoom code after release of The Last Sanctuary, so they maybe have fixed that bug. You could quickly observe this bug by downloading gzdoom-g2.1.pre-1354-gad6ce5a.7z from devbuilds, dated Nov 09 2015 20:01:12.
So, the only port which needs fixing is Eternity Engine, still i haven't got any reports about my issue.

Graf Zahl said:

Since the animation state is never saved in any port, there is no guarantee this will remain synced in the other ports as well. Just one save/reload action should be enough to break sync.

That's the reason why ZDoom doesn't bother with this.

I remember that Da Werecat (one of my testers) reported that sky have gone out of sync in PrBoom+ after he have played several hours using saves, but I haven't put too much attention on that. Well, that's a pity, however, I made this WAD for FDC#16 event, where participants were disallowed to use saves at all.

cybermind said:

Cool, I could confirm it too. I see some skybox-related changes in GZDoom code after release of The Last Sanctuary, so they maybe have fixed that bug.

No. I fixed that bug when I saw it broken in your map. It's the first time I ever saw a map using the upper part of a Boom-242 sector with a sky above the normal part, and that simply was broken due to lack of testing material.