MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000368Zandronum[All Projects] Suggestionpublic2011-04-04 12:312018-09-30 23:02
ReporterGez 
Assigned ToTorr Samaho 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version2.0Fixed in Version2.0 
Summary0000368: Backport MUSINFO support
DescriptionIn the interest of cross-port compatibility, I suggest adding support for the MUSINFO lump to the next official version of Skulltag. The motive being that this feature is not merely a ZDoom feature, but a new cross-port standard also supported by other ports such as Risen3D and PrBoom+. Adopting it as soon as convenient would therefore be a step forward for cross-port compatibility.
Steps To Reproduce
Additional InformationThis corresponds to ZDoom revision 2366.
TagsNo tags attached.
Relationships
parent of 0002138confirmed  MUSINFO code is not multiplayer aware 
child of 0001490closed Torr Samaho Backport ZDoom 2.5.0 
Not all the children of this issue are yet resolved or closed.
Attached Files? musinfo_test_01.wad (1,251) 2011-04-09 18:27
/tracker/file_download.php?file_id=238&type=bug
Issue History
Date ModifiedUsernameFieldChange
2011-04-04 12:31GezNew Issue
2011-04-06 01:28Torr SamahoNote Added: 0001296
2011-04-06 01:29Torr SamahoNote Edited: 0001296bug_revision_view_page.php?bugnote_id=1296#r672
2011-04-06 01:34Torr SamahoAssigned To => Torr Samaho
2011-04-06 01:34Torr SamahoStatusnew => feedback
2011-04-06 11:07GezNote Added: 0001299
2011-04-06 11:07GezStatusfeedback => assigned
2011-04-09 15:08Torr SamahoNote Added: 0001317
2011-04-09 15:08Torr SamahoStatusassigned => feedback
2011-04-09 18:19unknownnaNote Added: 0001318
2011-04-09 18:27unknownnaFile Added: musinfo_test_01.wad
2011-04-09 18:32unknownnaStatusfeedback => assigned
2011-05-01 12:06GezNote Added: 0001523
2011-05-01 23:29Torr SamahoNote Added: 0001544
2012-02-06 23:27GezNote Added: 0002579
2014-01-17 14:22GezNote Added: 0008041
2014-01-17 14:56Blzut3Relationship addedchild of 0001490
2014-01-17 14:57Blzut3Target Version => 2.0
2014-01-17 16:16DuskStatusassigned => needs testing
2014-02-09 19:39QentStatusneeds testing => assigned
2014-02-19 15:00DuskStatusassigned => needs testing
2014-04-13 01:05ArcoNote Added: 0008549
2014-05-12 21:32StrikerMan780Note Added: 0008788
2014-06-09 03:21ArcoStatusneeds testing => feedback
2014-06-21 01:40StrikerMan780Note Edited: 0008788bug_revision_view_page.php?bugnote_id=8788#r5087
2014-10-06 04:43StrikerMan780Note Edited: 0008788bug_revision_view_page.php?bugnote_id=8788#r5607
2014-10-06 09:19DuskNote Added: 0010363
2014-10-06 13:24GezNote Added: 0010364
2014-10-06 13:24GezStatusfeedback => assigned
2014-10-06 20:42DuskNote Added: 0010366
2014-10-21 01:27StrikerMan780Note Added: 0010650
2014-10-21 01:27StrikerMan780Note Edited: 0010650bug_revision_view_page.php?bugnote_id=10650#r5831
2014-10-21 01:28StrikerMan780Note Edited: 0010650bug_revision_view_page.php?bugnote_id=10650#r5832
2015-01-05 20:14DuskNote Added: 0011292
2015-01-05 20:15DuskNote Deleted: 0011292
2015-01-05 20:15DuskNote Added: 0011293
2015-01-05 20:28Torr SamahoNote Added: 0011296
2015-01-05 20:33cobaltStatusassigned => needs testing
2015-01-05 20:34cobaltNote Added: 0011298
2015-01-06 01:45DuskNote Edited: 0011298bug_revision_view_page.php?bugnote_id=11298#r6343
2015-01-06 16:04WaTaKiDNote Added: 0011314
2015-03-16 01:13DuskNote Added: 0011832
2015-03-16 01:13DuskStatusneeds testing => resolved
2015-03-16 01:13DuskFixed in Version => 2.0
2015-03-16 01:13DuskResolutionopen => fixed
2015-03-28 14:17Edward-sanRelationship addedparent of 0002138
2018-09-30 23:02Blzut3Statusresolved => closed

Notes
(0001296)
Torr Samaho   
2011-04-06 01:28   
(edited on: 2011-04-06 01:29)
I had a quick look at this: To port 2366 without conflicts, I also need to port the changes to d_main.cpp and s_sound.cpp from 2262, i.e. the move of the S_ParseReverbDef() call from the latter to the former. Can I assume that this is safe to do?
(0001299)
Gez   
2011-04-06 11:07   
I do think it is safe. All it does is load reverbs before mapinfo instead of after and I don't remember seeing any problem arising from this change.
(0001317)
Torr Samaho   
2011-04-09 15:08   
Done. Can somebody test if it works properly?
(0001318)
unknownna   
2011-04-09 18:19   
Newly connected clients aren't informed about music changes.
(0001523)
Gez   
2011-05-01 12:06   
Should this be closed and a new tracker item made for the problem unknownna found? Or can it be left this way.
(0001544)
Torr Samaho   
2011-05-01 23:29   
I think we can consider this to be not fully implemented yet and leave it open.
(0002579)
Gez   
2012-02-06 23:27   
You know what, newly connected clients shouldn't be informed about changes anyway. It's supposed to be something local to the player, as it's triggered for each player by visiting sectors. If two different players visit two different sectors with different music changers, then they should hear two different songs.

That said, there's an additional fix in r3313:'http://zdoom.org/Changelog/3313/files [^]'
(0008041)
Gez   
2014-01-17 14:22   
I guess this should fall under this umbrella.
(0008549)
Arco   
2014-04-13 01:05   
Clients new to the game are still not aware of the music changes in 2.0.
(0008788)
StrikerMan780   
2014-05-12 21:32   
(edited on: 2014-10-06 04:43)
"You know what, newly connected clients shouldn't be informed about changes anyway. It's supposed to be something local to the player, as it's triggered for each player by visiting sectors. If two different players visit two different sectors with different music changers, then they should hear two different songs."

I disagree. That should be left for LocalSetMusic only. (Sets music for one client alone.) If a server changes music globally, new clients should be made aware of the changes like normal. In fact, I need new clients to be aware of global music changes for one of my mods. (Has Dynamic/Situational Music.)

In short: SetMusic = Inform Everyone. LocalSetMusic = Music for individual clients only.

ChangeMus console command should still inform clients of the change as it does already.
(0010363)
Dusk   
2014-10-06 09:19   
This has nothing to do with SetMusic or LocalSetMusic.
(0010364)
Gez   
2014-10-06 13:24   
Quote from "Arco"
Clients new to the game are still not aware of the music changes in 2.0.

Quote from "StrikerMan780"
I disagree. That should be left for LocalSetMusic only. (Sets music for one client alone.) If a server changes music globally, new clients should be made aware of the changes like normal. In fact, I need new clients to be aware of global music changes for one of my mods. (Has Dynamic/Situational Music.)


Okay. What is MUSINFO? I think we have to explain what this feature is exactly.

MUSINFO allows to use MusicChangers in sectors. When a player enters a sector with a music changer, the music is changed for that player who is in the sector.

What does this mean for multiplayer? Supposed you have two a Y-shaped intersection. Players can move to the left or the right. Player going on the left corridor enter a sector with a MusicChanger changing the music to Never Gonna Give You Up. Player going to the right corridor, instead, get the music changed to Dragostea Din Tei. What happens if there are two players, and one goes to the left while simultaneously the other goes to the right?

If you think about it, the answer should be obvious: MusicChanger, being sector-based thing, should be LOCAL. LOCAL, not global. Local. MusicChanger should basically be a rough equivalent of LocalSetMusic.

So: clients new to the game should NOT be aware of music changes. The music should only change them when they go to the concerned sectors, not before.

It is not a global music change. It's a music change tied to areas. It changes the music for the players in an area, not for all players. It is a local computer change because it is a local sector change, and other players are not necessarily in the same sector. It's therefore local in both meanings of the term: local to the computer, and virtually local to the area of the map with the music changer.

Is it clear now? If it's not clear, I can go on and on and on. It's local.
(0010366)
Dusk   
2014-10-06 20:42   
So this would otherwise be ripe for 'resolved' but r3313 is still not backported.
(0010650)
StrikerMan780   
2014-10-21 01:27   
(edited on: 2014-10-21 01:28)
@Gez: I just got confused, because I thought Unknownna was referring to music changes of *all forms* were not being sent to clients for some reason (which would be a bug if true). I understand now.
(0011293)
Dusk   
2015-01-05 20:15   
Bump - we still need to get this out of the way for 2.0, see my note'http://zandronum.com/tracker/view.php?id=368#c10366 [^]'
(0011296)
Torr Samaho   
2015-01-05 20:28   
Backported.
(0011298)
cobalt   
2015-01-05 20:34   
(edited on: 2015-01-06 01:45)
Issue addressed by commit 82bfd5cc14af: out of sequence fix backport from ZDoom revision 3313: - Fixed: Starting in a sector with a musinfo thing would not trigger the thing. This addresses 368.
Committed by Benjamin Berkels [Torr Samaho] on Monday 05 January 2015 21:21:29

Changes in files:
 src/g_level.cpp | 5 +++++
 src/g_level.h | 1 +
 src/s_advsound.cpp | 56 ++++++++++++++++++++++++++++++++++++++++++--------------
 3 files changed, 48 insertions(+), 14 deletions(-)
(0011314)
WaTaKiD   
2015-01-06 16:04   
<WaTaKiD> kinda confused about gez's musinfo explanation, maybe cuz im dumb
<WaTaKiD> i thought if players are in different sectors, theyll hear the music of that sector, but as i join my local server twice, 1 player can switch between 2 sectors and change the music of the 2nd player, who is in a 3rd sector
<WaTaKiD> (using a modified version of the example wad with a music thing in the starting sector and d_in_cit added to musinfo)
<WaTaKiD> but this behavior is the same in zdoom 2.7.1 so i guess its working as intended?
also, the example wad already on the ticket can reproduce this behavior, so i didnt feel it necessary to upload the one i used
(0011832)
Dusk   
2015-03-16 01:13   
It's behaving as it does in ZDoom so I think we can close this now.