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

Freedoom friendly wads?

Recommended Posts

I was curious about something. I once accidentally launched Valiant with Freedoom: Phase 2 as the Iwad and I ended up with something like this:

 

doom00P.png.863cbbc3479a33e0e3e4ba99df66e3ae.png

 

The enemies would randomly switch between Freedoom enemies and normal DOOM enemies. As far as I can tell - the reason this is happening is because Valiant has extra rotation frames for the normal DOOM monsters which conflict with the Freedoom monsters (this doesn't happen if you use the normal Iwads).

This raises two questions from me:

  1. Do full 8 rotation frames exist for the Freedoom monsters?
  2. Are there any Pwads that are more Freedoom friendly? Like, ones that don't have these kinds of inconsistencies. 

 

Share this post


Link to post

I played Vanguard and some DBP wads with Freedoom just fine. But I know that Preacher also has that very same problem with the extra rotations.

 

REKKR also works fine because it replaces everything.

Share this post


Link to post
7 hours ago, Ar_e_en said:

I was curious about something. I once accidentally launched Valiant with Freedoom: Phase 2 as the Iwad and I ended up with something like this

Try Valiant: Vaccinated Edition.

 

As for your question, any mapset that only uses vanilla assets should work fine.

Share this post


Link to post

It can happen on any wad that replaces sprites, or like you said, conflicts with the FreeDoom assets. Sunlust for example has a different pallete and different sprites that overwrite the Iwad ones.

Share this post


Link to post
9 hours ago, Lol 6 said:

It can happen on any wad that replaces sprites, or like you said, conflicts with the FreeDoom assets. Sunlust for example has a different pallete and different sprites that overwrite the Iwad ones.

I've noticed that "Ancient Aliens" and "Dimensions of the Boomed" also come with special palletes, if I launch those wads with Freedoom - I get the normal DOOM monsters.

Share this post


Link to post

Most of the maps on this comment are Freedoom friendly.
Save for HFFM and 2048 Units of /vr/ that replaces the monster and the guns the first, and only the funs the later, all should work pretyy good with Freedoom.
Oh, Tangerine Nightmare also has new skin for the usual monsters, so it may also work for Freedoom as they new skin completely replaces the original one.

Do not even try to play Doom Zero with Freedoom2, i don't know how it was made, but the author made it impossible to play with it.
https://www.doomworld.com/forum/post/2383512

Edited by P41R47

Share this post


Link to post
23 hours ago, P41R47 said:

Do not even try to play Doom Zero with Freedoom2, i don't know how it was made, but the author made it impossible to play with it.
https://www.doomworld.com/forum/post/2383512

 

I did a very quick check and Freedoom seems to work fine with DOOM ZERO, it's not completely Freedoom friendly, but it does work better than expected with it. I tried it with Woof (version 6.3.1) and Freedoom (version 0.11.3) and the only problems that I found is that some of the textures were misaligned, the SSG animation was a bit wonky and the pistol animation was really wonky.

 

 

Share this post


Link to post
51 minutes ago, Ar_e_en said:

 

I did a very quick check and Freedoom seems to work fine with DOOM ZERO, it's not completely Freedoom friendly, but it does work better than expected with it. I tried it with Woof (version 6.3.1) and Freedoom (version 0.11.3) and the only problems that I found is that some of the textures were misaligned, the SSG animation was a bit wonky and the pistol animation was really wonky.

 

 

For no apparent reason, i found that the dehacked patch doesn't get loaded when i try to use Freedoom2 as an iwad, don't know why thats happening on PrBoom+2.6UM latest build.
Cool that it works, i wanted to check hos the guns looked in there with the Freedoom sprites.

Share this post


Link to post
1 hour ago, Ar_e_en said:

and FreeDoom (version 0.11.3)

 

 

Oh, I'd recommend you switch to v.0.12.1

Share this post


Link to post
7 hours ago, P41R47 said:

For no apparent reason, i found that the dehacked patch doesn't get loaded when i try to use Freedoom2 as an iwad, don't know why thats happening on PrBoom+2.6UM latest build.
Cool that it works, i wanted to check hos the guns looked in there with the Freedoom sprites.

Does it work with GZDoom?

 

6 hours ago, Lol 6 said:

Oh, I'd recommend you switch to v.0.12.1

I tried that version once. It's fine, but I didn't like some of the minor changes (some of the music placement felt odd to me).

 

Also, they got rid of the spooky red skeleton! 

I liked that guy ;(

Share this post


Link to post

I was also surprised to read that Doom Zero allegedly does not work with FD, because I remember being able to play several DZ releases, albeit I did not play extensively. I use MBF for DOS and Crispy Doom if it helps.

Share this post


Link to post
23 hours ago, MrFlibble said:

I was also surprised to read that Doom Zero allegedly does not work with FD, because I remember being able to play several DZ releases, albeit I did not play extensively. I use MBF for DOS and Crispy Doom if it helps.

Its a problem of PrBoom+UM and Woof, chocolate and other sourceport work as intended, but for some reason, those two load the embeded dehacked patch and discard the proper DZ patch, even if loaded from the command line :/

Share this post


Link to post
15 hours ago, P41R47 said:

Its a problem of PrBoom+UM and Woof, chocolate and other sourceport work as intended, but for some reason, those two load the embeded dehacked patch and discard the proper DZ patch, even if loaded from the command line :/

That's weird. I've tested Woof and the normal outdated PRBoom-Plus and the DeHackEd stuff works fine there, so I don't know where those problems are coming from. I could try and compile one of the PRBoom-Plus forks and check one of those out.

Share this post


Link to post
16 hours ago, Ar_e_en said:

That's weird. I've tested Woof and the normal outdated PRBoom-Plus and the DeHackEd stuff works fine there, so I don't know where those problems are coming from. I could try and compile one of the PRBoom-Plus forks and check one of those out.

maybe i have an outdated version.
Don't worry, if you say it works in woof, it surely work.

EDIT: i just donwloaded the lates version, and most of the deh patch work...but the level names don't, and the text screen also don't work :/
So its a mixed result... strange indeed.

Edited by P41R47

Share this post


Link to post
7 hours ago, P41R47 said:

EDIT: i just donwloaded the lates version, and most of the deh patch work...but the level names don't, and the text screen also don't work :/
So its a mixed result... strange indeed.

The end-level text screens not showing the right DeHackEd text is an issue that isn't exclusive to DOOM ZERO if you run it with Woof and Freedoom. I just launched REKKR with Freedoom: Phase 1 on Woof and the end texts were incorrect. Also, I may have an incorrect memory, but I kinda remember this happening also on the outdated PRBoom-Plus, but I may be wrong on that one. 

Share this post


Link to post
4 hours ago, Ar_e_en said:

The end-level text screens not showing the right DeHackEd text is an issue that isn't exclusive to DOOM ZERO if you run it with Woof and Freedoom. I just launched REKKR with Freedoom: Phase 1 on Woof and the end texts were incorrect. Also, I may have an incorrect memory, but I kinda remember this happening also on the outdated PRBoom-Plus, but I may be wrong on that one. 

yeah, it seems to be a problem when using Freedoom as an IWAD.

Batman Doom and STRAIN also don't show their automaps level names or text screens but the dehacked monsters and all seems to work without problem.

Share this post


Link to post
6 hours ago, P41R47 said:

yeah, it seems to be a problem when using Freedoom as an IWAD.

Batman Doom and STRAIN also don't show their automaps level names or text screens but the dehacked monsters and all seems to work without problem.

A thing that I have noticed:

If you look at a DeHackEd file in the section where the mod author has changed the end level text strings - you don't just see the newly made text, you first see the text strings from the original DOOM and then you see the newly created text. Maybe something in the many source-ports out there is looking at the DeHackEd file for both the original DOOM strings and the new mod strings, and it's checking the original text strings with whatever iwad the user has selected before it makes the changes with the new strings? And because the strings in Freedoom are different - the source-port detects a discrepancy, throws up an error and just compensates by using the preselected iwad strings instead.

 

But even this doesn't make sense, because text strings aren't stored in the original DOOM iwad, they are written inside the executable of the source-port (or a prepackaged .wad/.pk3 file that is automatically run when the port launches up). So, why would this check be required in the first place? I don't know, maybe someone with port writing knowledge has the answer as to why Freedoom doesn't change its text strings when a DeHackEd file is used.

Share this post


Link to post
42 minutes ago, Ar_e_en said:

A thing that I have noticed:

If you look at a DeHackEd file in the section where the mod author has changed the end level text strings - you don't just see the newly made text, you first see the text strings from the original DOOM and then you see the newly created text. Maybe something in the many source-ports out there is looking at the DeHackEd file for both the original DOOM strings and the new mod strings, and it's checking the original text strings with whatever iwad the user has selected before it makes the changes with the new strings? And because the strings in Freedoom are different - the source-port detects a discrepancy, throws up an error and just compensates by using the preselected iwad strings instead.

 

But even this doesn't make sense, because text strings aren't stored in the original DOOM iwad, they are written inside the executable of the source-port (or a prepackaged .wad/.pk3 file that is automatically run when the port launches up). So, why would this check be required in the first place? I don't know, maybe someone with port writing knowledge has the answer as to why Freedoom doesn't change its text strings when a DeHackEd file is used.

thats how dehacked work, actually.
Freedoom has embeded dehacked patched, altered to work under chocolate limitations.
Dehacked patches, usually, don't work together if they modifiy the same information, so, if you load two that changes the same thing, you will be seeing the information of the one loaded last.
The same as when you load two different mapsets, you will only play the one loaded alst.

Its not about a source-port not locating the original strings.
Freedoom modified them through dehacked, so the original strings are still there, too, so when you load another dehacked, it should overwrite the one inside freedoom2.wad
Chocolate Doom works as intended. And Crispy Doom works also as intended because the automap strings were altered to show a different information.

 

What is already happening, is probably that, as many sourceports allow HACX, REKKR, Freedoom and Freedoom2 to be use as IWAD, an option probably detects and read their embeded dehacked patches.
For some reason, maybe an oversight or something, this option conflicts with the option to load an external dehacked.
Thus resulting on the little bugs we found.

Kraflab already stated on the PrBoom+ thread that the bug was already fixed, at least on DSDA-Doom.
So its a matter of time of it to be ported to Woof and PrBoom+, that at this rate, seems to be falling into obvlivion since both Woof and DSDA are better offers to the same spot PrBoom+ had during long years.

Share this post


Link to post
15 hours ago, P41R47 said:

Kraflab already stated on the PrBoom+ thread that the bug was already fixed, at least on DSDA-Doom.
So its a matter of time of it to be ported to Woof and PrBoom+, that at this rate, seems to be falling into obvlivion since both Woof and DSDA are better offers to the same spot PrBoom+ had during long years.

So this bug has already been fixed, but the fix hasn't migrated to other source-ports? I guess I'll just have to wait until the fix spreads to Woof.

Share this post


Link to post
16 hours ago, Yandere_Doomer said:

A freedoom friendly wad would be without custom monsters, weapons, or any specific scripts. Basically just a wad that is plain and vanilla, just a normal map. 

Yeah, but that's too obvious, also I don't think vanilla compatibility has that much of an effect on friendliness - a Freedoom friendly mod can also be Boom/MBF/GZDoom compatible. 

Share this post


Link to post
7 hours ago, Ar_e_en said:

So this bug has already been fixed, but the fix hasn't migrated to other source-ports? I guess I'll just have to wait until the fix spreads to Woof.

well, making a bug report on the woof thread would not hurt anyone and will aslo help, if this little bug was forgotten or something.

Share this post


Link to post
On 9/15/2021 at 1:57 PM, MrFlibble said:

I was also surprised to read that Doom Zero allegedly does not work with FD, because I remember being able to play several DZ releases, albeit I did not play extensively. I use MBF for DOS and Crispy Doom if it helps.

on a side note, while testing things out, DZ crash with chocolate doom and Freedoom2.wad. with the following warning:
R_InstallSpriteLump: Bad frame character on lump 2863

Something bad on freedoom2.wad sprites, maybe?

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
×