Doomy__Doom

I'm away from the pc with editing tools, but last I checked this all I did was open the decohack file with "using dsdhacked", then made a whatever thing while directly using new sprites in states block (no pre-declaration or anything), and that would automatically generate the [SPRITES] block for dsdhacked. If I'm misunderstanding and you need custom mnemonics in the vanilla merging sense (i.e. renamed sprites with vanilla-compat strings section), then I'm not sure.

You just use new mnemonics directly in code with "using dsdhacked", decohack should generate the relevant patch sections. There's a brief mention in the docs under "SPECIAL: DSDHACKED Patch Behavior".

I'm going to guess you're talking about sector 602 of map01 - it's the same problem as here - namely, the vanilla action uses numeric model and depends on linedef index order to function correctly. Some incorrect setups may indeed crash vanilla/choco, where other source ports will simply not change the texture/effect. Use Linedefs->Change Linedef index (for UDB) such that the linedef between the floor that's changing the texture and the adjacent source (original floor that has correct texture) has the lowest index among all linedefs of the lowering sector. For example, turn linedef #3727 into linedef #1.

The problem appears to be with your nodebuilder (default ZenNode I guess? See game configuration->Nodebuilders). As provided, the line doesn't block. I rebuilt nodes with ZDBSP and it started blocking as it should.

Definitely not the case. Just made a startan square with a line in the middle with your exact flags, it does everything as it should in dsda-doom 0.28.1. Blocks the player, blocks an imp, does not block a lost soul. Launching dsda-doom with explicit -complevel 21 parameter in the command line through the port configuration in UDB.

Like this.

That's not how slaughter works. Compare: the imp staircase in the beginning of Okuplok vs the exact same amount of imps in a featureless square room.

To add a different point - sometimes technical execution challenge can be, in fact, the point. Platforming, shootable sequences, pressable sequences, rocket jumps and other concepts that require any degree of timing and precision test movement skills. Not every secret has to be solely about observation, imagining level structure, gathering clues and such. Some secrets may very well require both capabilities. Since you've brought up Eviternity, let's go back to Evi 1 - Map 12 features a shooting switches in sequence puzzle with several 90 degree turns and some movement. Surely that doesn't raise a "what's the point?" question, even if that puzzle is likely not controller-friendly at all?

You can't, valve sunset steam client on win 7, I believe since the start of this year.

I don't see the point of JSON validation being required to hard fail on "metadata" field absence and/or contents. Community-wise, it's going to produce nothing but extra traffic to Editing Questions subforum with a typical answer being "copy sample from <wiki or smth link> and edit just the 'data' section". It's fine for commercial port/wad to fail that way if it wants to, it's made by professionals who are good at (and have a job of) reading/following specs to a T. It does not help anyone in a wide public standard imo. People routinely fail at easier to make lumps. Otherwise, lots of cool stuff!

You probably have custom patches/textures, but you didn't import PNAMES/TEXTUREx from base resource archive (i.e. the IWAD). Zdoom ports automatically merge those lumps for you from every loaded wad, but many (if not most?) ports do not - they read the last lump in load order and expect everything to be included there. The detailed steps to do it right have probably been recounted more than once on dw, try searching phrase "base resource archive" in the editing subforum.

Following as in having, not "doing what other people do". Poor choice of words, I suppose. The only way there can be a concept of "too big" and "digestible" wad is if one tries to stuff themselves more than they should, similar to eating the whole buffet to "get your money's worth". Otherwise it should not matter whether a wad has 9 or 99 maps.

3rd option: it does not matter, because I stopped following the "must play the whole wad from start to end with nothing allowed inbetween" mentality. I would actually go as far as to say it might be more toxic than "UV or bust", in an insidiously unnoticeable way.

It does what it's supposed to. But what it's supposed to do according to GZDoom does not include voodoo dolls as per this comment (source: codebase, duh) // Some levels designed with Boom in mind actually want things to accelerate // at neighboring scrolling sector boundaries. But it is only important for // non-player objects. if (player != NULL || !(Level->i_compatflags & COMPATF_BOOMSCROLL)) { if (countx > 1) { cumm.X /= countx; } if (county > 1) { cumm.Y /= county; } } If you race a pair of dormant imps on cut-up vs single-sector scroller, you'll observe one being faster than the other. Voodoo dolls will move at the "gzdoom" speed. I'd love to be wrong about this (and if someone knows better please correct me), but the practical test result is the above.

Looking at the setup in the video, if the problem is due to conveyor being made of multiple sectors, why not just... not do that? Draw trigger lines completely inside a single conveyor sector. Something like this https://postimg.cc/s1Q06GfR. If you need sectors because of changing textures/sector specials via linedef that ofc nulls the solution, but yours seems to be lighting-related from what I can tell.