Fix sounds playing for objects not sent to the client

[Emojigit]

This PR fixes sounds playing for objects not sent to the client. Does not fix, but make sense anyways.

To do

This PR is Ready for Review.

How to test

1. Try to reproduce the bug¹ without this patch. Sounds from nonexistent objects should be played at full volume.
2. Apply this patch and try again. This should not happen again.
3. Confirm that normal object sounds aren't affected by this patch.

Footnotes

1. I don't know how to reproduce this bug reliably. However, if you're a regular player of LinuxForks, 1F616EMO Survival Server, or any servers with extensive Advtrains network, you should have encountered this at least once. ↩

[Emojigit]

Well, not fixed ye...

[sfan5]

Even if it doesn't fix the issue you're having the code changes make sense to me. How about merging it in this state?

[Emojigit]

Okay :-D

[Desour]

There's max_hear_distance, so in normal cases, these sounds only play if the object is near enough, so obj was also sent to the client. If the obj observers feature is used, this is of course not true (the doc also says that attached sounds don't work in this case).
The issue is usually probably rather that the object gets unloaded (e.g. because it gets removed, or it moves away, or the player moves away).

Tested.
/lua local obj = assert(core.add_entity(here:offset(0,0,10), "soundstuff:racecar")) local snd = core.sound_play("soundstuff_mono", {loop = true, object = obj, gain = 10, max_hear_distance = 10000}) core.after(3, function() obj:remove() core.sound_stop(snd) end)

The above code doesn't play a sound with PR, but it should. => PR introduced a bug. 👎
My guess is that the object gets sent to the client after the sound is sent. So I have doubts that the check introduced by this PR can work at all.

[sfan5]

As it turns out the server sends a position even with SoundLocation::Object, so the fallback code path is actually valid.

.