Adding SVC like svc_cdtrack but w/fullname music file

[Baker]

Please no "But existing Quake mods/maps use cd track" stuff ... this isn't for that ...

I don't like "svc_cdtrack" for level music because it is a byte field (This means you have to call track names track000.ogg or whatever and this is 2011 and I could care less about the CD player.). I have to obfuscate author's filenames and for no good reason. This isn't a field likely to be sent more than once per level most of the time.

I want to add something like ...

Code: Select all

"svc_musictrack",         // [string] background music name without extension

I don't care what the name is "svc_bgmusic" or "svc_whatever" ... and I don't care what the number is.

But I don't want to muck up the existing status quo or do something incompatible (like the 14 different ways to specify a skybox or the 10 folders it might be in).

I would like to use the actual music name, like "thissong.mp3" or "thissong.ogg" as is (obviously in worldspawn with its own field).

Part 1: Does DarkPlaces or FTEQW already do this?
Part 2: What should the svc name be (svc_bgmusic? Etc.)
Part 3: What should the svc number be?
Part 4: Does this need an extension, I suppose? What should it be called?

This is provided this isn't already in DarkPlaces or FTEQW. Just looking for the correct way to do this.

[szo]

AFAIK, darkplaces doesn't have a svc for this (I may be wrong, though.) As for the number to use, the last svc number in original quake is 34 implying that 35 can be used if you don't care about qw. As for the trivial point about the svc name, svc_bgmusic sounds fine I guess. Hexen2 uses svc_midi_name for this purpose (it originally uses it for midi background music but I extended it to use ogg/wav/mp3/etc replacements as well in uhexen2.)

In any case, a new svc_* message will definately dictate a protocol change and require support from the map side as well. Don't know how feasible would that be given the massive amount of chaos already present..

[metlslime]

Well, first of all if you just want to support this filename being in the worldspawn, you don't need a server message. The client can read it out of the bsp the same as fog and skybox support works.

However, if you want quakec to be able to change the music track on the fly, then you do need a server message. And you should be aware that this means a new protocol number (because if a stock client gets a message it doesn't recognize, it will crash.) And it also means a new quakec builtin, and a new "extension" so that quakec can query the engine and find out of the builtin is available before attempting to use it. (otherwise attempting to use it when it doesn't exist would cause a server crash i think.)

[szo]

Well, first of all if you just want to support this filename being in the worldspawn, you don't need a server message. The client can read it out of the bsp the same as fog and skybox support works.

... which is much better, I agree.

However, if you want quakec to be able to change the music track on the fly, then you do need a server message.

Well, one can always do a stufftext for "music filename.ext" (this requires quakespsam implementation which takes this kind of possibility into consideration. and yeah, stufftext is evil and will kill your dog, I know..)

PS. for Baker: if you ever want to do what you plan and do that svc_bgmusic thing, please do not omit the file extension.

[mankrip]

The number of the CD track is defined is defined by the "sounds" field in the worldspawn entity, and since the table of entities is stored as text... You can probably just hack the engine to also accept a string from this field, by copying the string to somewhere else, and setting the field to "0" when parsing the map's entities table.

Also, maybe the "cd remap" command could be changed to support filenames. This would solve everything, with no need to change protocols, and would make the above hack unnecessary.

[Spirit]

I think it is super important to be able to change music whenever wanted. Imagine the possibilities of atmospheric mapping or dynamic change of music based on gameplay events.

You can probably just hack the engine to also accept a string from this field (...)

Darkplaces does this.

(..) please do not omit the file extension.

Why not? By omitting it you leave the quality/format choice to the user which is a good idea in my opinion. Some people might want wav or flac, others would be sad about the waste of space. Yet they could use their preferences and still stay compatible by not having to chance anything in the code. Of course the question would be what overrides what.

[mh]

An alternative - which makes me feel dirty, but oh well - is a new command on the client that takes a track name. QC could then stuffcmd it and it would be safely ignored by anything that doesn't support it.

Another alternative is to just enumerate the files in your music directory (using findfirstfile/findnextfile or equivalent). Then your "cd play 3" (or whatever) command would play the third file, and it wouldn't matter what it was called. This is the approach I'd be in favour of.

[szo]

(..) please do not omit the file extension.

Why not? By omitting it you leave the quality/format choice to the user which is a good idea in my opinion. Some people might want wav or flac, others would be sad about the waste of space. Yet they could use their preferences and still stay compatible by not having to chance anything in the code. Of course the question would be what overrides what.

Your final argument is the answer to your question. Look at quakespasm code to see how many hoops you might have to jump through to overcome that when you support multiple formats concurrently. Nothing major, of course, but an additional PITA nonetheless.

[szo]

.... a new command on the client that takes a track name. QC could then stuffcmd it and it would be safely ignored by anything that doesn't support it.

This is in parallel to all q3-engined games and is my preferred solution as implemented in quakespasm and uhexen2 (see the "music" command.) Any quakec code can issue it and it isn't limited to just stupid ripped track names but can play any music with any name.

[mh]

I'd personally prefer a well-defined server message rather than encourage more stuffcmd abuse though, but of course that needs a protocol change.

I still favour enumerating the files anyway; for one thing it means that you can add tab autocompletion to the command. It also means that you can adjust the command to take either a number or a file name, and it can therefore interoperate more cleanly with the existing command.

[szo]

I still favour enumerating the files anyway; for one thing it means that you can add tab autocompletion to the command. It also means that you can adjust the command to take either a number or a file name, and it can therefore interoperate more cleanly with the existing command.

You mean precaching all existing music/*.[wav|ogg|mp3] names at engine start?

[mh]

I still favour enumerating the files anyway; for one thing it means that you can add tab autocompletion to the command. It also means that you can adjust the command to take either a number or a file name, and it can therefore interoperate more cleanly with the existing command.

You mean precaching all existing music/*.[wav|ogg|mp3] names at engine start?

Yeah, that's more or less it. It's already done for other content in other engines and it's not really a huge overhead.

If you could live without tab autocompletion on the names (and while it's nice I'm not convinced it's essential) you don't even need to precache. The behaviour of the "cd play" command would then go like:

• Try to open the file name directly.
• If that fails convert the param to a number (atoi); if it converts OK:
• Enumerate the files; as soon as the enumerator hits the appropriate track number play that one.

There are probably weird edge cases where it breaks down for sure, but it's more or less what I've been doing for the past 2 years. Nobody's complained so I guess it's safe to say that on general principles it works.

[Spike]

I favour a stuffcmd over an svc because it means you don't have mods abusing writebyte, and then booting off clients because it got the protocol wrong.
At least with stuffcmds, the worst you generally get is 'unrecognised command', and even that can be avoided if the stuffcmd itself is specified to be prefixed by a "//".

when its a choice between mods fucking up writebyte or stuffcmd, I'll go with stuffcmd any day.
Especially when you consider that quakeworld HATES writebyte(MSG_ONE, foo) when crossing backbuffer boundaries, due to it not having a clue how much space has to be reserved.

I will personally hate you, Baker, if this thread results in mods sending this via writebyte (a builtin instead is okay).
svc numbers _must_ be kept out of QC code.

Either way, it should be sent at the same sort of time as the existing cdtrack (probably just before) so the client knows to ignore the cdtrack if the filename is specified instead. Or to send one or the other, that works too.

the 'cd play' / 'cd loop' commands accepting track names as well as numbers also works, and is fairly unambiguous in its meaning when faketracks are considered, even if not intuitive to users.

[Baker]

Well, first of all if you just want to support this filename being in the worldspawn, you don't need a server message. The client can read it out of the bsp the same as fog and skybox support works.

Well, like Spirit suggests about the flexibility of music changing entities, I want to be able to setup triggers that change the music for when a door slams behind you and you discover you are in for a "boss fight".

So worldspawn alone isn't enough.

@Spike: Not looking to bust up Quakeworld compatibility nor looking to make any protocol changes.

stuffcmd is really gross, but the accumulated feedback here seems to suggest this is the most compatible way for a short term solution. I'll live with this grossness as a short term solution. I don't like it, but there isn't enough of a well-prepared and blueprinted body of work yet for a deeper discussion I foresee maybe late this year or early next.

[mh]

If you really want gross...

svc_cdtrack is a 2 byte message. The red book standard defines a max of 99 tracks for a CD. That leaves you 9 bits to play with. Stuff some flags into them, and if one of those flags is set you just read another string containing the name.