Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: CountBuggula on April 18, 2014, 01:02:10 pm
-
To my knowledge, there is no in-game voice chat. I think this could be a huge improvement for multiplayer, as it could selectively be set up for server-wide or team-restricted chat. Pretty much all modern games have similar functionality and players today expect it.
I asked Chief about this and he seemed to think there was voice support in the original game but it might have been a proprietary codec or something. I searched this forum and could only find a couple of mentions voice chat or voip so I don't think it's ever really been discussed.
My suggestion is to integrate mumble (http://mumble.sourceforge.net/) as a seamless backend (on the server) and client (within the game). It's stable, well tested, and has a variety of codecs and low-bitrate options available. For the number of players that SCP supports in multiplayer, I don't think it would cause any perceptible performance hit. There's extensive documentation on their wiki for linking a game to Mumble (http://mumble.sourceforge.net/Link).
There may be other alternatives to mumble that might fit the SCP better, I'm just throwing out an idea - I think it's worth discussing.
-
I don't want to sound aggressive here, but what's wrong with mumble, or TeamSpeak in a separate process?
Asked differently, what features would an integrated VON (Voice Over Network) system have over a separate VON system?
-
I run a mumble server on 184.22.118.104 on port 64738 if you require VON for freespace. :)
-
i wouldn't mind seeing the game's voip system restored to functionality. all the interface crap is still there, might as well make it do something.
-
I think players are far more likely to use voice communication if they don't have to tab out of the game, make sure they have the right client installed, connect to the server, and then return to the game. More so that they're likely to have to repeat the process every time they switch teams or servers. In-game would make sure every player has the opportunity to participate with voice, set up for the correct server and team, every time. I think it'd be worthwhile.
-
Honestly? I never use the built-in VOIP solutions in games. It's always skype, or mumble, or teamspeak.
Put another way, I would rather work on improving and stabilizing the current netcode before we start to add features to it.
-
Yeah, I think this is quite laudable in theory, but first we need to have multiplayer that's worth playing by modern standards. And obstacle 0 is the netcode.
-
And it's a big, big obstacle.
The simple fact is that AFAIK no one on the team understands the netcode particularly well. I'm probably the person who has done the most with it and I'm mostly shooting in the dark with it as the code is quite big, complicated and not particularly well documented. While I can code on top of what already exists (as I did when I fixed SEXPs for multiplayer by adding a new API), getting into the nuts and bolts of psnet2 is a complete and utter pain in the arse as the code is very difficult to read and even harder to understand. Especially for someone like me who always programs anything that works online via much higher level APIs.
Which basically highlights the problem with multiplayer. When it comes to the SCP the coders are either
1) Interested in multiplayer coding but like myself lacking the knowledge needed to actually get the job done.
2) Not interested in multiplayer coding, or lacking the time to work on such a major project.
When solutions for the problem are discussed, we're usually hunting for the Golden BB that will solve all our problems. For instance the last discussion we had was surrounding the use of an external multiplayer library we could use to improve the game. enet was the one most people agreed upon and I'll state that for the record, I've tried playing around with adding enet to FS2 and as far as I can tell, there's no reason it can't be done. The problem is that I could spend the next week or two replacing all the psnet2 functions with enet equivalents and find it's made absolutely no difference because the problem isn't at the level of psnet but instead in the object update code or some other part of the multiplayer code. Funnily enough it's hard to find the motivation to do that when both enet and psnet2 are so poorly documented.
A while back I had the suggestion of making everything use the standalone (http://www.hard-light.net/forums/index.php?topic=85766.msg1714679#msg1714679) so that we could simplify the code. A great idea which fell at the first hurdle, getting the game to spawn a process is something I have no experience of, and trying to figure out which was the best way to do it only left me confused. Especially as the standard MFC method didn't seem to work no matter which way I tried it. It's pretty annoying since I probably could do everything else once that task was sorted.
What we've been hoping for is for someone with both the time and experience to write better netcode. Someone like Taylor or Valathil but with an emphasis on netcode. But we've been at this for over 10 years and we've not had them appear yet, so maybe we need a better plan. I'm more than happy to collaborate with other coders who know the areas I don't have experience with, but I don't know who else is actually interested in fixing the netcode given that it would be a very big task.
-
A while back I had the suggestion of making everything use the standalone (http://www.hard-light.net/forums/index.php?topic=85766.msg1714679#msg1714679) so that we could simplify the code. A great idea which fell at the first hurdle, getting the game to spawn a process is something I have no experience of, and trying to figure out which was the best way to do it only left me confused. Especially as the standard MFC method didn't seem to work no matter which way I tried it. It's pretty annoying since I probably could do everything else once that task was sorted.
There are multiple cross-platform libraries for process management available (e.g. Boost.Process (http://www.highscore.de/boost/process/) or libexecstream (http://libexecstream.sourceforge.net/)).
For faster communication in single player mode I would recommend implementing an abstraction layer for the communication so both regular network for multiplayer and inter-process communication for single player can be used. That way the single-player experience would not suffer from network delays (even if the connection is only between two processes on the same machine it will still result in a performance penalty).
-
You're not helping. :p
-
Wow, I didn't expect this to generate this kind of feedback! I suppose I was unaware that the multiplayer code was in that bad of shape. I wish I knew anyone who had the right kind of experience to pull into this project to help. That said, VON support (if using mumble) would be almost entirely separate from the rest of the multiplayer netcode, and could be implemented by someone who couldn't replace or fix the netcode (if it's a matter of experience or understanding).
And while I understand that there are some who never use in-game voice support, there are many games that I use it for all the time (mostly valve FPS games come to mind, such as DoD and TF2) and especially when used as team-based communication, adds a huge boon to gameplay and tactics. The advantage of building the client into the game engine is that even if someone doesn't have a mic or opts to not use voice, they can still hear those who do, and follow commands or input from their teammates.
-
Wow, I didn't expect this to generate this kind of feedback! I suppose I was unaware that the multiplayer code was in that bad of shape. I wish I knew anyone who had the right kind of experience to pull into this project to help. That said, VON support (if using mumble) would be almost entirely separate from the rest of the multiplayer netcode, and could be implemented by someone who couldn't replace or fix the netcode (if it's a matter of experience or understanding).
And while I understand that there are some who never use in-game voice support, there are many games that I use it for all the time (mostly valve FPS games come to mind, such as DoD and TF2) and especially when used as team-based communication, adds a huge boon to gameplay and tactics. The advantage of building the client into the game engine is that even if someone doesn't have a mic or opts to not use voice, they can still hear those who do, and follow commands or input from their teammates.
They can get the same bonuses using any non-integrated voice service. I use TS all the time for Planetside, League, and GMod games. It is not the entire process you described between every game. The clients will tell you if they are outdated and update themselves automatically. Joining a team is as simple as drag and dropping yourself to the channel. You do not need a microphone to join these servers either.
You're asking the programmers to enable something on already messed up netcode that doesn't solve the problem AND would be relient on them hosting a proper mumble server themselves. One that they need access to in order to make it compatable with FSO. It would take you 5 whole seconds between games to do it manually for missions that last about 20-30 minutes. You could easily do that while the mission itself is loading.
Considering the state of FSO multiplayer in terms of community, it is not hard to ask if they would like to join a VOIP service with you. There are barely enough players to bother with a VOIP service at all. I personaly would not put this high on any priority list.
My 2 cents.
-
...AND would be relient on them hosting a proper mumble server themselves. One that they need access to in order to make it compatable with FSO.
Ideally, the mumble server code would be merged into our standalone server code so there isn't a second service a host needs to run. Given the extensive documentation on their site, it looked to me like a relatively easy thing to do for someone familiar with the FSO source. With the server built into the host, and the client built into the game, there would be no additional setup required, allowing it to just work, every time, for everyone. I don't mean to start an argument, I just thought it'd be a valuable feature that would make it more likely that new players use voice communication and hopefully have a better multiplayer experience.
I understand that there aren't a lot of active multiplayer players currently. I'm just trying to find ways to improve the experience so more people might be tempted to try. And if at some point we DO get the rest of the netcode fixed up and working better, the experience as a whole might be good enough that they stick around.
-
...AND would be relient on them hosting a proper mumble server themselves. One that they need access to in order to make it compatable with FSO.
Ideally, the mumble server code would be merged into our standalone server code so there isn't a second service a host needs to run. Given the extensive documentation on their site, it looked to me like a relatively easy thing to do for someone familiar with the FSO source. With the server built into the host, and the client built into the game, there would be no additional setup required, allowing it to just work, every time, for everyone. I don't mean to start an argument, I just thought it'd be a valuable feature that would make it more likely that new players use voice communication and hopefully have a better multiplayer experience.
I understand that there aren't a lot of active multiplayer players currently. I'm just trying to find ways to improve the experience so more people might be tempted to try. And if at some point we DO get the rest of the netcode fixed up and working better, the experience as a whole might be good enough that they stick around.
And for people that would like to be in one large group even if they are on opposing teams?
Teamspeak and Mumble will work every time for everyone. They are not finicky programs, and that is not a valid excuse in my opinion. Using the main programs themselves also gives you far far more functionality. However, forcing everyone who plays to use this feature, even if they do not want to, is bad.
As a result, not only do you need to piggyback Mumble on to the existing crippled netcode, but you also have to build an interface both for the clients, and for the server. Options to be changed, etc. Not to mention, how do you silence just one person if you want to? That functionality is not in FSO Multiplayer. Where in-game do you control the bitrate for the VOIP, or the volume level per person? We don't even have a menu for that.
Literally everything else must be fixed for multiplayer, and the feature you wish to have is 100% achievable by a 3rd party program. This would not be a simple addition. Even if it was a simple addition, you have no where to hang it since the wall it goes on is a heap on the floor.
-
Chief1983 reminded me that the framework for the old retail voice implementation is all still in the code, and likely only needs a codec alternative (http://opus-codec.org/) to the proprietary one that was originally used. Since this was functionality that existed in the retail FS2 offering but has been missing in the SCP, I think it's a worthwhile feature.
-
Kyad, no one's saying that TeamSpeak or whatever shouldn't be used, but you seem to be missing that in a pub game, in-game voice chat is pretty much the only way to have voice communication with your teammates. Maybe in a community where everyone is chums, or when playing extended matches always on the same server like in IL-2, a TS server works fine, but what about something like Counter-Strike? Having an in-game option that just works would be far preferred to constantly jumping around in rooms on an external client every time I join a new game. It doesn't have to exist instead of TS, but having it could enable voice chat in situations where it previously wouldn't have been feasible.
-
Kyad, no one's saying that TeamSpeak or whatever shouldn't be used, but you seem to be missing that in a pub game, in-game voice chat is pretty much the only way to have voice communication with your teammates. Maybe in a community where everyone is chums, or when playing extended matches always on the same server like in IL-2, a TS server works fine, but what about something like Counter-Strike? Having an in-game option that just works would be far preferred to constantly jumping around in rooms on an external client every time I join a new game. It doesn't have to exist instead of TS, but having it could enable voice chat in situations where it previously wouldn't have been feasible.
Chief, FSO Multi -is- that community. I could count the number of players on my hands. Everything I am saying is in the context of FSO and only FSO.
And it still does not address any of my concerns including per-player volume level, per-player muting/ignoring, bitrate setting, or anythng else.
-
I'm not averse to adding this feature, but I do agree that it is rather low priority as there are other ways to achieve the same ends. Adding mumble (or anything else) would probably not affect the netcode in any way though as I suspect it wouldn't require access to the FSO netcode and would merely use its own.