Re: [Warzone-dev] Music
hello everybody, I've been following this list for some time now, however, I'm not a programmer... Perhaps a testplayer at best... However, on this subject, perhaps it would be a good idea to use the same method the flightgear project uses (www.flightgear.org), which is to seperate data and source code repo's. This would make for a rather radical change in how things are set up currently, however I think it would be quite an advantage in the long run, as the amount of data will keep increasing with better textures, movies etc etc. A checkout of the source would then be far less time consuming as it is currently. Stefan 2008/6/17, Per Inge Mathisen <[EMAIL PROTECTED]>: > On Tue, Jun 17, 2008 at 12:17 AM, Angus Lees <[EMAIL PROTECTED]> wrote: >> Can we keep the original files losslessly compressed (using something like >> flac, perhaps) for posterity? or are the flac files still too large to >> put >> through our repository? > > I do not think they are too large, as long as you do not have to > download them every time. I suggest creating a new directory/branch > called 'originals' side by side with 'trunk', 'branches' and 'tags' > for this purpose. > > - Per > > ___ > Warzone-dev mailing list > Warzone-dev@gna.org > https://mail.gna.org/listinfo/warzone-dev > ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
On Tue, Jun 17, 2008 at 12:17 AM, Angus Lees <[EMAIL PROTECTED]> wrote: > Can we keep the original files losslessly compressed (using something like > flac, perhaps) for posterity? or are the flac files still too large to put > through our repository? I do not think they are too large, as long as you do not have to download them every time. I suggest creating a new directory/branch called 'originals' side by side with 'trunk', 'branches' and 'tags' for this purpose. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
On Sun, Jun 15, 2008 at 12:17 PM, Per Inge Mathisen <[EMAIL PROTECTED]> wrote: > I would like to commit the original game music to the repository under > base/music. I ripped it directly from the game CDs, using normal ogg > compression. Any objections? > > The music playing patch that is attached is a quick hack, but should > work well enough. > Can we keep the original files losslessly compressed (using something like flac, perhaps) for posterity? or are the flac files still too large to put through our repository? -- - Gus ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
Per Inge Mathisen schreef: > On Sun, Jun 15, 2008 at 4:11 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> Either way, I simply don't like >> spreading all sorts of "default" files all throughout the codebase. I'd >> much rather keep these "default" files as *data* files and perhaps copy >> them to the user's config dir when starting the game for the first time. > > You are right that keeping a default file in the code is not clean, > which is why I said it was a "quick hack". Is it so ugly that we > should wait for someone to code something cleaner before we add the > music? Well, if you'd at least put the part that creates the "default" file in a separate function and mark it as a HACK, then I don't mind having/using it as a temporary solution. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
On Sun, Jun 15, 2008 at 4:11 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> That would mean keeping one music playlist in data/ and one in >> ~/.warzone2100. I do not like duplicated data files, as that tends to >> be confusing. > > Nope, it wouldn't be a duplication because the one in ~/.warzone2100 > would override the file in data/. I am still counting two copies of the same file (unless user changes one - but then the user first has to understand that he should change the one in ~/.warzone2100/, and not the other one). So it would at least have to bear another name. > Either way, I simply don't like > spreading all sorts of "default" files all throughout the codebase. I'd > much rather keep these "default" files as *data* files and perhaps copy > them to the user's config dir when starting the game for the first time. You are right that keeping a default file in the code is not clean, which is why I said it was a "quick hack". Is it so ugly that we should wait for someone to code something cleaner before we add the music? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
Per Inge Mathisen schreef: > On Sun, Jun 15, 2008 at 1:46 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> Per Inge Mathisen schreef: >>> The music playing patch that is attached is a quick hack, but should >>> work well enough. >> How about not modifying the code to insert a default playlist but adding >> a default playlist to the data instead > > That would mean keeping one music playlist in data/ and one in > ~/.warzone2100. I do not like duplicated data files, as that tends to > be confusing. Nope, it wouldn't be a duplication because the one in ~/.warzone2100 would override the file in data/. Either way, I simply don't like spreading all sorts of "default" files all throughout the codebase. I'd much rather keep these "default" files as *data* files and perhaps copy them to the user's config dir when starting the game for the first time. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
On Sun, Jun 15, 2008 at 1:46 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: > Per Inge Mathisen schreef: >> I would like to commit the original game music to the repository under >> base/music. I ripped it directly from the game CDs, using normal ogg >> compression. Any objections? > > Which quality setting did you use? As I said above, I used the default options (using oggenc). >> The music playing patch that is attached is a quick hack, but should >> work well enough. > > How about not modifying the code to insert a default playlist but adding > a default playlist to the data instead That would mean keeping one music playlist in data/ and one in ~/.warzone2100. I do not like duplicated data files, as that tends to be confusing. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music
Per Inge Mathisen schreef: > I would like to commit the original game music to the repository under > base/music. I ripped it directly from the game CDs, using normal ogg > compression. Any objections? Which quality setting did you use? For "oggenc" it ranges from -1 (very low) to 10 (very high), with 3 being the default. > The music playing patch that is attached is a quick hack, but should > work well enough. How about not modifying the code to insert a default playlist but adding a default playlist to the data instead -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Music
I would like to commit the original game music to the repository under
base/music. I ripped it directly from the game CDs, using normal ogg
compression. Any objections?
The music playing patch that is attached is a quick hack, but should
work well enough.
- Per
Index: lib/sound/playlist.c
===
--- lib/sound/playlist.c (revision 5252)
+++ lib/sound/playlist.c (working copy)
@@ -72,7 +72,6 @@
{
PHYSFS_file* fileHandle;
char* path_to_music = NULL;
-
char fileName[PATH_MAX];
// Construct file name
@@ -82,6 +81,21 @@
fileHandle = PHYSFS_openRead(fileName);
if (fileHandle == NULL)
{
+ // Create default playlist file
+ fileHandle = PHYSFS_openWrite(fileName);
+ if (fileHandle)
+ {
+ const char *gamestr = "[game]\npath=music\nshuffle=yes\ntrack1.ogg\ntrack2.ogg\n\n";
+ const char *menustr = "[menu]\npath=music\nmenu.ogg\n";
+
+ PHYSFS_write(fileHandle, gamestr, strlen(gamestr), 1);
+ PHYSFS_write(fileHandle, menustr, strlen(menustr), 1);
+ PHYSFS_close(fileHandle);
+ }
+ fileHandle = PHYSFS_openRead(fileName);
+ }
+ if (fileHandle == NULL)
+ {
debug(LOG_NEVER, "sound_LoadTrackFromFile: PHYSFS_openRead(\"%s\") failed with error: %s\n", fileName, PHYSFS_getLastError());
return false;
}
Index: lib/netplay/netplay.c
===
--- lib/netplay/netplay.c (revision 5252)
+++ lib/netplay/netplay.c (working copy)
@@ -210,6 +210,7 @@
}
memcpy(pMsg, message, size);
+ pMsg->size = SDL_SwapBE16(message->size);
bs->buffer_start += size;
bs->bytes -= size;
Index: data/base/music/menu.ogg
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: data/base/music/menu.ogg
___
Name: svn:mime-type
+ application/octet-stream
Index: data/base/music/track1.ogg
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: data/base/music/track1.ogg
___
Name: svn:mime-type
+ application/octet-stream
Index: data/base/music/track2.ogg
===
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: data/base/music/track2.ogg
___
Name: svn:mime-type
+ application/octet-stream
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Saturday, January 27, 2007 6:35 PM Subject: tmp Troman schreef: - Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Friday, January 26, 2007 10:44 PM Subject: tmp2 Dennis Schridde schreef: Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman: - Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Thursday, January 25, 2007 5:57 PM Subject: temp Wel the functions on their own look quite good to me. Their prototypes however... Let's just say that I don't like the idea of passing pointers into the scripting engine. Why not? That's the way most of the scripting stuff works right now. Scripts currently work with a lot of pointers passed from WZ, although from the scriptor's point of view there's no difference between integers/bools or pointers to some internal wz structures. Not that it really matters to me. If we just work with integer ids, that would mean we have less different types to define for scripts (I don't really like the idea of flooding scripts with dozens of new types, unless really needed, but i'm not yet sure what would be optimal for us). The fact that that's the currently employed technique hardly makes it be good. Not just because of that, it simply works well, I had no issues with pointers whatsoever. And indeed from the scripter there is no difference between a regular integer or a pointer. Which makes it all the more dangerous to pass pointers into scripts. This could easily result in a segfault beyond our control. The way it is now you can't do anything to a pointer but only access it, bison would simply not compile script if you tried to manipulate a pointer, there are no operations that pointers support. You can't even set it to NULL using scripts, that makes pointers safe. What you can do is pass it to some internal function for it to mess it up and that's it. So that's not an issue. Ah so if I understand it correctly the scripts can only use pointers for API calls and only change their value through them? Yes, exactly. In that case it wouldn't be as dangerous as I thought it was. BTW why don't we just use forums for such discussions? This starts to look a bit awkward to me. Maybe we can ask Kamaze to set up some protected area for the developers and those participating in the mailinglist discussion? Personally i'd also be fine with a public forum, not sure if this would work well though. I think most of us are going well with a mailinglist and prefer it this way. At least to me it's much simpler to fire up my mail client and watch several threaded discussions. Forums have that flat, time-related style (lost the words... Allready getting late. I mean they only have one direction, you can't split of a discussion as easily) which makes the inconvenient IMO... Yep, I'm one of them, I really do prefer an email client above a forum. Well no forum then. It's just when replying you have to count those 'greater than' signs to find out who you are actually refering to and when you have more than 10 that looks messy not to mention that all text is cluttered. Hmm, well, I could advise the Thunderbird thingy again. It turns those '>'-signs into nice quote blocks for viewing purposes. Although I thought MS outlook did the same. -- Giel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
Am Freitag, 26. Januar 2007 schrieb Giel van Schijndel:
> Dennis Schridde schreef:
> > Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman:
> >> - Original Message -
> >> From: "Troman" <[EMAIL PROTECTED]>
> >> To: "Troman" <[EMAIL PROTECTED]>
> >> Sent: Thursday, January 25, 2007 5:57 PM
> >> Subject: temp
> >>
> Wel the functions on their own look quite good to me.
> Their prototypes however... Let's just say that I don't like the idea
> of passing pointers into the scripting engine.
> >>
> >> Why not? That's the way most of the scripting stuff works right now.
> >> Scripts currently work with a lot of pointers passed from WZ, although
> >> from the scriptor's point of view there's no difference between
> >> integers/bools or pointers to some internal wz structures.
> >> Not that it really matters to me. If we just work with integer ids, that
> >> would mean we have less different types to define for scripts (I don't
> >> really like the idea of flooding scripts with dozens of new types,
> >> unless really needed, but i'm not yet sure what would be optimal for
> >> us).
>
> The fact that that's the currently employed technique hardly makes it be
> good. And indeed from the scripter there is no difference between a
> regular integer or a pointer. Which makes it all the more dangerous to
> pass pointers into scripts. This could easily result in a segfault
> beyond our control.
I guess the engine provides something like a const keyword...
So there is no difference at all between a integer id, where we would have to
guard that it doesn't get mixed up with another id in the same range, like
Troman said, and a pointer were we would also have to guard, so that it
doesn't get confused with another pointer to some other struct.
> In fact I think dynamic arrays (std::vector or std::list) are probably
> the
> best way to solve this. Then once your using C++ anyway you might as
> well use a smartpointer to hold the `track' object which will fix the
> problem I
> mentioned above.
>
> Such a small usage of C++ should be rather easy to contain/manage in a
> single (e.g. `lib/sound/playlist.cpp') source file.
> >>>
> >>> Well, C doesn't have std::vector, so I had no other idea...
> >>> What I just thought about was some selfmade dynamic array:
> >>> struct Playlist { meta-info; Track[]; }
> >>> malloc( sizeof(meta-info) + sizeof(Track*) * playlistSize );
> >>> or realloc( ... );
> >>> Doesn't look nice, but would be an option...
> >>
> >> While surely not as elegant as dynamic arrays we can as well just use
> >> fixed arrays if those are only used to hold pointers to playlists, to be
> >> honest I doubt anyone would want more than, say, 20 playlists at a time
> >> (i'm being rather generous).
>
> Erm, I actually meant to contain the playlist itself (i.e. a list of
> tracks in an order) in a dynamic array, so that dynamic array would _be_
> the playlist.
>
> Oh and 20 playlists? Yes you're being generous, I'd guess 5 would
> already be enough. ;-)
Actually I meant the internal structure of the playlists, not the external.
Means: My problem was not the dynamic number of playlists, but the dynamic
number of tracks in it.
> > WZSound_setPlaylist( "none" );
> > WZSound_playTrack( "event1.ogg" );
> > WZSound_setPlaylistMode( "shuffle", "fadein" );
> > WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
> > WZSound_setPlaylistMode( "none" );
>
> Lets not use Cstrings (or any piece of rope for that matter; i.e.
> strings)
> to indicate play modes.
> >>>
> >>> This was for the scripting engine. I don't think it supports bitflags,
> >>> does
> >>> it? So the first and possibly easiest option was concatenating strings.
> >>> Maybe we could also provide the C-defines (PLAYLIST_SHUFFLE,...) as
> >>> constants
> >>> to the scripting engine and add them on another...
> >>
> >> Sure, best way to solve this is to provide constants predefined by wz,
> >> works like a charm.
>
> Sounds nice.
>
> PS: geez am I the only one having trouble replying to attached
> files?
> >>>
> >>> Apparently: Yes...
> >>
> >> Wouldn't have asked if it was apparent. I was refering to those '>'
> >> markers actually. Don't see a way how to add them with outlook
> >> express,
> >> which forces me to make a small detour.
> >
> > Outlook doesn't give you those '>' if you press reply on a mail which
> > has
> > an attached file???
>
> Of course I can advise you to take and use Thunderbird instead ;-) .
> It's more powerful than Outlook (e.g. in case of low level access, mem
> footprint, etc).
> >>
> >> Might as well do this someday, for now I think I'll give Outlook a try
> >> and see if it offers enough functionality (using Outlook Express right
> >> now).
> >>
> >> BTW why don't we just use forums for such discussions? This starts to
> >
Re: [Warzone-dev] Music playlists
Am Freitag, 26. Januar 2007 schrieb Giel van Schijndel: > Dennis Schridde schreef: > >> I think we should just allow the creation of multiple playlists, and > >> then have some function to select the current active one (like > >> bindPlaylist below). Then when you select a playlist to be active it > >> should simply start playing automatically. If you would want nothing to > >> play then just select playlist NULL or something similar, meaning no > >> playlist is active. > > > > When everything starts you must have the state playing=no/stoped=yes, > > because you don't even have a playlist to play from. > > Your idea would imply that bindPlaylist doesn't only bind the playlist, > > but also implicitly advises the soundengine to play it. > > Doesn't sound too nice to me. 1st that function does several things > > instead of only one and 2nd the modder might not want to start it > > immediately for whatever reason. > > Nope it would imply that the soundengine would play it if playing=yes. > > > Eg. in GL the texture you bind is also not immediately painted on the > > screen. Or if AL uses a similar way, I don't think every sound-source you > > bind is immediately played. (But I have _no_ idea of AL, I must admit.) > > In fact an ALsource is nothing more than a set of coordinates, a speed > vector (for the Doppler effect), etc. > > Anyway, an ALsource _can_ only be played when a filled ALbuffer is > attached to it. > > > So my advice would be to let bindPlaylist bind the playlist and let > > startPlaylist/resumePlaylist handle the beginning playback. > > (Maybe we should have start/stop and pause/resume functions, where > > start/stop start from the beginning or stop entirely and pause/resume > > only ... pause and resume. Would save us from weird double namings (start > > and resume being the same thing) and would also add some functionality > > for no fees.) > > > >> That way you would have to provide a single song playlist though. This > >> could be done by a wrapping function though: * creating a playlist > >> * add the one song to it > >> * hook some kind of playlistFinished event on it (as a callback > >> function) * add the ID of the currently playing playlist to a member var > >> of the new playlist * make the new playlist active > >> Then upon raising of playlistFinished event (i.e. through callback > >> function): * make previous playlist active again > >> * destroy one-track playlist > > > > With the bound playlists (GL style architecture) I don't think we need > > the play-one-track and resume function anymore. I don't even think that > > we should provide a wrapper for that purpose... More work for us for > > something the modder can easily achive by himself. Additionaly we need to > > do some magic with our temporary playlists in the background, which might > > bring confusion. We would need to find out who created the playlist which > > just ended to know if we need to inform the scripts or handle it > > ourselves. (Otherwise we might do some harm to the modders playlist or he > > might to ours.) > > So IMO lots of work for little benefit. > > Yeah probably didn't put that as simple as I could have: don't use a > separate playTrack function, simple let the modder create a one-song > playlist instead. > > >>> Function to stop playlist playback and one function to resume > >>> playback. > >> > >> Probably would apply to all playlists? I.e. no playlists should be > >> played from at all. > >> > >> That way some `static bool playing;' could accomplish this (i.e. global > >> across all playlists). > > > > ? > > start/stop, pause/resume would advise the sound engine to > > start/stop/pause/resume the current playlist, not one single playlist... > > Well my idea was this: > You can have only one playlist actively being played from at a time. > Then if that is the case you do not need to control the > playing/paused/stopped state of individual playlists. So you could > effectively use one playing state for the entire playlist handling part > of the soundlib. I didn't suggest something different. ;) > > This was _not_ a proposal for the scripting engine, but for the C-API... > > The scripting engine would get some integer IDs or similar... > > Yes, well the absence of that WZSound_ prefix was a bit confusing. Sorry. Got lazy without codecompletion... > > Hmmm... Actually the idea is not that bad... > > Would make it easy to handle multiple playlists, eg. one for the menu > > and for the game, or when The Modder wants to interupt the game with > > a few different songs to acompany his cutscenes or the attack of the > > clones... (And wants to switch back to the usual theme afterwards.) > > > > Implementation for createPlaylist: > > New item of a playlist-linked-list. All pointers NULL. (next, prev, > > thisTrack). > > > > addTrack: > > Walk to the end of Playlist*, check if thisTrack is NULL, yes-> set > > thisTrack to Track*, no-> append ano
Re: [Warzone-dev] Music playlists
Troman schreef: > > - Original Message - From: "Troman" <[EMAIL PROTECTED]> > To: "Troman" <[EMAIL PROTECTED]> > Sent: Friday, January 26, 2007 10:44 PM > Subject: tmp2 >> Dennis Schridde schreef: >>> Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman: - Original Message - From: "Troman" <[EMAIL PROTECTED]> To: "Troman" <[EMAIL PROTECTED]> Sent: Thursday, January 25, 2007 5:57 PM Subject: temp >> Wel the functions on their own look quite good to me. >> Their prototypes however... Let's just say that I don't like the >> idea of >> passing pointers into the scripting engine. >> Why not? That's the way most of the scripting stuff works right now. Scripts currently work with a lot of pointers passed from WZ, although from the scriptor's point of view there's no difference between integers/bools or pointers to some internal wz structures. Not that it really matters to me. If we just work with integer ids, that would mean we have less different types to define for scripts (I don't really like the idea of flooding scripts with dozens of new types, unless really needed, but i'm not yet sure what would be optimal for us). >> The fact that that's the currently employed technique hardly makes it be >> good. > Not just because of that, it simply works well, I had no issues with > pointers whatsoever. >> And indeed from the scripter there is no difference between a >> regular integer or a pointer. Which makes it all the more dangerous to >> pass pointers into scripts. This could easily result in a segfault >> beyond our control. > The way it is now you can't do anything to a pointer but only access > it, bison would simply not compile script if you tried to manipulate a > pointer, there are no operations that pointers support. You can't even > set it to NULL using scripts, that makes pointers safe. What you can > do is pass it to some internal function for it to mess it up and > that's it. So that's not an issue. Ah so if I understand it correctly the scripts can only use pointers for API calls and only change their value through them? In that case it wouldn't be as dangerous as I thought it was. BTW why don't we just use forums for such discussions? This starts to look a bit awkward to me. Maybe we can ask Kamaze to set up some protected area for the developers and those participating in the mailinglist discussion? Personally i'd also be fine with a public forum, not sure if this would work well though. >>> I think most of us are going well with a mailinglist and prefer it >>> this way. >>> At least to me it's much simpler to fire up my mail client and watch >>> several >>> threaded discussions. Forums have that flat, time-related style >>> (lost the >>> words... Allready getting late. I mean they only have one direction, >>> you >>> can't split of a discussion as easily) which makes the inconvenient >>> IMO... >>> >> Yep, I'm one of them, I really do prefer an email client above a forum. > > Well no forum then. It's just when replying you have to count those > 'greater than' signs to find out who you are actually refering to and > when you have more than 10 that looks messy not to mention that all > text is cluttered. Hmm, well, I could advise the Thunderbird thingy again. It turns those '>'-signs into nice quote blocks for viewing purposes. Although I thought MS outlook did the same. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Friday, January 26, 2007 10:44 PM
Subject: tmp2
Dennis Schridde schreef:
Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman:
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 5:57 PM
Subject: temp
Wel the functions on their own look quite good to me.
Their prototypes however... Let's just say that I don't like the idea
of
passing pointers into the scripting engine.
Why not? That's the way most of the scripting stuff works right now.
Scripts currently work with a lot of pointers passed from WZ, although
from
the scriptor's point of view there's no difference between
integers/bools
or pointers to some internal wz structures.
Not that it really matters to me. If we just work with integer ids, that
would mean we have less different types to define for scripts (I don't
really like the idea of flooding scripts with dozens of new types,
unless
really needed, but i'm not yet sure what would be optimal for us).
The fact that that's the currently employed technique hardly makes it be
good.
Not just because of that, it simply works well, I had no issues with
pointers whatsoever.
And indeed from the scripter there is no difference between a
regular integer or a pointer. Which makes it all the more dangerous to
pass pointers into scripts. This could easily result in a segfault
beyond our control.
The way it is now you can't do anything to a pointer but only access it,
bison would simply not compile script if you tried to manipulate a pointer,
there are no operations that pointers support. You can't even set it to NULL
using scripts, that makes pointers safe. What you can do is pass it to some
internal function for it to mess it up and that's it. So that's not an
issue.
In fact I think dynamic arrays (std::vector or std::list) are probably
the
best way to solve this. Then once your using C++ anyway you might as
well use a smartpointer to hold the `track' object which will fix the
problem I
mentioned above.
Such a small usage of C++ should be rather easy to contain/manage in a
single (e.g. `lib/sound/playlist.cpp') source file.
Well, C doesn't have std::vector, so I had no other idea...
What I just thought about was some selfmade dynamic array:
struct Playlist { meta-info; Track[]; }
malloc( sizeof(meta-info) + sizeof(Track*) * playlistSize );
or realloc( ... );
Doesn't look nice, but would be an option...
While surely not as elegant as dynamic arrays we can as well just use
fixed
arrays if those are only used to hold pointers to playlists, to be
honest I
doubt anyone would want more than, say, 20 playlists at a time (i'm
being
rather generous).
Erm, I actually meant to contain the playlist itself (i.e. a list of
tracks in an order) in a dynamic array, so that dynamic array would _be_
the playlist.
Oh and 20 playlists? Yes you're being generous, I'd guess 5 would
already be enough. ;-)
WZSound_setPlaylist( "none" );
WZSound_playTrack( "event1.ogg" );
WZSound_setPlaylistMode( "shuffle", "fadein" );
WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
WZSound_setPlaylistMode( "none" );
Lets not use Cstrings (or any piece of rope for that matter; i.e.
strings)
to indicate play modes.
This was for the scripting engine. I don't think it supports bitflags,
does
it? So the first and possibly easiest option was concatenating strings.
Maybe we could also provide the C-defines (PLAYLIST_SHUFFLE,...) as
constants
to the scripting engine and add them on another...
Sure, best way to solve this is to provide constants predefined by wz,
works like a charm.
Sounds nice.
PS: geez am I the only one having trouble replying to attached
files?
Apparently: Yes...
Wouldn't have asked if it was apparent. I was refering to those '>'
markers actually. Don't see a way how to add them with outlook
express,
which forces me to make a small detour.
Outlook doesn't give you those '>' if you press reply on a mail which
has
an attached file???
Of course I can advise you to take and use Thunderbird instead ;-) .
It's more powerful than Outlook (e.g. in case of low level access, mem
footprint, etc).
Might as well do this someday, for now I think I'll give Outlook a try
and
see if it offers enough functionality (using Outlook Express right now).
BTW why don't we just use forums for such discussions? This starts to
look
a bit awkward to me. Maybe we can ask Kamaze to set up some protected
area
for the developers and those participating in the mailinglist
discussion?
Personally i'd also be fine with a public forum, not sure if this would
work well though.
I think most of us are going well with a mailinglist and prefer it this
way.
At least to me it's much simpler to fire up my mail client and watch
several
threaded discussions. Forums have that flat, time-related style (lost the
words...
Re: [Warzone-dev] Music playlists
Dennis Schridde schreef:
> Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman:
>
>> - Original Message -
>> From: "Troman" <[EMAIL PROTECTED]>
>> To: "Troman" <[EMAIL PROTECTED]>
>> Sent: Thursday, January 25, 2007 5:57 PM
>> Subject: temp
>>
Wel the functions on their own look quite good to me.
Their prototypes however... Let's just say that I don't like the idea of
passing pointers into the scripting engine.
>> Why not? That's the way most of the scripting stuff works right now.
>> Scripts currently work with a lot of pointers passed from WZ, although from
>> the scriptor's point of view there's no difference between integers/bools
>> or pointers to some internal wz structures.
>> Not that it really matters to me. If we just work with integer ids, that
>> would mean we have less different types to define for scripts (I don't
>> really like the idea of flooding scripts with dozens of new types, unless
>> really needed, but i'm not yet sure what would be optimal for us).
>>
The fact that that's the currently employed technique hardly makes it be
good. And indeed from the scripter there is no difference between a
regular integer or a pointer. Which makes it all the more dangerous to
pass pointers into scripts. This could easily result in a segfault
beyond our control.
In fact I think dynamic arrays (std::vector or std::list) are probably
the
best way to solve this. Then once your using C++ anyway you might as
well use a smartpointer to hold the `track' object which will fix the
problem I
mentioned above.
Such a small usage of C++ should be rather easy to contain/manage in a
single (e.g. `lib/sound/playlist.cpp') source file.
>>> Well, C doesn't have std::vector, so I had no other idea...
>>> What I just thought about was some selfmade dynamic array:
>>> struct Playlist { meta-info; Track[]; }
>>> malloc( sizeof(meta-info) + sizeof(Track*) * playlistSize );
>>> or realloc( ... );
>>> Doesn't look nice, but would be an option...
>>>
>> While surely not as elegant as dynamic arrays we can as well just use fixed
>> arrays if those are only used to hold pointers to playlists, to be honest I
>> doubt anyone would want more than, say, 20 playlists at a time (i'm being
>> rather generous).
>>
Erm, I actually meant to contain the playlist itself (i.e. a list of
tracks in an order) in a dynamic array, so that dynamic array would _be_
the playlist.
Oh and 20 playlists? Yes you're being generous, I'd guess 5 would
already be enough. ;-)
> WZSound_setPlaylist( "none" );
> WZSound_playTrack( "event1.ogg" );
> WZSound_setPlaylistMode( "shuffle", "fadein" );
> WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
> WZSound_setPlaylistMode( "none" );
>
Lets not use Cstrings (or any piece of rope for that matter; i.e.
strings)
to indicate play modes.
>>> This was for the scripting engine. I don't think it supports bitflags,
>>> does
>>> it? So the first and possibly easiest option was concatenating strings.
>>> Maybe we could also provide the C-defines (PLAYLIST_SHUFFLE,...) as
>>> constants
>>> to the scripting engine and add them on another...
>>>
>> Sure, best way to solve this is to provide constants predefined by wz,
>> works like a charm.
>>
Sounds nice.
PS: geez am I the only one having trouble replying to attached
files?
>>> Apparently: Yes...
>>>
>> Wouldn't have asked if it was apparent. I was refering to those '>'
>> markers actually. Don't see a way how to add them with outlook
>> express,
>> which forces me to make a small detour.
>>
> Outlook doesn't give you those '>' if you press reply on a mail which
> has
> an attached file???
>
Of course I can advise you to take and use Thunderbird instead ;-) .
It's more powerful than Outlook (e.g. in case of low level access, mem
footprint, etc).
>> Might as well do this someday, for now I think I'll give Outlook a try and
>> see if it offers enough functionality (using Outlook Express right now).
>>
>> BTW why don't we just use forums for such discussions? This starts to look
>> a bit awkward to me. Maybe we can ask Kamaze to set up some protected area
>> for the developers and those participating in the mailinglist discussion?
>> Personally i'd also be fine with a public forum, not sure if this would
>> work well though.
>>
> I think most of us are going well with a mailinglist and prefer it this way.
> At least to me it's much simpler to fire up my mail client and watch several
> threaded discussions. Forums have that flat, time-related style (lost the
> words... Allready getting late. I mean they only have one direction, you
> can't split of a discussion as easily) whi
Re: [Warzone-dev] Music playlists
Dennis Schridde schreef: >> I think we should just allow the creation of multiple playlists, and then >> have some function to select the current active one (like bindPlaylist >> below). Then when you select a playlist to be active it should simply start >> playing automatically. If you would want nothing to play then just select >> playlist NULL or something similar, meaning no playlist is active. >> > When everything starts you must have the state playing=no/stoped=yes, because > you don't even have a playlist to play from. > Your idea would imply that bindPlaylist doesn't only bind the playlist, but > also implicitly advises the soundengine to play it. > Doesn't sound too nice to me. 1st that function does several things instead > of > only one and 2nd the modder might not want to start it immediately for > whatever reason. > Nope it would imply that the soundengine would play it if playing=yes. > Eg. in GL the texture you bind is also not immediately painted on the screen. > Or if AL uses a similar way, I don't think every sound-source you bind is > immediately played. (But I have _no_ idea of AL, I must admit.) > In fact an ALsource is nothing more than a set of coordinates, a speed vector (for the Doppler effect), etc. Anyway, an ALsource _can_ only be played when a filled ALbuffer is attached to it. > So my advice would be to let bindPlaylist bind the playlist and let > startPlaylist/resumePlaylist handle the beginning playback. > (Maybe we should have start/stop and pause/resume functions, where start/stop > start from the beginning or stop entirely and pause/resume only ... pause and > resume. Would save us from weird double namings (start and resume being the > same thing) and would also add some functionality for no fees.) > >> That way you would have to provide a single song playlist though. This >> could be done by a wrapping function though: * creating a playlist >> * add the one song to it >> * hook some kind of playlistFinished event on it (as a callback function) >> * add the ID of the currently playing playlist to a member var of the new >> playlist * make the new playlist active >> Then upon raising of playlistFinished event (i.e. through callback >> function): * make previous playlist active again >> * destroy one-track playlist >> > With the bound playlists (GL style architecture) I don't think we need the > play-one-track and resume function anymore. I don't even think that we should > provide a wrapper for that purpose... More work for us for something the > modder can easily achive by himself. Additionaly we need to do some magic > with our temporary playlists in the background, which might bring confusion. > We would need to find out who created the playlist which just ended to know > if we need to inform the scripts or handle it ourselves. (Otherwise we might > do some harm to the modders playlist or he might to ours.) > So IMO lots of work for little benefit. > Yeah probably didn't put that as simple as I could have: don't use a separate playTrack function, simple let the modder create a one-song playlist instead. >>> Function to stop playlist playback and one function to resume >>> playback. >>> >> Probably would apply to all playlists? I.e. no playlists should be played >> from at all. >> >> That way some `static bool playing;' could accomplish this (i.e. global >> across all playlists). >> > ? > start/stop, pause/resume would advise the sound engine to > start/stop/pause/resume the current playlist, not one single playlist... > > Well my idea was this: You can have only one playlist actively being played from at a time. Then if that is the case you do not need to control the playing/paused/stopped state of individual playlists. So you could effectively use one playing state for the entire playlist handling part of the soundlib. > This was _not_ a proposal for the scripting engine, but for the C-API... > The scripting engine would get some integer IDs or similar... > Yes, well the absence of that WZSound_ prefix was a bit confusing. > Hmmm... Actually the idea is not that bad... > Would make it easy to handle multiple playlists, eg. one for the menu > and for the game, or when The Modder wants to interupt the game with a > few different songs to acompany his cutscenes or the attack of the > clones... (And wants to switch back to the usual theme afterwards.) > > Implementation for createPlaylist: > New item of a playlist-linked-list. All pointers NULL. (next, prev, > thisTrack). > > addTrack: > Walk to the end of Playlist*, check if thisTrack is NULL, yes-> set > thisTrack to Track*, no-> append another empty item, link it in, set > it's thisTrack. > >> That implementation would have to require that the same piece of code that >> manages the playlist also manages the tracks. Because a pointer in that >> playlist would become i
Re: [Warzone-dev] Music playlists
Am Donnerstag, 25. Januar 2007 18:38 schrieb Troman:
> - Original Message -
> From: "Troman" <[EMAIL PROTECTED]>
> To: "Troman" <[EMAIL PROTECTED]>
> Sent: Thursday, January 25, 2007 5:57 PM
> Subject: temp
>
> > Am Donnerstag, 25. Januar 2007 15:46 schrieb Giel van Schijndel:
> >> On Thu, 25 Jan 2007 07:31:25 +0100, Dennis Schridde <[EMAIL PROTECTED]>
> >
> > wrote:
> >> > Am Donnerstag, 25. Januar 2007 01:21 schrieb Troman:
> >> >> - Original Message -
> >> >> From: "Dennis Schridde" <[EMAIL PROTECTED]>
> >> >> To:
> >> >> Sent: Thursday, January 25, 2007 12:26 AM
> >> >> Subject: Re: [Warzone-dev] Music playlists
> >> >>
> >> >>> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> >> >>>> - Original Message -
> >> >>>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
> >> >>>> To: "Development list"
> >> >>>> Sent: Wednesday, January 24, 2007 8:43 PM
> >> >>>> Subject: Re: [Warzone-dev] Music playlists
> >> >>>>
> >> >>>>> Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> >> >>>>>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> >> >>>>>>> I had some musings about the way this should work. Playlist
> >> >>>>>>> script
> >> >>>>>>> interface will be most used by scriptors I assume. I see two
> >> >>>>>>> main occasions when such an interface might be used:
> >> >>>>>>>
> >> >>>>>>> 1) when it is time to interrupt any background music that might
> >> >>>>>>> be
> >> >>>>>>> played and kick in some moody piece to create atmosphere, like
> >> >>>>>>> it is usually done in campaigns.
> >> >>>>>>>
> >> >>>>>>> 2) when someone wants to attach a custom playlist to his map,
> >> >>>>>>> the way it is done with Unreal Tournament maps for example.
> >> >>>>>>
> >> >>>>>> Agreed.
> >> >>>>>>
> >> >>>>>>> As for the implementation, looks like wz uses 'tracks' to store
> >> >>>>>>> songs. Track 2 corresponds to menu, track 1 to the in-game
> >> >>>>>>> music.
> >> >>>>>>
> >> >>>>>> I do not think we should let that get in the way of a decent API.
> >> >>>>>> We can change the way Warzone stores songs, if necessary.
> >> >>>>
> >> >>>> Since i'm not the one to program it it's fine with me. ;-)
> >> >>>>
> >> >>>>>>> When modder wants his custom playlist to be played when someone
> >> >>>>>>> is using his map he either loads all songs manually to the user
> >> >>>>>>> track using scripts, like
> >> >>>>>>>
> >> >>>>>>> playlistAddUserSong("mySong1.ogg");
> >> >>>>>>> playlistAddUserSong("mySong2.ogg");
> >> >>>>>>
> >> >>>>>> Sounds good.
> >> >>>>>>
> >> >>>>>>> Since this is not the most convenient approach it might be a
> >> >>>>>>> better idea to load playlist from an external playlist file,
> >> >>>>>>> which will come with the mod
> >> >>>>>>
> >> >>>>>> Well, to me the in-script version above seems more convenient
> >> >>>>>> than adding yet another file, since the number of songs will
> >> >>>>>> probably never be high.
> >>
> >> I agree, I think it's better to simply stick with creating the playlist
> >> through scripted functions. Also since I believe the scripts support an
> >> `#include' style directive, you don't have to clutter all your scripts
> >> with
> >> playlist-append calls.
> >>
> >> >>>>>>> In case of a map with custom playlist it is simple, just call
> >> >>>&g
Re: [Warzone-dev] Music playlists
On 1/25/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > I just don't know what else could be used. There are no dynamic arrays in
> > C, at least none that I know of. And I don't have another idea how
> > several dynamic-sized playlists could be handled. (I am lacking
> > experience and probably I didn't read my C book till the end.)
...
What I just thought about was some selfmade dynamic array:
struct Playlist { meta-info; Track[]; }
malloc( sizeof(meta-info) + sizeof(Track*) * playlistSize );
or realloc( ... );
Doesn't look nice, but would be an option...
Making dynamic arrays in C is not hard, but if you want a really nice
one, feel free to steal Freeciv's. It even has an iterator for easy
loops and you can define multiple types of dynamic arrays with a
separate namespace for the accessors of each... just what the doctor
ordered for the C++ addicts! ;-) All that in less than 150 lines.
See
http://svn.gna.org/viewcvs/freeciv/trunk/utility/specvec.h?rev=11261&view=auto
You get it for free today. Tomorrow the price will double ;-)
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Troman" <[EMAIL PROTECTED]>
Sent: Thursday, January 25, 2007 5:57 PM
Subject: temp
Am Donnerstag, 25. Januar 2007 15:46 schrieb Giel van Schijndel:
On Thu, 25 Jan 2007 07:31:25 +0100, Dennis Schridde <[EMAIL PROTECTED]>
wrote:
> Am Donnerstag, 25. Januar 2007 01:21 schrieb Troman:
>> - Original Message -
>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
>> To:
>> Sent: Thursday, January 25, 2007 12:26 AM
>> Subject: Re: [Warzone-dev] Music playlists
>>
>>> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
>>>> - Original Message -
>>>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
>>>> To: "Development list"
>>>> Sent: Wednesday, January 24, 2007 8:43 PM
>>>> Subject: Re: [Warzone-dev] Music playlists
>>>>
>>>>> Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
>>>>>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
>>>>>>> I had some musings about the way this should work. Playlist
>>>>>>> script
>>>>>>> interface will be most used by scriptors I assume. I see two main
>>>>>>> occasions when such an interface might be used:
>>>>>>>
>>>>>>> 1) when it is time to interrupt any background music that might
>>>>>>> be
>>>>>>> played and kick in some moody piece to create atmosphere, like it
>>>>>>> is usually done in campaigns.
>>>>>>>
>>>>>>> 2) when someone wants to attach a custom playlist to his map, the
>>>>>>> way it is done with Unreal Tournament maps for example.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> As for the implementation, looks like wz uses 'tracks' to store
>>>>>>> songs. Track 2 corresponds to menu, track 1 to the in-game music.
>>>>>>
>>>>>> I do not think we should let that get in the way of a decent API.
>>>>>> We can change the way Warzone stores songs, if necessary.
>>>>
>>>> Since i'm not the one to program it it's fine with me. ;-)
>>>>
>>>>>>> When modder wants his custom playlist to be played when someone
>>>>>>> is using his map he either loads all songs manually to the user
>>>>>>> track using scripts, like
>>>>>>>
>>>>>>> playlistAddUserSong("mySong1.ogg");
>>>>>>> playlistAddUserSong("mySong2.ogg");
>>>>>>
>>>>>> Sounds good.
>>>>>>
>>>>>>> Since this is not the most convenient approach it might be a
>>>>>>> better idea to load playlist from an external playlist file,
>>>>>>> which will come with the mod
>>>>>>
>>>>>> Well, to me the in-script version above seems more convenient
>>>>>> than adding yet another file, since the number of songs will
>>>>>> probably never be high.
I agree, I think it's better to simply stick with creating the playlist
through scripted functions. Also since I believe the scripts support an
`#include' style directive, you don't have to clutter all your scripts
with
playlist-append calls.
>>>>>>> In case of a map with custom playlist it is simple, just call
>>>>>>> something like playlistPlayUserTrack(); from within the scripts
>>>>>>> (or again we can make wz start playing user track automatically
>>>>>>> if a map comes with a user playlist) for wz to switch from player
>>>>>>> playlist to the custom map playlist.
>>>>>>
>>>>>> I think starting the script-supplied playlist automatically seems
>>>>>> like the simpler and better way.
>>>>
>>>> What if the user doesn't want any music to be played at the
>>>> beginning?
>>>> It's probably better to let the modder decide this.
>>>
>>> I think what Per meant is that there should be an initPlaylist
>>> function
>>> in the scripts, which is called upon mission start. If the modder
>>> doesn't want that, he must not provide that function.
>>
>> I don't know how we jumped from playback to init
Re: [Warzone-dev] Music playlists
Am Donnerstag, 25. Januar 2007 15:46 schrieb Giel van Schijndel:
> On Thu, 25 Jan 2007 07:31:25 +0100, Dennis Schridde <[EMAIL PROTECTED]>
wrote:
> > Am Donnerstag, 25. Januar 2007 01:21 schrieb Troman:
> >> - Original Message -
> >> From: "Dennis Schridde" <[EMAIL PROTECTED]>
> >> To:
> >> Sent: Thursday, January 25, 2007 12:26 AM
> >> Subject: Re: [Warzone-dev] Music playlists
> >>
> >>> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> >>>> - Original Message -
> >>>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
> >>>> To: "Development list"
> >>>> Sent: Wednesday, January 24, 2007 8:43 PM
> >>>> Subject: Re: [Warzone-dev] Music playlists
> >>>>
> >>>>> Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> >>>>>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> >>>>>>> I had some musings about the way this should work. Playlist script
> >>>>>>> interface will be most used by scriptors I assume. I see two main
> >>>>>>> occasions when such an interface might be used:
> >>>>>>>
> >>>>>>> 1) when it is time to interrupt any background music that might be
> >>>>>>> played and kick in some moody piece to create atmosphere, like it
> >>>>>>> is usually done in campaigns.
> >>>>>>>
> >>>>>>> 2) when someone wants to attach a custom playlist to his map, the
> >>>>>>> way it is done with Unreal Tournament maps for example.
> >>>>>>
> >>>>>> Agreed.
> >>>>>>
> >>>>>>> As for the implementation, looks like wz uses 'tracks' to store
> >>>>>>> songs. Track 2 corresponds to menu, track 1 to the in-game music.
> >>>>>>
> >>>>>> I do not think we should let that get in the way of a decent API.
> >>>>>> We can change the way Warzone stores songs, if necessary.
> >>>>
> >>>> Since i'm not the one to program it it's fine with me. ;-)
> >>>>
> >>>>>>> When modder wants his custom playlist to be played when someone
> >>>>>>> is using his map he either loads all songs manually to the user
> >>>>>>> track using scripts, like
> >>>>>>>
> >>>>>>> playlistAddUserSong("mySong1.ogg");
> >>>>>>> playlistAddUserSong("mySong2.ogg");
> >>>>>>
> >>>>>> Sounds good.
> >>>>>>
> >>>>>>> Since this is not the most convenient approach it might be a
> >>>>>>> better idea to load playlist from an external playlist file,
> >>>>>>> which will come with the mod
> >>>>>>
> >>>>>> Well, to me the in-script version above seems more convenient
> >>>>>> than adding yet another file, since the number of songs will
> >>>>>> probably never be high.
>
> I agree, I think it's better to simply stick with creating the playlist
> through scripted functions. Also since I believe the scripts support an
> `#include' style directive, you don't have to clutter all your scripts with
> playlist-append calls.
>
> >>>>>>> In case of a map with custom playlist it is simple, just call
> >>>>>>> something like playlistPlayUserTrack(); from within the scripts
> >>>>>>> (or again we can make wz start playing user track automatically
> >>>>>>> if a map comes with a user playlist) for wz to switch from player
> >>>>>>> playlist to the custom map playlist.
> >>>>>>
> >>>>>> I think starting the script-supplied playlist automatically seems
> >>>>>> like the simpler and better way.
> >>>>
> >>>> What if the user doesn't want any music to be played at the beginning?
> >>>> It's probably better to let the modder decide this.
> >>>
> >>> I think what Per meant is that there should be an initPlaylist function
> >>> in the scripts, which is called upon mission start. If the modder
> >>> doesn't want that, he must not provide that func
Re: [Warzone-dev] Music playlists
On Thu, 25 Jan 2007 07:31:25 +0100, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 25. Januar 2007 01:21 schrieb Troman:
>> - Original Message -
>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
>> To:
>> Sent: Thursday, January 25, 2007 12:26 AM
>> Subject: Re: [Warzone-dev] Music playlists
>>
>>> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
>>>> - Original Message -
>>>> From: "Dennis Schridde" <[EMAIL PROTECTED]>
>>>> To: "Development list"
>>>> Sent: Wednesday, January 24, 2007 8:43 PM
>>>> Subject: Re: [Warzone-dev] Music playlists
>>>>
>>>>> Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
>>>>>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
>>>>>>> I had some musings about the way this should work. Playlist script
>>>>>>> interface will be most used by scriptors I assume. I see two main
>>>>>>> occasions when such an interface might be used:
>>>>>>>
>>>>>>> 1) when it is time to interrupt any background music that might be
>>>>>>> played and kick in some moody piece to create atmosphere, like it
>>>>>>> is usually done in campaigns.
>>>>>>>
>>>>>>> 2) when someone wants to attach a custom playlist to his map, the
>>>>>>> way it is done with Unreal Tournament maps for example.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> As for the implementation, looks like wz uses 'tracks' to store
>>>>>>> songs. Track 2 corresponds to menu, track 1 to the in-game music.
>>>>>>
>>>>>> I do not think we should let that get in the way of a decent API.
>>>>>> We can change the way Warzone stores songs, if necessary.
>>>>
>>>> Since i'm not the one to program it it's fine with me. ;-)
>>>>
>>>>>>> When modder wants his custom playlist to be played when someone
>>>>>>> is using his map he either loads all songs manually to the user
>>>>>>> track using scripts, like
>>>>>>>
>>>>>>> playlistAddUserSong("mySong1.ogg");
>>>>>>> playlistAddUserSong("mySong2.ogg");
>>>>>>
>>>>>> Sounds good.
>>>>>>
>>>>>>> Since this is not the most convenient approach it might be a
>>>>>>> better idea to load playlist from an external playlist file,
>>>>>>> which will come with the mod
>>>>>>
>>>>>> Well, to me the in-script version above seems more convenient
>>>>>> than adding yet another file, since the number of songs will probably
>>>>>> never be high.
I agree, I think it's better to simply stick with creating the playlist through
scripted functions. Also since I believe the scripts support an `#include'
style directive, you don't have to clutter all your scripts with
playlist-append calls.
>>>>>>> In case of a map with custom playlist it is simple, just call
>>>>>>> something like playlistPlayUserTrack(); from within the scripts
>>>>>>> (or again we can make wz start playing user track automatically
>>>>>>> if a map comes with a user playlist) for wz to switch from player
>>>>>>> playlist to the custom map playlist.
>>>>>>
>>>>>> I think starting the script-supplied playlist automatically seems
>>>>>> like the simpler and better way.
>>>>
>>>> What if the user doesn't want any music to be played at the beginning?
>>>> It's probably better to let the modder decide this.
>>>
>>> I think what Per meant is that there should be an initPlaylist function
>>> in the scripts, which is called upon mission start. If the modder
>>> doesn't want that, he must not provide that function.
>>
>> I don't know how we jumped from playback to initialization. Anyway, for
>> the initialization of the playlist you just place the necessary code into
>> the script callback that gets called whenever a map is loaded.
I think we should just allow the creation of multiple playlists, and then have
some function to select the current active one (like bindPlaylist below). Then
whe
Re: [Warzone-dev] Music playlists
Am Donnerstag, 25. Januar 2007 01:21 schrieb Troman:
> - Original Message -
> From: "Dennis Schridde" <[EMAIL PROTECTED]>
> To:
> Sent: Thursday, January 25, 2007 12:26 AM
> Subject: Re: [Warzone-dev] Music playlists
>
> > Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> > > - Original Message -
> > > From: "Dennis Schridde" <[EMAIL PROTECTED]>
> > > To: "Development list"
> > > Sent: Wednesday, January 24, 2007 8:43 PM
> > > Subject: Re: [Warzone-dev] Music playlists
> > >
> > > >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> > > >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > > >> > I had some musings about the way this should work. Playlist script
> > > >> > interface will be most used by scriptors I assume. I see two main
> > > >> > occasions when such an interface might be used:
> > > >> >
> > > >> > 1) when it is time to interrupt any background music that might be
> > > >> > played and kick in some moody piece to create atmosphere, like it
> > > >> > is usually done in campaigns.
> > > >> >
> > > >> > 2) when someone wants to attach a custom playlist to his map, the
> > > >> > way it is done with Unreal Tournament maps for example.
> > > >>
> > > >> Agreed.
> > > >>
> > > >> > As for the implementation, looks like wz uses 'tracks' to store
> > > >> > songs. Track 2 corresponds to menu, track 1 to the in-game music.
> > > >>
> > > >> I do not think we should let that get in the way of a decent API. We
> > > >> can change the way Warzone stores songs, if necessary.
> > >
> > > Since i'm not the one to program it it's fine with me. ;-)
> > >
> > > >> > When modder wants his custom playlist to be played when someone is
> > > >> > using his map he either loads all songs manually to the user track
> > > >> > using scripts, like
> > > >> >
> > > >> > playlistAddUserSong("mySong1.ogg");
> > > >> > playlistAddUserSong("mySong2.ogg");
> > > >>
> > > >> Sounds good.
> > > >>
> > > >> > Since this is not the most convenient approach it might be a
> > > >> > better idea to load playlist from an external playlist file, which
> > > >> > will come with the mod
> > > >>
> > > >> Well, to me the in-script version above seems more convenient than
> > > >> adding yet another file, since the number of songs will probably
> > > >> never be high.
> > > >>
> > > >> > In case of a map with custom playlist it is simple, just call
> > > >> > something like playlistPlayUserTrack(); from within the scripts
> > > >> > (or again we can make wz start playing user track automatically if
> > > >> > a map comes with a user playlist) for wz to switch from player
> > > >> > playlist to the custom map playlist.
> > > >>
> > > >> I think starting the script-supplied playlist automatically seems
> > > >> like the simpler and better way.
> > >
> > > What if the user doesn't want any music to be played at the beginning?
> > > It's probably better to let the modder decide this.
> >
> > I think what Per meant is that there should be an initPlaylist function
> > in the scripts, which is called upon mission start. If the modder doesn't
> > want that, he must not provide that function.
>
> I don't know how we jumped from playback to initialization. Anyway, for the
> initialization of the playlist you just place the necessary code into the
> script callback that gets called whenever a map is loaded.
>
> > > >> > In cases when some music must kick in from time to time depending
> > > >> > on some in-game conditions it is a bit more complicated.
> > > >>
> > > >> There are probably two different needs here:
> > > >> 1) Scripter wants to play a short song to set the theme of some
> > > >> event, then resume the playlist as normal. The new song should then
> > > >> not be in the playlist afterwards.
> > > >> 2) Scripter wants to change the whole theme of a level by pl
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To:
Sent: Thursday, January 25, 2007 12:26 AM
Subject: Re: [Warzone-dev] Music playlists
> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> > - Original Message -
> > From: "Dennis Schridde" <[EMAIL PROTECTED]>
> > To: "Development list"
> > Sent: Wednesday, January 24, 2007 8:43 PM
> > Subject: Re: [Warzone-dev] Music playlists
> >
> > >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> > >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > >> > I had some musings about the way this should work. Playlist script
> > >> > interface will be most used by scriptors I assume. I see two main
> > >> > occasions when such an interface might be used:
> > >> >
> > >> > 1) when it is time to interrupt any background music that might be
> > >> > played and kick in some moody piece to create atmosphere, like it is
> > >> > usually done in campaigns.
> > >> >
> > >> > 2) when someone wants to attach a custom playlist to his map, the way
> > >> > it is done with Unreal Tournament maps for example.
> > >>
> > >> Agreed.
> > >>
> > >> > As for the implementation, looks like wz uses 'tracks' to store songs.
> > >> > Track 2 corresponds to menu, track 1 to the in-game music.
> > >>
> > >> I do not think we should let that get in the way of a decent API. We
> > >> can change the way Warzone stores songs, if necessary.
> >
> > Since i'm not the one to program it it's fine with me. ;-)
> >
> > >> > When modder wants his custom playlist to be played when someone is
> > >> > using his map he either loads all songs manually to the user track
> > >> > using scripts, like
> > >> >
> > >> > playlistAddUserSong("mySong1.ogg");
> > >> > playlistAddUserSong("mySong2.ogg");
> > >>
> > >> Sounds good.
> > >>
> > >> > Since this is not the most convenient approach it might be a better
> > >> > idea to load playlist from an external playlist file, which will come
> > >> > with the mod
> > >>
> > >> Well, to me the in-script version above seems more convenient than
> > >> adding yet another file, since the number of songs will probably never
> > >> be high.
> > >>
> > >> > In case of a map with custom playlist it is simple, just call
> > >> > something like playlistPlayUserTrack(); from within the scripts (or
> > >> > again we can make wz start playing user track automatically if a map
> > >> > comes with a user playlist) for wz to switch from player playlist to
> > >> > the custom map playlist.
> > >>
> > >> I think starting the script-supplied playlist automatically seems like
> > >> the simpler and better way.
> >
> > What if the user doesn't want any music to be played at the beginning? It's
> > probably better to let the modder decide this.
> I think what Per meant is that there should be an initPlaylist function in
> the
> scripts, which is called upon mission start. If the modder doesn't want that,
> he must not provide that function.
I don't know how we jumped from playback to initialization. Anyway, for the
initialization of the playlist you just place the necessary code into the
script callback that gets called whenever a map is loaded.
>
> > >> > In cases when some music must kick in from time to time depending on
> > >> > some in-game conditions it is a bit more complicated.
> > >>
> > >> There are probably two different needs here:
> > >> 1) Scripter wants to play a short song to set the theme of some event,
> > >> then resume the playlist as normal. The new song should then not be in
> > >> the playlist afterwards.
> > >> 2) Scripter wants to change the whole theme of a level by playing a
> > >> new song or songs throughout the remaining time (or until it changes
> > >> again). So we need a way to reset the playlist; then the scripter can
> > >> add the new songs.
> > >>
> > >> So how about an API like this:
> > >> playlistReset() -- deletes existing playlist (eg to remove game
> > >> supplied playlist)
> > >> playlistAdd(son
Re: [Warzone-dev] Music playlists
Am Donnerstag, 25. Januar 2007 00:22 schrieb Dennis Schridde:
> Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> > - Original Message -
> > From: "Dennis Schridde" <[EMAIL PROTECTED]>
> > To: "Development list"
> > Sent: Wednesday, January 24, 2007 8:43 PM
> > Subject: Re: [Warzone-dev] Music playlists
> >
> > >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> > >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > >> > I had some musings about the way this should work. Playlist script
> > >> > interface will be most used by scriptors I assume. I see two main
> > >> > occasions when such an interface might be used:
> > >> >
> > >> > 1) when it is time to interrupt any background music that might be
> > >> > played and kick in some moody piece to create atmosphere, like it is
> > >> > usually done in campaigns.
> > >> >
> > >> > 2) when someone wants to attach a custom playlist to his map, the
> > >> > way it is done with Unreal Tournament maps for example.
> > >>
> > >> Agreed.
> > >>
> > >> > As for the implementation, looks like wz uses 'tracks' to store
> > >> > songs. Track 2 corresponds to menu, track 1 to the in-game music.
> > >>
> > >> I do not think we should let that get in the way of a decent API. We
> > >> can change the way Warzone stores songs, if necessary.
> >
> > Since i'm not the one to program it it's fine with me. ;-)
> >
> > >> > When modder wants his custom playlist to be played when someone is
> > >> > using his map he either loads all songs manually to the user track
> > >> > using scripts, like
> > >> >
> > >> > playlistAddUserSong("mySong1.ogg");
> > >> > playlistAddUserSong("mySong2.ogg");
> > >>
> > >> Sounds good.
> > >>
> > >> > Since this is not the most convenient approach it might be a better
> > >> > idea to load playlist from an external playlist file, which will
> > >> > come with the mod
> > >>
> > >> Well, to me the in-script version above seems more convenient than
> > >> adding yet another file, since the number of songs will probably never
> > >> be high.
> > >>
> > >> > In case of a map with custom playlist it is simple, just call
> > >> > something like playlistPlayUserTrack(); from within the scripts (or
> > >> > again we can make wz start playing user track automatically if a map
> > >> > comes with a user playlist) for wz to switch from player playlist to
> > >> > the custom map playlist.
> > >>
> > >> I think starting the script-supplied playlist automatically seems like
> > >> the simpler and better way.
> >
> > What if the user doesn't want any music to be played at the beginning?
> > It's probably better to let the modder decide this.
>
> I think what Per meant is that there should be an initPlaylist function in
> the scripts, which is called upon mission start. If the modder doesn't want
> that, he must not provide that function.
>
> > >> > In cases when some music must kick in from time to time depending on
> > >> > some in-game conditions it is a bit more complicated.
> > >>
> > >> There are probably two different needs here:
> > >> 1) Scripter wants to play a short song to set the theme of some event,
> > >> then resume the playlist as normal. The new song should then not be in
> > >> the playlist afterwards.
> > >> 2) Scripter wants to change the whole theme of a level by playing a
> > >> new song or songs throughout the remaining time (or until it changes
> > >> again). So we need a way to reset the playlist; then the scripter can
> > >> add the new songs.
> > >>
> > >> So how about an API like this:
> > >> playlistReset() -- deletes existing playlist (eg to remove game
> > >> supplied playlist)
> > >> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
> > >> supplied playlist)
> > >> playlistInterruptWith(song) -- play a song once, then resume playing
> > >> playlist (eg for event)
> >
> > Makes sense to me.
>
> Didn't say that it doesn't to me.
> Just the nami
Re: [Warzone-dev] Music playlists
Am Mittwoch, 24. Januar 2007 22:42 schrieb Troman:
> - Original Message -
> From: "Dennis Schridde" <[EMAIL PROTECTED]>
> To: "Development list"
> Sent: Wednesday, January 24, 2007 8:43 PM
> Subject: Re: [Warzone-dev] Music playlists
>
> >Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> >> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> >> > I had some musings about the way this should work. Playlist script
> >> > interface will be most used by scriptors I assume. I see two main
> >> > occasions when such an interface might be used:
> >> >
> >> > 1) when it is time to interrupt any background music that might be
> >> > played and kick in some moody piece to create atmosphere, like it is
> >> > usually done in campaigns.
> >> >
> >> > 2) when someone wants to attach a custom playlist to his map, the way
> >> > it is done with Unreal Tournament maps for example.
> >>
> >> Agreed.
> >>
> >> > As for the implementation, looks like wz uses 'tracks' to store songs.
> >> > Track 2 corresponds to menu, track 1 to the in-game music.
> >>
> >> I do not think we should let that get in the way of a decent API. We
> >> can change the way Warzone stores songs, if necessary.
>
> Since i'm not the one to program it it's fine with me. ;-)
>
> >> > When modder wants his custom playlist to be played when someone is
> >> > using his map he either loads all songs manually to the user track
> >> > using scripts, like
> >> >
> >> > playlistAddUserSong("mySong1.ogg");
> >> > playlistAddUserSong("mySong2.ogg");
> >>
> >> Sounds good.
> >>
> >> > Since this is not the most convenient approach it might be a better
> >> > idea to load playlist from an external playlist file, which will come
> >> > with the mod
> >>
> >> Well, to me the in-script version above seems more convenient than
> >> adding yet another file, since the number of songs will probably never
> >> be high.
> >>
> >> > In case of a map with custom playlist it is simple, just call
> >> > something like playlistPlayUserTrack(); from within the scripts (or
> >> > again we can make wz start playing user track automatically if a map
> >> > comes with a user playlist) for wz to switch from player playlist to
> >> > the custom map playlist.
> >>
> >> I think starting the script-supplied playlist automatically seems like
> >> the simpler and better way.
>
> What if the user doesn't want any music to be played at the beginning? It's
> probably better to let the modder decide this.
I think what Per meant is that there should be an initPlaylist function in the
scripts, which is called upon mission start. If the modder doesn't want that,
he must not provide that function.
> >> > In cases when some music must kick in from time to time depending on
> >> > some in-game conditions it is a bit more complicated.
> >>
> >> There are probably two different needs here:
> >> 1) Scripter wants to play a short song to set the theme of some event,
> >> then resume the playlist as normal. The new song should then not be in
> >> the playlist afterwards.
> >> 2) Scripter wants to change the whole theme of a level by playing a
> >> new song or songs throughout the remaining time (or until it changes
> >> again). So we need a way to reset the playlist; then the scripter can
> >> add the new songs.
> >>
> >> So how about an API like this:
> >> playlistReset() -- deletes existing playlist (eg to remove game
> >> supplied playlist)
> >> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
> >> supplied playlist)
> >> playlistInterruptWith(song) -- play a song once, then resume playing
> >> playlist (eg for event)
>
> Makes sense to me.
Didn't say that it doesn't to me.
Just the naming is not my favourite...
playlistReset -> clearPlaylist
playlistInteruptWith -> playTrack
That was my idea... Maybe not ideal, either.
> >My proposal:
> >
> >Function to set a playlist.
> >Function to immediately play one track.
> >Function to stop playlist playback and one function to resume playback.
> >Function to set playback-modes, like repeat_all, shuffle, fadein, fadeout,
> >crossfade.
Those effects (not shuffle, but .*fade.*) would al
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Dennis Schridde" <[EMAIL PROTECTED]>
To: "Development list"
Sent: Wednesday, January 24, 2007 8:43 PM
Subject: Re: [Warzone-dev] Music playlists
>Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
>> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
>> > I had some musings about the way this should work. Playlist script
>> > interface will be most used by scriptors I assume. I see two main
>> > occasions when such an interface might be used:
>> >
>> > 1) when it is time to interrupt any background music that might be played
>> > and kick in some moody piece to create atmosphere, like it is usually
>> > done in campaigns.
>> >
>> > 2) when someone wants to attach a custom playlist to his map, the way it
>> > is done with Unreal Tournament maps for example.
>>
>> Agreed.
>>
>> > As for the implementation, looks like wz uses 'tracks' to store songs.
>> > Track 2 corresponds to menu, track 1 to the in-game music.
>>
>> I do not think we should let that get in the way of a decent API. We
>> can change the way Warzone stores songs, if necessary.
Since i'm not the one to program it it's fine with me. ;-)
>>
>> > When modder wants his custom playlist to be played when someone is using
>> > his map he either loads all songs manually to the user track using
>> > scripts, like
>> >
>> > playlistAddUserSong("mySong1.ogg");
>> > playlistAddUserSong("mySong2.ogg");
>>
>> Sounds good.
>>
>> > Since this is not the most convenient approach it might be a better idea
>> > to load playlist from an external playlist file, which will come with the
>> > mod
>>
>> Well, to me the in-script version above seems more convenient than
>> adding yet another file, since the number of songs will probably never
>> be high.
>>
>> > In case of a map with custom playlist it is simple, just call something
>> > like playlistPlayUserTrack(); from within the scripts (or again we can
>> > make wz start playing user track automatically if a map comes with a user
>> > playlist) for wz to switch from player playlist to the custom map
>> > playlist.
>>
>> I think starting the script-supplied playlist automatically seems like
>> the simpler and better way.
What if the user doesn't want any music to be played at the beginning? It's
probably better to let the modder decide this.
>> > In cases when some music must kick in from time to time depending on some
>> > in-game conditions it is a bit more complicated.
>>
>> There are probably two different needs here:
>> 1) Scripter wants to play a short song to set the theme of some event,
>> then resume the playlist as normal. The new song should then not be in
>> the playlist afterwards.
>> 2) Scripter wants to change the whole theme of a level by playing a
>> new song or songs throughout the remaining time (or until it changes
>> again). So we need a way to reset the playlist; then the scripter can
>> add the new songs.
>>
>> So how about an API like this:
>> playlistReset() -- deletes existing playlist (eg to remove game
>> supplied playlist)
>> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
>> supplied playlist)
>> playlistInterruptWith(song) -- play a song once, then resume playing
>> playlist (eg for event)
Makes sense to me.
>My proposal:
>
>Function to set a playlist.
>Function to immediately play one track.
>Function to stop playlist playback and one function to resume playback.
>Function to set playback-modes, like repeat_all, shuffle, fadein, fadeout,
>crossfade.
This all can surely be usefull to the end user/scriptor. Crossfades for
'insertations' especially in campaigns etc.
>
>Clearing the playlist is simply supplying an empty playlist.
>I don't think there is any need to dynamically attach a track to the playlist,
>am I correct? Why would one attach a song if he doesn't know when it will be
>played...
You never know what's going on inside of a modder's head, it doesn't take much
affort to provide this functionality, besides I don't see how else we would
want to re-fill the list (see below).
>Stoping and resuming the playlist may be interesting to create moments of
>total silence or when cutscenes are played.
>
>C-Functions:
>WZSound_setPlaylist( Song * song1, ... );
>WZSound_playTrack( Track interuptionTrack );
>WZSound_stopPlaylist();
>WZSound_resumePlay
Re: [Warzone-dev] Music playlists
Am Mittwoch, 24. Januar 2007 18:46 schrieb Per Inge Mathisen:
> On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
> > I had some musings about the way this should work. Playlist script
> > interface will be most used by scriptors I assume. I see two main
> > occasions when such an interface might be used:
> >
> > 1) when it is time to interrupt any background music that might be played
> > and kick in some moody piece to create atmosphere, like it is usually
> > done in campaigns.
> >
> > 2) when someone wants to attach a custom playlist to his map, the way it
> > is done with Unreal Tournament maps for example.
>
> Agreed.
>
> > As for the implementation, looks like wz uses 'tracks' to store songs.
> > Track 2 corresponds to menu, track 1 to the in-game music.
>
> I do not think we should let that get in the way of a decent API. We
> can change the way Warzone stores songs, if necessary.
>
> > When modder wants his custom playlist to be played when someone is using
> > his map he either loads all songs manually to the user track using
> > scripts, like
> >
> > playlistAddUserSong("mySong1.ogg");
> > playlistAddUserSong("mySong2.ogg");
>
> Sounds good.
>
> > Since this is not the most convenient approach it might be a better idea
> > to load playlist from an external playlist file, which will come with the
> > mod
>
> Well, to me the in-script version above seems more convenient than
> adding yet another file, since the number of songs will probably never
> be high.
>
> > In case of a map with custom playlist it is simple, just call something
> > like playlistPlayUserTrack(); from within the scripts (or again we can
> > make wz start playing user track automatically if a map comes with a user
> > playlist) for wz to switch from player playlist to the custom map
> > playlist.
>
> I think starting the script-supplied playlist automatically seems like
> the simpler and better way.
>
> > In cases when some music must kick in from time to time depending on some
> > in-game conditions it is a bit more complicated.
>
> There are probably two different needs here:
> 1) Scripter wants to play a short song to set the theme of some event,
> then resume the playlist as normal. The new song should then not be in
> the playlist afterwards.
> 2) Scripter wants to change the whole theme of a level by playing a
> new song or songs throughout the remaining time (or until it changes
> again). So we need a way to reset the playlist; then the scripter can
> add the new songs.
>
> So how about an API like this:
> playlistReset() -- deletes existing playlist (eg to remove game
> supplied playlist)
> playlistAdd(song) -- adds song to top of playlist (eg to add to game's
> supplied playlist)
> playlistInterruptWith(song) -- play a song once, then resume playing
> playlist (eg for event)
My proposal:
Function to set a playlist.
Function to immediately play one track.
Function to stop playlist playback and one function to resume playback.
Function to set playback-modes, like repeat_all, shuffle, fadein, fadeout,
crossfade.
Clearing the playlist is simply supplying an empty playlist.
I don't think there is any need to dynamically attach a track to the playlist,
am I correct? Why would one attach a song if he doesn't know when it will be
played...
Stoping and resuming the playlist may be interesting to create moments of
total silence or when cutscenes are played.
C-Functions:
WZSound_setPlaylist( Song * song1, ... );
WZSound_playTrack( Track interuptionTrack );
WZSound_stopPlaylist();
WZSound_resumePlaylist();
WZSound_setPlaylistMode( PlaylistMode newMode );
typedef PlaylistMode UInt8;
#define PLAYLIST_SHUFFLE 0x1
#define PLAYLIST_REPEAT_ALL 0x2
#define PLAYLIST_CROSSFADE 0x4
...
C-Function examples:
WZSound_setPlaylist( song1, song2, song3 );
WZSound_setPlaylist( NULL );
WZSound_setPlaylistMode( PLAYLIST_SHUFFLE | PLAYLIST_CROSSFADE );
Script-Function examples:
WZSound_setPlaylist( "song1.ogg", "song2.ogg", "song3.ogg" );
WZSound_setPlaylist( "none" );
WZSound_playTrack( "event1.ogg" );
WZSound_setPlaylistMode( "shuffle", "fadein" );
WZSound_setPlaylistMode( "repeat_all", "crossfade", "fadeout" );
WZSound_setPlaylistMode( "none" );
Additionally I would sent following events to the scripts (and over the
internal event-bus), namings are currently very bad:
playlist_stop
playlist_resume
playlist_nextTrack
playlist_customTrack
playlist_customTrackEnd
playlist_modeChange
playlist_new
playlist_end
--Dennis
pgpUNWRoLS1NN.pgp
Description: PGP signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
On 1/18/07, Troman <[EMAIL PROTECTED]> wrote:
I had some musings about the way this should work. Playlist script interface
will be most used by scriptors I assume. I see two main occasions when such
an interface might be used:
1) when it is time to interrupt any background music that might be played
and kick in some moody piece to create atmosphere, like it is usually done
in campaigns.
2) when someone wants to attach a custom playlist to his map, the way it is
done with Unreal Tournament maps for example.
Agreed.
As for the implementation, looks like wz uses 'tracks' to store songs. Track
2 corresponds to menu, track 1 to the in-game music.
I do not think we should let that get in the way of a decent API. We
can change the way Warzone stores songs, if necessary.
When modder wants his custom playlist to be played when someone is using his
map he either loads all songs manually to the user track using scripts, like
playlistAddUserSong("mySong1.ogg");
playlistAddUserSong("mySong2.ogg");
Sounds good.
Since this is not the most convenient approach it might be a better idea to
load playlist from an external playlist file, which will come with the mod
Well, to me the in-script version above seems more convenient than
adding yet another file, since the number of songs will probably never
be high.
In case of a map with custom playlist it is simple, just call something like
playlistPlayUserTrack(); from within the scripts (or again we can make wz
start playing user track automatically if a map comes with a user playlist)
for wz to switch from player playlist to the custom map playlist.
I think starting the script-supplied playlist automatically seems like
the simpler and better way.
In cases when some music must kick in from time to time depending on some
in-game conditions it is a bit more complicated.
There are probably two different needs here:
1) Scripter wants to play a short song to set the theme of some event,
then resume the playlist as normal. The new song should then not be in
the playlist afterwards.
2) Scripter wants to change the whole theme of a level by playing a
new song or songs throughout the remaining time (or until it changes
again). So we need a way to reset the playlist; then the scripter can
add the new songs.
So how about an API like this:
playlistReset() -- deletes existing playlist (eg to remove game
supplied playlist)
playlistAdd(song) -- adds song to top of playlist (eg to add to game's
supplied playlist)
playlistInterruptWith(song) -- play a song once, then resume playing
playlist (eg for event)
I'm not sure if we really need an additional 'user track', but it has
following advantages: songs defined by player and modder are present at the
same time and are kept in separate places. While playing player playlist
(sorry for the tongue twister) wz will not accidentally start playing a song
which might be reserved for a special occasion by the modder.
On startup wz can switch to the 'user track' to play songs defined by modder
while still leaving the player ability to switch back to his own playlist.
I did not quite understand the above.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message -
From: "Troman" <[EMAIL PROTECTED]>
To: "Development list"
Sent: Sunday, January 14, 2007 3:48 PM
Subject: Re: [Warzone-dev] Music playlists
On 1/12/07, Troman <[EMAIL PROTECTED]> wrote:
Per, do you want scripts to be able to create/manage playlists or just
start
some soundtrack with playBackgroundAudio()?
Now that you mention it, I think we would should have an interface to
some kind of playlist from scripts, not just playBackgroundAudio().
Not sure what exactly you have in mind, but as I see it all we need is
an
interface between scripts and some wz playlist functionality, and in
either
case that should be fairy easy to add the necessary script functions.
Could you have a go at it? If changes to the sound code is required, I
can do those, but I think pretty much everything that would be needed
is there already.
I might take a look at it in the next days.
Troman
I had some musings about the way this should work. Playlist script interface
will be most used by scriptors I assume. I see two main occasions when such
an interface might be used:
1) when it is time to interrupt any background music that might be played
and kick in some moody piece to create atmosphere, like it is usually done
in campaigns.
2) when someone wants to attach a custom playlist to his map, the way it is
done with Unreal Tournament maps for example.
As for the implementation, looks like wz uses 'tracks' to store songs. Track
2 corresponds to menu, track 1 to the in-game music. We can add a 'user
track', which will not be directly accessible by the player from inside the
game.
When modder wants his custom playlist to be played when someone is using his
map he either loads all songs manually to the user track using scripts, like
playlistAddUserSong("mySong1.ogg");
playlistAddUserSong("mySong2.ogg");
Since this is not the most convenient approach it might be a better idea to
load playlist from an external playlist file, which will come with the mod;
either using scripts, like:
playlistLoadUserTrack("myPlaylist.wpl");
or we can make wz recognize a pre-defined filename and load it
automatically.
In case of a map with custom playlist it is simple, just call something like
playlistPlayUserTrack(); from within the scripts (or again we can make wz
start playing user track automatically if a map comes with a user playlist)
for wz to switch from player playlist to the custom map playlist.
In cases when some music must kick in from time to time depending on some
in-game conditions it is a bit more complicated. If user manually adds songs
to the user playlist using script functions we might make this function
return some handle so that modder can refer to a particular song, since
different songs must be played on different occasions selectively, using
this handle or we can simply reuse the filename.
When some song must be played call playlistPlayUserSong(song_handle); or
playlistPlayUserSong("song_name.ogg");
In such cases it might not even be necessary to add songs to the playlist
before playing it, I guess it depends on whatever implementation we will
choose.
I'm not sure if we really need an additional 'user track', but it has
following advantages: songs defined by player and modder are present at the
same time and are kept in separate places. While playing player playlist
(sorry for the tongue twister) wz will not accidentally start playing a song
which might be reserved for a special occasion by the modder.
On startup wz can switch to the 'user track' to play songs defined by modder
while still leaving the player ability to switch back to his own playlist.
Comments?
Troman
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
Troman schreef: > > - Original Message - From: "Per Inge Mathisen" > <[EMAIL PROTECTED]> > To: "Development list" > Sent: Sunday, January 14, 2007 2:51 PM > Subject: Re: [Warzone-dev] Music playlists > > >> On 1/12/07, Troman <[EMAIL PROTECTED]> wrote: >>> Per, do you want scripts to be able to create/manage playlists or >>> just start >>> some soundtrack with playBackgroundAudio()? >> >> Now that you mention it, I think we would should have an interface to >> some kind of playlist from scripts, not just playBackgroundAudio(). >> >>> Not sure what exactly you have in mind, but as I see it all we need >>> is an >>> interface between scripts and some wz playlist functionality, and in >>> either >>> case that should be fairy easy to add the necessary script functions. >> >> Could you have a go at it? If changes to the sound code is required, I >> can do those, but I think pretty much everything that would be needed >> is there already. > > I might take a look at it in the next days. You'll have to look for a function called something like create2dsource in either track.c or openal_track.c -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Sunday, January 14, 2007 2:51 PM Subject: Re: [Warzone-dev] Music playlists On 1/12/07, Troman <[EMAIL PROTECTED]> wrote: Per, do you want scripts to be able to create/manage playlists or just start some soundtrack with playBackgroundAudio()? Now that you mention it, I think we would should have an interface to some kind of playlist from scripts, not just playBackgroundAudio(). Not sure what exactly you have in mind, but as I see it all we need is an interface between scripts and some wz playlist functionality, and in either case that should be fairy easy to add the necessary script functions. Could you have a go at it? If changes to the sound code is required, I can do those, but I think pretty much everything that would be needed is there already. I might take a look at it in the next days. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
On 1/12/07, Troman <[EMAIL PROTECTED]> wrote: Per, do you want scripts to be able to create/manage playlists or just start some soundtrack with playBackgroundAudio()? Now that you mention it, I think we would should have an interface to some kind of playlist from scripts, not just playBackgroundAudio(). Not sure what exactly you have in mind, but as I see it all we need is an interface between scripts and some wz playlist functionality, and in either case that should be fairy easy to add the necessary script functions. Could you have a go at it? If changes to the sound code is required, I can do those, but I think pretty much everything that would be needed is there already. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
- Original Message - From: "Per Inge Mathisen" <[EMAIL PROTECTED]> To: "Development list" Sent: Thursday, January 11, 2007 1:17 PM Subject: [Warzone-dev] Music playlists I think it would be a good idea to start adding some of the music that has been made, just to show that we care. So I had a look at the playlist code, and was a bit surprised at why it was made the way it is. Basically, the current playlist code was made after the code release, and just uses the text file data/music/music.wpl as a list. There is also a script command "playBackgroundAudio" which looks like it is supposed to control music from within scripts, and this seems to me a vastly superior solution. This way a scenario can change the music soundtrack from its scripts depending on where you are in the campaign, for example. However, this script command does not seem to be used anywhere, and ends up in a dummy function (lib/sound/openal_track.c:sound_PlayStream(...)). I think I would prefer fixing the script function, rather than keeping the playlist code. What is the opinion of everyone else? Troman, you are the script guru, any thoughts? - Per Sorry, wasn't online in the last few days. Per, do you want scripts to be able to create/manage playlists or just start some soundtrack with playBackgroundAudio()? Not sure what exactly you have in mind, but as I see it all we need is an interface between scripts and some wz playlist functionality, and in either case that should be fairy easy to add the necessary script functions. Troman ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
On 1/11/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: Am Donnerstag, 11. Januar 2007 13:17 schrieb Per Inge Mathisen: > I think it would be a good idea to start adding some of the music that > has been made, just to show that we care. So I had a look at the > playlist code, and was a bit surprised at why it was made the way it > is. Basically, the current playlist code was made after the code > release, and just uses the text file data/music/music.wpl as a list. > > There is also a script command "playBackgroundAudio" which looks like > it is supposed to control music from within scripts, and this seems to > me a vastly superior solution. This way a scenario can change the > music soundtrack from its scripts depending on where you are in the > campaign, for example. However, this script command does not seem to > be used anywhere, and ends up in a dummy function > (lib/sound/openal_track.c:sound_PlayStream(...)). > > I think I would prefer fixing the script function, rather than keeping > the playlist code. What is the opinion of everyone else? Troman, you > are the script guru, any thoughts? The idea is to let the user write a simple script to get his playlist playing? Sounds good IMO. Perhaps we can get an ingame menu later, so it is easier for the users... --Dennis imo it's not a good idea to let a regular user(assuming he has little or no knowledge in scripting),not to mention most of us are 'dummy' when it comes to 'wz scripting'... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
On 1/11/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: The idea is to let the user write a simple script to get his playlist playing? No, I want to put the campaign/mod author in charge of which music is to be played, so that you can match the appropriate music to levels. Eg Campaign 1 should have one list of songs to be played, while campaign 2 has another list of songs, and so on. Perhaps we can get an ingame menu later, so it is easier for the users... I do not like much the idea of making the user in charge of making a playlist. This is a feature that I would guess only 1% of our users would make use of. Much better if we could together come up with the best playlists for the different levels. As for the game's start menu, I think we should just have a song called data/music/menu.ogg for it. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Music playlists
Am Donnerstag, 11. Januar 2007 13:17 schrieb Per Inge Mathisen: > I think it would be a good idea to start adding some of the music that > has been made, just to show that we care. So I had a look at the > playlist code, and was a bit surprised at why it was made the way it > is. Basically, the current playlist code was made after the code > release, and just uses the text file data/music/music.wpl as a list. > > There is also a script command "playBackgroundAudio" which looks like > it is supposed to control music from within scripts, and this seems to > me a vastly superior solution. This way a scenario can change the > music soundtrack from its scripts depending on where you are in the > campaign, for example. However, this script command does not seem to > be used anywhere, and ends up in a dummy function > (lib/sound/openal_track.c:sound_PlayStream(...)). > > I think I would prefer fixing the script function, rather than keeping > the playlist code. What is the opinion of everyone else? Troman, you > are the script guru, any thoughts? The idea is to let the user write a simple script to get his playlist playing? Sounds good IMO. Perhaps we can get an ingame menu later, so it is easier for the users... --Dennis pgpiRNRzHHkxE.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Music playlists
I think it would be a good idea to start adding some of the music that has been made, just to show that we care. So I had a look at the playlist code, and was a bit surprised at why it was made the way it is. Basically, the current playlist code was made after the code release, and just uses the text file data/music/music.wpl as a list. There is also a script command "playBackgroundAudio" which looks like it is supposed to control music from within scripts, and this seems to me a vastly superior solution. This way a scenario can change the music soundtrack from its scripts depending on where you are in the campaign, for example. However, this script command does not seem to be used anywhere, and ends up in a dummy function (lib/sound/openal_track.c:sound_PlayStream(...)). I think I would prefer fixing the script function, rather than keeping the playlist code. What is the opinion of everyone else? Troman, you are the script guru, any thoughts? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
