[SBARINFO] "AltHud" StatusBar type

[Xaser]

Here's a simple-to-explain one. I've noticed there's no way to replace the Alternative HUD using SBARINFO, rather surprisingly. An "AltHud" type for StatusBar definitions could be very useful here, especially considering how the default Alternative HUD doesn't work very well with certain mods (e.g. Psychic). Being able to define a custom version of it would be useful, indeed.

[Enjay]

You can do a limited amount of customising using [wiki]ALTHUDCF[/wiki] (basically you can use it to add or remove items) but I agree that more customisability would be nice.

[Xaser]

Ah, even if this is [No]'d, it's good to know it's possible to tweak it a bit. Thanks there.

Still, I see no reason to disallow full customizability of it, even if (as I suspect might be the case) the AltHud itself cannot be translated into SBARINFO.

[Project Shadowcat]

I agree with this feature suggestion (i.e., if the Big Numbers aren't even in an IWAD) but it certainly urges modders to make sure it is very close to what it shows now. It does have a lot of information in a HUD that isn't at all distracting.

[Blzut3]

I believe Graf added the alt hud to ZDoom for the sole purpose of providing an alternative when SBarInfo is in use.

[Project Shadowcat]

AltHud has also been around since before your SBARINFO advancements, too.

[Zippy]

If I recall, Blzut3 has got the spirit of the idea dead on. The point of the alt hud was to provide a hud in the event that the one included with the wad was really unsatisfactory to the player. Hence, an alternative hud the player always has the option to fall back on. In which case the customization you get may be limited.

[Xaser]

Are you sure that's why it was done? The althud itself was created before SBARINFO for sure, though I don't know of its exact date of inclusion in 'vanilla' ZDoom. If that predates SBARINFO as well, then it can't be for that reason.

Regardless, this situation proposes a bit of a dilemma: What about those of us who don't care for the alternative HUD? I'll use myself as an example: I find it takes up a bit too much space, and prefer the fullscreen HUD over any of the other default ones. However, my preferred HUD style can be replaced at the will of the modder already -- not like that's a bad thing, as long as it's done all right. But the point is, for me, there is no satisfactory alternative HUD for me to fall back on.

At its core, I suppose this is yet another one of those modder vs. player issues. If we see it as such, though, then the current functionality is very odd: Here we have two HUDs (status bar and fullscreen) that are freely override-able and one (althud) that is not. If the player's choice in such a situation is really preferable here, as you say, then the current position is not satisfactory, as illustrated above. This essentially means that we should either be allowed to replace the AltHud or we should have a cvar that disables use of SBARINFO entirely. And I'm afraid of what the latter situation's implications would be.

[Graf Zahl]

The alt HUD is completely outside the status bar code as it was designed initially for a non-ZDoom engine. When I later merged my original code with ZDoom it remained that way. This is why the SBARINFO code can't access it.

[Gez]

Regardless, this situation proposes a bit of a dilemma: What about those of us who don't care for the alternative HUD? I'll use myself as an example: I find it takes up a bit too much space, and prefer the fullscreen HUD over any of the other default ones.

Try the althudscale CVAR. I put it at 0.5 and it looks good that way IMO.

At its core, I suppose this is yet another one of those modder vs. player issues. If we see it as such, though, then the current functionality is very odd: Here we have two HUDs (status bar and fullscreen) that are freely override-able and one (althud) that is not. If the player's choice in such a situation is really preferable here, as you say, then the current position is not satisfactory, as illustrated above.

The difference is that you have the SBARINFO code of the normal status bar and fullscreen HUDs. So you can take that SBARINFO lump out of ZDoom.pk3, and then load it along with the other mod. As long as it's loaded after, it'll override the other mod's SBARINFO and you'll get the normal HUD back.

[Xaser]

Exactly -- and along the same lines, if this is added, I'd expect that doing the same would enable the AltHud again. I figured the current AltHud, because of its nature, would need to stay in its semi-hardcoded state. That's fine as long as there's an SBARINFO option to enable the default AltHud back, much like you can use the Base command to bring back the default Doom/Heretic/Hexen/Strife status bar. No harm done, then.

Try the althudscale CVAR. I put it at 0.5 and it looks good that way IMO.

Hmm, was this CVAR added recently? It doesn't seem to exist, but my SVN build's likely a little bit out of date.

[EDIT] Never mind, found it. It's hud_althudscale, silly.

[Blzut3]

Personally I would prefer to have the alt hud remain a user option. I recall it being stated many times in the past that the alt-hud could be used as a fallback for people who didn't like the custom huds. Perhaps a good solution to get a user to use the custom status bar is to have a third option "unless custom" which would detect if a new sbarinfo lump is loaded and switch back to the normal hud?

Since Graf didn't auto-no this I will reconsider my opinion if there is enough demand.

[Graf Zahl]

I think the best option would be to let the SBARINFO decide for itself if such replacement makes sense. Then anyone creating a HUD with relevant info that's not visible in the alt HUD can say that if such a user option is on it will override the alt HUD. The only problem I see here is again the idiot factor. I'm dead certain that some stupid individuals still think it's ok to annoy the players of their mods by trying to force something they shouldn't. But with a 'never' option I can live with that.