Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

This is Woof! 2.3.0 (Sep 21, 2020) [Updated WinMBF]

Recommended Posts

I really like this port, its basically a strong limit removing port with Boom and MBF compatibility and doesn't feel the need to change anything regarding the gameplay or quirks. Thank you!

Share this post


Link to post
4 hours ago, hawkwind said:

Woof seems to have issues with certain masked mid textures.

 

Single-patched masked textures with a different height between the texture and the patch, yes.

Share this post


Link to post
4 hours ago, fabian said:

 

Single-patched masked textures with a different height between the texture and the patch, yes.

There is no diffference in the height between the texture and the patch.

The patches are ZCLOCK01-04, 160x160 pixels, and the textures are exactly the same.

So there is still an issue.

Share this post


Link to post

How does "rescue dying friends" work? I know this is from the original MBF source but I'm just now noticing Lee's (honestly pretty cool) additions to enemy AI, but I can't really seem to find anything on what it changes.

Share this post


Link to post

I'd also like to request that the autoloaded wads\DEHACKED patches are loaded before those in the command line -- mostly for the sprite fixing project.

Share this post


Link to post
19 hours ago, maxmanium said:

I'd also like to request that the autoloaded wads\DEHACKED patches are loaded before those in the command line -- mostly for the sprite fixing project.

 

In general, I agree. However, for some unknown reason, Lee explicitly decided to load them last:

 

https://github.com/fabiangreffrath/woof/blob/583e6d2196438bc8099abd41eeb2f844b519ba51/Source/d_main.c#L1742

 

Edit: I guess I figured it out. DEHACKED lumps are processed from last to first, so it actually makes sense to load "preloaded" DEH files last - their changes will be overridden by DEHACKED lumps included in WADs and DEH files loaded from the command line. WAD files, however, are loaded in order and thus override each other. Now, what happens with DEHACKED lumps in WAD files? If preloaded WAD files contain DEHECKED lumps, these will get processed last if the WAD files are loaded first. I guess that's what Lee wanted to avoid by loading "preloaded" WAD files last - this way makes sure that their embedded DEHACKED lumps will be processed first.

Edited by fabian

Share this post


Link to post

Been using Woof! for a few weeks now,  I heard talk about it in another topic, and I thought to myself: "What the hell is Woof!?"

I was curious. A new port? I never used Marines Best Friend, but I did manage to try it out for "historical purposes". I thought it was a decent port, for the time.

I recently switched from using GZDoom: to Crispy Doom (for purist reasons.) And then when I tried Woof!, I fell in love immediately. 

 

Now all I use on a daily basis: is Crispy and Woof.

 

Please continue to release new versions! excited to see the progress!

 

 

Share this post


Link to post

I'm probably about to sound like a complete nonce but... how do I actually run "WooF!"?

When I downloaded what I thought was the main files, there wasn't any .exe file in the folders. I thought it may have needed WinMBF to work but that did nothing (WinMBF just worked like usual).  Any idea what I'm supposed to do? :S

Share this post


Link to post
1 hour ago, maxmanium said:

I'm getting a "Bad V_CopyRect" crash with Pathogen after taking any significant amount of damage. Something to do with the status bar face?

Yeah, the vertical offsets on some of the images are a pixel too low, which is enough to go past the intended drawing area. STFST3* being one example, the y offset is -2 but the original statusbar face is only -1 on that one. This isn't a problem unique to Woof, occasionally PrBoom+ will crash too (but not always, depends on your system and which PrB+ version?). If you don't want to fix it yourself, maybe Crunchynut will if you post in that thread?

Share this post


Link to post
1 hour ago, plums said:

Yeah, the vertical offsets on some of the images are a pixel too low, which is enough to go past the intended drawing area. STFST3* being one example, the y offset is -2 but the original statusbar face is only -1 on that one. This isn't a problem unique to Woof, occasionally PrBoom+ will crash too (but not always, depends on your system and which PrB+ version?). If you don't want to fix it yourself, maybe Crunchynut will if you post in that thread?

 

Still seems to crash on STFST1* (STFKILL1?) even after fixing it.

 

EDIT: It's definitely STFKILL1. Even SLADE keeps crashing when I try to zoom or move the image...

Edited by maxmanium

Share this post


Link to post

I have just released Woof! 2.3.0:

  • Binaries are now built with optimization flags and debugging information (stripped for release).
  • A "secret" option to force integer video scaling factors has been added ("integer_scaling").
  • A mouse button binding for the "Use" action has been added. Double click acting as "Use" has been made optional.
  • The "Ouch Face" and the "Picked up a Medikit that you really need" message are now shown as intended.

https://github.com/fabiangreffrath/woof/releases/download/woof_2.3.0/Woof-2.3.0-win32.zip

 

You may have to rebind your mouse buttons!

Edited by fabian

Share this post


Link to post
15 hours ago, fabian said:

A mouse button binding for the "Use" action has been added. Double click acting as "Use" has been made optional.

My man! Thanks for this.

Share this post


Link to post

I am using Woof! 2.1.0 currently due to my in-progress playthrough of Icarus: Alien Vanguard and on MAP29: Brutality I've ran into a game stopper due to this switch doing nothing (it's suppose to raise the floor you're on in order to get to the switch up there). The other one opposite of me was the first of such switch/platform raising and it worked whereas this one won't budge. This is a vanilla megawad from 1996 so I've no idea what could've went wrong but looks like I'm noclipping.

doom00.png

doom01.png

E: This area is all kinds of screwed up, I had to noclip two more times as I couldn't get to other switches, again from the floors not raising. Also don't ask me why DW made this text blue.

Edited by Lila Feuer

Share this post


Link to post

It looks like those switches are stair builders? IIRC the algorithm for building stairs is a little different in Boom/MBF. Under Options->Setup->Doom Compatibility->2nd Page->"Use exactly Doom's stairbuilding method", is it set to yes?

 

edit: I can confirm the stairs build only when that stairbuilding compat option is set to NO, which I think is not the default. This is also the case for PrBoom+ with complevel 11. So, "working as intended" I guess, though maybe the default should be changed (if it doesn't mess up Boom/MBF stairs that is...)

Edited by plums

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×