|
Notes |
|
|
|
|
|
|
(0010461)
|
|
Blzut3
|
|
2014-10-11 01:19
|
|
I don't believe we make any guarantee that the sound indexes are the same (would require SNDINFO to be protected, which in turn would make skins problematic). That said, I think that only raises a concern if anything extra is loaded before the mods loaded by the server. Or if for some reason someone modified their zandronum.pk3.
Could have some implications for 0001473 as optional wads would need to be loaded by the server following those required.
Requiring proper load order could be a good thing as it could potentially also imply that the FName table is safe as well. |
|
|
|
|
One solution to this if it fails I'm guessing would be to make a custom array for required sounds and send from that.
I'm going to investigate how skins handle sound overriding. |
|
|
|
|
|
Yeah, I'm rather sure that with the current possibilities of the skins directory you cannot assume that the sound indices are equal on the server and the clients. The files from the skins dir are loaded before the files specified with "-file". |
|
|
|
|
|
I wonder if you can do a reverse indexing: last has index 1, first without skins dir has last index. |
|
|
|
|
|
This wouldn't help: While skins are loaded before "-file" stuff, they are loaded after zandronum.pk3 and the IWAD. |
|
|
|
|
I'm going to have to create an indexed list that doesn't take into account the skins folder.
My plan is to not write any SNDINFO definitions from files that aren't required (this way it can be expanded to ignore optional wads too when added).
|
|
|
|
(0010743)
|
|
Watermelon
|
2014-10-30 22:58
(edited on: 2014-10-31 03:21) |
|
My idea right now is as follows (using Dusk's idea):
1) Index all the sounds in a TArray based on their index
2) Send the index and sound over to the client
3) Mark in a boolean list which have been sent (or some kind of hashmap)
4) Only send the sound ID when it has been sent once
5) Clear on client disconnecting
This way we get around the optional wad and sound order problem.
|
|
|
|
|
|
|
|
(0010756)
|
|
Blzut3
|
|
2014-11-01 05:03
|
|
|
Wouldn't it be possible to do the sound name lookup before storing into g_sndinfoLookupTable? That way it just translates a server index to a client index. |
|
|
|
|
|
First, there is lots of copy and paste in here, which is always bad :P. Second, trying to manually maintain a list of used sounds for each client is quite cumbersome. Can't you just send the full table when a client connects? Or is the table too big for this? |
|
|
|
(0010762)
|
|
Dusk
|
|
2014-11-01 11:59
|
|
Quote
Can't you just send the full table when a client connects?
I'm a bit worried this might be a rather large bandwidth sink. |
|
|
|
|
|
Did you check how big the table is? You may be overestimating its size. |
|
|
|
|
Quote
First, there is lots of copy and paste in here, which is always bad :P.
Are we okay with macros? That'd cut down the annoying code duplication. |
|
|
|
|
I'd say macros are a last ditch effort to reduce code duplications, where functions and classes simply can't do it. But I don't see why you can't put
// [CK] Now read the short and bitmask.
sSoundID = NETWORK_ReadShort( pByteStream );
// [CK] If the server is sending us a new sound, read the string, otherwise
// we will get it from our indexed sound map.
if ( sSoundID & SOUNDID_CONTAINS_STRING_MASK )
{
pszSound = NETWORK_ReadString( pByteStream );
CLIENT_AddToSndinfoTable( sSoundID & SOUNDID_NETWORK_ID_MASK , pszSound );
}
else
{
pszSound = CLIENT_GetSoundStringFromSndinfoTable( sSoundID );
}
into a function that gets pByteStream and returns pszSound.
But the code fragment above is not necessary anyway, if the whole table is transferred on connect. So, before just reducing the code duplication, how big is the table? |
|
|
|
|
|
So far on IRC we estimated it to be around 20 kb at worst, on average most mods are 10-12 kb. |
|
|
|
|
On further thought, I'm going to try out the "send the full table" idea since in addition to what you said, it will integrate *way* easier with Zan 2.0's netcommandification (and then I don't have to do these annoying copy paste things)
|
|
|
|
|
Quote from Watermelon
So far on IRC we estimated it to be around 20 kb at worst, on average most mods are 10-12 kb.
That amount shouldn't be any problem if it's only sent when initially connecting to the server. |
|
|
|
|
Is is there a hardcoded limit for the number of sounds per zdoom game? It's in order to get the number of bytes to assign to the index.
|
|
|
|
|
So far the idea is to allow 32767 sounds, which no wad should exceed hopefully ever.
If they ever did, then we can always tweak it to make 0x7FFF represent a raw string. |
|
|
|
|
|
Pull request with a table sent on connection done. |
|
|
|
|
|
I left some comments in the pull request. |
|
|
|
|
|
Submitted updated pull request. |
|
|
|
(0010936)
|
|
Torr Samaho
|
2014-11-23 11:07
(edited on: 2014-11-23 11:10) |
|
You may have overlooked my question in the pull request:
Quote from Torr Samaho
You didn't post the pull request for the NetCommand rewrite of the SERVERCOMMANDS_* functions in question, did you?
|
|
|
|
|
|
|
|
|
No, you misunderstood me. I'm not talking about upgrading all SERVERCOMMANDS_* functions in 1.4. Let me dig out my old comment from the pull request that is hidden by now:
Quote from Torr Samaho
The easiest thing would be if you first send a pull request for the stable repository that just upgrades the SERVERCOMMANDS_* functions necessary for the sound table changes to their 2.0 versions. Then I can pull the changes and merge them into the main repository. Finally, you can send a new pull request with the actual sound info changes.
|
|
|
|
(0010963)
|
|
Watermelon
|
2014-11-24 21:40
(edited on: 2014-11-24 21:42) |
|
I'm sorry if this isn't making sense. Can I get some further clarification? Based on what I read, if I interpreted this right:
Quote
The easiest thing would be if you first send a pull request for the stable repository that just upgrades the SERVERCOMMANDS_* functions necessary for the sound table changes to their 2.0 versions
If I read this right, send a pull request from the sandbox-zandronum-stable repository to the 2.0 repository that has the new SERVERCOMMANDS update. Then somehow select from that pull only the lines that we want that will be applied.
Then you pull the changes into zandronum-stable from the sandbox repo from a pull request I make based off of this. After that I then send just the sound info pull request based on the SERVERCOMMANDS update.
I think I'm getting confused by your first line.
If I get this wrong, could you restate it (maybe something like: sandbox pulls from 2.0 branch <something>, then you do <something>, then sandbox makes a pull request for stable.
|
|
|
|
|
|
Sorry, for the unclear wording. Let me elaborate. First you need to manually copy the NetCommand based implementation of the SERVERCOMMANDS_* functions necessary for the sound table changes from 2.0 to your stable head (replacing their old versions in the stable head) and commit this. Then send a pull request for this changeset only to the stable repo. I'll then pull this changeset to stable and merge it with 2.0 (which should actually mean no changes and no conflicts during the merge, because the changes originate from 2.0). Then you can make a pull request for the traffic optimization based on the stable version that already has the necessary upgraded SERVERCOMMANDS_* functions. |
|
|
|
|
|
|
|
(0011091)
|
|
cobalt
|
|
2014-12-26 09:56
|
|
|
|
|
|
|
Apparently, the current approach of sending the table is infeasible, see 0002045. Either we need to fix this or completely remove it. |
|
|
|
|
|
To not stall the release of 2.0, we decided to remove this for the time being. A proper way to fix this, is to introduce output packet buffers that allow us to control how many packets per time are send to an individual client. This will also solve other problems. Once we have those, we can re-introduce the sound table optimization. |
|