Looping sound that stays with player
Looping sound that stays with player
I am trying to set up some triggers that play an ambient wav warning the player that some sort of danger is imminent. (I'm actually using this to limit player freedom to just go anywhere they want and if they ignore this ... kill them. Sure I could just centerprint a warning only but I'd rather freak out the player).
1. Now I am rather certain there is no way in standard Quake to have this play only for the player (and not other players). Not a problem. However, anyone know what extension (if any) can do a player only sound (no CSQC)?
2. Is there a way that the origin of the looping sound can move with the player in standard Quake? If not, what extension would allow such a thing?
I'd dig in QuakeC except ... well ... I'm not sure what mod has such a feature (if any).
1. Now I am rather certain there is no way in standard Quake to have this play only for the player (and not other players). Not a problem. However, anyone know what extension (if any) can do a player only sound (no CSQC)?
2. Is there a way that the origin of the looping sound can move with the player in standard Quake? If not, what extension would allow such a thing?
I'd dig in QuakeC except ... well ... I'm not sure what mod has such a feature (if any).
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Looping sound that stays with player
stuffcmd("play foo/warning.wav\n");
many engines either have a play2 command, or directly modified the play command such that the sound follows the player (audio code already accepts some specific entity value to mean 'follow player').
many engines either have a play2 command, or directly modified the play command such that the sound follows the player (audio code already accepts some specific entity value to mean 'follow player').
Re: Looping sound that stays with player
Not on topic, but QuakeC would royally suck without fteqcc
I've been looking at Nexuiz source codes and I see div0 wrote most of his QuakeC sensibly Stock QuakeC without fteqcc is quite the bit of a mess.
I've been looking at Nexuiz source codes and I see div0 wrote most of his QuakeC sensibly Stock QuakeC without fteqcc is quite the bit of a mess.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Looping sound that stays with player
still offtopic, but qc even with fteqcc is a bit of a mess, when it comes to complex stuff.
noone is brave enough to use classes and pointers and other stuff that would really help out quite a lot of things, mostly on account of those things being the most likely to blow up.
Still, I would like to see people use classes more (which are meant to work without engine extensions). It would greatly help readability in mods like TF that munge all fields together and then forget what each field was used for, in theory at least.
Xonotic's code on the other hand uses some seriously evil features that I had never intended, like #defines within #defines. Utterly evil, but also quite useful (and I often wished #pragma worked in #defines in C as well), and also an unintentional feature. Still, a feature is a feature and people tend to use features.
Arrays are handy, but you have to remember that they are emulated with V6 progs, and so somewhat inefficient.
Heads up for you: from here on in, I'm just gonna start using malloc in qc, when I can get away with targetting just fte.
on topic:
*no text*
noone is brave enough to use classes and pointers and other stuff that would really help out quite a lot of things, mostly on account of those things being the most likely to blow up.
Still, I would like to see people use classes more (which are meant to work without engine extensions). It would greatly help readability in mods like TF that munge all fields together and then forget what each field was used for, in theory at least.
Xonotic's code on the other hand uses some seriously evil features that I had never intended, like #defines within #defines. Utterly evil, but also quite useful (and I often wished #pragma worked in #defines in C as well), and also an unintentional feature. Still, a feature is a feature and people tend to use features.
Arrays are handy, but you have to remember that they are emulated with V6 progs, and so somewhat inefficient.
Heads up for you: from here on in, I'm just gonna start using malloc in qc, when I can get away with targetting just fte.
on topic:
*no text*
Re: Looping sound that stays with player
Hello Baker,
I know that you asked for a standard Quake possibility. I cannot gve you one.
But then you also asked: "If not, what extension would allow such a thing ?"
At least I want to throw this extension into this thread, that I personally use for sounds with fixed coordinates:
DP_SV_POINTSOUND
It is similar to the standard Quake sound function, but it uses an origin instead of an entity.
Which is, I guess, exactly what you wanted.
Again, this is only an engine specific extension, but you (as an engine dev yourself) can easily implement it into your engine.
Then again, maybe this extension is not capable to do this, but maybe worth a try.
void(vector origin, string sample, float volume, float attenuation) pointsound = #483;
vector origin = player origin
Please dont punish me for mentioning a dpextension...
Kind regards,
Seven
I know that you asked for a standard Quake possibility. I cannot gve you one.
But then you also asked: "If not, what extension would allow such a thing ?"
At least I want to throw this extension into this thread, that I personally use for sounds with fixed coordinates:
DP_SV_POINTSOUND
It is similar to the standard Quake sound function, but it uses an origin instead of an entity.
Which is, I guess, exactly what you wanted.
Again, this is only an engine specific extension, but you (as an engine dev yourself) can easily implement it into your engine.
Then again, maybe this extension is not capable to do this, but maybe worth a try.
void(vector origin, string sample, float volume, float attenuation) pointsound = #483;
vector origin = player origin
Please dont punish me for mentioning a dpextension...
Kind regards,
Seven
Re: Looping sound that stays with player
I'm just trying to figure out whose homework I should be thinking about copying if I have to go there. And trying to figure out if I have to go there.Seven wrote:At least I want to throw this extension into this thread, that I personally use for sounds with fixed coordinates:
DP_SV_POINTSOUND
It is similar to the standard Quake sound function, but it uses an origin instead of an entity.
Which is, I guess, exactly what you wanted.
I noticed in Nexuiz div0 essentially wrote a monster file from scratch and handled the animations in a very sensible way that isn't possible except using fteqcc as a compiler.Spike wrote:Xonotic's code on the other hand uses some seriously evil features that I had never intended, like #defines within #defines
I think the monster code in QuakeC --- especially the animations --- is written rather unintelligibly and is quite a headache to even think about. But at the same time, the original qcc had quite a few limitations and far fewer convenience features than fteqcc.
But I guess my real point is that div0 essentially did a scratch qc type of tutorial within Nexuiz but for some reason very few people look at Nexuiz or Xonotic for ideas on how to improve upon how QuakeC is written. Which is funny because I think div0 probably has written more QuakeC than anyone else.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Looping sound that stays with player
Some engines have a built-in called localsound that calls PF_localsound or similar. Only a specific player hears it, and it's non-locational. (it's all in your head...) "PF_privatesound" might be more accurate.
Re: Looping sound that stays with player
its also unusable.
single player because its no different from calling sound - only one player hears anyway.
multiplayer because you really get no control over *who* hears it - only the person playing on the server hears it, which is useless if its a dedicated server.
note that fte's dimension stuff includes dimension_send which allows filtering sound calls. However, as an extension that encompasses so much more than just that, its a little clumsy to use for specific players, and non-trivial to implement into an engine (fte multicasts everything), but it does exist and can be used to send sounds to specific players.
single player because its no different from calling sound - only one player hears anyway.
multiplayer because you really get no control over *who* hears it - only the person playing on the server hears it, which is useless if its a dedicated server.
note that fte's dimension stuff includes dimension_send which allows filtering sound calls. However, as an extension that encompasses so much more than just that, its a little clumsy to use for specific players, and non-trivial to implement into an engine (fte multicasts everything), but it does exist and can be used to send sounds to specific players.
Re: Looping sound that stays with player
play the sound from the viewentity?
Re: Looping sound that stays with player
I'm playing radio transmissions on the player in RMQ, via trigger.
The trigger code simply uses sound(). The engine does the moving sound stuff (no csqc). Sound in rmqe was buggy though recently.
The trigger code simply uses sound(). The engine does the moving sound stuff (no csqc). Sound in rmqe was buggy though recently.
Re: Looping sound that stays with player
Hmmm, looking at fteqw source, PF_localsound is different in qbism Super8. (been planning to change the name of that function anyway...) In super8 it actually directs to a specific client. It can be used like the announcer on q3. "Red took your flag." (for/next loop, send to each person on team) "Warning, your shoes are untied". (send to individual)Spike wrote:its also unusable.
single player because its no different from calling sound - only one player hears anyway.
multiplayer because you really get no control over *who* hears it - only the person playing on the server hears it, which is useless if its a dedicated server.
Code: Select all
void PF_localsound (void)
{
char *sample;
char volume;
client_t *client;
int entnum;
entnum = G_EDICTNUM(OFS_PARM0);
if (entnum < 1 || entnum > svs.maxclients)
{
Con_Printf ("tried to send local sound to a non-client\n");
return;
}
client = &svs.clients[entnum-1];
sample = G_STRING(OFS_PARM1);
volume = (char)(G_FLOAT(OFS_PARM2) * 255);
SV_LocalSound (client, sample, volume);
}
Re: Looping sound that stays with player
fte's pf_localsound was added for compatibility with telejano. I don't recommend using it.
qbism, which builtin number are you using? I assume it uses channel=0, attenuation=0 over the wire...
I guess you can do it with unmodified QW servers but its really hacky!
create a room in some far away corner of the map.
when you want a sound, setorigin the player into that room, play the sound (quakeworld plays sounds using multicast so it won't be sent to anyone not in that obscure room), then teleport the player back where they were.
You'll near to center the sound on the player though, which can cause problems with sounds overriding each other. An attenuation of 0.001 is also a possibility, but it will still be spacialised (ie: stronger in one ear, depending on which way you're facing).
From an engine perspective, all you really have to do is to build the svc_startsound message into a unicast message instead of broadcast, and make sure SND_Spatialize sets the leftvol and rightvol to the same value for the sound.
qbism, which builtin number are you using? I assume it uses channel=0, attenuation=0 over the wire...
I guess you can do it with unmodified QW servers but its really hacky!
create a room in some far away corner of the map.
when you want a sound, setorigin the player into that room, play the sound (quakeworld plays sounds using multicast so it won't be sent to anyone not in that obscure room), then teleport the player back where they were.
You'll near to center the sound on the player though, which can cause problems with sounds overriding each other. An attenuation of 0.001 is also a possibility, but it will still be spacialised (ie: stronger in one ear, depending on which way you're facing).
From an engine perspective, all you really have to do is to build the svc_startsound message into a unicast message instead of broadcast, and make sure SND_Spatialize sets the leftvol and rightvol to the same value for the sound.
Re: Looping sound that stays with player
I'm using #33, which in some engines is 'PF_Fixme'. I wrote that pf_localsound independently in 2002 which is slightly different, but I was looking at telejano code at the time. I don't really remember why svc_localsound had to be different that svc_sound in the first place but somehow it did for a mod at the time.
Re: Looping sound that stays with player
#33...
flymove in qtest (unused)...
tracebox in hexen2...
the (handicapped) telejano one is apparently #177
flymove in qtest (unused)...
tracebox in hexen2...
the (handicapped) telejano one is apparently #177
Re: Looping sound that stays with player
So stuffcmd("play foo/warning.wav\n"); is the only current way to do this within qc? No extension for qc to tell the engine that the sound should come straight from a single player's speakers w/o spatialization?Baker wrote:have this play only for the player (and not other players).
Other methods are OK for single player. But in multiplayer I imagine that when a second player is nearby, they'd overhear the announcement being delivered and think the other player was saying it.