Worst

Yeah, but then you have to align the 64x64 textures as if they were 64x128, because if you simply align the 64x64 textures so that they seem to line up, you might end up with something like this happening: While on the other hand, if you had 64x128 dummy textures, you could more clearly see if their offsets line up as you want: But yeah, I agree that you don't need to worry too much about this, since editors let you easily auto-align textures both horizontally and vertically.

So judging from your screenshot, 4x4 is 128x128 mapunits/pixels if using the original resolution for doom textures? Unless you plan to use custom textures made for these sizes in particular, you should definitely have one for 64x128 (w,h) textures, since that is probably the most common texture size in Doom. In my opinion it would be more clear to name them directly according to the mapunit sizes, unless you have some specific need to use this 32x32 scale.

If you mean the Doom CDs collection at https://archive.org/details/doom-cds, I don't think it is in there. It reads "MADE IN FINLAND" on the side of the CD case, so I would guess that maybe this CD was not ever distributed too widely outside of Finland. Cool! I suppose using the Wad Archive API and the MD5 hashes of each wad, I could find out if there are any wads in the CD that are not already present in one of the other Doom CDs.

In addition to using a LOADACS lump, make sure to also place the script in an ACS library.

Russell_P's 'Wads of Wads' topic reminded me that I have this 1994 CD called 'Advanced Doom Utility CD'. I didn't see it in the Wad Archive list of Discs, but I'm not all that familiar with Doom shovelware, so no idea if it's just a rehash of things you could find elsewhere already. It was not in great condition, but I managed to copy the contents. If anyone is interested, I have uploaded it here: Advanced Doom Utility CD.zip From the readme: Advanced Doom Utility CD 1 =========================== Here it is finaly: The ultimate Doom CD-ROM. We hope you enjoy this product and find it useful. On this CD-ROM there is all the nessessery utils for producing and editing levels for the Doom game. Also you find a lot of self made levels and episodes for Doom game, enjoy! You need a registered Doom 1.2 to use most of data and/or programs! ******************************************************* CONTENTS OF DOOM CD-ROM: UTILS1 > This directory is full of various utilities. UTILS2 > This directory is full of various utilities. DOOMADDS > Wads that will change main wad. (Sounds & Graphics) LEVELS > Enough new wads. THEMES > Theme wads like StarWar, Terminator (Sounds & Graphics) COMBOS > Fully rewritten wads with all episodes. Look in specific directory for readme files for more information. *******************************************************

Is your self-referencing sector properly surrounded by an enclosing sector?

I'm not sure there is a direct way of obtaining that information in ACS, but what you could do is assign a Thing Special to each monster, that executes a script with a parameter that supplies the type of monster that was killed. By default the activator of the script will be the player that killed the monster. To assign the specials to the monsters, you could do: a) If you are making a new map, assign the specials in the editor by selecting all monsters of a specific type and assigning the special accordingly b) Make replacements for the monsters in decorate, and assign the specials when they spawn according to the type. c) Use SetActivator & Thing_ChangeTID and CheckActorClass/GetActorClass to loop through all the actors in the map and assign thing specials accordingly. (But this method also requires messing with actor TIDs, which may become an issue if the map makes use of any TIDs) See: https://zdoom.org/wiki/SetThingSpecial https://zdoom.org/wiki/Thing_SetSpecial https://zdoom.org/wiki/Thing_executed_specials https://zdoom.org/wiki/MAPINFO/Map_definition#ActivateOwnDeathSpecials https://zdoom.org/wiki/Actor_properties#Activation However if you give each monster a thing special, whatever special they had prior to that will be replaced. So in case you plan to use this with existing maps/mods, it might cause issues with maps/mods that already make use of thing specials.

When I want to stick to the grid, I usually split the door linedef to two or more parts, and then adjust the texture offsets of each part until it looks acceptable.

You could try using LOADACS with a script such as: #library "SECTDMG0" #include "zcommon.acs" // This number should match the 'ACSReturn' property in the Skill definition. #define SKILL_INSTADEATH 5 script "SectorDamageDisable" OPEN { if (GameSkill() == SKILL_INSTADEATH) { // Disable sector damage for every tag available in doom & hexen format maps. // UDMF format maps have such a high tag limit, that looping through all of // them would not be reasonable. Just have to hope they fall within the range. for(int tag=0; tag<=32767; tag++) { Sector_SetDamage(tag, 0, MOD_UNKNOWN); } } } But it's not going to work well for maps that set sector damage with scripts. Though you could add a little delay in the beginning of the script to hopefully override any sector damage set right at the beginning of a level by possible map scripts. Edit: This is assuming that you don't need the damaging floors hurting anyone while the skill is active.

Look at https://zdoom.org/wiki/Infighting

You could use a script like this: #include "zcommon.acs" Script 1 (void) { int tid_monster = 1; int tid_tele = 2; While(ThingCount(0, tid_monster)) { SetActivator(tid_monster); //Select one of the monsters (not random) int x = GetActorX(0); //Get current location int y = GetActorY(0); Teleport(tid_tele); //Try teleporting int newx = GetActorX(0); //Get new location int newy = GetActorY(0); if (newx != x || newy != y) //If the location changed, teleporting succeeded. Thing_ChangeTID(0, 0); //Untag monster to prevent script from teleporting it again Delay(1); //Delay to prevent script from dying } } This script will always teleport the monsters in the same order, but they will 'land' randomly on different teleport destinations if there are multiple of them. ZDoom seems to pick at random if you have multiple teleport destinations and the map is in Hexen or UDMF format. Though if you use a mapspot instead of a teleport destination, it will only choose the first one.

You still have extra commas at the first Random calls in both A_FireCustomMissile lines, take the last comma out, so that it's Random(-4, 4) Also the sprite name seems to be "SLRF" instead of "SRLF" in two of those lines, is that correct?

In the SuperLauncher A_FireCustomMissile lines you have misplaced parenthesis and commas This: SRLF B 4 BRIGHT A_FireCustomMissile ("SuperMissile")Random(-4, 4,) 0, 0, 0, 0, Random(-1, 1,)) Should be: SRLF B 4 BRIGHT A_FireCustomMissile ("SuperMissile", Random(-4, 4), 0, 0, 0, 0, Random(-1, 1)) Also in the SuperMissile A_Explode line you have a misplaced comma This: MISL B 8 BRIGHT A_Explode (100, 64, 0,) Should be: MISL B 8 BRIGHT A_Explode (100, 64, 0)

If you want to count things regardless of their type, you should be using ThingCount instead. ThingCountName expects a class name string, so the T_NONE identifier shouldn't be used with it, as it maps to a number rather than a string. //ThingCount While (ThingCount (T_NONE, 669) > 0) Delay(35); //ThingCountName While (ThingCountName ("BaronOfHell", 669) > 0) Delay(35);

I remember the first case happening when I was trying to make a rocket jump level as high as possible. Had to settle for a smaller sector height to avoid the issue.