Freedoom friendly wads?

[Ar_e_en]

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:

 

 

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. 

 

Edited September 11, 2021 by Ar_e_en

[Antkibo]

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.

Edited September 11, 2021 by Antkibo

[Rudolph]

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.

Edited September 11, 2021 by Rudolph

[xX_Lol6_Xx]

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.

[Ar_e_en]

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.

[P41R47]

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 September 13, 2021 by P41R47

[Ar_e_en]

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.

 

 

[P41R47]

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.

[xX_Lol6_Xx]

1 hour ago, Ar_e_en said:

and FreeDoom (version 0.11.3)

 

 

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

[Ar_e_en]

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 ;(

Edited September 14, 2021 by Ar_e_en

[MrFlibble]

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.

Edited September 15, 2021 by MrFlibble

[P41R47]

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 :/

[Ar_e_en]

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.

[P41R47]

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 September 18, 2021 by P41R47

[Ar_e_en]

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. 

[P41R47]

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.

[Ar_e_en]

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.

[Yandere_Doomer]

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. 

[P41R47]

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.

Edited September 18, 2021 by P41R47

[Ar_e_en]

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.

[Ar_e_en]

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. 

[P41R47]

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.

[P41R47]

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?

[EricxDu]

I haven't found very many mods incompatible with Freedoom. Coincidentally, Valiant is the only weird one I've run into! Two of my favorites are Bury My Heart Knee Deep and Suspended In Dusk. I'd say they're not only compatible, but I think Freedoom's high-tech/alien aesthetic meshes well with the map concepts.

[Ar_e_en]

Most of the sprite based incompatibilities occur due to the new sprites trying to mesh with the original DOOM sprites and not with the Freedoom ones. A long time ago - I played "Pirate Doom" with Freedoom as the iwad. From what I remember - "Pirate Doom" (if it ran with Freedoom as the iwad) has an incompatibility with the Hell-Knight sprites, specifically - one of its back sprites will switch to the Freedoom equivalent.

[RonLivingston]

I recognize Scythe 2 and kamasutra being compatible with freedoom