Dedicated Music Issues Thread

[LeonZA]

I am moving the music issue part out ot the other thread, because it did not belong over there. I would also like to know of anyone else can get there music to work.

Original Thread: viewtopic.php?f=8&t=38503

I really don't know how other people are getting the music to work as I think this is a problem on the server. I can get the music working flawlessly on other shards like Origins Online without any effort. Any MP3 I put in the Music\Digital folder with the correct Config.txt gets played.

I really do think that if the client does not receive the correct order of packets during login then the music just wont work correctly afterwards.

This is how it works on the other shards:
After you have selected a character and you are about to enter the world the following packets (From client point of view):
Receives 0x55 - LoginComplete
Sends 0x06 - DoubleClick
Sends 0x34 - ClientQuery
Receives 0x5B - GameTime
Receives 0x1C - ASCII Welcome message
Receives 0x6D - Play Music <-- I think it is important that this directly follows 0x5B and 0x1C
..Other packets
Any other play 6D music packets received after this play correctly.

On this shard:
Receives 0x55 - LoginComplete
Sends 0x06 - DoubleClick
Sends 0x34 - ClientQuery
Receives 0x5B - GameTime
Receives 0x1C - ASCII Welcome message
..Other packets
Any play 6D music packets received will now force the client to play the MIDI versions instead...

I might be wrong, but this is the only logical explanation that I could find after looking at all the packets.

Edit:
On the out of town music issue:
There should be two ways to get out of town music working. On the server change the 65535 music id received when leaving town to a valid music id. Not sure if that id is hardcoded in runuo though
or
Add a global out of town region with a valid music id

[LeonZA]

Any play 6D music packets received will now force the client to play the MIDI versions instead...

Just to explain this part a bit better: If it can't find the MIDI version there is just silence.

[xenoglyph]

Sorry, working music is NEA.

[LeonZA]

Sorry, working music is NEA.

lol, for some maybe. I am pretty sure I could remember music.

Anyway so I set up RunUO 2.2 and logged into it with my client and was shocked to see that it was also broken. So I played around with the scripts and got it working flawlessly

I had to edit the following files: Mobiles\PlayerMobile.cs, Misc\LoginStats.cs and Regions\BaseRegion.cs
My theory was correct about sending a music packet after the welcome message in Misc\LoginStats.cs
Any music packets after the initial music packet works flawlessly, but I also modified the code a bit so that when you travel outside a protected region a random out of town tune plays .
Any area that doen't have music assigned to it will now play a random tune. The kind of tune depends if the area is protected by guards or not.


Here are the chages that I made:
In Regions\BaseRegion.cs add the following code in the BaseRegion class:

Code: Select all

	public static MusicName GetRandomOutdoorMusic()
		{
	            Random random = new Random();
		    
		    MusicName randomMusic = (MusicName)random.Next(27,34);
		    
		    //We don't want InTown01 or Sailing
		    if ((randomMusic == MusicName.InTown01) || (randomMusic == MusicName.Sailing))
		    {
			return MusicName.Forest_a;
	            }
		    return randomMusic;
		}

		public static MusicName GetRandomIndoorMusic()
		{
	            Random random = new Random();
		    
		    MusicName randomMusic = (MusicName)random.Next(0,9);
		    
		    //We don't want Create1
		    if (randomMusic == MusicName.Create1)
		    {
			return MusicName.InTown01;
	            }
		    return randomMusic;
		}

In Misc\LoginStats.cs:
After the welcome message line:

Code: Select all

			m.SendMessage( "Welcome, {0}! There {1} currently {2} user{3} online, with {4} item{5} and {6} mobile{7} in the world",
				args.Mobile.Name,
				userCount == 1 ? "is" : "are",
				userCount, userCount == 1 ? "" : "s",
				itemCount, itemCount == 1 ? "" : "s",
				mobileCount, mobileCount == 1 ? "" : "s");

Add this after the above line:

Code: Select all

			if ((m.Region == null) || (m.Region.Music == MusicName.Invalid))
			{
			    if (m.Region != null)
			    {
				Regions.GuardedRegion reg = (Regions.GuardedRegion) m.Region.GetRegion( typeof( Regions.GuardedRegion ) );
				bool isProtected = ( reg != null && !reg.IsDisabled() );
				
				Server.Mobiles.PlayerMobile player = m as Server.Mobiles.PlayerMobile;
				if (player != null)
				{
				    player.SendMusic(isProtected);
				}				
		            }
			    else
			    {
				m.Send( Network.PlayMusic.GetInstance(Server.Regions.BaseRegion.GetRandomIndoorMusic()));
			    }
			}
			else
			{
			    m.Send( Network.PlayMusic.GetInstance(m.Region.Music));    
			}

In Mobiles\PlayerMobile.cs:
After these lines line:

Code: Select all

				if ( isProtected )
					SendLocalizedMessage( 500112 ); // You are now under the protection of the town guards.
				else
					SendLocalizedMessage( 500113 ); // You have left the protection of the town guards.

Add this line:

Code: Select all

SendMusic(isProtected);

And then add this method:

Code: Select all

		public virtual void SendMusic(bool isProtected)
		{
		    if ((this.Region == null) || (this.Region.Name == null) || (this.Region.Music == MusicName.Invalid))
		    {
		        if ( isProtected )
			{
			    this.Send( Network.PlayMusic.GetInstance(Server.Regions.BaseRegion.GetRandomIndoorMusic()));		
			}
			else
			{
			    if ((Regions.DungeonRegion) this.Region.GetRegion( typeof( Regions.DungeonRegion ) ) != null)
			    {
			        this.Send( Network.PlayMusic.GetInstance(Server.MusicName.Dungeon2)); //Most dungeons already have dungeon09 set
			    }
			    else
			    {
		                this.Send( Network.PlayMusic.GetInstance(Server.Regions.BaseRegion.GetRandomOutdoorMusic()));
			    }
		    			
		        }
		    }	
		}

Could we try these changes on the Test Shard? Is the quality of the code good enough?

[xenoglyph]

Nice work. You should probably PM Derrick if you want a timely response, I don't think he has time to monitor all the boards.

Do you know how compatible the code is with certain clients? i.e. Will this code work with a certain range of client versions, or all of them? I don't know the history of the music packet or when/if new music was added but it might be worth looking into.

[LeonZA]

Do you know how compatible the code is with certain clients? i.e. Will this code work with a certain range of client versions, or all of them? I don't know the history of the music packet or when/if new music was added but it might be worth looking into.

As far as I know that packet was sent from way back in the T2A days. I can't confirm if it was sent before T2A, but it probably also was sent.

I currently have 3 clients that I can test:
- The Second Age Client from this site. 5.0.8.3
- UOT2A from the orignail installer I have manually patched to 5.0.8.4
- 2D and 3D UOML that I have patched to 5.0.9.1

The best would be to make backups of those 3 .cs files before making the changes. Then deploy to the test shard and get as many people possible to test the changes.

[LeonZA]

Hmm, don't do anything yet. I have tried my changes on RunUO 2.1 now and it isn't working 100%. Will check what is happening different from RunUO 2.1 to RunUO 2.2.

[Derrick]

Thanks much again for your efforts on this.

I've refactored your code a bit, and have been testing it out. It works very well.
I'mna put it in for next patch.

I think one of the issues is the lack of attention to assigning music to many of the outdoor regions, there are a lot of regions....

One other thing that we are missing are the random wildlife sounds.

[LeonZA]

No problem,
What I meant about not working 100% correctly is that it seems that with RunUO 2.1(Rebirth scripts) even when the music packet is sent after the welcome message it still forces the MIDIs instead of the MP3s for some reason. On RunUO 2.2 it works fine with this code.
I briefly compared the packets sent by RunUO 2.1 and RunUO 2.2 and I did notice a few differences, but I will check all the differences when I get home from work.
From the few minutes that I looked at the packets I noticed the the Welcome message from RunUO 2.1 was in ASCII while from RumUO 2.2 the Welcome message was in Unicode, but I don't think that has anything do to with the music. There might be something received by the client even before the welcome message that forces it to use MIDIs instead of MP3s.

I will keep you updated.

[Border Patrol]

Random wildlife sounds would be awesome. I usually have music muted but the sound effects I have blasting!

[LeonZA]

Found something interesting:

Packet Name: Enable locked client features
Last Modified: 2011-10-25 11:24:59
Modified By: Tomi

Packet: 0xB9
Sent By: Server
Size: 3/5 Bytes

Packet Build
Original Legacy Client Version
BYTE[1] 0xB9
BYTE[2] Feature Bitflag

From Legacy Client 6.0.14.2+
BYTE[1] 0xB9
BYTE[4] Feature Bitflag

Subcommand Build
N/A

Notes
feature flags:

0x01: enable T2A features: chat, regions
0x02: enable renaissance features
0x04: enable third dawn features
0x08: enable LBR features: skills, map
0x10: enable AOS features: skills, map, spells, fightbook
0x20: 6th character slot
0x40: enable SE features
0x80: enable ML features: elven race, spells, skills
0x100: enable 8th age splash screen
0x200: enable 9th age splash screen
0x400: enable 10th age
0x800: enable increased housing and bank storage
0x1000: 7th character slot
0x2000: enable KR faces
0x4000: enable trial account
0x8000: enable 11th age
0x10000: enable SA features: gargoyle race, spells, skills
0x20000: enable HSA features
0x40000: enable Gothic housing tiles
0x80000: enable Rustic housing tiles

This packet is send immediatly after login.
If you need several features you have to summ the flags.


Older notes (not sure which are correct!):

if (MSB not set)
Bit# 1 T2A upgrade, enables chatbutton
Bit# 2 enables LBR update. (of course LBR installation is required)(plays MP3 instead of midis, 2D LBR client shows new LBR monsters,...)
if (MSB set)
Bit# 3 T2A upgrade, enables chatbutton
Bit# 4 enables LBR update
Bit#5 enables AOS update (Aos monsters/map (AOS installation required for that) , AOS skills/necro/paladin/fight book stuff - works for ALL clients 4.0 and above)


Examples:
ML: B980FB
AOS-7AV: B9803B
AOS: B9801B
LBR: B90003


Custom housing uses these flags to enable some parts.

for FeatureMask check floors.txt, roofs.txt etc in client folder

FeatureMask 0 = AOS ( flag 0x10 )
FeatureMask 64 = SE ( flag 0x40 )
FeatureMask 128 = ML ( flag 0x80 )
FeatureMask 512 = 9th age ( flag 0x200 )
FeatureMash 65536 = SA ( flag 0x10000 )

Seems like that the Bit# 2 flag needs to be set for MP3s to play instead of MIDIs. Will confirm if the RunUO 2.2 sent this when I get home.

[LeonZA]

Okay, that was indeed the issue. It has nothing to do with the RunUO version. The Expansion needs to be set to LBR for the Music to work, but this does raise some questions. Does setting the Expansion setting change any other mechanics/rules within RunUO? If it does then we still need to keep it on T2A but only change the flags that is sent to the client:

[Flags]
public enum FeatureFlags
{
None = 0x00000000,
T2A = 0x00000001,
UOR = 0x00000002,
UOTD = 0x00000004,
LBR = 0x00000008,
AOS = 0x00000010,
SixthCharacterSlot = 0x00000020,
SE = 0x00000040,
ML = 0x00000080,
Unk1 = 0x00000100,
Unk2 = 0x00000200,
Unk3 = 0x00000400,
Unk4 = 0x00000800,
SeventhCharacterSlot = 0x00001000,
Unk5 = 0x00002000,
Unk6 = 0x00004000,
Unk7 = 0x00008000,
SA = 0x00010000,


ExpansionNone = None,
ExpansionT2A = T2A,
ExpansionUOR = ExpansionT2A | UOR,
ExpansionUOTD = ExpansionUOR | UOTD,
ExpansionLBR = ExpansionUOTD | LBR,
ExpansionAOS = ExpansionLBR | AOS | Unk7,
ExpansionSE = ExpansionAOS | SE,
ExpansionML = ExpansionSE | ML | Unk2,
ExpansionSA = ExpansionML | SA
}


Maybe change this
ExpansionT2A = T2A,
to this?
ExpansionT2A = T2A | LBR,

Hopefully the FeatureFlags is only used within Packets.cs for the 'SupportedFeatures : Packet' class. If it is used somewhere else then we can simple harcoded the LBR flag within the SupportedFeatures consructor.

At last I know why my music wasn't working.
For MP3 music to work the correctly:
- 0xB9 packet needs to be sent with the LBR bit set during the login process.
- 0x6D music packet must be sent after the welcome message after login

[LeonZA]

Alternatively if the LBR flag enables other stuff on the client that might cause issues then we could maybe hack the client to always makes the MP3 music enabled regardless of the packet received, but I am not clever enough to do this

[LeonZA]

FYI:
Pre-LBR mode: Plays MIDIs from the 'Music' folder.
LBR mode: Plays MP3s from the 'Music\Digital' folder and also requires a Config.txt in the 'Music\Digital' to map the music ids to MP3s.

Alternatively if the LBR flag enables other stuff on the client that might cause issues then we could maybe hack the client to always makes the MP3 music enabled regardless of the packet received, but I am not clever enough to do this

The client included with UOSA already does not check for the LBR flag and plays MP3s directly from the 'music' folder as if they were MIDIs
I am not sure how they modified the client to work like that.
BUT with a drawback...They also seem to act like the MIDIs:
- After song has completed it starts playing the oldult01 to oldult06 tunes + create1 + dragflit and loops them. Not really a big issue.

In LBR mode it doesn't seem to have this issue.

Problem on both modes:
Sometimes a song does not play immediately. You have to wait till the current song is finished or alternatively you can go to combat mode and back. Again not a big issue.