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

MUSINFO: is doomwiki documentation wrong?

Recommended Posts

So, I was in the process of adding MUSINFO support to the prboom libretro core, following what's explained in: https://doomwiki.org/wiki/MUSINFO

However, I've noticed something strange. The wiki page makes the following claims:



It is used to associate music lumps to numbers, which are then referenced by "music changer" things with an editor number in the 14100—14164 range.


a thing 14100 would trigger a return to the default music for the level


Limitations for PrBoom+

Currently in PrBoom+, type 14100 has no effect, so you can't rely on it changing music to default. Also the allowed music range is limited to 1-63 inclusive, meaning that type 14164 also has no effect.


I can confirm that 14100 has no effect in PrBoom+, but it also doesn't seem to have any effect in ZDoom.

I'm also not sure if it's true that 14164 does not work in Prboom+, though I can see that in ZDoom there seems to be a 14165 (out of the range of 14100—14164) that's also a MusicChanger (and in fact, it seems the documented id for that thing is 14165).


And yet, in ZDoom wiki it's stated that the MusicChanger id range is meant to be 14101-14164 (which does not include either 14100 nor 14165).


Can I assume that 14165 is actually the id that's meant to change the music to default?

Is this implemented differently in other ports? does any port consider 14100 a valid MusicChanger?

Edited by Ferk

Share this post

Link to post
4 minutes ago, fabian said:

I have fixed PrBoom+'s MUSINFO parser to play the map's default music for thing type 14100 in SVN.


Thank you! ...but my question is: is that actually the correct behavior?

Because that's not what ZDoom seems to be doing (which I believe was the port who introduced this lump), so my impression was that the doomwiki docs are wrong.


Although if it turns out that many other ports do this, then maybe ZDoom should also support 14100

Share this post

Link to post

When I wrote the original version of the article, nine years ago already, I went with what I understood of the PrBoom+ code I had looked at. It's very likely I made a mistake since Printz later noted that the 0-value didn't work in PrBoom+. Sorry.


MUSINFO never had a formal definition of specs, it was just "hey, Risen3D does this thing, PrBoom+ copied its implementation, please copy it too in your ports, thanks".

Share this post

Link to post

Well, now it seems both crispy and doom retro are supporting 14100 just like doomwiki says. I wonder if there are wads using that.

Maybe adding support for 14100 wouldn't be out of the question for GZDoom & Eternity?

Anybody knows what did Risen3D do? Maybe 14100 is correct after all, it does make sense since 14100 - 14100 = 0 music id.


In prboom libretro port I can easily support both 14100 and 14165, though, so I'll do that.

Edited by Ferk

Share this post

Link to post

My riscos port supports 14100 to play the default music for the level.
Perhaps we could just play the default if there is a music changer on the level that isn't defined in the MUSINFO lump?

Share this post

Link to post
2 hours ago, Ferk said:

In prboom libretro port I can easily support both 14100 and 14165, though, so I'll do that. 


You should not support 14165. That's the Hexen format version which uses one of its args to define the actual number.

Share this post

Link to post
On 10/1/2019 at 8:23 PM, Ferk said:


which I believe was the port who introduced this lump

Risen3D introduced this.


On 10/1/2019 at 8:53 PM, Ferk said:

Anybody knows what did Risen3D do?

If you download R3D, it is documented here ...R3D_Docs\Editing\R3D_musinfo.txt


I thought it too large to quote here.

Share this post

Link to post

For the record: it appears that Risen3D documentation never talks about "14100" being a valid id (only 14101 to 14164 inclusive). In fact there's no reference to any specific way to make default music for the map play.


So it seems ZDoom, Eternity & PrBoom+ were following the Risen3D spec correctly by not supporting 14100 and the feature might have been sneaked into several ports due to the mistake in the wiki documentation.

Well, but since it seems there are ports using it, I guess it's not too much of a problem to support 14100 anyway.

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