Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There is no toggle-able option for "Vertical Level Stats & Player Co-ords Widgets" #2179

Open
PorpiangWriter opened this issue Feb 4, 2025 · 13 comments

Comments

@PorpiangWriter
Copy link

Even Woof 15.2.0 offers the Vertical Level Stats & Player Co-ords Widgets option, but I can't toggle it either on the game itself or the CFG file.

@rfomin
Copy link
Collaborator

rfomin commented Feb 4, 2025

It's toggleable in SBRADEF, see woof.pk3/sbardef.lmp: "vertical": true

@fabiangreffrath
Copy link
Owner

Same is true for centered messages (i.e. they can be modified by SBARDEF), and nevertheless we added a switch to the menu for them. Maybe another such exception could be added here as well?

@PorpiangWriter
Copy link
Author

Well, I'm going to check out the pk3 files, however, I think this Vertical Level Stats & Player Co-ords Widgets option should be easier to access.

@NiIex
Copy link

NiIex commented Feb 12, 2025

I second PorpiangWriter motion. Stats look great vertically in Automap but I can't handle them horizontally on HUD so I turned them off there. Hopefully a convenient menu toggle is not too far away :)

Btw while drifting through the SBARDEF forest I noticed one in .\all-all & .\id1-wad folders differ on line 1239. Intentional? LoR-specific weapon carousel related perhaps?


I'm thinking about modifying HUD stats coordinates for myself to match Automap ones, before menu toggle or editor come about. To that end if you could indulge me, a couple of quick questions to get me started.

Where's the origin of the X/Y coordinates (they go up to 320/200 right)?
Do all 3 stats share the same widget coordinate or each one has its own?

That should be enough to find my way around, thank you!

@rfomin
Copy link
Collaborator

rfomin commented Feb 12, 2025

Btw while drifting through the SBARDEF forest I noticed one in .\all-all & .\id1-wad folders differ on line 1239. Intentional? LoR-specific weapon carousel related perhaps?

This is intentional. id1.wad has a different sprite for cells.

Where's the origin of the X/Y coordinates (they go up to 320/200 right)?

It's the upper left corner of a 4:3 screen, so from (0, 0) to (320, 200). If you want widgets to move to the left in widescreen mode, you need to enable the wide alignment flag ("alignment": 16).

Do all 3 stats share the same widget coordinate or each one has its own?

They share widget coordinate.

@NiIex
Copy link

NiIex commented Feb 13, 2025

Managed to do it but it'll look like butcher job to you pros :)

Had to delete sbardef.lmp from pk3 (all 3, not sure if less is sufficient) for my changes to apply. Seems Woof overrides the .lmp loaded with -file parameter with default ones in pk3. That was what stopped me yesterday, after I figured that out it was pretty easy since it's all about the coordinates and I grew up on 320x200. Thanks for your help!

@NiIex
Copy link

NiIex commented Feb 13, 2025

Small guide how I did it, for future Internet travelers. It matches Stats widget position & orientation with one in Automap.
(works only for wide-screen ratios "alignment": 16)

  1. Extract "sbardef.lmp" from "woof.pk3" that comes with Woof! (7-Zip or similar will do)
    Take one from all-all folder for regular Doom WADs, or id1 for Legacy of Rust.
  2. Open it with any text editor that shows lines (Notepad++ for example)

Stats "widget" appears 4 times, once for every HUD (Classic with Status Bar, Crispy, LoR, and no HUD) and you'll want to change all 4 places. Or simply ignore 3 other HUDs you never use, your call. Btw there is another widget entry exclusive to Automap - you may adjust that one too if you really want to. Each HUD's widget section starts at specific line of the document. Simply adjust its "y" and add "vertical". Note that adding lines will shift everything down slightly.

Status Bar and Crispy HUD - lines 843 and 2727 ("y" was 160)
LoR HUD - line 1684 ("y" was 155)
No HUD - line 3017 ("y" was 192)

"widget" ("type": 0 & "alignment": 16)
  "y": 8,
  "vertical": true, (add bellow "Digits")
  1. Save changes and load "sbardef.lmp" with -file parametar as you would a normal PWAD.

Note that changes won't work if any WAD you load is named either all-all, extras, or id1. That's because Woof has a built-in lumps for such names and will prioritize them from its default woof.pk3 over -file. It normally applies only to Legacy of Rust which is named id1. Simplest workaround is to rename id1 to something else, or you may use the autoload trick described bellow.

Method is sadly locked to v15.2.0 as I presume future Woof updates will eventually scramble sbardef content, in particular "widget" positions in the document. Every time you update Woof you'll have to repeat the process but with different line positions. Or at least until Woof gets user-friendly UI support. Just remember to delete your trusty sbardef and its -file parametar when latter happens.

@rfomin
Copy link
Collaborator

rfomin commented Feb 13, 2025

Had to delete sbardef.lmp from pk3 (all 3, not sure if less is sufficient) for my changes to apply. Seems Woof overrides the .lmp loaded with -file parameter with default ones in pk3.

I can't reproduce it, woof -file sbardef.lmp should overwrite sbardef.lmp in woof.pk3. You could also put it in the autoload folder.

@NiIex
Copy link

NiIex commented Feb 13, 2025

Hmm, that's odd. Though maybe it was because of my -noautoload parametar so I removed it but it's still the same. Default woof.pk3 overrides -file sbardef.lmp.

After further testing and removing more -file parameters one by one... it turns out to be a pretty bizarre reason. When I removed Legacy of Rust "id1.wad" then sbardef lump finally started to override default woof pk3.

My full parametar order is -noautoload -save ..\rerelease\Saves -shotdir ..\rerelease\Screenshots -iwad ..\rerelease\DOOM2.WAD -file ..\Patches\D2SPFX20.WAD ..\rerelease\id1.wad ..\rerelease\sbardef.lmp ..\Patches\doom_wide.wad -config ..\rerelease\legacy.ini

Tried replacing id1.wad with "Doom the way id did" wad (only one I have on hand currently) just to see if maybe any PWAD (even though it's not Doom2) causes it but nope, only id1 messes up lump/pk3 override it seems. What do you make of that one? :)

@rfomin
Copy link
Collaborator

rfomin commented Feb 13, 2025

id1.wad has it's own SBARDEF lump. To overwrite it, put your sbardef.lmp in autoload\id1.wad folder.

@NiIex
Copy link

NiIex commented Feb 13, 2025

Suspected as much. Same thing happens if any wad with all-all/extras/id1 name is loaded.
Thanks for getting to the bottom of that little detail. I'll update the guide above.

I don't like using autoload feature so I just renamed id1 to legacy :)

@fabiangreffrath
Copy link
Owner

fabiangreffrath commented Feb 13, 2025

So, I just tried to give it a shot, but oh well!

diff --git a/src/mn_setup.c b/src/mn_setup.c
index b6636cd5..de0fe729 100644
--- a/src/mn_setup.c
+++ b/src/mn_setup.c
@@ -325,6 +325,7 @@ enum
     str_center_weapon,
     str_screensize,
     str_stlayout,
+    str_stralign,
     str_show_widgets,
     str_show_adv_widgets,
     str_stats_format,
@@ -1830,6 +1831,10 @@ static const char *st_layout_strings[] = {
     "Original", "Wide"
 };
 
+static const char *st_align_strings[] = {
+    "Default", "Never", "Always"
+};
+
 #define H_X_THRM8 (M_X_THRM8 - 14)
 #define H_X       (M_X - 14)
 
@@ -1843,6 +1848,9 @@ static setup_menu_t stat_settings1[] = {
     {"Layout", S_CHOICE, H_X, M_SPC, {"st_layout"},
      .strings_id = str_stlayout},
 
+    {"Vertical Stats/Coords", S_CHOICE, H_X, M_SPC, {"st_align"},
+     .strings_id = str_stralign},
+
     MI_GAP,
 
     {"Status Bar", S_SKIP | S_TITLE, H_X, M_SPC},
@@ -4796,6 +4804,7 @@ static const char **selectstrings[] = {
     center_weapon_strings,
     NULL, // str_screensize
     st_layout_strings,
+    st_align_strings,
     show_widgets_strings,
     show_adv_widgets_strings,
     stats_format_strings,
diff --git a/src/st_sbardef.c b/src/st_sbardef.c
index 30cbe368..53299389 100644
--- a/src/st_sbardef.c
+++ b/src/st_sbardef.c
@@ -222,6 +222,7 @@ static boolean ParseSbarElemType(json_t *json, sbarelementtype_t type,
                             json_t *vertical = JS_GetObject(json, "vertical");
                             if (JS_IsBoolean(vertical))
                             {
+                                widget->default_vertical =
                                 widget->vertical = JS_GetBoolean(vertical);
                             }
                         }
diff --git a/src/st_sbardef.h b/src/st_sbardef.h
index 54f4500d..7240b96e 100644
--- a/src/st_sbardef.h
+++ b/src/st_sbardef.h
@@ -205,6 +205,7 @@ typedef struct sbe_widget_s
     int duration;
     int duration_left;
 
+    boolean default_vertical;
     boolean vertical;
 } sbe_widget_t;
 
diff --git a/src/st_stuff.c b/src/st_stuff.c
index c087b592..0d05baa2 100644
--- a/src/st_stuff.c
+++ b/src/st_stuff.c
@@ -1905,6 +1905,8 @@ void ST_BindSTSVariables(void)
 {
   M_BindNum("st_layout", &st_layout, NULL,  st_wide, st_original, st_wide,
              ss_stat, wad_no, "HUD layout");
+  M_BindNum("st_align", &st_align, NULL, st_align_default, st_align_default,
+             st_align_always, ss_stat, wad_no, "Vertical Stats/Coords");
   M_BindBool("sts_colored_numbers", &sts_colored_numbers, NULL,
              false, ss_stat, wad_yes, "Colored numbers on the status bar");
   M_BindBool("sts_pct_always_gray", &sts_pct_always_gray, NULL,
diff --git a/src/st_stuff.h b/src/st_stuff.h
index 5a935db9..32fb94c1 100644
--- a/src/st_stuff.h
+++ b/src/st_stuff.h
@@ -78,6 +78,15 @@ const char **ST_StatusbarList(void);
 
 void ST_BindSTSVariables(void);
 
+typedef enum
+{
+    st_align_default,
+    st_align_never,
+    st_align_always
+} st_align_t;
+
+extern st_align_t st_align;
+
 #endif
 
 //----------------------------------------------------------------------------
diff --git a/src/st_widgets.c b/src/st_widgets.c
index d5619cbb..4ff92ebd 100644
--- a/src/st_widgets.c
+++ b/src/st_widgets.c
@@ -702,6 +702,24 @@ static void ForceDoomFont(sbe_widget_t *widget)
     }
 }
 
+st_align_t st_align;
+
+static void ForceVertical(sbe_widget_t *widget)
+{
+    if (st_align == st_align_default)
+    {
+        widget->vertical = widget->default_vertical;
+    }
+    else if (st_align == st_align_always)
+    {
+        widget->vertical = true;
+    }
+    else
+    {
+        widget->vertical = false;
+    }
+}
+
 static void UpdateCoord(sbe_widget_t *widget, player_t *player)
 {
     ST_ClearLines(widget);
@@ -723,6 +741,7 @@ static void UpdateCoord(sbe_widget_t *widget, player_t *player)
     }
 
     ForceDoomFont(widget);
+    ForceVertical(widget);
 
     fixed_t x, y, z; // killough 10/98:
     void AM_Coordinates(const mobj_t *, fixed_t *, fixed_t *, fixed_t *);
@@ -816,6 +835,7 @@ static void UpdateMonSec(sbe_widget_t *widget)
     }
 
     ForceDoomFont(widget);
+    ForceVertical(widget);
 
     const int cr_blue = (widget->font == stcfnt) ? CR_BLUE2 : CR_BLUE1;
 
diff --git a/src/st_widgets.h b/src/st_widgets.h
index 7c47750e..b978e5e2 100644
--- a/src/st_widgets.h
+++ b/src/st_widgets.h
@@ -83,4 +83,4 @@ void ST_ResetMessageColors(void);
 
 void ST_BindHUDVariables(void);
 
-#endif
\ No newline at end of file
+#endif

Image

So, I have mistaken it the other way round. STBARDEF tells the engine if a widget has vertical alignment and which coordinates to use, it's not the engine that chooses vertical alignment for a widget. 😞

@rfomin
Copy link
Collaborator

rfomin commented Feb 13, 2025

So, I have mistaken it the other way round. STBARDEF tells the engine if a widget has vertical alignment and which coordinates to use, it's not the engine that chooses vertical alignment for a widget. 😞

We can add another condition and set coordinates for vertical widgets in various automap modes in SBARDEF. But I think this option is not worth it. At this point, editing without an editor is cumbersome even for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants