A rework on EmitSound function

[samyycX]

With #808 we implemented EmitSound function to counterstrikesharp, which rely on a game function EmitSoundFilter.

But from my research, this function is no longer maintained and volume and pitch parameter is not working. (volume needs another plugin to fix, and pitch is currently not working and likely can't get a fix with the same method as volume).

With more research, we can know that the soundevent and its param is completely based on netmessage, which are completely able to controlled in managed side (ideally), and we are able to set more soundevent param theoretically (position, pitch, etc)

I'm posting this discussion because we have various ways to implement this rework:

1. Do nothing (needs a plugin to fix volume and the pitch is not working, but we still can send sound on per player basis)
2. Implement it on c++ side, with SetSoundEventParam function (fix volume and pitch, but need another signature, and its hard to support more soundevent param)
3. Implement it on managed side, with NetMessage method (fix volume and pitch, support more params, but need PbSetBytes method to write bytes to netmessage, which we can't do right now)

anyways this rework won’t affect current API usage so no need to worry about compatibility

[roflmuffin]

Can I offer another alternative, which is implement it on C++ side, but still using Net Messages? That way the Native API method for it is fairly straightforward, and the C# side can be more naive

[samyycX]

the net message approach is basically byte sequence serialization/deserialization, c# is sufficient and easier to code. But it’s still possible to implement on c++ side, but it will be more expensive because of more pinvoke calls and more complex to code.

[roflmuffin]

I agree that it's easier to implement a lot of things on the C# side, but I think as a general philosophy we should try to do more things on the core side to make API compat a little bit cleaner (and move towards a script agnostic future). There are exemptions of course for things that are in the critical hot code path. An example of such an outlier is the entity system which is implemented in C# side due to frequent access.

[samyycX]

Actually, although the title says it is a rework of the EmitSound function, the implementation is not to call the function of the game itself, but a complete reimplementation of the soundevent processing part of the game's SoundSystem. So instead of calling it a low-level core feature, I think it is a high-level helper to help users parse or generate UserMessage (CMsgSosStartSoundEvent or others) related to soundevent.

[samyycX]

For example, the API may look like this:

// creating a new one
var soundevent = new SoundEvent("WeaponAK47.Single");
soundevent.SourceEntityIndex = 1;
soundevent.SetParam("public.volume", 1f);
soundevent.SetParam("public.position", new Vector(0f, 0f, 0f));
soundevent.EmitToAll();

// or in a builder format
// new SoundEventBuilder().name(xxx).param("public.volume, 1f").Build().EmitToAll()

We also have to consider the memory issue if its on native side.
But some feature still need to rely on native side, like reading soundevent name from hash, or getting a guid.