0000368: Backport MUSINFO support

(0001296)
Torr Samaho (administrator)
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 (reporter)
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 (administrator)
2011-04-09 15:08

Done. Can somebody test if it works properly?

(0001318)
unknownna (updater)
2011-04-09 18:19

Newly connected clients aren't informed about music changes.

(0001523)
Gez (reporter)
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 (administrator)
2011-05-01 23:29

I think we can consider this to be not fully implemented yet and leave it open.

(0002579)
Gez (reporter)
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 (reporter)
2014-01-17 14:22

I guess this should fall under this umbrella.

(0008549)
Arco (updater)
2014-04-13 01:05

Clients new to the game are still not aware of the music changes in 2.0.

(0008788)
StrikerMan780 (reporter)
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 (developer)
2014-10-06 09:19

This has nothing to do with SetMusic or LocalSetMusic.

(0010364)
Gez (reporter)
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 (developer)
2014-10-06 20:42

So this would otherwise be ripe for 'resolved' but r3313 is still not backported.

(0010650)
StrikerMan780 (reporter)
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 (developer)
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 (administrator)
2015-01-05 20:28

Backported.

(0011298)
cobalt (updater)
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 (updater)
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 (developer)
2015-03-16 01:13

It's behaving as it does in ZDoom so I think we can close this now.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2011-04-04 12:31	Gez	New Issue
2011-04-06 01:28	Torr Samaho	Note Added: 0001296
2011-04-06 01:29	Torr Samaho	Note Edited: 0001296	View Revisions
2011-04-06 01:34	Torr Samaho	Assigned To	=> Torr Samaho
2011-04-06 01:34	Torr Samaho	Status	new => feedback
2011-04-06 11:07	Gez	Note Added: 0001299
2011-04-06 11:07	Gez	Status	feedback => assigned
2011-04-09 15:08	Torr Samaho	Note Added: 0001317
2011-04-09 15:08	Torr Samaho	Status	assigned => feedback
2011-04-09 18:19	unknownna	Note Added: 0001318
2011-04-09 18:27	unknownna	File Added: musinfo_test_01.wad
2011-04-09 18:32	unknownna	Status	feedback => assigned
2011-05-01 12:06	Gez	Note Added: 0001523
2011-05-01 23:29	Torr Samaho	Note Added: 0001544
2012-02-06 23:27	Gez	Note Added: 0002579
2014-01-17 14:22	Gez	Note Added: 0008041
2014-01-17 14:56	Blzut3	Relationship added	child of 0001490
2014-01-17 14:57	Blzut3	Target Version	=> 2.0
2014-01-17 16:16	Dusk	Status	assigned => needs testing
2014-02-09 19:39	Qent	Status	needs testing => assigned
2014-02-19 15:00	Dusk	Status	assigned => needs testing
2014-04-13 01:05	Arco	Note Added: 0008549
2014-05-12 21:32	StrikerMan780	Note Added: 0008788
2014-06-09 03:21	Arco	Status	needs testing => feedback
2014-06-21 01:40	StrikerMan780	Note Edited: 0008788	View Revisions
2014-10-06 04:43	StrikerMan780	Note Edited: 0008788	View Revisions
2014-10-06 09:19	Dusk	Note Added: 0010363
2014-10-06 13:24	Gez	Note Added: 0010364
2014-10-06 13:24	Gez	Status	feedback => assigned
2014-10-06 20:42	Dusk	Note Added: 0010366
2014-10-21 01:27	StrikerMan780	Note Added: 0010650
2014-10-21 01:27	StrikerMan780	Note Edited: 0010650	View Revisions
2014-10-21 01:28	StrikerMan780	Note Edited: 0010650	View Revisions
2015-01-05 20:14	Dusk	Note Added: 0011292
2015-01-05 20:15	Dusk	Note Deleted: 0011292
2015-01-05 20:15	Dusk	Note Added: 0011293
2015-01-05 20:28	Torr Samaho	Note Added: 0011296
2015-01-05 20:33	cobalt	Status	assigned => needs testing
2015-01-05 20:34	cobalt	Note Added: 0011298
2015-01-06 01:45	Dusk	Note Edited: 0011298	View Revisions
2015-01-06 16:04	WaTaKiD	Note Added: 0011314
2015-03-16 01:13	Dusk	Note Added: 0011832
2015-03-16 01:13	Dusk	Status	needs testing => resolved
2015-03-16 01:13	Dusk	Fixed in Version	=> 2.0
2015-03-16 01:13	Dusk	Resolution	open => fixed
2015-03-28 14:17	Edward-san	Relationship added	parent of 0002138
2018-09-30 23:02	Blzut3	Status	resolved => closed

Notes
(0001296) Torr Samaho (administrator) 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 (reporter) 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 (administrator) 2011-04-09 15:08	Done. Can somebody test if it works properly?

(0001318) unknownna (updater) 2011-04-09 18:19	Newly connected clients aren't informed about music changes.

(0001523) Gez (reporter) 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 (administrator) 2011-05-01 23:29	I think we can consider this to be not fully implemented yet and leave it open.

(0002579) Gez (reporter) 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 (reporter) 2014-01-17 14:22	I guess this should fall under this umbrella.

(0008549) Arco (updater) 2014-04-13 01:05	Clients new to the game are still not aware of the music changes in 2.0.

(0008788) StrikerMan780 (reporter) 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 (developer) 2014-10-06 09:19	This has nothing to do with SetMusic or LocalSetMusic.

(0010364) Gez (reporter) 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 (developer) 2014-10-06 20:42	So this would otherwise be ripe for 'resolved' but r3313 is still not backported.

(0010650) StrikerMan780 (reporter) 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 (developer) 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 (administrator) 2015-01-05 20:28	Backported.

(0011298) cobalt (updater) 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 (updater) 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 (developer) 2015-03-16 01:13	It's behaving as it does in ZDoom so I think we can close this now.