Fullscreen Statusbar Mod [v5.1.9]

[3saster]

Implemented interpolation for all level stats and pushed to the repo. You were right Milten, it looks a lot better overall, not just on percentages. It has a little tricker to do than I'd have liked, but I got a little creative and managed to implement it. I tested it as best as I could, but I am not 100% confident it works flawlessly, so feel free to use the GitHub dev version to insure I didn't miss anything.

[XxMiltenXx]

Thanks for the quick implementation!

Yeah, it's a little complicated, but it seems like you managed . Everything looks correct to me and it works fine ingame.
The only thing I would've done differently, is to use 3 DynamicValueInterpolators (1 for kills, 1 for secrets, 1 for items) instead of seperating them between percentages, fractions and countdowns as well and then worked with Switches to determine between them. But that would have required more CVar checks, so albeit being maybe a little shorter, it might've been a little bit more "performance-hungry", so I think your implementation is better.

I also just tested an interpolation speed user option, however, due to the small numbers (0 to 100 for percentage) the actual speed difference is negligible, so I don't think it's worth the effort to actually implement it.

Anyway, great work as usual @3saster & @NightFright!

[3saster]

I actually initially did do three, rather than nine, but I ran into the problem that you could not dynamically switch properly. If you were on fraction and kill 1000 enemies, then switch to percentage, it would stay at 1000 until unpaused, then lower to the percentage. Quite frankly, it looked really bad and inconsistent with the other instantaneous changes, so I decided to store the values separately across nine. Minor issue perhaps, but distracting. For reference, this mod is not performance intensive at all; a few more CVAR checks would be fine for maintainibility, but there were other problems.

I dont plan on implementing user speed for interpolation. The default speed is totally fine, even for large numbers, and the point of interpolation is more to see the number smoothly rise than anything else. Besides, that would probably be an unnecessarily confusing user option.

It seemed easy at first, but there were a lot of problems to deal with in practice. The trickiest one was when you finished a level, the values would not reset, and would lower to zero from their previous value, it looked really weird. Eventhandlers for detecting level changes is a no go either, because they cannot access the ui scope. I eventually came up with the solution of checking the map name every tick and seeing if it changed from the previous tick, and if so reset the values. It sounds simple now, but it took a long time to come up with it...

[NightFright]

Level stats resetting on map change was actually already an issue in pre-5.0. Good that it was finally addressed. Really didn't look great to watch those stats reset, especially for percentages. Surprising how much additional code this whole interpolation thing required, though.

[azeta]

is this mod only compatible with the latest version of gzdoom? I keep trying to use it with gzdoom vintage but it doesnt work

[NightFright]

You will indeed need GZDoom 4.2.0 or later to use this. If you can't run it, you will have to keep using the last SBARINFO release, v4.10.3. I have attached it here again for your convenience.

[3saster]

Actually, it turns out that with minimal changes, I can make it support GZDoom Vintage. You will need the latest devbuild of GZDoom Vintage/LZDoom. You can find the vintage build here, though it will have some missing features compared to the non-vintage version. Also note that I did this because there was little I needed to change; the second it becomes less trivial to maintain, consider support dropped. If someone wishes to fork the project to maintain legacy support, feel free to do so.

[drfrag]

You don't need to do that but i don't visit mod threads very often. Actually the vintage build has been discontinued and replaced with LZDoom. It should run with the next LZDoom release.
I missed something but now it aborts with an unknown font 'NewConsoleFont' error.
This line:

Code: Select all • Expand view

s.fnt = "NewConsoleFont";

Changing it to

Code: Select all • Expand view

s.fnt = NewConsoleFont;

makes it run.
That font doesn't exist in the legacy builds, it's fake.

[3saster]

There are two reasons it won't work on LZDoom/GZDoom vintage without changes. The first is the new console font (which you provided a fix for, although the spacing is different), and the second is that DrawAmmoBar is not defined in LZDoom. If DrawAmmoBar were provided in the next LZDoom build, this would work without changes from the main version. BTW, is there a convenient place to get LZDoom devbuilds? The DRDTeam site has gzdoom-vintage, but I can't tell if that's LZDoom or not.

Is there a particular reason LZDoom doesn't use the NewConsoleFont?

[drfrag]

But why does the mod need to load the VGA font? Unless i'm missing something it's already loaded by the engine. The legacy builds don't support the modern UI and it would look bad anyway. The spacing is wrong since it's not the real font, just choose a different font. BTW changing the stats font i don't see any difference in GZDoom, are they disabled by default?
Next time do a bug report and i will try to fix it. The vintage build is discontinued but like i said i'm still updating the legacy branch in order to port the code to LZDoom in two steps and that way people can still "suck" code from there. We haven't changed the devbuilds to LZDoom yet, will do in a few days. This way you could have both and they actually slow down development since i try to minimize the number of devbuilds. No big deal until now since they're pretty much the same for GZDoom derived stuff.

This is the LZDoom branch:
https://github.com/drfrag666/gzdoom/commits/g3.3mgw

[Yebudoom]

This is a great HUD mod, thank you for all the work put into this. One tiny suggestion though: I think the split bars would make more sense with Health and Armor on the left, and Ammo counter on the right side. It would be more intuitive IMO. I know keeping Ammo with Health on the left side is consistent with the traditional Doom status bar, of course. But when the bar is split, I'd arrange it like previously said: Health/Armor (left), Ammo/Keys (right). But that's just me

Would it be possible to make it toggleable? If you see any sense in my idea, that is.

[NightFright]

And here we go again. No, it's not planned to do this currently. If it ever changes, we'll let you know.

As I have already pointed out before, this may work for the standard Doom statusbar, but not for other mods that alter STBAR more excessicely. It also adds a lot of code for a feature I cannot help but find secondary at best. That also goes for native upscale pack support, btw. This is a direction I refuse to take with this project.
If this is getting done, it's gonna be a branch in GitHub and will stay as such. No merge with master.

Priority right now is adding Strife support, anyway.

[Yebudoom]

And here we go again. No, it's not planned to do this currently. If it ever changes, we'll let you know.

As I have already pointed out before, this may work for the standard Doom statusbar, but not for other mods that alter STBAR more excessicely. It also adds a lot of code for a feature I cannot help but find secondary at best. That also goes for native upscale pack support, btw. This is a direction I refuse to take with this project.
If this is getting done, it's gonna be a branch in GitHub and will stay as such. No merge with master.

Priority right now is adding Strife support, anyway.

Damn, I had read through the last three pages of this thread and there was nobody mentioning a similar idea, so I thought "Right, I'll be the first one to suggest it". Turns out, I should have digged a little deeper, because a similar idea was actually here FOUR pages back. Since then, I've read through the whole thread. My apologies, I see now what the issue with implementing this would be.

[site]

That also goes for native upscale pack support, btw.

Last night i just happened to browse through the patch dropbox on a whim and saw that you had made new 5.x versions of the patches. So that was my bad. I must have missed you saying you updated those in the 5.0 announcement

[NightFright]

Yeah, like I wrote earlier, all 4.x patches have been updated except for Alien Vendetta and Avactor (which didn't need any change), Speed of Doom (no longer needs a fix in 5.x) plus the two Woolball fixes which will return at some later point.

Old patches are still available in the 4.x folder on Dropbox if needed.