Hello,

When I kill the two bosses in the big room the walls won't lower. It's supposed to do that for you to proceed.

Thank you for replying.

It's a 99.99% probability that the problem is Brutal Doom, as it's known to not work well with many WADs. With regular ol' Doom 1/2 it's either the source port or BD, but it's still usually BD.

I have also heard that the latest GZDoom isn't friendly with BD, but that was back during devbuilds so that may have been fixed with a new release of BD (it was due to how it's programmed, not the source port's fault).

Thanks for the advice guys. I tried restarting the map but that didn't work. I also tried the no clip cheat, but the console couldn't understand it for some reason. I just quit the map and started the next episode.

The old cheat codes (idkfa, idclip, etc.) are not to be typed in the console, but while playing the game. (The original Doom, after all, did not have a console at all.) The console has its own commands.

So, to no clip, the cheat codes are idclip or idspispopd; the console command is noclip.

You guys aren't going to believe this...

I went back to the level to try the cheat without the console. I go into the big room and gun down everything. As soon as I kill the second baron of hell the walls lower. I honestly have absolutely no idea what happened differently.

Some users reported that the walls not coming down error was often experienced when the barons were gibbed rather than just killed, which means it could be due to how Brutal Doom handles the gibs. The Brutal Doom gibs also used to block elevators and doors and such, but those were fixed.

Just curious,do you know if Project Brutality is better coded? it's the way I lean for a Brutalized DooM experience.

I've heard it was more robust, though I've never actually tried it or looked at its code, so I can't vouch for it.

I've played through the Hell on Earth Starter Pack using Project Brutality and that mod does add a lot to the stock Brutal Doom mod. I know that various fixes have been implemented in it before they were fixed in Brutal Doom (like the stuck elevators), but I'm not sure if the blood.txt 0.l issue is fixed in it, it might be.

On a different note, though, am I right in assuming from your recent posts that you are the GZDoom author (Graf Zahl)? If so, I do have a quick question, as I'm just wondering what it is about the GZDoom releases (and dev build releases) that breaks save game compatibility, as the WAD files being used for the game files aren't changing. Is GZDoom injecting something into them when in use and that causes different sectors which prevents the saves working, or something along those lines? Would you happen to know what text file within the PK3 the Baron deaths are coded in? Just wondering if it is simply a case of finding the relevant file, then looking for the references within that file to the death states and adding in the call.

I've never learned DECORATE or whatever code it is that it uses, but if I can see an example of how it is meant to call it then I might be able to copy that to the other states to create my own fixed version, as I do have coding experience in other languages.

I am not Christopher Oelcker, no. I have contributed code to ZDoom and GZDoom, though, but I'm not one of the main developers.

Save games in ZDoom, until recently, were based on a binary serialization format where it saves every attribute of every object. From time to time, though, objects get to have a new attribute -- because someone wants a new feature for example -- and that tosses things out of alignment. To some extent it's possible to still keep backward compatibility with old saves by looking at the version number and predicting then that such or such attribute will be missing so we can just give it its default value instead of trying to read it, but eventually there would be a point where keeping all the compatibility cruft would just be too much work.

Recently, the entire save game format was completely changed. Instead of recording everything in a compact binary format, it now saves only changed values in a JSON format, which means that saves become human-readable but shouldn't get too large anyway. This change was motivated by weird and very rare save bugs where it was too difficult to find out what caused the save data to become incorrect. Having a human-readable format means that when you get a corrupted save, it's a lot easier for the developer to look at it and discover which values aren't being recorded correctly. But it might also have the advantage that backward compatibility might be easier to preserve from now on.


I don't know specifically and I haven't kept a copy of Brutal Doom around to check, but it is going to be either in a file named "DECORATE" or in a file that is #included in a DECORATE file. You can find out more precisely where each class is defined by using the [url=http://zdoom.org/wiki/CCMDs:Informational#dumpactors]dumpactors[/url] console command. Keep in mind that, as the wiki explains, it's going to take a while to process and format all the information and you have to use a logfile first because it's going to take more lines that the console buffer has. The output is tab-separated so you can easily copy-paste it from your logfile into a spreadsheet and everything will fall neatly into columns, and you can then turn it into a pivot table.

Keep in mind that if it's in a file named DECORATE, you might have several different files with the exact same name in an archive, so that might not be enough to pinpoint it.

Anyway, once you've found out the baron replacement, it's mostly a question of making sure that each of its possible deaths does call A_BossDeath somewhere. DECORATE is a very simple language so it's pretty easy to understand. Basically you have a bunch of properties, and a list of states. States are identified by a sprite (four characters), a frame (one character), a duration, and then they can have an action (such as A_BossDeath). You can have several states on the same line, sharing the same sprite, action and duration but not necessarily the same frame, in that case instead of one character for the frame, you'll get a string of several characters, each one indicating which frame this state uses. It's all explained here if you want examples.

Okay, checking in the DECORATE file it includes files for various enemies. One of them called BARON. There is then a BARON.txt file present that seems to hold the necessary code.

However, going through that, whilst I can see some Death.<name> references, I can't really see why some of these blocks have a line containing A_BossDeath and others don't, as it seems that some lines are calling others via some call to A_CustomMissile.

There is a block for Death (and also many subsections for Death.<name> as I mentioned above).
This Death section then has A_CustomMissiles for XDeath1, XDeath2, XDeath3 and XDeath4. But I can't see such a named reference, just a standard XDeath block. Do the numbers mean something related to the text part of the reference (so that these all call XDeath with a numbered parameter)?

Anyway, XDeath does contain A_BossDeath, but other Death.<name> blocks don't.

I've compared it to the same file in Project Brutality. This one seems to have many more A_BossDeath calls, but even so, not all of the Death.<name> blocks contain this call, such as the Death.Blackhole block.

I've uploaded the two BARON.txt files here (_BD for the Brutal Doom version, _PB for the Project Brutality version). The file extensions need to be renamed as GOG only allows upload of image files.

I feel that if I could understand the statements better then I might stand a chance at doing something with it, but it seems to be jumping around all over the place and I can't make head nor tail of the 4 character names (these are called the "sprite" names, right?). Are they just a unique identifier for something, and where are they initialized?

Guess I would need to properly learn some DECORATE to do this (I hoped it would be just an easy search for the references and add in the missing A_BossDeath line per affected block), but I don't have the time.

EDIT: Okay, so sprite names really are part of an actual image file. The sprite name + frame + a number for the directional angle should correspond to an actual image in the WAD/PK3. Only not all such constructs have a corresponding image file (or at least not in the Brutal Doom PK3 file). Maybe always using a TNT1 (invisible sprite) would be okay? Or the ---- for the current sprite?

A_CustomMissile is a function that, like its name implies, spawns missiles. It doesn't do state jumps, so I guess XDeath1 and so on are the names of special gibs that are spawned as missiles. That's how it does with death animation where the monster is split into several parts. However, only the real monster can call A_BossDeath -- any gib piece spawned (as a missile or not) is not the boss, so they wouldn't have any effect if they called A_BossDeath... It has to be done by the real thing.

As for why BD uses a missile function to spawn something that isn't a missile, well, Brutal Doom's poor coding strikes again, I guess.

And I guess killing the barons with whatever deals blackhole damage will cause E1M8 to fail.

Generally just inserting a line such as "####" "#" 0 A_BossDeath at some point in the death sequence will work without affecting anything else, yes.

Just tested this by loading up map E1M8 with Project Brutality, using the give all command to give me all of the weapons, and completing the level by using the Black Hole Generator gun. The walls came down fine. Even though the code is just:

Death.Blackhole:
TNT1 A 0 A_Scream
TNT1 A 0 A_NoBlocking
TNT1 A 0 A_SpawnItem("BlackHoledBaron")
Stop