Adding SVC like svc_cdtrack but w/fullname music file

[mankrip]

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.

This solution is perfect. However, others seems to be not understanding how it would work.

If I ever get around to implementing file-based music support to Makaqu, I'll certainly do it this way. Thanks for the idea.

[Baker]

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.

This solution is perfect. However, others seems to be not understanding how it would work.

If I ever get around to implementing file-based music support to Makaqu, I'll certainly do it this way. Thanks for the idea.

How would any of the above help in map creation? Case in point ... the "sounds" field in worldspawn indicates the cdtrack number (subtract 1, right?). So in worldspawn you have "sounds" "4" to indicate the cdtrack. "4" doesn't really say anything descriptive about what exactly that music is.

I'd prefer to have "backgroundtrack" "mymusic" or "backgroundtrack" "mymusic.ogg" in there. (I don't care about the worldspawn key name ... shorter is better). And I'd like to create a "trigger_backgroundmusic" entity that sends the track name to the client --- well, actually it has to be all of them clients --- maybe. Hmmm ... in coop is that desired? What if I have a castle that plays old tyme music upon entry ...

Anyways ... the point of this is convenience for the mapper and courtesy to the guy who created the sound track. In the former case (teh mapper), you want him to think about business naturally. If he wants "beethoven.ogg" to play, don't make him have to do something stupid like rename that to "track004.ogg" and then he doesn't know WTF that is without playing it. Neither do you or I.

And the soundtrack creator can't work naturally with that either. Add to the fact you have to subtract 1 and give the file name a very specific name that varies from engine to engine.

... Anyway, Quake or "Quake" (not quite Quake) doesn't need obscure weirdnesses. We've got enough of that with the model format, the wad editors and having to add a looping byte somewhere in the .wav files.

/My 2 cents -- all of my ideas cater to developers and players. Developers create the content. Players use it. I truly think developers have been ignored. By developers, I really mean mappers. (Engine development is more of establishing a platform and a piece of the toolset. Usually.) Even if it isn't obvious HOW they've been ignored ... I understand it. Is Quake actually convenient and modern to mappers --- not compared to other games, but within its own context?

[szo]

[...]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".
[...]
I'd prefer to have "backgroundtrack" "mymusic" or "backgroundtrack" "mymusic.ogg" in there. (I don't care about the worldspawn key name ... shorter is better). And I'd like to create a "trigger_backgroundmusic" entity that sends the track name to the client ---
[...]

Well, thanks for not limiting yourself to just ripped cd tracks as the music.

It turns out that all you need will be some qc code sending a certain stuffcmd, eg. "music myohsocoolmusic.ogg", and if the client supports that all will be fine.

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.

Well, <i>that</i> would be gross indeed.

[mh]

There's two types of content that need to be covered here:

• New content
• Existing content

Now, I can definitely see the advantages of Baker's proposals for new content, but what of existing content? What of the 15 years worth of accumulated maps and mods?

Unless a proposal can also cover those in a clean and sensible manner, I don't think it's going to get much uptake. So you've got to define how a new worldspawn key will interact with the current "sounds" key.

Anyways ... the point of this is convenience for the mapper and courtesy to the guy who created the sound track. In the former case (teh mapper), you want him to think about business naturally. If he wants "beethoven.ogg" to play, don't make him have to do something stupid like rename that to "track004.ogg" and then he doesn't know WTF that is without playing it. Neither do you or I.

The point is that you don't have to rename the file using my enumeration proposal. The fact that it's the fourth file in the list will be enough; it can be called anything so long as it's fourth in the list of files.

[mankrip]

The point is that you don't have to rename the file using my enumeration proposal. The fact that it's the fourth file in the list will be enough; it can be called anything so long as it's fourth in the list of files.

Exactly. It would be like...

If you have something like this in your music dir:
A Really Loud Track.mp3
Bad Ambience.ogg
Chorus of Horror.wav
Demonic Hearsay.mid
Eastern Bukkake.flac

... and set the "sounds" field of the worldspawn entity to 4 in the BSP file, it will play the "Demonic Hearsay.mid" music upon loading, because it's the fourth one. No need for mysterious track names!

However, there's a potential problem, specially for developers, since it's common to have files being replaced or deleted during development: If you delete one of the files, the number assigned to the ones that followed them will change. So, if you delete "Chorus of Horror.wav", "Demonic Hearsay.mid" will change to the third position, and "Eastern Bukkake.flac" will become the fourth track.

To avoid this, we could just make the engine read the track number directly from the file's metadata when available. OGG, MP3 and FLAC files support this, and iirc MID files also supports it. So, for example, when enumerating MP3 files the engine would assign them to the track number defined in their ID3 tags, if available.

When no track number is indicated in the file's metadata, we can just enumerate them like explained before, enumerating them into the gaps between the files with metadata-defined track numbers.

The only remaining issue would be with the possibility of multiple files having the same track number indicated into their metadata, and since there could be multiple approaches to solve that, I'm open to suggestions. But maybe this is the kind of problem that should really be taken care of by the content creators instead.

[szo]

The point is that you don't have to rename the file using my enumeration proposal. The fact that it's the fourth file in the list will be enough; it can be called anything so long as it's fourth in the list of files.

Exactly. It would be like...

If you have something like this in your music dir:
A Really Loud Track.mp3
Bad Ambience.ogg
Chorus of Horror.wav
Demonic Hearsay.mid
Eastern Bukkake.flac

... and set the "sounds" field of the worldspawn entity to 4 in the BSP file, it will play the "Demonic Hearsay.mid" music upon loading, because it's the fourth one. No need for mysterious track names!

Well this looks inherently evil and fragile. The ordering, ie. enumeration as you guys like calling it, can be very arbitrary depending on the developer. filename casing is one issue that comes to mind, one can find more if wants to. This is another candidate to be called as gross, according to me. No one should bother with ugly hacks using an old field like this. Invent a new field, invent a new music command in your engine (cf: quakespasm, quake3, etc.) and find a way of sending it from the server to the client.

[mh]

If case-sensitivity is a problem then you're doing it wrong. Too much Quake development has been done with a programmer's hat on; that hat needs to come off and be replaced by a content-creator's or a player's hat.

Get the basics for content right and everything else falls into place. Why should case-sensitivity be important anyway? Just use a case-insensitive file enumerator. Use an enumerator that allows you to list them alphabetically - it's the order in which most players will be viewing files on their OS anyway. Don't stress over weird edge-cases that are extremely unlikely in the real world. Think about how the code is going to be used by a creator or a player (who may not be a programmer and may not care - or even know - about these things) in other words.

Invent a new field, invent a new music command in your engine (cf: quakespasm, quake3, etc.) and find a way of sending it from the server to the client.

That would be great - and definitely the preferred approach - if we were just talking about new content. But there's still that 15 years worth of existing content to worry about, and that all has "sound" "4" or whatever in it. And if you don't support that.....

[szo]

If case-sensitivity is a problem [...]

Case sensitivity is only one problem, not _all_

Invent a new field, invent a new music command in your engine (cf: quakespasm, quake3, etc.) and find a way of sending it from the server to the client.

That would be great - and definitely the preferred approach - if we were just talking about new content. But there's still that 15 years worth of existing content to worry about, and that all has "sound" "4" or whatever in it. And if you don't support that.....

Well, do not those "sound" "4" stuff refer to cd tracks?? Ripped cd track code have already been done by many engines, so I can't see the issue here, but it's just me..

[mankrip]

Well this looks inherently evil and fragile.

Like me.

The ordering, ie. enumeration as you guys like calling it, can be very arbitrary depending on the developer. filename casing is one issue that comes to mind, one can find more if wants to. This is another candidate to be called as gross

And this is what I've talked about in the rest of my post - the part you haven't quoted.

It's all about reading the track number from the ID3 tags, or whatever tags are used in formats other than MP3. Those audio files can have their track number defined right into themselves, why ignore that? Let's use that info, this is the preferred method I'm talking about.

This way the content creators can have full control of which file they want to play, while retaining full compatibility with vanilla Quake's standards.

[mh]

If case-sensitivity is a problem [...]

Case sensitivity is only one problem, not _all_

Invent a new field, invent a new music command in your engine (cf: quakespasm, quake3, etc.) and find a way of sending it from the server to the client.

That would be great - and definitely the preferred approach - if we were just talking about new content. But there's still that 15 years worth of existing content to worry about, and that all has "sound" "4" or whatever in it. And if you don't support that.....

Well, do not those "sound" "4" stuff refer to cd tracks?? Ripped cd track code have already been done by many engines, so I can't see the issue here, but it's just me..

Using enumeration (or the ID3 tag idea - which never occurred to me) you don't have to rename the tracks. That's where I'm coming from; I've now said it maybe 3 or 4 times. Pop the tracks into your music directory and that's it; it Just Works with both existing and new content, things play in the order that the player will expect, and nothing else needs to be done.

[szo]

Invent a new field, invent a new music command in your engine (cf: quakespasm, quake3, etc.) and find a way of sending it from the server to the client.

That would be great - and definitely the preferred approach - if we were just talking about new content. But there's still that 15 years worth of existing content to worry about, and that all has "sound" "4" or whatever in it. And if you don't support that.....

Well, do not those "sound" "4" stuff refer to cd tracks?? Ripped cd track code have already been done by many engines, so I can't see the issue here, but it's just me..

Using enumeration (or the ID3 tag idea - which never occurred to me) you don't have to rename the tracks. That's where I'm coming from; I've now said it maybe 3 or 4 times. Pop the tracks into your music directory and that's it; it Just Works with both existing and new content, things play in the order that the player will expect, and nothing else needs to be done.

Well why do the ripped cd tracks need renaming? If you are referring to the fact that they should be in the track<nn>.ext name format and that's called renaming, well, ehh, ehm, ugh.... I'm out of words....

[mh]

I never said they needed renaming. I'm pointing out a solution that avoids the need to rename them (the solution doesn't care what they're called) but yet retains compatibility with the existing way of handling music.

This was all in response to Baker's post:

Anyways ... the point of this is convenience for the mapper and courtesy to the guy who created the sound track. In the former case (teh mapper), you want him to think about business naturally. If he wants "beethoven.ogg" to play, don't make him have to do something stupid like rename that to "track004.ogg" and then he doesn't know WTF that is without playing it. Neither do you or I.

Using the solution I gave, the mapper doesn't need to rename the file.

You're the one calling it ugly and fragile. Two years worth of people playing the game using this solution disagrees with you. It does work, it's been proven to work, it's passed the only test that counts.

Now, if you want to create something new, then by all means find a better and more elegant way. I won't argue with that. But my point is that if you also want to be able to handle existing content, then you've got to put some thought into how you do that too.

[Spike]

sure, enumerate the files and then the mapper doesn't need to rename it. He doesn't have a clue exactly which file will be played, no clue at all. Maybe he tries to get some nice ambient track that plays nicely with the dark atmosphere in a quiet part of the map, only to find that some other joke map that the user installed last week results in it playing a certain track by Rick Astley.
That's useless.

Here's an alternative solution:
If the potential filenames are actually specified as a list of some kind in the worldspawn entity (like _fog and stuff), then the client can map track number X to filename Y, and play filename Y instead of using the cd player.
This means it works on any server you want, with any QC mod you want, only the client (and map, obviously) needs updating. The mapper can name whatever files they want. The client knows which sounds need to be precached/downloaded in advance. The track played does not depend upon which files they have installed already, nor the sort-order of the user's music collection, doesn't have issues above 255 (unused) tracks. Will not unintentionally rickroll someone, which tbh is a major major advantage.

An aside: I added voicechat into FTE, the group I got to test it just use it for spamming each other with arnie quotes, and still do. yay.

Actually, the only downside to this alternative solution I can think of is that it means the mod cannot specify a track which is not named by the BSP.
Depends who you're trying to target, I suppose.

[Spirit]

How about:

track###.ext for the numbers
anythingelse.ext for anything else

[szo]

How about:

track###.ext for the numbers
anythingelse.ext for anything else

That's the sensible thing. And with the new engines around, the track##.ext have already been supported for quite some time, so the only thing needed is the anythingelse.ext thing, which, as I understand. is the only thing Baker is after.

PS: the track thing actually needs to be track##.ext: redbook audio <= 99 tracks