ZDoom

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.

The new version of the plane in the beginning, now relatively accurately modeled after a C-47 instead of some thing I made up in my head.

Central Transit updated with a sweet new skybox.

All the damn chairs are now simple MD3 models and the other furniture is enhanced with GZDoom's 3d floors.

Shot of the Barracks showing off dynamic lighting in GZDoom.

Medical area showing off dynamic lights and 3d sectors.

Entering the Barracks.

(I can't get into ImageShack right now, so there's some new stuff on page 7)

General Info:

When I get around to releasing this again, I'm going to put up one master version that includes the GZDoom enhanced "Cold as Hell" episode along with any additional content I create, if any. Also, the resource file from the GZDoom version will work under regular ZDoom with a kind of "classic episode" consisting of the CaH levels without any GZDoom enhancement for those with crappier computers. I plan to release the fixed versions of the original levels separately and include the GZDoom version of everything as the default. Any new content is going to be GZDoom-only.

Back in 2004, I created what I thought was a pretty neat WAD. It was a partial conversion set during the cold war in a military research facility in Greenland. It had a plot people seemed to like, some interesting new enemies, and altered the gameplay in a number of ways (reloading weapons, limited ammo, less health, bleeding system, mission objectives, etc.).

Unfortunately it had a number of rather severe performance issues.

Well... I didn't have the time or inclination to fix it at the time. However, for one reason or another, I feel like the WAD would really stand up to the test of time better if I, y'know, fixed the problems. Basically, there are performance issues, there are bugs (it was heavily reliant on using ZDoom 2.0.63a and will not work right with other versions).

So I'm going to go back and fix some major problems with Cold As Hell to make it into a decent, playable WAD that even people without quad core processors and 4 gigs of RAM can enjoy.

The current plan is to release a GZDoom "Special Edition" which will include numerous visual enhancements. However, there will also be a revised "classic edition" of the level set packaged in with the mod that will run on ZDoom 2.2.0 just fine. The "CE" version will lack the various GZDoom-only features, but will still feature the various gameplay enhancements and improvements such as the inclusion of weatherFX-based weather stuff. The two mods will use mostly the same resources, although using the CE levels will disable the fancy new fire effects for the flamethrower because they look like total shit without OpenGL.

Awesome, great to hear. For a long while it was looking like Cold As Hell was forever doomed (ugh, no pun intended) to a fate of being a buggy wad that only worked in an outdated ZDoom version, as (afaik) the ACS source was never released so no one else could fix it to work properly in newer versions.

esselfortium wrote:Awesome, great to hear. For a long while it was looking like Cold As Hell was forever doomed (ugh, no pun intended) to a fate of being a buggy wad that only worked in an outdated ZDoom version, as (afaik) the ACS source was never released so no one else could fix it to work properly in newer versions.

Yep. I actually thought I'd lost the original ACS code and source files a year or two ago, but I found an old hard drive that had the entire project on it. When I finished the project I patched it a bit and kind of dropped out of sight (end of school, looking for work, getting married, etc. all kind of made it a far-back-burner priority). I figure I've got some time to finally fix the stupid thing.

And yeah, I'm definitely including the ACS source this time. It's a goddamn mess (which is why it was omitted - awful decision in hindsight), but better to have it than not.

The lag was twofold, I guess. On any kind of slower computer the snow itself lagged things out, and there were issues with the memory before that would lag even a faster computer. I think it's worth sacrificing the snow is probably worth it for those with older computers, but I'm open to feedback.

esselfortium wrote:It's not uncommon for maps that use weather effects (snow, rain, falling meteors, etc.) to have a script and KEYCONF setup that allows the player to toggle the weather on or off with a keypress.

The original release did have such a thing, although it didn't always work properly.

Perhaps having it default to "off" but keeping the possibility of the effect there would be best?

In the SVN versions, there's a +NOINTERACTION flag that removes the object from any kind of collision which would greatly increase the game speed.

There's also a garbage collector in the SVNs, which allows a lot of objects to be spawned and destroyed constantly to use memory more efficiently. What this means is that particle effects that constantly get spawned and removed don't lag the game as much as it used to anymore.

Combining the two would mean you can pretty much have the effects left intact (well maybe you might want to tweak it by lessening it just a wee bit, maybe about 10%) and they wouldn't slow the system as much as it used to be.

The downside to this is that these features are only available in development versions. Or you can choose to put your project on hold until these features become official features (wait for Randy to make an official release).

EDIT: Oh and it's good to have you here. A lot of people want to see this mod fixed and balanced properly and it was bad news that you just disappeared after you released your mod without leaving the ACS source. Graf Zahl would be glad to see this thread... :P

I always thought that if these issues hadn't been this would have been one of the best Doom mods ever.

I actually managed to decompile most of the scripts and get a semi-working version that was playable but some features I just couldn't repair in the decompiled scripts. This included the weapon reloading, the bleeding system and the ACS HUD.

That said, I have to mention that the biggest gameplay issue I had with this was the extemely low health of the player which made it a chore to play. I really think you should either increase the max. health or make the player a little more resistant to damage. With exising DECORATE features this shouldn't be too hard.

I have to say the bleeding bothered me more than the lag when I was playing, because generally playing Doom I take hits frequently and rely on there being a fair stream of health to back up my reckless play style - however I was stopped cold (hehe) here due to the bleeding taking me down... can't remember how much using a bandage helped there.

Phobus, using a bandage would stop bleeding for only ten seconds, which is really harsh. I think I suffered a lot from "I made this, so I know where everything is" syndrome in playtesting, but now that it's been a while I realize how goddamn frustrating it can be.

I'm thinking I'll maybe double the player health and make the bleeding less extreme. Also, I think I might make it so you can't actually bleed to death, only down to, say, 10% of total health or something. One of the other things I found annoying in hindsight is that the pistol fires too slowly, which makes no sense. It's completely outclassed by the thompson once you get it, plus it uses the same ammo!

Nash, I may very well do that. I'd like to keep the effect, but I'm trying to put a higher priority on playability over prettiness this time around. It seems a lot of the issues were due to memory management as well, as I noticed lag on some of my later systems only after traveling through a few levels in the hub.

Graf, good to hear that you were working on it. The weapon reloading is hopelessly broken in all current versions of ZDoom anyway, so that's a high priority fix for me. I've been kind of out of the ZDoom editing scene for a while, so if you know any more about how the new DECORATE weapons stuff might simplify that, I'm all ears.

The other thing I've been considering is to work on the follow-up episode I had planned alongside the modifications, then release the whole thing as an updated package. I had it originally plotted as a two-episode cycle, but never actually started work on the second episode. Since most of the resources (notably, the enemies and weapons) are in place already, the development time would be less extreme than the first time around, barring time taken to scrape the rust off my editing... thing.

JonnyFive wrote:Graf, good to hear that you were working on it. The weapon reloading is hopelessly broken in all current versions of ZDoom anyway, so that's a high priority fix for me. I've been kind of out of the ZDoom editing scene for a while, so if you know any more about how the new DECORATE weapons stuff might simplify that, I'm all ears.

I think you better ask the experienced weapon modders about that. They have far more experience than me. I just gave up on the reloading feature and opted for making the mode playable - which meant I removed the reloading completely (Yeah, I know - not what was intended but it was either that or not being able to play it at all...)

BTW, one thing you should address is the overlapping sectors. Some cause problems with the GL renderer in GZDoom.

Graf Zahl wrote:I think you better ask the experienced weapon modders about that. They have far more experience than me. I just gave up on the reloading feature and opted for making the mode playable - which meant I removed the reloading completely (Yeah, I know - not what was intended but it was either that or not being able to play it at all...)

Actually, I had some free time at work and was able to dig up some info on creating a DECORATE based reloading system that is about a million times more robust than the current system. It will require some changes to the level design and play balance, but nothing major.

BTW, one thing you should address is the overlapping sectors. Some cause problems with the GL renderer in GZDoom.

Yeah, I'll put that in with the fixes to look at. A lot of it was from furniture, IIRC. I went a little crazy with my chairs once I figured out how to make nice looking ones. I'm trying to clean that up a little.

This is good to hear. The screenshots of this wad that I saw on wadsinprogress years ago looked really impressive, and I always felt disappointed that I never actually got the chance to get in and play it. (I kept getting stuck in the helicopter in the beginning, sad as it may sound.)

Funny how this topic shows up mere days after I downloaded the mod. I didn't get very far (about to the point where you first get attacked by monsters), but the objectives HUD bugged me, which may have been partly related to playing in 16:10 wide screen. Well, I guess I should just wait till this updated version is released before fully jumping into the mod.

Also, how come early reloading systems like this mod (and others like Zen Dynamics) used ACS compared to the decorate based systems of later reloading systems?

ThatOneZDoomer wrote:Also, how come early reloading systems like this mod (and others like Zen Dynamics) used ACS compared to the decorate based systems of later reloading systems?

Because it hadn't been discovered at that point that one could just create a dummy Decorate inventory item to serve as the Reload key. Earlier ACS reload scripts relied on the player pressing a key to puke the respective script to give the player a flag to reload. Nowadays, though, we've figured out that such a thing can be done using CustomInventory.