Menu
▾
▴
#97 Show level status.
Hello:
I recently created a patch for my own amusement in which the level stats (monsters killed, secrets found and items picked up) are shown to the player. I added the ability to turn it on and off via the options menu and wondered if you would be interested in reviewing the code and merging it.
There are some caveats though:
- There are funky size and spacing issues when changing from game to menu (maybe some state carried over by V_DrawString?)
- Might be a bit redundant with ST_overlayDrawer if recompiled so cv_stbaroverlay.string adds e and s (no items, I thinkg).
- Did not do much testing. I know it works in Doom, Doom2 and Heretic, don't know about Strife at all but I guess we could check gamemode_t mode?
Overall, I made it because I personally like to know how I'm doing. If you think this could be a worthy addition, please, let me know how could we proceed.
Thanks for your time.
Hi again:
Now that I'm at it I patched in the ability to make next/previous weapon changes be "accumulative" to ease play with a gamepad. What this mean is if I had all weapons and had the pistol equipped I could do three quick "next weapon" taps to equip the chaingun. I considered having a toggle key for "change weapon" and mapping each weapon to a pad button, but that seemed cumbersome.
The feature can be toggled on and off from the menu/shell (I guess console too somehow?) and I think it would work with two-player split-screen.
What I don't think it would work good with is with demos because I haven't touched those. Maybe I would need to change how it works because the structure that tracks the change works locally and is not stored in a ticcmd_t (it could, of course) but for demo compatibility we should also check if the feature is enabled in the demo, etc...
Again, these are all for my own pleasure but I'm all for reviewing these and trying to incorporate them to the codebase.
Hello, and thank you for showing such interest in Doom Legacy.
I am currently just days from releasing 4.8.10, and am trying to finish up on bugs I already know about, but have failed to fix, yet.
As examples, FR96 and FR97 sat around for a year, got improved a bit, and then in a flurry of action, I got around to doing something about them. It depends if the feature request brings something that is significant to many users.
I also have a series of improvements I want to work on, and less time to work on them, due to having to put more time on some possibly income producing projects.
When you have code you like, submit a code file (zip file usually) to this FR as an attachment. Eventually I will get around to looking at it.
Any code submitted will get heavily modified (usually mangled). I am mangling much of the existing code too, trying to make it easier to maintain.
Question will be:
- How many other users will find this useful ?
- Will it interfere with any existing displays ?
- How much work to include the code ?
- Does it duplicate any existing displays ?
- Do other Doom ports do similar things ?
- Can it be made part of the existing status panels ?
- Can this be added as more options in the existing configurable overlay display. Most users probably don't realize this exists.
- Does it need to be blocked or controlled during netplay ?
- Can it be used as a cheat during deathmatch ?
- How much of it should be saved as config, or should it just be a temporary display, like frame-rate.
Status displays have been a can-of-worms. The status display code was rewritten several years ago, so the existing display functions should be used.
Status displays have to support:
- Doom status bar
- Doom overlay status
- Heretic status bar
- Heretic overlay status
- Software draw and OpenGL draw, which use different sized fonts, and different kerning, and different positioning.
- Compatibility with the frame-rate display.
An overlay display with the vanilla status bar would clash.
It may be that such a display would only work as an addition to the overlay display.
DoomLegacy supports Doom, Heretic, and Chex, but not Strife, at least not yet.
Hexen will be next, as DoomLegacy 2.0 has support for that.
Last edit: Wesley Johnson 2021-10-28
Hi Wesley:
Thanks for your reply. Before going on to business, a word about my interest in Doom Legacy, so we can know why these things come from out of nowhere. Doom Legacy and I date back to a couple decades ago. It was the first Doom port I ever tried, the one I most played and the one I did maps for. Back in the day I used to pester Hurdler and Smite-Meister in NewDoom.com about putting slopes in but as the years went on and the forums closed I drifted away from the whole Doom scene and moved on to another things. Recently I started replaying Doom and Legacy is still my port of choice but this time around I figured I could try and contribute.
That said, I would like to answer the questions you posted (I will group them, as the same answer applies to most)
- How many other users will find this useful ?
- Do other Doom ports do similar things ?*
To my knowledge, PrBoom, PrBoom+, CrispyDoom and ZDoom derivatives do this. I think there are more. Considering that the current ST_overlayDrawer allows for two out of the three counters, I would say its useful, though hidden from the user view.
- Does it duplicate any existing displays ?
- Will it interfere with any existing displays ?
- Can it be made part of the existing status panels ?
- Can this be added as more options in the existing configurable overlay display. Most users probably don't realize this exists.
- How much of it should be saved as config, or should it just be a temporary display, like frame-rate.*
Turns out it does duplicate the job of ST_overlayDrawer, but does not interfere with anything to my knowledge. At the time I did not realise that we could set the "overlay" variable through console (maybe a bit too obscure for the average user) so I was thinking something like this:
0) Turn the feature into "overlay only", no status bar, to avoid modifying it.
1) Add a separate option to put them in the automap (so status bar players can access the info).
2) Add item count to ST_overlayDrawer.
3) Add a prefix to the ST_overlayDrawer so we know what we look at (something like K:1/10, I:10/10, S:1/3, right now it's not apparent what each number is)
4) Maybe make the Y position of these items not fixed, so there won't be no gaps if you activate only two items.
5) To make it more accesible to users, create an options menu for the overlay display with the following Yes/No parameters: draw health, draw armor, draw frags, draw ammo, draw keys, draw monster kills, draw items, draw secrets. Turning them on and off would modify cv_stbaroverlay.string (this can have the effect of altering the order of kills, items and secrets... we can always put them in fixed positions if we don't want that). cv_stbaroverlay is defined as CV_SAVE, so it would be saved with the rest.
6) Add "all monsters/items/secrets have been slain/collected/revealed" messages when a player reaches 100% in singleplayer and the features are active.
I don't think so. Its mostly a single player/coop thing
I would strive to make it easy. The changes in the menu would be integrated into the existing codebase, no other way around that (I can make #includes with the patches into separate files). Drawing the counters in the overlay would be segregated to a new header/implementation pair (given that I would make it available to the automap too). New messages would be added to the strings part. Functions to check if these messages exists would reside in new files. All new files would be there for your ease of use, so you could reimplement them however you see fit. I would also include a diff file, so you can see the changes.
Finally, I would make sure to test it with the Doom, Doom2 and Heretic, both in software and OpenGL.
As for the next/previous weapon change thing, I don't think it is mature enough for Legacy. Maybe I could segregate it into a different module so I can keep it for myself, build it on top of 4.8.10 and iterate. What I could do is add some little changes to NextWeapon so it returns a weapontype_t, add another function that converts weapontype_t to byte (as expected in a ticcmd_t when changing weapons) and connect these two. It is a very small cleanup measure and would make any future changes easier.
I will submit a zip file with the source when done. Cheers and thanks for your time!.
Hello.
Here's the zip file. Inside you will find:
I have been testing it with Doom2 and a bit of Heretic and everything seems under control. In the future I would like to contribute with some more things (for example, the ability to use a gamepad in the automap), if that's allright.
If you need an email account so we can discuss something there, please just let me know.
Cheers.
| - How many other users will find this useful ?
+1 (most interested in secret count/secrets found)