Could we standardize how voodoo dolls interact with music changer objects?

[T-117]

I've recently become aware that boom-compatible source ports do not all have the same behavior when it comes to music changer objects and voodoo dolls.  Some source ports (like GZDoom) change the music for the player when a voodoo doll enters a sector with a music change object.  For other ports, the voodoo doll is not considered the same as the player and so the music changes for the doll but not the human player.  When mapping for Zdoom, it has been a useful feature to be able to change music remotely via voodoo doll for a significant fight.  Is there a good reason this should not become the standard behavior when a doll encounters a music changer object?  Co-op could be a concern I guess; but it seems easy enough to not put music change objects in voodoo doll closets if you don't want that behavior in your co-op map.  Any thoughts?

[ramon.dexter]

How can you put words "standardize" and "voodoo dolls" into one sentence is beyond my understanding... :D

 

Since the "scripting" with voodoo dolls is more a hack than actual programming, what kind of standardization you want? Also, you're speaking about various ports. Some are limit removing, while some are vanilla. When you want to make for, for example, gzdoom, just use all the stuf gzdoom offers - acs, zscript and more. If you target limit removing, use hacks. But dont expect such hacks to work everywhere the same. These are after all hacks, so some ports have these hacks fixed, while others not.

Edited August 30, 2022 by ramon.dexter

[T-117]

The kind of standardization I'm going for is how a voodoo doll's interaction with a music changer object affects the music for the local player, nothing else.  This would apply only to ports that support the MUSINFO lump and the music changer object.  The whole point is to try and have similar behavior when targeting a wider range of ports.

[ramon.dexter]

But the ports are different, that's the point! Also, technically, voodoo doll trighers the action, the doll is the one for whom the music will change. It makes complete sense. So, again, you want some kind of hack as a standard. Sorry, this is just impossible.

[Bauul]

I'm curious what ports support a music changer object, and how the behavior differs between them.

 

You say for GZDoom it changes the music for all players, but what are the other ports, and what happens there?

 

Basically if this is something you feel strongly about, you'd need to petition the developers of the source ports with the behavior you do not agree with to change their code (or do it yourself and petition to accept the pull request).

[Faceman2000]

20 hours ago, T-117 said:

boom-compatible source ports

 

10 hours ago, ramon.dexter said:

Also, you're speaking about various ports. Some are limit removing, while some are vanilla.

No, he quite clearly isn't. He's speaking exclusively about MUSINFO coupled with a Boom-compatible behavior in Boom-compatible ports. Suggesting that this behavior be standardized makes a lot of sense.

 

10 minutes ago, Bauul said:

I'm curious what ports support a music changer object

According to the DoomWiki, CrispyDoom, PrBoom+ and derivatives, ZDoom and derivatives, Eternity, Risen3D, and Doom Retro support it. There's not any concern with Crispy because it doesn't have conveyor belts so you wouldn't want to use a voodoo doll to remotely trigger it. As for the behavior in each of these ports, I'm not sure.

Edited August 30, 2022 by Faceman2000

[T-117]

1 hour ago, Bauul said:

I'm curious what ports support a music changer object, and how the behavior differs between them.

 

You say for GZDoom it changes the music for all players, but what are the other ports, and what happens there?

 

Basically if this is something you feel strongly about, you'd need to petition the developers of the source ports with the behavior you do not agree with to change their code (or do it yourself and petition to accept the pull request).

I only know about this "issue" because I was converting a map I made for GZDoom using Decorate over to MBF21 so as to be a bit more accessible.  During the conversion process, using DSDA-Doom, I noticed that the music wasn't changing during certain fights any longer.  So I assume (perhaps incorrectly) that it works as I describe in Zdoom based ports but not in those derived from PRBoom.  I did check PRBoom+ UM and it has the same behavior as DSDA.

As to your last comment, I actually did submit a GitHub issue about this to the DSDA maintainers and was told it wouldn't be changed unless it became the standard behavior.  I don't really know who decides these things among the community at large so I figured I'd at least get the conversation going.