This is Woof! 14.3.0 (Mar 15, 2024)

[rzh]

1 minute ago, NightFright said:

I will try it in other ports and play around with Woof settings to see if it has any impact.

 

Something else I noticed, btw: This particular addon uses custom graphics for the keys in the statusbar (arrows for keycards and circles for skull keys) which screw up the keys display in the Boom-style fullscreen HUD. Maybe a good idea could be to have an optional override for such cases to use the default Doom key graphics (in the Boom HUD only).

There's also the issue with having an autoloaded .wad with big font graphics for all menu items, where certain WADs like Avactor or Dimensions of the Boomed replace some of these menu items with their own, but General or Setup still show up with the default Doom big font since no such replacement is provided.

If not all of the graphics are replaced (in this case they are, partially by the autoload WAD, partially by the other one), then the entire menu gets displayed with the default small font.

I'd say these cosmetic issues are kind of low on the priority list if at all, since nothing is wrong with the port itself in this scenario.

I guess a different logic could be implemented in order for the port to better handle this type of situation, but I have no idea how feasible it would be or even if it's worth the effort.

[NightFright]

The thing is, one could load a small fix wad with keycard images as override, but then it screws up the regular statusbar which you would still see on the automap. It's tricky and I dunno how many pwads cause issues like that.

 

Coming up with a solution isn't easy without including graphics in a separate resource wad, which should be avoided. I guess a menu option could optionally ignore all replacements loaded for the specified gfx lumps (but only where it makes sense, in this case the Boom HUD only), if that is doable at all. It's definitely a rather cosmetic issue, yet sometimes those are the ones that puzzle me quite a bit for some reason... 😅

[Average]

I just noticed in the dev build that there's now an option to centre in-game messages.  I just wanted to say thank you so much. :)

 

PS:  Also loving the new colourised message option for key pick ups.  

[garu32]

13 minutes ago, Average said:

I just noticed in the dev build that there's now an option to centre in-game messages.  I just wanted to say thank you so much. :)

 

PS:  Also loving the new colourised message option for key pick ups.  

Just asking, how do I download the dev builds?

[Average]

Just now, LucasRafael132 said:

Just asking, how do I download the dev builds?

Just look under the Actions tab near the top of the page, choose the latest build, scroll down to the bottom of the page and download the zip file. :)

 

https://github.com/fabiangreffrath/woof

[garu32]

2 minutes ago, Average said:

Just look under the Actions tab near the top of the page, choose the latest build, scroll down to the bottom of the page and download the zip file. :)

 

https://github.com/fabiangreffrath/woof

Thanks man!!

[Average]

You're welcome. :)

[NightFright]

2 hours ago, NightFright said:

[...] It's definitely a rather cosmetic issue, yet sometimes those are the ones that puzzle me quite a bit for some reason... 

One thing just came to my mind: While the issue seems trivial, the Boom HUD is supposed to look the same at all times. Therefore it should ignore changes to any resources it uses, in this case the key images.

Edited June 3, 2022 by NightFright

[Shepardus]

5 hours ago, NightFright said:

One thing just came to my mind: While the issue seems trivial, the Boom HUD is supposed to look the same at all times. Therefore it should ignore changes to any resources it uses, in this case the key images.

What if the in-game graphics of the keys are changed (e.g. recolored keys) and the HUD indicators are just changed to match? I think cases like 400minvr, where the replacement graphics don't mesh well with the Boom HUD, are more the exception than the rule (and frankly the graphics they chose for that wad were unintuitive to me even in the normal status bar HUD, so I don't really see it as a Boom HUD issue in the first place).

[Mr. Alexander]

On 6/2/2022 at 10:59 PM, rfomin said:

Because it's work in progress and not finished. Hopefully we will make a new release soon.

 

23 hours ago, NightFright said:

If you had an account, you would find these builds conveniently precompiled for you in the "Actions" tab after clicking on latest (topmost) commit in the master branch, on the bottom of that page.

Thanks very much to you both! I downloaded the precompiled latest build from the GitHub page. This build doesn't have the high-res/widescreen-res-option problem. Keen to put this port through its paces!

[rfomin]

10 hours ago, rzh said:

There's also the issue with having an autoloaded .wad with big font graphics for all menu items, where certain WADs like Avactor or Dimensions of the Boomed replace some of these menu items with their own, but General or Setup still show up with the default Doom big font since no such replacement is provided.

Not much we can do about it. Theoretically, we could add support for the ZDoom BIGFONT lump, but not all WADs provide it (for example, Avactor does not), and GZDoom already deprecates it. Also, the current behavior is the same as PrBoom+ and both of these WADs have been tested in it, so maybe this is the intention of the authors? (or lack of time)

[rzh]

2 hours ago, rfomin said:

Not much we can do about it.

Yeah, I knew this is probably outside of Woof's jurisdiction, which is why I posted it here :P

It's ok, everyone that contributed to Woof already did more than enough and I can only wish I could repay you for all of your effort.

Thank you for your work!

[liPillON]

I was trying out the latest devbuild and found something wrong with the automap zoom key bindings:

when using keyboard keys (ie: "i" for zooming in and "o" for zooming out) we get the expected behaviour

when using the mouse wheel (ie: "up" for zooming in and "down" for zooming out) we get the opposite behaviour

 

woof 9.0, dsda 0.24.3 and gzdoom 4.7.x all behave on my pc as expected, so it should not be an issue with my mouse/drivers

 

should I open an issue on github?

 

[rfomin]

19 hours ago, Delfino Furioso said:

I was trying out the latest devbuild and found something wrong with the automap zoom key bindings:

when using keyboard keys (ie: "i" for zooming in and "o" for zooming out) we get the expected behaviour

when using the mouse wheel (ie: "up" for zooming in and "down" for zooming out) we get the opposite behaviour

Hmm, this works as expected for me so far. I think yes, a github issue with more details would be appreciated.

[LuciferSam86]

Played a bit of JUMPWAD with this sourceport and worked really well (I'm using the excellent Doom Explorer as GUI)

A question : there was a plan/idea to implement freelook in a future version of this port, or such feature is out of scope ( I hope I used this term correctly) for this port?

 

[fabian]

44 minutes ago, LuciferSam86 said:

A question : there was a plan/idea to implement freelook in a future version of this port, or such feature is out of scope ( I hope I used this term correctly) for this port?

 

It's already implemented and waiting for the next release. 

[liPillON]

3 hours ago, rfomin said:

Hmm, this works as expected for me so far. I think yes, a github issue with more details would be appreciated.

 

opened as issue #580

[LuciferSam86]

45 minutes ago, fabian said:

 

It's already implemented and waiting for the next release. 

Oh sweet. So if I compile from the master branch I can try it ? 

[fabian]

50 minutes ago, Delfino Furioso said:

opened as issue #580

 

And closed, thanks! 

 

11 minutes ago, LuciferSam86 said:

Oh sweet. So if I compile from the master branch I can try it ? 

 

Yes!

[Gez]

On samedi 4 juin 2022 at 10:59 AM, rzh said:

Yeah, I knew this is probably outside of Woof's jurisdiction, which is why I posted it here :P

It's ok, everyone that contributed to Woof already did more than enough and I can only wish I could repay you for all of your effort.

Thank you for your work!

There are threads for widescreen art packs, and UMAPINFO packs, why not create one for missing menu graphics and other miscellaneous cosmetic enhancements? Crowd-sourcing that stuff is probably the best option.

[rzh]

2 hours ago, Gez said:

There are threads for widescreen art packs, and UMAPINFO packs, why not create one for missing menu graphics and other miscellaneous cosmetic enhancements? Crowd-sourcing that stuff is probably the best option.

I could definetly see a thread for missing titlepic, M_ files (maybe even endoom) and so on. Too bad I'm just an ideas man, usually someone has to start working on a project in order to inspire others to join.

[Lila Feuer]

I am playing Reverie for Doom II, on MAP15: Blade Runner and may have found an issue.



It is the bottom most middle, there are presumably shootable switches (marked with skulls), in addition to being stuck I am at a loss as to whether or not this is a bug. Pinging @valkiriforce for more context if possible (also I have no idea what to do or where to go after hitting the red switch).

Off-topic edit: Figured out the red key problem, wasn't too obvious at first, just hope that slender section of the map is housing a secret and isn't mandatory to proceed.

Edited June 9, 2022 by Lila Feuer

[valkiriforce]

@Lila Feuer Those skulls aren't actually shootable switches, they were just decorations. The red switch unlocks one of the northern buildings over the waters which holds the red key.

[NightFright]

Cool stuff, they also added swirling liquids from International Doom now. Another great visual bonus feature!

[rzh]

And I already found an unwanted effect with it :P

Not sure if it can be fixed though.

The bridge/ pathway also swirls.

[fabian]

4 hours ago, NightFright said:

Cool stuff, they also added swirling liquids from International Doom now. Another great visual bonus feature!

Sorry, but squirling flats is an original feature from SMMU which I have adopted into Crispy - which in turn is where International Doom has inherited it from. 

[Ar_e_en]

4 hours ago, NightFright said:

Cool stuff, they also added swirling liquids from International Doom now. Another great visual bonus feature!

I'm looking forward to this!

[fabian]

1 hour ago, rzh said:

And I already found an unwanted effect with it :P

Not sure if it can be fixed though.

The bridge/ pathway also swirls.

Can't be fixed if the bridge is defined as an animated flats sequence. 

[NightFright]

1 hour ago, fabian said:

Sorry, but squirling flats is an original feature from SMMU which I have adopted into Crispy - which in turn is where International Doom has inherited it from. 

Fair enough. It's just that I have seen this implementation for the first time in International, that's why I mentioned it. But good to know where it originally came from.

 

And that bridge part is probably also an animated flat since it's transparent and has slime parts underneath it which are animated. I guess that's a rare but possible limitation of the feature. Guess you would have to turn it off in such cases. It might possibly also happen for brightmaps, btw (that texture/sprite parts are brightmapped which shouldn't be) - even though I still have no direct example.

[LuciferSam86]

A low priority report: I was playing Attack on IO with Vesper (Woof commit: 5f5e0e2 compiled with Visual Studio 2022 x64 build (if that matters)) and I found this on Map 03: a weird HOM effect that doesn't exist if I play it on GZDoom.

The coordinates are on the top (I've used IDMYPOS).

 

The second screenshot is taken with GZDoom 4.8 with the same mods, and as you can see, there is the sky.

 

The complevel set on Woof is 21, on GZDoom there is no complevel selected.

 

If you want I can post an issue on github.

 

 

Edited June 10, 2022 by LuciferSam86