Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: karajorma on October 06, 2013, 11:05:23 pm
-
Okay, this isn't quite as drastic as it sounds but I had a weird idea.
What if we changed the code that so that whenever the player decides to host a multiplayer game, instead of simply hosting on the machine as it currently does, the game instead started up a new standalone instance instead?
Basically the game would detect that the player wants to host a new multiplayer game and fire off a second fs2_open process with the -standalone switch. The player would then connect to this automatically and be set as the host, same as if they'd connected to a standalone on a separate computer. When the player wanted to quit, the game would send a message to the standalone telling it to shutdown.
The advantages are as follows :-
1) The multiplayer code instantly becomes more manageable. Currently we have several different possible options. The process we're running may be a client or a server. If the process is running the server there may be a player on it or it might be a standalone. If there is a player on it, they are the host. If the process is a client it also may or may not be the host depending on whether the server is or isn't a standalone.
The code frequently has to check which one we're dealing with and we have had lots of bugs caused by people not realising that things can be different when a game is on a standalone.
With this change the server never has a player on it, it's always a standalone, so we can remove any code that deals with a host on the server, making the server-side code much easier to deal with (We don't actually need to remove it immediately, but with this change it would be unreachable).
The client-side code already has to deal with a client being a host since that's exactly what happens when someone connects to a standalone for the first time, so we wouldn't need to make any client side changes.
2) Multiplayer testing of new features becomes much easier. Even when you play a multiplayer co-op on your own you'd now be playing as a client. So testing features for multiplayer would become as simple as switching the mission in FRED from singleplayer to co-op and replaying it. We instantly remove that whole class of bugs where something works on the server but doesn't work on the client because no one ever plays on the server any more. Admittedly we now have "Works in SP but not in Multi" issues but we've always had that, and now they're easier to reproduce.
Of course there are some possible downsides
1) I'm worried it might make it harder to debug the server side of things. Since the standalone is being launched by the code itself, we'd need some way to attach a debugger to it. Is it possible to have a second process do this automatically?
2) The standalone code is currently buggier than the standard multiplayer code. I'm thinking of adding this feature using a commandline switch for now so that people can still play multiplayer normally without having this issue. Eventually we'd want to remove the switch or we'd lose the benefits of a neater code.
3) The standalone only works on Windows currently. This solution would effectively lock Linux and Mac OS X out of hosting multiplayer games until they also have a standalone. I believe some work has been carried out on a wxWidgets port though. A daemonised standalone might be a much better solution though.
If anyone has any thoughts, Especially about problem 1) I'd like to hear them.
-
Issue 1) can be worked around, this is a solved problem others have faced.
http://sourceware.org/gdb/onlinedocs/gdb/Forks.html
http://stackoverflow.com/questions/15126925/gdb-debugging-child-process-after-fork-follow-fork-mode-child-configured0
-
The obvious solution to problem 1 would be to just run the standalone from a different VS instance with the standalone flag set under the assumption that any problems caused by the process being spawned by the host will be minor.
-
Removed: I misunderstood what karajorma was saying here.
-
sounds like a good idea to me, just to make the multi code simpler :)
chief1983 has been doing some work with Eli2's new standalone, hopefully that's not too far off making it into SVN so I don't think the lack of Linux/OSX hosting will be too big a deal.
As for the stats, I thought the fs2netd stats are the only "official" ones and there's already some mechanism for a standalone to send stats there?
edit: struckout the reply to Fury's question
-
What's the status of the
wx cross-platform standalone? I can take a look and see if I can put some time into it.
EDIT: I thought Eli2's cross-platform standalone uses wxWidgets, but E9's post below makes me think it uses something else.
EDIT 2: I really think we should aim for a single standalone code base for all platforms. Having different standalone code bases for different platforms sounds pretty :ick: to me. That'd mean two or more separate codebases to have to maintain, fix, develop, extend...
-
Frankly, this sounds like a really good idea (coming from a coder). If we can get this working on Windows, plus Eli2's web standalone which I remember testing briefly on OS X some time ago, then I will personally ensure that standalone builds work on at least Mac.
And having standalone working on Mac will likely fix most of the Linux issues too.
Happy to dig into what ever reason it is that has kept the standalone daemon Windows-only up until now.
-
Well we don't actually have a daemon really. The Standalone has a gui which must be invoked in order for it to do anything. Making it into a daemon would be really useful actually.
-
Ah yes, well then Eli2's webui is even more important!
-
2) Multiplayer testing of new features becomes much easier. Even when you play a multiplayer co-op on your own you'd now be playing as a client. So testing features for multiplayer would become as simple as switching the mission in FRED from singleplayer to co-op and replaying it. We instantly remove that whole class of bugs where something works on the server but doesn't work on the client because no one ever plays on the server any more. Admittedly we now have "Works in SP but not in Multi" issues but we've always had that, and now they're easier to reproduce.
Might have to be careful with this one. Some things seem to actually be processed on the host client and passed to the server then out to the clients. Can't remember what off the top of my head. I think the nebula code tried to do something like this but since there was no support for it on the standalone it crashed.
Also if your going this far taking out all the texture loading/unloading and particle stuff on the standalone might be a good idea.
And on a side note I saw the discussion about split screen in relation to this. It was possible at one time to do something like this but quit working/was removed a long time ago. Of course the input controlled both windows so it was really fun tring to circle fight yourself in testing. If I remember correctly you could actually go into the controll pannel after both games were launched and change one from joystick to mouse and you could controll one window with the joystick and the other with the mouse.
-
Once upon a time, there was a Qt, or wx, or some such standalone. This code has grown far too old to be of much use to us, but Eli2 has done a great deal of work on a WebUI based standalone. It integrates a tiny web server directly into the game binary, and serves up a small administration webpage that allows similar functionality to the Windows standalone at this point, save for that it's not 100% implemented yet. As coded, it only implements the WebUI on *nix platforms, leaving the Windows one intact. I see no reason to immediately clobber the Windows one as it's already separated, but we may consider removing it if we are happy enough with just the WebUI some day. I have had success compiling the standalone on Ubuntu so far, and FreeBSD should likely work just as well, but Xcode 3 has been giving me an odd error.
=== BUILD NATIVE TARGET code OF PROJECT FS2_Open WITH CONFIGURATION Debug ===
Check dependencies
CompileC build/FS2_Open.build/Debug/code.build/Objects-normal/ppc/stand_gui-unix.o ../../code/network/stand_gui-unix.cpp normal ppc c++ com.apple.compilers.gcc.4_0
cd /Users/cliff.gordon/fs2_standalone/projects/Xcode
setenv LANG en_US.US-ASCII
/Developer-3.2.6/usr/bin/gcc-4.0 -x c++ -arch ppc -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -D_DEBUG -DSCP_UNIX -DUSE_OPENAL -DAPPLE_APP -isysroot /Developer-3.2.6/SDKs/MacOSX10.4u.sdk -mtune=G5 -mmacosx-version-min=10.4 -gdwarf-2 -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/code.hmap -Wno-char-subscripts -F/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/Debug -F/Users/cliff.gordon/fs2_standalone/projects/Xcode/Frameworks -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/Debug/include -I../../code -IFrameworks/Ogg.framework/Headers -IFrameworks/Vorbis.framework/Headers -IFrameworks/Theora.framework/Headers -IFrameworks/SDL.framework/Headers -I/Developer-3.2.6/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenAL.framework/Headers -I/Developer-3.2.6/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/DerivedSources/ppc -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/DerivedSources -c /Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp -o /Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/Objects-normal/ppc/stand_gui-unix.o
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp: In function 'Container& split(Container&, const typename Container::value_type&, const typename Container::value_type&, split::empties_t)':
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:27: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:27: error: 'no_empties' was not declared in this scope
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp: In function 'bool webserverApiRequest(mg_connection*, const mg_request_info*)':
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:663: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:663: error: 'no_empties' was not declared in this scope
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:672: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:672: error: no matching function for call to 'split(SCP_vector<SCP_string>&, SCP_string&, const char [2], <type error>)'
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:701: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:701: error: no matching function for call to 'split(SCP_vector<SCP_string>&, SCP_string&, const char [2], <type error>)'
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:707: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:707: error: no matching function for call to 'split(SCP_vector<SCP_string>&, const std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >&, const char [2], <type error>)'
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp: In function 'void std_debug_multilog_add_line(const char*)':
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:801: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:801: error: 'no_empties' was not declared in this scope
CompileC build/FS2_Open.build/Debug/code.build/Objects-normal/i386/stand_gui-unix.o ../../code/network/stand_gui-unix.cpp normal i386 c++ com.apple.compilers.gcc.4_0
cd /Users/cliff.gordon/fs2_standalone/projects/Xcode
setenv LANG en_US.US-ASCII
/Developer-3.2.6/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -D_DEBUG -DSCP_UNIX -DUSE_OPENAL -DAPPLE_APP -isysroot /Developer-3.2.6/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -gdwarf-2 -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/code.hmap -Wno-char-subscripts -F/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/Debug -F/Users/cliff.gordon/fs2_standalone/projects/Xcode/Frameworks -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/Debug/include -I../../code -IFrameworks/Ogg.framework/Headers -IFrameworks/Vorbis.framework/Headers -IFrameworks/Theora.framework/Headers -IFrameworks/SDL.framework/Headers -I/Developer-3.2.6/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenAL.framework/Headers -I/Developer-3.2.6/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/DerivedSources/i386 -I/Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/DerivedSources -c /Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp -o /Users/cliff.gordon/fs2_standalone/projects/Xcode/build/FS2_Open.build/Debug/code.build/Objects-normal/i386/stand_gui-unix.o
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp: In function 'Container& split(Container&, const typename Container::value_type&, const typename Container::value_type&, split::empties_t)':
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:27: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:27: error: 'no_empties' was not declared in this scope
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp: In function 'bool webserverApiRequest(mg_connection*, const mg_request_info*)':
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:663: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:663: error: 'no_empties' was not declared in this scope
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:672: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:672: error: no matching function for call to 'split(SCP_vector<SCP_string>&, SCP_string&, const char [2], <type error>)'
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:701: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:701: error: no matching function for call to 'split(SCP_vector<SCP_string>&, SCP_string&, const char [2], <type error>)'
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:707: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:707: error: no matching function for call to 'split(SCP_vector<SCP_string>&, const std::basic_string<char, std::char_traits<char>, SCP_vm_allocator<char> >&, const char [2], <type error>)'
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp: In function 'void std_debug_multilog_add_line(const char*)':
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:801: error: 'split' is not a class or namespace
/Users/cliff.gordon/fs2_standalone/projects/Xcode/../../code/network/stand_gui-unix.cpp:801: error: 'no_empties' was not declared in this scope
Without access to the new stand_gui-unix.cpp file this probably won't make sense to any of you. I've attached an updated version of the WebUI against latest trunk, the autotools patch, and the Xcode3 patch. If anyone needs Eclipse I can dig it back out :P
The Xcode 3 patch is the complex version that adds mongoose and jansson as separate libs instead of compiling them directly into the code lib, to keep it separated. Either method broke Xcode3 during compiling stand_gui-unix.cpp though with the above error, so it doesn't seem to be related. I can do one for the Xcode4 project later, I plan on making a complex version of it as well and seeing if I have luck there. Might be the instigation I need to abandon Xcode 3 altogether.
edit: webui3.patch was broken, attached webui4.patch which should be working correctly. Also added Xcode4 patch that uses separate library setup and compiles.
[attachment deleted by ninja]
-
As to the original topic, I see one thing here. Currently the standalone does load all the game resources, doesn't it? So this would in fact double the resource load on the host computer, as opposed to the current methodology? Not sure if there's an easy way around that if we go down this route or not, just throwing it out there.
-
IIRC the standalone does load the models but it doesn't load the textures. So yes there would be an increased load on memory.
On the other hand this may possibly make some machines faster for multiplayer as the process doing the collision detection would now be different from the one actually running the game.
Might have to be careful with this one. Some things seem to actually be processed on the host client and passed to the server then out to the clients. Can't remember what off the top of my head. I think the nebula code tried to do something like this but since there was no support for it on the standalone it crashed.
Well the thing is that any bugs like that would still be problems now. They'll crash the standalone but not player hosted multiplayer. The reason bugs like that don't get fixed quickly is often because they're in areas of the code not familiar to the coders who work on multiplayer (like myself). Going down this route would definitely increase the priority of standalone bugs, which is not necessarily a bad thing. I think you'd agree with me that making it easier for any coder to test multiplayer should eventually result in much better multiplayer compatibility.
Obviously the first stage would be to implement this followed by heavy testing. Only after testing would I remove the ability to run multiplayer with the host on the server.
-
Something I'd like to see in the future, perhaps an evolution of kara's current proposal, is to have FSO spawn "host" and "client" threads for every game that is started, including singleplayer. If set up right, this should provide a common framework to allow features and bug fixes to be applied to both singeplayer and multiplayer without worry of breaking something, as well as allow for some exotic stuff such as split-screen play.
The host thread would take care of the AI and collision detection for all craft, and the client thread will process a degree of functions depending on its connection to the host thread. For example, if the client is on the same machine as the host, then the client doesn't need to process any collision detection, etc. and can just grab the physics results from the host. If the client is on the LAN or a fast internet connection, it would at least do some processing on objects in the immediate vicinity of the player and any of the player's weapons (like detecting if the player bumped into somebody or if the player's bullets hit something).
...I unfortunately don't have any fine details on how this would play out just yet, I've got a number of things going on at the moment that prevent me from fully focusing on designing this. :nervous:
-
Something I'd like to see in the future, perhaps an evolution of kara's current proposal, is to have FSO spawn "host" and "client" threads for every game that is started, including singleplayer. If set up right, this should provide a common framework to allow features and bug fixes to be applied to both singeplayer and multiplayer without worry of breaking something, as well as allow for some exotic stuff such as split-screen play.
The host thread would take care of the AI and collision detection for all craft, and the client thread will process a degree of functions depending on its connection to the host thread. For example, if the client is on the same machine as the host, then the client doesn't need to process any collision detection, etc. and can just grab the physics results from the host. If the client is on the LAN or a fast internet connection, it would at least do some processing on objects in the immediate vicinity of the player and any of the player's weapons (like detecting if the player bumped into somebody or if the player's bullets hit something).
...I unfortunately don't have any fine details on how this would play out just yet, I've got a number of things going on at the moment that prevent me from fully focusing on designing this. :nervous:
THIS.
Not that it would be easy, of course. You'd have to untangle and separate the various bits of code and make them thread-safe. For example, model collision detection code is heavily reliant on global variables. At least for now... ;7
-
Dunno about the rest, but I'll put here what I put on IRC.
As is, I won't touch multiplayer with a ten foot pole. It's complicated and there isn't a big enough multi audience to make me want to overcome it's complications. This method, however... giving me the ability to just switch to multiplayer mode and test my mission there? I would do that if it were that simple.
-
It literally would be as simple as changing the option in the Mission Specs Editor.
Hell you can actually do that now, it's just that it doesn't provide much useful testing since you're on the same process as the server.
-
It literally would be as simple as changing the option in the Mission Specs Editor.
Hell you can actually do that now, it's just that it doesn't provide much useful testing since you're on the same process as the server.
Lag testing could be done by forcing a specific update rate between the client and host instances, so you could simulate a crappy 56K connection... You could possibly also generate a noise waveform and apply it to the raw data.
-
I vaguely remember seeing that the game already has a way to simulate lag. Not sure if it works or not though.
-
:bump:
Okay, I've finally got the time I need to work on this but I'm having a little trouble deciding which is actually the best way to spawn the new process. However I do it, the process needs to be able to be identified from within FS2_Open and it also needs to be able to be shut down by FS2_Open.
In addition, I need some way of identifying which file to run. FRED identifies the FS2_Open .exe by simply looking at its own name and then spawning the a process with the same name except for FRED replaced by FS2_Open. That would work for Windows but I doubt it would work for Linux or Mac OS.
-
Are we speaking of simply relaunching our own process? If so then we could just use the commandline argument array passed to main which includes the path to the executed executable. You could simply use that if it works on all platforms. If it doesn't work then we can just use the respective OS APIs to get the path.
-
I'm talking about spawning a second process using the same command line plus -standalone.
-
Then I'm pretty sure that the first element of the command line array should work on all platforms.
-
Not sure if it's related, but just in case, I feel I should mention OSX has a nasty tenancy to suppress multiple instances of the same program by default. To get around it you have to have the system do it with the "open" command.
Something to do with the silly autosave and resume feature in osx.
-
That shouldn't be a problem at the process level — OS X is still POSIX.
-
There's definitely a way to do it on OS X. I'd press ahead getting Windows working first and we can then adjust for other platforms.