Xaser: the mechanics to filter it to specific players already exist - this is how the speed trails in gzdoom.pk3 work. Basically, you check against consoleplayer.
Code: Select all
class LADPrecipitation : Actor
{
// snip
override void Tick()
{
Super.Tick();
// snip
if (!tracer)
{
return;
}
// destroy precipitation from other players
if (tracer && tracer != players[consoleplayer].mo)
{
// Hexen speed trails are doing this
//bINVISIBLE = true;
// but instead, I do this
Destroy();
}
}
}
I talked about this issue briefly in the ZScript thread when ZScript was still very new (I can't find the post) but my solution involves destroying the precipitation immediately if the check fails. As Graf said, this is a recipe for sync disaster, which is why I was very,
VERY careful in how my precipitation stuff is setup.
They have absolutely no chance to interact with anything else in the game, so the way I've set it up, it doesn't ruin multiplayer.
And yes I've tested this in actual MP games, it works. :)
Obviously if GZDoom supports true C/S then I'd do it differently, but given the currently available mechanics in the engine, this is all that I have to work with for now.
NOW! That said... you'd probably be disappointed in how it actually looks in-game. You always get the feel that the precipitation is following you. Like it's only raining on you.
Things I have also tried and the results were "meh"
1) Hard-offsetting the precipitations' position relative to the camera. This has the "Oblivion" effect where the rain/snow is stuck hard on to the screen. It looks ridiculous
2) Soft offset via checking the player camera's current velocity and spawning the precipitation at an offset. Well it sort of works but sometimes when the player moves too fast, you will notice the precipitation density be sparse until you stop moving
I have settled with (2). Precipitation effets have come a long way in my weather system Bumi since a few years back but there's still plenty of room for improvement.
Xaser: the mechanics to filter it to specific players already exist - this is how the speed trails in gzdoom.pk3 work. Basically, you check against consoleplayer.
[code=php]
class LADPrecipitation : Actor
{
// snip
override void Tick()
{
Super.Tick();
// snip
if (!tracer)
{
return;
}
// destroy precipitation from other players
if (tracer && tracer != players[consoleplayer].mo)
{
// Hexen speed trails are doing this
//bINVISIBLE = true;
// but instead, I do this
Destroy();
}
}
}
[/code]
I talked about this issue briefly in the ZScript thread when ZScript was still very new (I can't find the post) but my solution involves destroying the precipitation immediately if the check fails. As Graf said, this is a recipe for sync disaster, which is why I was very, [size=200]VERY[/size] careful in how my precipitation stuff is setup.
They have absolutely no chance to interact with anything else in the game, so the way I've set it up, it doesn't ruin multiplayer.
And yes I've tested this in actual MP games, it works. :)
Obviously if GZDoom supports true C/S then I'd do it differently, but given the currently available mechanics in the engine, this is all that I have to work with for now.
NOW! That said... you'd probably be disappointed in how it actually looks in-game. You always get the feel that the precipitation is following you. Like it's only raining on you.
Things I have also tried and the results were "meh"
1) Hard-offsetting the precipitations' position relative to the camera. This has the "Oblivion" effect where the rain/snow is stuck hard on to the screen. It looks ridiculous
2) Soft offset via checking the player camera's current velocity and spawning the precipitation at an offset. Well it sort of works but sometimes when the player moves too fast, you will notice the precipitation density be sparse until you stop moving
I have settled with (2). Precipitation effets have come a long way in my weather system Bumi since a few years back but there's still plenty of room for improvement.