WWHC-Diaz + (NEW!) The VR Missions (help wanted!)

[Zippy]

In terms of functionality, this is just a test so it won't work for multiplayer (actually, it very well might. I just didn't try), it can't be toggled on or off, it will be drawn regardless of your screenblocks settings, it ignores the status bar stretching cvar, etc. You're going to have to specify exactly how you want me to make this thing behave with regards to those things.

In other words, yeah, I'll get to it. You just need to ask for what you want and I'll hook you up. If you leave anything unspecified, I guess I'll just improvise or make it how I'd personally like it to work.

[Zippy]

Alright, here we go, prototype number 2. This one is basically the same as the last one but it adds onto it an entire ammo section, which makes a full status bar out of it (for now.) This mainly just shows that the ammo drawing works without a hitch. No problems that I could experience at least. Also, puking script 579 toggles the hud on and off, though there's no KEYCONF included in this simple package.

One thing to notice about this one is that it can act like a full status bar, which some people may or may not find preferable, probably in according with however they set their status bar scale cvar. To that end I'm sure I can make it that there are can be two versions of the hud that the user can toggle between (one similar to now with whatever kind of graphics you supply and a reduced, minimized version of the hud), or even just increase the values of SetHudSize so the relative graphics shrink. Also in that regard, if you have any kind of custom font for the ammo numbers, I'd like to work with it instead of Doom's font.

Lastly, I think things that I should add are a more prominent ammo display for the currently selected weapon, indicators for which weapons the player actually has, and getting the key display going. And, of course, add in anything else of interest that you want.

Oh, and this took a bit of time because I was testing again. And by "testing" I mean "ensure a quality product" and not "made a tiny little offset change and then played through the first 10 maps of Doom 2 a lot." Certainly don't mean that. On a side note, this is a very nice weapon wad. Since I was having so much fun, I went ahead and recorded a brief demo with this wad on everyone's favorite 'O' of Destruction and included it in the zip (demo1.lmp so it replaces the first demo) . The demo was made with SVN release 546, which I think is the latest at the time of this posting.

[wildweasel]

Alright, apologies for the silence, but I was moving and had no internet for a week...Zippy, I'm currently unable to test your HUD at the moment because a recent change to wwhc-diaz itself has resulted in GZDoom not even running.

Anybody know what's the deal?

http://armory.drdteam.org/wwmods/inprog ... c-diaz.rar

[Matt]

.......something in DECORATE line 2959.

And XWE isn't counting lines the same way GZDoom is, it seems.

...you might want to split the DECORATE into several lumps...

[wildweasel]

I'm using SlumpEd, and line 2959 has absolutely nothing wrong with it. In fact, I don't find anything wrong with the Decorate lump at all, anywhere. I'm stumped.

[DoomRater]

Summary of changes from the previous version?

Edit: My GZDoom is just slightly out of date and reports a problem with line 2735: "Frames must be a-z, [, \, or ]" so the error must be there or just before.

[Zippy]

For the record this problem manifests itself in ZDoom r546 as well. I'm not sure what it is but it is bizarre.

It told me as well that there was a DECORATE error at line 2959, Frame expected to be a-z, A-Z, etc... So, I tried removing the actor (it was a strife replacer) and ran it again and it produced the same exact error on the same exact line. I tried removing the ALL of the Strife replacer actors and it still produced the same error on the same exact line. Even more unusually, with all the Strife actors gone, the DECORATE lump doesn't even have 2959 lines, so there is no 2959th line for there to be an error on.

[DoomRater]

Needs to be posted as a bug in ZDoom bugs.

Anyway, the problem was in line 2735:

2734 Raise:
2735 NAZ5 7KJIH 5
2736 Goto See

[wildweasel]

Alright, it's fixed.

[wildweasel]

Alright, the fixed version is uploaded for those of you who don't wish to make the minor change yourself. Changes this version: I can't even remember, it's been so long!

That link again: http://armory.drdteam.org/wwmods/inprog ... c-diaz.rar

Zippy, had a look at your HUD finally, and I'd like to make some feedback on it.

- Custom fonts...um, I've been in the market for one of those lately, and if I have any intention of having it not look dumb, I may end up having to make my own. I really don't want to have to do that, though. I don't suppose anybody would be willing to write a program that generates a Doom or IMGTOOL font from a TTF font of a specified size/formatting?
- To show the player which weapons are in the inventory, I suggest that you have the individual panel for that weapon not show up at all if the player doesn't have the weapon.
- Increasing SetHUDSize would be most welcome, but instead of just shrinking it like Doom's status bar does when it's not scaled, I'd like for the pieces of the HUD to be relegated to their corners instead of centered on the bottom.
- An interesting idea I had: instead of numbers for the weapon clips, use a bar graph to indicate how much ammo is left in the magazine, and a number to show how many clips are left. Probably wouldn't work too well in practice, but I say it's worth a try.

[DoomRater]

Does HudMessage have transparency? Half transparency would be nice, or better yet puking the script with the desired transparency (0 means off) would rawk.

[Risen]

It doesn't.

[Zippy]

- Custom fonts...um, I've been in the market for one of those lately, and if I have any intention of having it not look dumb, I may end up having to make my own. I really don't want to have to do that, though. I don't suppose anybody would be willing to write a program that generates a Doom or IMGTOOL font from a TTF font of a specified size/formatting?

So long as you can supply a font I'll use it. Unfortunately, I've yet to do my own font for the experience of figuring how to make one, and even if it isn't too difficult I feel I don't have the time to put into learning it and doing it. Also, just as you say, if you want it to look how you want it to look, then you probably want to me mostly responsible for making it.

- To show the player which weapons are in the inventory, I suggest that you have the individual panel for that weapon not show up at all if the player doesn't have the weapon.

Will do.

- Increasing SetHUDSize would be most welcome, but instead of just shrinking it like Doom's status bar does when it's not scaled, I'd like for the pieces of the HUD to be relegated to their corners instead of centered on the bottom.

Will do.

- An interesting idea I had: instead of numbers for the weapon clips, use a bar graph to indicate how much ammo is left in the magazine, and a number to show how many clips are left. Probably wouldn't work too well in practice, but I say it's worth a try.

It certainly can be done as doing bar graphs isn't especially difficult. It will likely increase the number of hud messages used unless I use a different bar graph algorithm. The health/armor bars are done by having 5 bar graphics: 50 pixels wide, 25 pixels wide, 10 pixels wide, 5 pixels wide, 1 pixel wide. The total size of a full bar is 50 pixels. Basically, it "fills up" the bar with the largest units of pixels it can, reducing size when it has to. So, 84 health? 84 / 2 = 42 -> draw 25 (25), draw 10 (35), draw 5 (40), draw 1 (41), draw 1 (42). The bar can thus be filled up to the SetHudSize'd pixel using no more than 8 HudMessage's.

Individual bar graphs for all ammo in clip done in that way would substantially increase HudMessage's used. However, there are alternatives. Maybe for the clip ammo bars, make it so there are only a maximum of 10 pixels (or generic larger "units" to be more visible) and there is an explicit graphic for each state (1 pixel/unit, 2 pixel/unit, 3 pixel/unit, etc...) Then you only need have to one HudMessage for each clip, though if you don't make the units SetHudSize'd pixels then you will lose the pixel precise accuracy.

Anyway, I'll give it a shot... see what works and everything.

[DoomRater]

Wow, I would have done something more like "draw four 10's and draw a 2" for the life bar, so that only two would be needed at any point... I didn't even look at the source personally but that it how I would do it. You'd have a graphic for 1 through 10, and 84 health breakdown goes like 84 / 2 = 42 -> 40 + 2; 40 / 4 = 4 -> draw four 10's in a row, 2 -> draw a 2.

Edit: Oh yeah, superhealth means needing one more.

[Risen]

Given that the bars draw to the side of the screen, you could use a single 50px wide graphic and change only its offset.

I didn't look at your example, just looking at weasel's screenshot.