Bauul

Honestly it feels like this thread is going in circles. There's a few people who really like non-vanilla lightmodes, and removing them from the menu introduces some inconvenience for them. It seems no amount of explanation or justification is going to make them feel positive about this decision. I think it just needs to come down to "I get some people don't like it, but it's not being changed" and leave it there.

As far as the team is aware, no co-op ports currently support DSDHacked and MBF21, so this is simultaneously focusing on solo-net and co-op.

My take is that every mapper, if they're targeting GZDoom, should specify a lightmode. The different lightmodes change things so much that if a mapper has spent any degree of time fine-tuning the lighting then they should probably specify a lightmode so their hard work isn't lost by a player using a different lighting engine. But if a mapper isn't targeting GZDoom (and the map is still fully compatible), it's more likely they're targeting a software renderer or "more traditional" source-port like DSDA. In those cases, the lightmodes that most closely resemble the original Doom renderer (i.e. the ones available in the options menu) are the right choice, because that's what the map will have been designed around. So having those as the ones available in the menu makes sense. And if a player really wants to use one of the old lightmodes (because they understand what they are and like the look of them) then the console / autoexec is there for them. Maybe I'm missing something but this seems logical to me? The lightening around the player is a fundamental aspect of how Doom plays, all the classic levels are designed around it, and all software renderers (and more traditional OpenGL renderers like DSDA's) all feature it. Given GZDoom is a fundamentally a Doom source port, having the defaults reflect the base game seems like a sensible move. If you're playing a map that features dynamic lighting or more detailed lighting gradients, then it's likely a map designed for GZDoom, and therefore the mapper should have specified the right lightmode in the MAPINFO anyway. And if they didn't for whatever reason, you can just force it in the console. Nothing here seems too controversial to me to be honest.

Bit of an old topic, but for what it's worth I fully support this change. I've seen plenty of new players butcher the intended way maps should be played by accidentally using the wrong lightmode and not even realizing they were doing it wrong. Keeping a smaller, more vanilla-accurate list in the menus and reserving the extended list in the console/auto-exec for more advanced users is a sound approach, and one I have no issues with. And for mappers: always, always put your desired lightmode in your MAPINFO if you care about the lighting in your map one iota.

It's true that sequel/prequel/remake loop is very pervasive, but I'd argue it's been going on for way longer than a decade. Look at the global top 10 selling games of 2004 (according to Wikipedia), twenty years ago: Grand Theft Auto: San Andreas Pokémon FireRed / LeafGreen FIFA Football 2005 Halo 2 Madden NFL 2005 Dragon Quest VIII: Sora to Umi to Daichi to Norowareshi Himegimi ESPN NFL 2K5 Pro Evolution Soccer 4 Need For Speed: Underground 2 Pokémon Ruby / Sapphire / Emerald Literally not a single new IP, they're all sequels and remakes. I wonder if it's less that the big AAA titles are becoming more unoriginal, and it's more the relative lack of new IP to fill in gaps is making the whole industry feel less creative.

I'll also add, and I think this is right, that GZDoom reads mod lumps in the following order: Dehacked Decorate ZScript So if you load mods with both Dehacked and Decorate or ZScript, the latter will win out in terms of what gets loaded.

For what it's worth, the Micro-Slaughter CP has difficulty settings fully implemented while still maintaining being a slaughter mapset. I'd recommend trying it on Easy or Medium.

I was in the market for a new laptop about a year ago, and read good things about the M18. One thing to consider is the physical aspects of the laptop: how big do you want it? Does it have a numpad? What ports does it have that you might need? Is it expandable with a second HDD or SDD? What's the resolution and the monitor frequency? Does it support HDR (do you even want it to)? Does it have a MUX switch? etc. etc. Those are important considerations as much as anything inside. Personally I went for a Lenovo Legion Pro 7 as fully pimped out as I could, and I've been very happy with it. It was the only laptop that fit my needs (specifically having a numpad) so I'm rather glad it worked out!

This was a bug in GZDoom 4.12.1. If you downgrade to an older version, or upgrade to the 4.12.2 pre-release, it should now work.

For resource heavy maps, building the original sectors in UDB and then converting them to models is a great way to increase performance. Most of the heaviest Elementalism maps, for example, have model-converted geometry in them.

Thanks for the thorough review! It's always appreciated to hear someone's thoughts in detail, so thank you for taking the time to go through everything. Just one specific point I wanted to call out: we had a hard target of 20 minutes for a blind UV FDA for all non-secret maps, and in testing we stick to that pretty thoroughly. Some maps actually had parts cut out to get down to the time limit. It's interesting, we tried very diligently not to make a bunch of super long maps, and technically none of them are that big, but the I think sheer grandness of some of the levels encourages potentially slower or more deliberate style of play that makes them feel bigger than they actually are.

I was aware of Strife: Veteran Edition implemented an approach to sprite overdraw (I myself have shared that blog before) but the method used is described in that very blog as rather inefficient and "This isn’t the BEST way to do it". That's what I meant by a "proper" fix. I wasn't aware of the Doom 64 renderer, but I was more specifically thinking about original engine Doom source ports. And AFAIK none have implemented a fix for this on the hardware renderer (although I welcome being corrected!)

This is pretty huge! I don't believe any other hardware renderer has managed to implement a proper fix for this, so this would be an amazing feather in Helion's cap if you can get it fully implemented.

I just saw the screenshot posted above and assumed it was from the game. Although having now watched the little behind-the-scenes video I see yes it was b-roll from the MachineGames office.

Could just be a fun anachronistic reference, given this is set in the mid 20th century, rather than any kind of actual teaser. The game itself looks pretty promising though: seems to nail the tone of Indy while also presenting a gameplay style that seems relatively fresh. You don't see too many FPS puzzle/brawler games with occasional third-person platforming.