SVC_SPAWNSTATICSOUND is not implemented

[Hedgefog]

SVC_SPAWNSTATICSOUND is not implemented

[a1batross]

@Hedgefog seems it's broken on current stable release for some reason. Don't really know how custom entities worked back then, but on next branch it seems to work!

[a1batross]

Isn't it a private engine message? I doubt we would change protocol for that.

[a1batross]

Maybe we can change MessageBegin/End behavior to accept GoldSrc protocol messages and rewrite them into our protocol.

But that needs to be switchable somehow. Another flag for -bugcomp maybe? Not sure.

[a1batross]

svc_spawnstaticsound index is 29.

In the current Xash protocol, it's a reserved index. We could also use that, like we did with svc_exec for TFC already.

[Hedgefog]

So is it possible to do this using index 29?

[a1batross]

No, I mean 29 is GoldSrc's index for this message.

We don't use this exact number (see engine/common/protocol.h file), so it can be reused for this specific message.

But if Metamod or AMXX scripts use other GoldSrc specific messages, it will get parsed incorrectly under Xash and force disconnect a client.

[Hedgefog]

I'm not familiar with this stuff, so I don't understand what exactly causes the issue.

Based on protocol.h most of the message indexes are similar to GoldSrc messages:

xash3d-fwgs/engine/common/protocol.h

Line 21 in a08f5e4

// server to client

For me, it looks like index 29 is not used right now and can be used for any message. Am I right?

In the current Xash protocol, it's a reserved index. We could also use that, like we did with svc_exec for TFC already.

Why is it reserved?

[a1batross]

You see, engine messages, unlike custom user messages, do not specify message length. It just the raw bytes.

If the client doesn't know how to process it, it will stop parsing the messages and disconnect, because it also doesn't know how to skip it.

I suggested two solutions here that won't require changing any code from your side:

1. Use unused index 29 that so happened to be the exact same index in GoldSrc protocol. The downside of this is that we lose one unused index that we could've used for something else and if it's going to be added, we will never remove it, unless we make new protocol version.

2. Or there could be some compatibility mode that will rewrite mod's any attempts to write GoldSrc-specific messages into Xash alternatives. This way we do not touch the protocol, but it's going to be an optional setting, and I don't want to make the engine any more complicated than it is already. It as well can be done at Metamod level.

[a1batross]

@Hedgefog can you, as a modder, explain one thing that always bothered me, as an engine developer.

So you do call MessageBegin( ..., SVC_SPAWNSTATICSOUND, ... ) and put raw bytes to the datagram. It's not something Valve ever put to SDK: https://github.com/ValveSoftware/halflife/blob/master/dlls/util.h#L426-L431

So somebody went and wasted their time reverse-engineering that part of the engine, and now you're risking your mod being tied to a specific protocol revision. Not like it's going to change any time soon, but I digress.

What's the problem of using engine function for that instead? svc_spawnstaticsound is being explicitly sent by pfnEmitAmbientSound. Here is the GoldSrc implementation for it: https://github.com/dreamstalker/rehlds/blob/0d1bdbab671752aa579d7b4e10f4cf04d69a49a4/rehlds/engine/pr_cmds.cpp#L260

So instead of:

MESSAGE_BEGIN( ..., SVC_SPAWNSTATICSOUND, );
WRITE_COORD( origin.x );
WRITE_COORD( origin.y );
WRITE_COORD( origin.z );
WRITE_SHORT( soundindex );
WRITE_BYTE( volume );
WRITE_BYTE( attn );
WRITE_SHORT( entidx );
WRITE_BYTE( pitch );
WRITE_BYTE( flags );
MESSAGE_END();

You all could've just used:

g_engfuncs.pfnEmitAmbientSound( entidx, origin, sample, volume, attn, flags, pitch );

And get basically the same thing except engine will do everything for you.

See, it's not the first time I notice when it was much simpler to call the engine function instead of sending protocol-revision-specific data directly.

[a1batross]

Hm... Maybe you want to send it to a specific player?

That's an interesting design choice. :D

But maybe a valid reason to do this instead of calling an engine func.

[Hedgefog]

@a1batross You are right! This was an old implementation and I didn't investigate too much about this when I implemented it. I can go with pfnEmitAmbientSound, it works for me.

EmitAmbientSound is a kinda confusing name and it's nothing about static sound spawn, so It's not surprising that I didn't find another way, because I didn't investigate the game and engine source code too much back then.

You can probably close the issue because there are probably almost no cases in which developers need this message.

Thanks!

[a1batross]

@Hedgefog well, I already implemented rewriting facility at bugcomp2 branch, enabled with -bugcomp or -bugcomp gsmrf command line switch.

I wanted to play your mod, but it doesn't work for me. Doesn't work on GoldSource under Linux either, crashes somewhere in glibc. =/

[a1batross]

How did you set it up on Xash?

I've installed metamod-p, AMXModX 1.9.0, ReGameDLL_CS and ReAPI version of CS Halloween mod.

Loaded game with hwnc_city_night map, nothing really happens except single ghost flying to me and does nothing. Spawning bots don't make a difference. Pressing f does nothing. Force giving myself a fireball spell through commands works, but ghost doesn't die from it nor attacks me.

[a1batross]

None of the custom entities seem to be spawned.

[Hedgefog]

None of the custom entities seem to be spawned.

Hmm, there are probably still issues with KVD implementation in Xash and the current release version uses an old version of custom entities. I'm currently working on a new Halloween Mod version with new APIs and for new version it is fixed.

As a solution, you can try to compile the next branch version manually or play on my Xash test server: 185.91.118.247:27025

[a1batross]

Fixed in dd410a2

To support this kind of message, -bugcomp (or -bugcomp gsmrf) must be passed to server.