Trov

I think it really deserves further development (in particular, motion aiming with a freefloating cursor, similar to the Wii Quake port.)

Oh thanks, that worked. My brain doesn't really notice the mismatched angle at all unless I am specifically looking for it. I think the only time an average person might notice is maybe when trying to shoot a very distant enemy. I'll play with it turned on for a while and report back later, but for now I think it's a great feature. I can tell that Doom's shorttics has a bigger angle increment than Marathon/Aleph One, but I think it's still fine enough to not be disorienting. But then again, I grew up playing Descent, so my tolerance for disorientation might be higher than the average person...

I think the new position is the correct placement. Why cover exactly in the center, right where the player is aiming? The original centered placement is a thoughtless and baffling design choice. Quake had it right.

Sorry, that test build is immediately closing on launch for me, without any error. I've tried a fresh config too. The stable release is launching fine. The .com version is not producing an error message either.

Honestly I think that's something the WAD needs to fix.

Well obviously if the wad contained all the textures itself that could be easily accounted for. But if a wad references Plutonia textures but does not define them it is apparent the Plutonia IWAD would be needed. But otherwise I agree with you that specifying it would be better. The idea is a way for the wad to define it so that the user doesn't have to.

I think this concept should go further and allow the lump or similar to specify a desired IWAD in general. It gets annoying to have to look whether a WAD wants say Plutonia or Doom 2 when it isn't obviously called "Plutonia 2" or such, for similar reasons as it being annoying for a user have the burden of specifying the complevel. I think ports could be smart enough to make a better guess based on which flats/patches are used as well.

Sorry for bump, but I just wanted to mention that the death exits in MAP05 and MAP10 don't work in cl9 or MBF21 compatibility modes. Apparently this is due to only being able to telefrag 1 actor that is at the exact same coordinates at a time, so only the Icon of Sin dies but the barrels don't blow up. You can fix this for the full megawad release by nudging the barrels around a couple units so that none occupy the exact origin coordinates as something else. This will ensure the player telefrags all of them even in modern compat modes.

How about an explicit death exit line special or umapinfo definition? I was playing Earthless Prelude and on MBF21 its death exits (map05, map10) don't work (at least in the MBF21 pioneering ports such as DSDA and Woof). The player telefrags the Icon of Sin and a pile of barrels, but only the Icon Of Sin actually gets telefragged and the barrels don't explode. It seems with cl9 (carrying over into MBF21) there is some limitation on telefragging more than a certain number of actors at once (possibly that number is exactly 1) that are at the same origin coordinates. I couldn't find a compat flag that avoids this. Vanilla Doom 2 compatability has no such limitation. Anyone know what's going on here & whether MBF24+ should have some kind of either fix or compat option for this behavior? I don't think there's any case where a mapper would want a player to be stuck in a killable object forever when taking a teleport. Given the number of high profile WADs that want vanilla compatability (e.g. BTSX) I don't think wanting a widescreen compatible HUD that doesn't crash vanilla is a tiny absolute edge case. But I'll concede this discussion as having little relevance to MBF24+. I mainly mention it as a "while we are discussing new standards for ports to adopt" sort of bonus.

If you actually read my proposal, that's pretty much what it is, plus a part that goes between the center part and repeatable filler part. The purpose of the 'in between' part being a separate graphic is so that you can have some kind of transition between the 320px center area and the repeatable filler piece, without doing so by having a wider STBAR that would crash vanilla doom. Consider this example based on the unused widescreen bar provided in Eviternity: Looking through all the widescreen bars I have made or found, almost all of them follow this pattern to some degree (even if the 'transition' part is usually just a couple pixels wide border of some kind.) so I strongly feel that just having a repeating filler alone is not sufficient to adapt the bars for arbitrary width. If all the other crap in my proposal about origins/overlapping were discarded how do you all feel about just this above? That goes without saying and applies to everything in this entire thread.

And most of them fall apart when you play on an ultrawide monitor because they aren't wide enough, or you a play a port that scales down the HUD. The proposed NEW standard, as I'll call it here to be specific for you, will let a status bar work at any arbitrary width or scale, even something like GZdoom's default tiny scale size, without having to make something absurd like a 1280px wide bar or wider or design for any particular width. The goal is to do the work one time to support any size, rather than having to do the work again later if another aspect ratio becomes common. I never said there was no standard; I explicitly called it "the current system". I proposed a better one, which is one not hoping that the current in-vogue aspect ratio remains so in perpetuity. The vanilla compatibility is a bit of a backdoor add. While it doesn't make sense for an MBF2_ WAD to be vanilla compatible, the uptake of a newer MBF2_ by practically all modern ports that includes the theoretical new non-STBAR-overwriting method would allow even non MBF2_ WADs to get the benefit of a widescreen bar that doesn't crash vanilla.

You should check out the Marathon source port 'Aleph One', it has this kind of feature built in (Marathon ALWAYS has -shorttics - esque player angle restrictions internally, but Aleph One totally decouples the camera from it) It doesn't seem too disorienting to me, I think most people might not even notice it if nobody told them about it. Essentially with its implementation it feels totally normal except your shots slightly align to fixed angles. It's not a 'smooth transition' between the limited angles - the camera is simply separated from them entirely.

Woof has become my favorite and is what I recommend for most new Doom players. I know DSDA is the gameplay standard but I think its options menu is way too much of a bloated salad for the average person.

I would like to propose a simple standard for widescreen status bar graphics, to allow for accommodating ANY aspect ratio and more complex filling of the widescreen area, without scripting or definitions files of any kind (just supply properly named graphics). Benefits over the current system (STBAR wider than 320px): A little bit more control over what goes into the widescreen side areas of the status bar and how it deals with being cropped Allows a wad to remain compatible with Vanilla/Chocolate Doom while also supplying a widescreen status bar for other ports. (An STBAR wider than 320px crashes Vanilla/Chocolate Doom.) Allows a widescreen status bar to accommodate ANY aspect ratios or HUD scale option, even extreme cases such as ultrawide, without having to create a super wide STBAR graphic A WAD will specify widescreen status bar graphics by simply containing the following graphics lumps: STBAR - the unchanged center section, 320px wide to guarantee Vanilla engine compatibility. STBARL - this section will be drawn a single time to the left of STBAR in widescreen resolutions, potentially being cropped by the edge of the screen. STBARR - this section will be drawn a single time to the right of STBAR in widescreen resolutions, potentially being cropped by the edge of the screen. STBARL2 - this section will be drawn to the left of STBARL starting from STBARL's edge, but will horizontally tile until the edge of the screen. If there is not enough room for it on the screen (such as because STBARL is cropped by the edge of the screen) it is not drawn. STBARR2 - this section will be drawn to the right of STBARR, but will horizontally tile until the edge of the screen. If the STBARL/2/R/2 graphics are not present, the status bar draws as usual, with the default tiling flat. This allows an STBAR wider than 320px (the "standard" before this proposal) to remain working. If only STBARL or R are not present (no L2 or R2), the usual tiling texture/Woof color fill is drawn after the L and R sections end. If only STBARL2 or R2 are present (no L and R), they are drawn adjacent to STBAR and horizontally tile forever. If a WAD is loaded after the widescreen-graphics-parts-containing WAD, and that newly loaded WAD only contains STBAR, all of the STBARL/R sections are disabled. This prevents a WAD's STBAR from getting mixed up with non-matching widescreen parts loaded from an autoload folder for instance. Offset considerations for STBARL: (0,0) should be the point where STBARL meets STBAR. This allows STBARL to potentially overlap STBAR if desired, such as to erase a left edge border on the original STBAR graphic. Offset considerations for STBARR: ditto but for the point where STBARR meets STBAR. Additional, but more complicated enhancements: STBARL3 - a 'cap' that is drawn a single time on the leftmost edge of the screen. This will be drawn on top of STBARL2. This allows making a leftmost edge of an arbitrarily wide status bar background. If it is too wide to fit in full between the edge of STBAR and the edge of the screen it is not drawn. STBARR3 - ditto for right side. I might make some mockups later to visually describe the behavior of each part. Maybe, if you want to go even more crazy, this system can apply to all pics such as TITLEPIC or INTERPIC. ----- Next proposal: A simple WAD metadata lump. The metadata here should be the bare minimum requirements that the WAD needs to function. The metadata should specify: WAD display title What IWAD the WAD needs. If it doesn't have a whole UMAPINFO definition: what episode or maps it replaces. Desired complevel Why? Makes it easier for launching WADs. Let's face it, in 2024 having to separately keep track of an IWAD and complevel for each WAD you have is kind of archaic. This metadata would allow any port to easily do what it needs in order to launch a WAD into a playable state without the user needing to specify anything else. Yes most of this info is included in the idgames .txt that comes with the WAD, but those usually have too much other stuff that make them in many cases unreliable for parsing by a launcher program or Doom engine. This functionality could for instance lead the way towards ports providing in-game WAD loading with as little hassle as possible. ----- Otherwise, I agree with providing the ability to define weapons slots for new weapons. I think things like reload and zoom and other such ZDoomisms are way too far for the scope of MFB2_ and I am not sure if most people replying in this thread understand the purpose of MBF2_, but picking a weapon slot number should be comparatively simple.

The Unity port's problem is that the rumble starts as soon as you click rather than when most guns fire ~7 tics later. It would probably feel a lot better if that were fixed (doing the rumble with the gunshot instead)