Nevander

That's weird... the middle tower is supposed to be lowering constantly automatically because it's raised into the ceiling by a ton of units, that way the fight will end close to the time the tower lowers far enough. Perhaps the line to trigger it wasn't made with vanilla behavior in mind, because it does work in ZDoom.

I just now added the death messages when you die and wait a bit. Added a few new ones too. When I started the project 2.2.0 was the newest version, so I just stuck with using that. What works in 2.2.0 should work in newer versions, and so far I haven't needed any features from 2.3.2+ ...that is until I update all the maps with gradient lighting, which will need 2.4.0 Doom 64 for Doom 2 is a vanilla project, so it should run on anything. The only reason this or other mods don't work on older versions is because of DECORATE, ACS and sometimes UDMF features. Those require certain pieces of code to be present in the engine, which of course means if it's not there then it won't work. And about the SSG, that's the original flash from Doom 64. It's not edited to be smaller. Unless you meant that it should be bigger in general...

This is most likely because of the way Lightning works. The light level changes from 200-231 and since 255 is the highest it never looks very bright. I'm not sure if I can change this or make the entire level flash at 255 but what I might could do is change the light level inside the skybox and then change it back after the lightning effect happens to make the effect more obvious. I'll try some things.

It should at least run in 1.8.6, but it's being designed and tested on 2.2.0 Some things will not work properly though, such as: - Sectors with multiple tags, only the first tag gets used on older versions. To counter this, I am making sure that the more important action is the first tag. So for example you'd get stairs rising but no flashing lights. On newer versions you'll get both as you should. - Pixelratio MAPINFO property. Not sure what version added support for this property, but I know that 2.0.05 does not support it, and so older versions will not either. This doesn't affect gameplay and it still runs fine. There may be more, but I know of these two. Once I add proper Doom 64 lighting to all maps, they will then require 2.4.0 or whatever official release version includes it. The first release of this however will be compatible with these older versions (I hope). Once I am finished with everything, I will find the minimum version requirement and post it on the OP. I am pretty sure it will run with 1.8.6 though for now.

Yes, the new episode I am making was something I myself was also going to do. However, don't let that discourage anyone else. It's actually my hope and expectation for others to make their own PWAD episodes for this (just don't use clearepisodes). They will be added to the list of episodes when starting a new game and we can end up with a ton of new content from user made episodes. So come release, I'd love to see some new episodes being made once the resources are available.

It's a shootable switch I believe. That was done so that the fight would begin, putting the switch there simply ensures it will, or you may have ended up with a player roaming the fight area forever wondering why nothing is happening.

Gameplay video posted in OP!

I have just completed going through all the maps a second time for polish and such. Now I am moving on to getting weapon, monster, and item behavior polished up. Then, since I have extra time, will begin the new episode's maps. I might be able to finish them all before release and actually have the new episode ready for version 1's release. Nine maps in a little under two months? I can at least make a dent anyway.

I thought runaway scripts get detected and terminated automatically, at least ZDoom does.

As someone who took way too long to start using it myself, I have to agree. UDMF just makes everything so easy and direct to do, and it gives you the most extensibility and customization. If you can use Hexen format, you can use UDMF and you'll be glad you switched unless for some reason you actually NEED to use Hexen format specifically.

The problem is that MAP01 is cluster 3 and you have exittext set to say "Normal ending." So this means when you exit MAP01 (you exit cluster 3) it will show this text. You should instead give cluster 9 an entertext instead. This way, when you enter cluster 9, it shows you "Secret level entrance." Also I would suggest using the newer MAPINFO format, as this is the old syntax.

Well I would counter that by saying that the number of monsters on the map is always true, since if you haven't spawned one yet then it's still the right amount that DID spawn. It's annoying sometimes in older maps that couldn't utilize spawning functions to say 140/152 and ends up being a monster stuck somewhere in a monster closet and can't get out. Whereas monsters spawned are either spawned in and counted, or blocked and just don't spawn in which case no harm done apart from missing potential monster spawns. I'd personally prefer to design maps with spawning through code in mind now, since I can control the exact moment they spawn and where.

Not at this time, no. I'd probably prefer to release to everyone at the same time and have the community as a whole be able to help resolve any problems it has over time. You can be sure the first release will be perfectly playable as is (at least in single player, co-op I'm sure will have some bugs). Obviously not perfect, but good enough as a first release.

I'm still going through them for additional polish. Then I need to make more adjustments and tweaks to the monsters and stuff to get them working the best they can. After that I need to do extensive playtesting from map to map together as a finished product to weed out any more obvious problems. The plan is still for the original release date.

How the hell did that cause sounds not to play? It seems like it would have instead dumped you to a console error as soon as you enter MAP01 claiming it can't find a map named "01." The Doom engine is weird.

Here's what I would do using your example: script 1 OPEN { While(ThingCount(0, 1) > 0) Delay(10); Delay(35); Thing_SpawnFacing(2, T_IMP, 0, 0); }Give the five Barons a TID of 1, and then set the MapSpots all to a TID of 2. Replace T_IMP with whatever you want to spawn, and remove or add MapSpots for the amount.

Just a heads up if the maps don't have the right lighting when this first comes out don't worry, the correct lighting and colors will be fixed and updated in due time. With the current situation of Doom 64 lighting in GZDoom, it's not perfect yet and not fully integrated into GZDB. I plan to properly address this and properly apply the correct exact color lighting in the near future when it permits. I may consider it to be the 2.0 version update. Obviously it releases as 1.0 and any bugs or small fixes will make it 1.1, 1.2 and so on. 2.0 will be the first major update which I plan and hope to contain the right lighting effects.

I'd recommend doing a run of Memento Mori 2. I see you've done the first one, and the second one was so much better to me personally. There are a couple reasons why, first of all like I said the levels in general were so much better, and every single level has a unique MIDI this time around. They are very good MIDIs too. Not incredibly challenging on UV but there's a few spots that sure did kick my ass.

Not unless someone wants to make Smooth Doom 64. I'm a terrible sprite artist so the most likely answer is no (as of now, like I said someone else might try it).

A couple folks over on the ZDoom thread suggested keeping the original weapon animation behavior and including it as a toggle option. I've added the framework and got it all set up, I just need to write the DECORATE states to reflect the cvar. The smoother animations from Cage will be default, but can be changed to "classic" via the D64 Feature Menu that I've added. Luckily the only states that are any different is the fire states (but unfortunately the hardest state to write).

Into Sandy's Megawad

Holy crap dude you've got like every D64 feature integrated into GZDB. Are you a wizard? lol

Let's say flag A was set (Peg Upper Wall Color), the middle texture for example will be green to red but only within the middle texture. The interpolation does not span from top all the way to bottom. The middle texture seems to be getting its own interpolation from the top and bottom colors and does not "join in" the interpolation from top to bottom. I hope that makes sense, perhaps I can take a quick screenshot. On the ones where I said completely one color it's probably full red and full green because of how tall the sector I made was, it only appears to be completely red because of the height. The part which is completely red is only full red because it doesn't reach enough height to start reaching the orange/yellow in the middle. EDIT: Here's a comparative shot of all possible flags: Imgur converted it to a JPG, so I apologize for that.

I can find out really quick in a map in Builder 64, because I'm curious as well. I don't think there's any spot in vanilla Doom 64 where there's not an interpolated color for a middle texture. EDIT: By default, middle textures automatically interpolate between top half and bottom half color. On a per linedef basis, you can check a box to do the following: These will assume a top color of green and bottom color of red. A. Peg Upper Wall Color - causes top to interpolate green to red on top only, middle texture still interpolates normally green to red, and bottom is completely red. B. Peg Lower Wall Color - the opposite, causes top to be completely green, middle texture interpolates normally yet again, and the bottom now interpolates green to red on bottom only. C. Flip Upper Pegged Color - entire top and bottom becomes red, middle texture still interpolates as normal green to red Combine A and C and top is now red to green instead of green to red, middle texture stays the same, bottom is completely red Combine A and B and both bottom and top fade green to red as well as middle Combine B and C and top is completely red and bottom fades green to red, middle texture still normal Combine A B and C and top interpolates red to green, middle texture green to red, and bottom green to red In all cases, the middle texture is never not interpolated.

SWEET! Awesome news, thanks for the hard work Graf. Are they settable through GZDB or is that yet to be added as a setting? This will immensely improve many maps, especially the tech base ones. I noticed going through them the second time, they are really mundane to the original counterparts due to the lack of color fading and darker top wall shadings.