dsda-dev

Maybe end of the month or in June.

The lump is based on the common and accepted standards, as seen by both source ports and authors, which work for most wads. There are rare, nonstandard use cases not covered by this lump. One example is having multiple complevels used in one wad in different maps. Another is numerical complevels targeting specific engine behavior that doesn't represent a cross-port standard. It might be more worthwhile to understand what kind of behavior you are trying to get and codify it in more compatibility behavior flags for the next iteration of mbf21+. There's a thread where such things can be gathered over in the editing forum.

Ya, I'll put it on the todo list. It didn't go unnoticed, it's just an old bug inherited from prboom+ so not a new issue for discussion. I think there is a thread about it somewhere here or maybe it's back in the pr+ port thread, not sure. I don't remember the specific details to be honest.

This is not an announcement of a new standard. MBF21 has been out for quite some time now and seen wide adoption, including half of the top 12 cacowards from 2023. While it was a big step forward from MBF, the standard was not meant to be the end, but rather to evolve over time alongside the community, and various developers and creators have discovered both strengths and weaknesses in the few years since its inception. This thread is a place to gather those ideas and critiques of the format that can be used to fuel potential future iterations. If you've run into blockers in your projects, or headaches working with the standard, or if you've got cool ideas that would enable new stuff, please share your thoughts below. It would also be helpful to know what works particularly well that should be preserved going forward. I (and Xaser if willing 😉) will collect and organize everything together if something formal takes shape in the coming year :^)

High res is very expensive in software mode. You'll get similar performance to woof if you lower the resolution to what it uses. Hardware rendering is relatively accurate and it can do a variety of "tricks" that software mode has, but there are still some gaps and some errors (for instance, corpses clip into the floor in opengl). The long term goal is to have complete parity between the modes, but for now it's a tradeoff.

Yes, this is also affecting some other wads. I'll be looking into it. Thanks for the report and the video.

Gregor: hit me up on discord if you are around there and I can see if I can make a build that works for you

Updated to v0.27.5 (same link in first post) DSDAHUD lumps are "merged" now so only redefined huds are changed Fixed umapinfo bunny scroller crash Fixed volume issue on song restart in OPL (rfomin) Getting this one out since the umapinfo crash affects a few projects.

Can you make a minimal wad demonstrating the problem?

The default is already "if intended by the author". This setting is an override if you want to allow it all the time. I can update the text. Boom sprite stuff can be changed in the config file or via the in game console. I'll be giving the whole menu system a look for 0.28.

Updated to v0.27.4 (same link in first post) Added background fps limit menu option Added option to hide stat totals until they are reached Added option to hide stat labels (unectomy) Added missing quitmsg dehacked keys (t-117) Changed invalid sndinfo definition to a warning Fixed some note skipping in opl (rfomin) Fixed textured automap showing in strict mode Fixed mapinfo Passover melee range height check Fixed undefined buffer issue with screenshots and viddump Fixed an overflow causing distant sprites (~8k map units) to not be rendered Fixed fullscreen cwilv replacement render position on entering screens

There have been a few cases where the parser doesn't work with all the different syntax in some SNDINFO lumps. I'll have this fixed for the next patch. Thanks for the report. I've kept posting here because it's the historical home and speedrunners are the group that need to know about new releases, but you're right that it probably doesn't make sense anymore.

I've looked into this some more. It's due to how actors spawn in the vanilla engine (you see the same effect if you spawn an enemy close to a wall for instance). The "floor" isn't updated until the actor moves / crosses lines, so it uses the sector floor and ignores the 3d midtex. I would need to add an algorithm that searches for the true floor / ceiling heights when spawning, and this won't just affect 3d midtex but normal geometry as well. I won't make that kind of big change in a smaller patch, so I'll put this on the topic list for 0.28 and it can be considered a limitation of the current implementation.

Yes, eventually. It's not a case of just copying Woof's code unfortunately.

This one is fixed for the next patch fyi

I don't have any plans for a feature like that.

The domed sky mode used when freelook is on isn't perfect. I know one issue happens if there are sectors in view that have different skies (not sure that's the case here).

At some point I had to rewrite how tag searching works (probably when adding udmf's ability to have multiple tags per line / sector) and that feature wasn't migrated. I think it would be better to implement a proper demo-compatible feature for this using a comp flag, but haven't pursued that as I've been focusing on other things.

Updated to v0.27.3 (same link in first post) - Fixed opengl renderer not working for some people - Fixed duplicate wipe when reloading with use while dead If you still have issues with opengl let me know. Thanks to ReaperAA and VanBog for debugging the issue with me.

Yes, there shouldn't be an issue.

Making progress on the opengl investigation, hoping to have a fix in 0.27.3 for anyone affected.

Glad you found a workaround for now. If you launch the game directly instead of using the launcher, does it have the issue or can you go straight to full screen? Basically, is it related to the launcher or the port itself?

You can't click on the window or switch focus to it? What renderer? @PBeGood4 do you have any idea about that?

You know next to nothing about speedrunners or source port development but have decided to take up strong opinions about how everything works and why decisions are made. You also decided to ignore the flaws in your argument that I brought up and instead doubled down on them. Your assumptions about why I make decisions are wrong and your assumptions about speedrunners are wrong. Your assumptions about casual players are wrong too. Why do some people feel the need to be so loud with their ignorance? Is it the lure of the spotlight? By the way you can't just say all respect and then repeatedly attack my character and intelligence. I do consider being told I ignore most of the players, as well as saying I'm too dumb to realize other people think differently than me to be personal attacks. There is no other way to take that.

Could you explain what a person being a speedrunner has to do with either of the features you mentioned in the op? Explain to me how my focus is only on speedrunners. Anyone can see in the patch notes that it's not true. Do you think speedrunners were clamoring for new mapping tools or finite height? The philosophical core of the port is more about compatibility and consistency than speedrunning in particular. That core happens to be important for speedrunning, but it also ends up being relevant for mapping and casual play as well. I pretty much implement any feature I think is interesting and they come more often from mappers and casual players than from speedrunners.