Author
|
Topic: Announcing network SuperMelee (was: Project ZOMG) (Read 34677 times)
|
Anthony
*Smell* controller
Offline
Gender:
Posts: 358
Star Control Lives!
|
What did you type in your arguments to play against yourself on 127.0.0.1?
|
|
|
Logged
|
|
|
|
Megagun
Enlightened
Offline
Gender:
Posts: 580
Moo
|
Well, with the game I played with Meep (won't say the outcome of the game. I don't want to spoil Meep's reputation), here's what I did:
--netport1=PORTNUMBER
Meep would then do something like --netport2=PORTNUMBER --nethost2=HOSTIPADDRESS
Optionally, either player can use --netdelay=NUMBER to set the netdelay. I believe the lowest netdelay setting will be used. Experiment with this a bit until you get it right.
Note: netport1 means settings for PLAYER 1, which is the BOTTOM PLAYER. IF you are hosting with netport1, set 'network player' on the BOTTOM PLAYER. Player 1 = bottom. Player 2 = top.
|
|
|
Logged
|
|
|
|
Anthony
*Smell* controller
Offline
Gender:
Posts: 358
Star Control Lives!
|
I keep getting the message "Top player: Connection closed"
Here are the arguments that I am using for the host and the client:
uqm.exe -C uqm -n content --addon remix --netport1=1337 For the host, the top player is "Network Control", and the bottom is "Human"
uqm.exe -C uqm -n content --addon remix --nethost2=127.0.0.1 --netport2=1338 For the client, the top player is "Human", and the bottom is "Network Control"
Even if I switch the network control and human, they just await a connection, and nothing happens. I know that this is still being testing, and I'm glad that I'm trying this out, so that I understand what needs to be done for netplay...
|
|
« Last Edit: October 28, 2006, 04:35:33 pm by batman4050 »
|
Logged
|
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
Yes, leave out the ports. You'll only need to ever specify the ports if your firewall doesn't allow port 21837 traffic, but does allow other ports, and you have no access to the firewall settings at all.
It is the maximum delay of the two sides that is used. If the gameplay is jittery, this usually means that the game is waiting for the remote input for a frame to arrive. By setting a delay, the input you send will only be processed that many frames later. So a higher delay means smoother play on bad connections, but less responsiveness of your ships. In my experience, a delay of more than 3 frames will cause the gameplay to suffer. Set the the delay as low as your connection will allow. Unless you're playing over a lan, you'll probably need a delay of at least 2. For me (from the Netherlands) to fOSSiL (in the USA) a delay of 3 frames worked nicely. As there are 24 frames in a second, each extra frame delayed will give the commands and extra 1000/24 = 42ms to arrive. Suppose you have a ping time of 200ms to the the remote party. This means it takes 200ms for a response to your ping packet to arrive, so it will actually take 100ms for a packet to reach the remote party. Divide this by the delay per frame gives you 100 / (1000/24) = 2.4. This is how many frames a packet will need to be delayed at the least for a smooth game. As you can only delay whole frames, you should set your frame delay to 3 in this case, which gives you 3*(1000/24) = 125ms. Note that a ping time of 200ms will usually mean an average ping time of 200ms. If some packets arrive later, you'll still encounter hickups. So it's better to set your frame delay so that it gives your commands some extra time. 125ms where the average time required is 100ms sounds good. Still, occasional stuttering may be unavoidable over long-distance connections.
But you don't really need to calculate all this. Just experiment. Let one player specify no input delay at all, and let the other player try with increasingly higher delay settings. As I said, the actual delay used is the maximum of the two.
In future versions, I'll probably have UQM calculate the required frame delay and set it automatically.
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Amusing factoid: if you set up player 1 in a UQM instance as a network host and player 2 as a network client connecting to the above host (in other words, have one copy of UQM talking to itself over the Net), it's impossible to start the game because it gets stuck waiting for remote game start confirmation. This is actually a good thing, as you can cancel at this stage and fix your settings.
In any case, I should be able to handle both in- and outbound UQM game connections (firewall settings check out); if anyone wants a shot at netplay UQM within an hour from now, PM me with a suggested configuration (connection settings, fleets, et.c.).
|
|
|
Logged
|
|
|
|
|
Anthony
*Smell* controller
Offline
Gender:
Posts: 358
Star Control Lives!
|
Thanks meep-eep. This is awesome. I was able to connect to myself.
If anyone wants to test out multiplayer, I'll be on Hamachi; it's a wicked VLAN program. check it out. http://hamachi.cc
Room: UQMultiplayer1 Password Fwiffo
EDIT: I played super melee with someone through Hamachi, and it was awesome! Although there was some lag, the experience was still just as great. So much fun. Again, good stuff meep-eep.
|
|
« Last Edit: October 29, 2006, 04:45:37 am by batman4050 »
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
I talked in the the IRC channel with your opponent, and you should not have any lag if you had set an input delay. With a link as good as yours, a delay of 1 would be enough, but 0, which you had, is pushing it.
Also, CVS now contains a fix for a loss-of-sync error with the Kohr-Ah Maurauder. It also has improved sync loss detection, which unfortunately makes it incompatible with earlier builds, so you won't be able to use it with people who are still running an older version. Snapshots are in the usual location.
And here's a little challenge for those who know C. What is wrong with the following piece of UQM code that could cause a network game to lose sync? (It didn't, but it could.)
SetVelocityVector (&AsteroidElementPtr->velocity, DISPLAY_TO_WORLD (((SIZE)TFB_Random () & 7) + 4), (COUNT)TFB_Random ());
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
|
|
|
Megagun
Enlightened
Offline
Gender:
Posts: 580
Moo
|
Hm. Don't think so.... Hmm... Maybe not. I think I have a content pack that enables the usage of SIS vs SIS in Melee (since I have a seperate UQMflagships EXE in my UQM folder)...
|
|
|
Logged
|
|
|
|
|
|
|