ZScript: Status Bar Questions

[Major Cooke]

I figured I'd dedicate this thread towards status bars and any questions pertaining to it, seeing as this is going to be a very radical redesign.

• How are we going to 'replace' huds when one is using a custom version?
• Can they be set to certain classes and/or conditions like SBARINFO?
• Will it be possible to no longer require copy/pasting over the sbar code if, for example, another mod brings in a hud of its own as an 'addon'?*

*- Right now, that's pretty much how it has to be done. To add onto the sbarinfo, one would have to copy/paste the entire thing over from the original to the addon and then add special conditions, which forces addon developers to constantly keep an eye out for the mod they're making it for.

[Graf Zahl]

Forget SBARINFO. I only use it as a guideline of what kinds of elements I need to implement.

But since you are dealing with a script here you can pretty much check for any condition that can be detected and draw whatever you like if a condition is true or false - even instantiating an existing other status bar class and use its functionality.

[Major Cooke]

Eeeeeeexcellent~!

[Graf Zahl]

A small example from the Doom status bar:

Code: Select all • Expand view

   //ammo
   drawimage ammoicon1, -14, -4, centerbottom;
   drawnumber 2147483647, HUDFONT_DOOM, untranslated, ammo1, drawshadow, -25, -20;

   usesammo
   {
      //secondary ammo and inventory
      usessecondaryammo
      {
         drawimage ammoicon2, -14, -22, centerbottom;
         drawnumber 2147483647, HUDFONT_DOOM, untranslated, ammo2, drawshadow, -25, -38;
         inventorybarnotvisible
         {
            drawselectedinventory centerbottom, drawshadow, alwaysshowcounter, HUDFONT_DOOM, -14, -39, -26, -56, untranslated;
         }
      }
      else //no secondary ammo
      {
         inventorybarnotvisible
         {
            drawselectedinventory centerbottom, drawshadow, alwaysshowcounter, HUDFONT_DOOM, -14, -21, -26, -38, untranslated;
         }
      }
   }
   else // no ammo but inventory
   {
      inventorybarnotvisible
      {
         drawselectedinventory centerbottom, drawshadow, alwaysshowcounter, HUDFONT_DOOM, -14, -3, -26, -20, untranslated;
      }
   }



becomes

Code: Select all • Expand view

      if (ammotype1 != null)
      {
         DrawInventoryIcon(ammotype1, (-14, -4));
         DrawString(mHUDFont, FormatNumber(ammotype1.Amount, 3), (-30, -20), DI_TEXT_ALIGN_RIGHT);
         invY -= 20;
      }
      if (ammotype2 != null && ammotype2 != ammotype1)
      {
         DrawInventoryIcon(ammotype2, (-14, invY + 17));
         DrawString(mHUDFont, FormatNumber(ammotype2.Amount, 3), (-30, invY), DI_TEXT_ALIGN_RIGHT);
         invY -= 20;
      }
      if (CPlayer.inventorytics == 0 && CPlayer.mo.InvSel != null)
      {
         DrawInventoryIcon(CPlayer.mo.InvSel, (-14, invY + 17));
         DrawString(mHUDFont, FormatNumber(CPlayer.mo.InvSel.Amount, 3), (-30, invY), DI_TEXT_ALIGN_RIGHT);
      }


[ZZYZX]

How do I point the statusbar to a ZScript class?
Will it completely replace all statusbars or like SBARINFO did it (separate for fullscreen, separate for regular, and althud disables any custom statusbars)?
How do I make something draw over statusbar hudmessage-style that'd work with any statusbar even the internal ones? I made RenderOverlay for that, but then Graf said it's going to be in the statusbar.

[Major Cooke]

You beat me to asking.

[Nash]

I'll want to move my ACS-HudMessage compass to the statusbar... I hope the draw refresh is not capped to 35 FPS...

[Major Cooke]

Only for the menus.

[Nash]

That's what I was worried about from the start. :( Really need RenderOverlay... otherwise there's not much difference to the abomination that is HudMessage abuse...

Perhaps there's can be a way to expose RenderOverlay safely from the status bar API? The restriction system is already in place, after all...

I don't mean to sound annoying, I'm trying my best to do things properly in the engine and without resorting to hacking...

[Major Cooke]

Wait, you're talking about when menus don't pause the game aren't you? I don't think that counts in this regard...

Menus and status bars are two whole different things.

[Nash]

Uh... what? I'm not talking about making a menu. I'm talking about an on-screen compass (like in Borderlands, Skyrim, GTA etc etc). I use it to plot enemies and quest objectives for the player to see.

Technically, I would consider it a status bar element. It's supposed to be part of the player's HUD.

It looks crappy when done via HudMessage because the draw refresh there is stuck at 35 FPS. I want the compass to update and rotate smoothly in real-time, at uncapped frame rates.

If the status bar API's draw refresh is also capped at 35 FPS... then, well, as I said, that's not much different than just using hacky ACS.

[Major Cooke]

Only for the menus.

I think you misread my post when you responded, then.
Specifically I meant list/option menus.

In no way did I say they would be related to status bars.

[Nash]

No, I didn't misread your post.

You answered my question, that the status bar API draw refresh is locked to 35 Hz. Whether that answer is accurate or not, I don't know yet - I'm holding on to your word (unless Graf or ZZYZX proves that your answer was wrong).

I responded with, I was worried that that was the case from the beginning. I then proceeded to elaborate why I think 35 Hz is not ideal for the use case I intended to use it for.

You then responded by talking about something completely unrelated to my question. I replied that what I was trying to do was this basically: https://staticdelivery.nexusmods.com/mo ... 447193.jpg

[Major Cooke]

...I was saying, only menus will lock the FPS to 35. Only when they're active for that player.

In no way did I mention status bar API's draw, I only mentioned the menu. I firmly think that sbars are not stuck with this limitation at all unless proven otherwise.

[Nash]

Ah, in that case, your short reply to my question was indeed confusing. I read it as, "only the menus can draw at uncapped framerate".

So, my question still remains unanswered then.

And no, I haven't tried the engine yet because I don't want to start using heavily-WIP code that will probably change tomorrow. I'll wait for the work to finish first before diving into it.

Still, I feel that asking some questions beforehand is harmless.