scifista42

A_Log works similarly to A_Print, but writes into the console rather than the screen.

BLOCKMAP size > 64 KB. Make the map smaller.

As I already said, every time FirePistol is called, the muzzle flash animation restarts from its first frame as defined in the Weapon table. If you don't want that, you have to use FireCGun, and if you want to use FireCGun safely, you have to keep the FireCGun states and the muzzle flash states in their original places. That's all.

In vanilla Doom, the function FireCGun has quirky hardcoded behavior for its muzzle flash animation. Every time FireCGun is called, the weapon starts its muzzle flash animation from a state whose index is defined by the following formula: weaponinfo[player->readyweapon].flashstate + psp->state - &states[S_CHAIN1] The value of "weaponinfo[player->readyweapon].flashstate" is the index of the weapon's muzzle flash state as defined in the Weapon table. The value of "psp->state" is the index of the current state that calls FireCGun. The value of "&states[S_CHAIN1]" is the index of the first state of the original, unmodified chaingun's firing animation (that is, number 52, a constant). Knowing these values, you should be able to arrange the states of your weapon's firing and muzzle flash animations to sync properly in vanilla Doom. However, beware that some source ports may not (and, from my experience, indeed do not) keep the vanilla behavior as is, so your weapon will end up not working properly in those ports. The safest thing to do is to avoid using FireCGun in any other states than the ones where the original, unmodified chaingun uses it, while also keeping the muzzle flash animation in its original place. Consider using FirePistol instead, which always calls muzzle flash animation from its very first frame as defined in the Weapon table.

It's a nodebuilder error. Randomly moving vertices or adding/removing linedefs in the affected area is all that can be done about it.

If the monster type is defined in DECORATE with Activation property with value "THINGSPEC_TriggerActs", the script activated by the monster's death will consider the monster itself its activator. Then you can call ActivatorTID to get its TID, or you can just call action specials inside the script with tag 0 as a parameter, making them affect the one monster without knowing its TID. If you don't want to mess with DECORATE just for this, or if you still need the killer to be considered the script's activator, Scypek2's solution below is probably the simplest one, unless you mind the fact that it affects the entire map, in which case I think "shove the TID in as a par to the script itself" is the simplest solution.

Even the switch activated action changes both texture and effect. Just keep in mind that, both in case of walkover and switch activated action, the texture and effect are copied from the front sector of the action line, not from the neighboring sector of the action's target sector.

The general rule for monster downward movement is: A monster cannot step onto a position where the monster's hitbox would overlap with any sector that has floor height more than 24 units below the monster's feet. In the process of checking this, the height of a sloped floor is calculated as the height at the lowest point on the sloped floor below the monster's hitbox. The monster's feet, on the other hand, cannot be lower than the height at the highest point on the sloped floor below the monster's hitbox. Therefore, for a monster to climb a slope, the slope must not be steeper than <the monster's diameter> horizontally per 24 units vertically. Even less steep (precisely, up to square-root-of-two times less steep) if the slope doesn't go directly north or south or east or west. In the context of monster movement at least, a slope could be considered practically equivalent to a staircase with infinitely thin/low steps.

The name could be anything, it doesn't matter. Ultimately, people will want to play your game for how good it is on its own, not for its references to another game. Presumably, the game will be accompanied by some description, so describe the game's style and gameplay there and that should do the trick even without mentioning copyrighted names. Consider using a phrase such as "inspired by game mechanics of first person shooters from 1990s".

Haha, the "horizontal portal" argument again! Horizontal as in the orientation of the portal's surface, or horizontal as in the direction you see/walk through the portal? Your interpretation may vary.

A basic trick is to build all rooms very close together with minimum void parts between them. At first, connect the rooms minimally, according to your own idea of how the map should flow. But finally, when the map could be considered finished, add more connections between all the rooms even where they aren't needed. Then possibly make some of them impassable if playtesting shows that they break the flow too much.

Now I think I understand - the portal itself is not one of the sectors that waggle. Thanks.

???

Cyberdemon - kills a full health player in one hit. I mean, monsters that don't kill the player in one hit are great to use in regular gameplay most of the time, but from a mapper's standpoint / game-design-wise, it's also nice to have a one-hit-killing monster available for specific scenarios, whether actual battles, traps, or even "puzzles". Archvile - long attack preparation delay, then instant hit unless out of sight. Similar reason as above - the potential for interesting usage. Resurrecting monsters in its path or launching the player into the air along with dealing damage are interesting too, but difficult to control. Pain Elemental - fills the whole area with monsters that naturally infight. Like above, good only in specific setups, appreciating the potential anyway. Demon - easily manipulated to walk where the player needs him to without endangering the player too much. Take cover behind him, make him activate doors or lifts for you, fun exploits. Revenant - homing missiles. Mancubus - spreading missiles. Arachnotron - stream of missiles. Cacodemon - flight and missiles. Icon of Sin - monster missiles. Obvious reasons. Shotgunner and chaingunner - their hitscans pose a decent threat. Imp - weak, predictable, versatile, overusable, classic. (Yes, this is one favorite thing, not multiple favorite things - I just don't know how to express it in one word or phrase.) The rest - just for completion - can't really decide what's my favorite thing about them. :)

I suggest you to stop associating this game with the name "Doom", firstly because of copyright, secondly because the only apparent elements reminiscent of Doom are the text and the head in the right 1/3 of the screen.

Some graphic editors automatically zero PNG offsets when editing PNGs. That's apparently what happened to you. Surely it's possible to set the offsets again. By the way, sprites do not need to be in square resolution.

Clearly the problem is that GZDoom ignores both sprite's offsets. They both display as if having offsets (0,0). That is, below the ground they're supposed to stand on. I don't know how to fix this other than putting the sprites into a wad instead of a pk3 and setting the offsets there.

Killing voodoo doll and icon of sin kills the player and exits the level. How exactly does that differ from what you actually want?

Exactly. I always clarify this about a week before the deadline, seems like an unnecessarily specific detail before that.

If I wanted to make the same point as you, I'd just say Doom Builder X.

If you want to delete only 1 thing and you have nothing else selected, just hover mouse onto the thing and press delete, no need to click it to select it.

Technically, 1) Baron projectiles did this in Doom 1 already, Mancubus ones are just more likely to do it because they're even faster, and 2) it's not a result of any code change, but of the high speed + low radius stats of the projectile type.

I've seen it done in vanilla wads and seen it discussed on this forum before, it is possible. Try one of the raise-and-change-texture actions instead of lower-to-lowest-floor-and-change-texture, as the latter is known for causing crashes in other unusual scenarios too.

From my experience, GZDB slows down when some sectors have too many adjancent linedefs. You might be able to speed it up by adding linedefs splitting those sectors into multiple smaller sectors, each with relatively small number of adjancent linedefs.